네트워크 - Application Layer

• Network Application
  
  
  
  
• Application architectures
  
  - Client-Server
   
  
  - Peer-to-Peer (P2P)
   
  
  - Hybrid of client-server and p2p
   
  
  
• Processes communicating
  : 같은 호스트간의 프로세스간 통신은 IPC(Inter-process communication)
  : 다른 호스트간의 통신은 Server process, Client process 로 이루어짐
  
  - Sockets
   : 발신자/수신자에게 메세지를 송수신하는 프로세스
   : 일종의 "door" 역할
   
  
  - Addressing processes
   : 수신 메세지를 받기위해 프로세스는 반드시 identifier를 가져야한다.
   : host는 유일한 32-bit(IPv4) IP address를 가진다.
   : identifier = IP address + PORT numbers
  
  
• Application protocol defines
  : Types of messages exchanged (request, response)
  : syntax, semantics
  : 프로세스들이 언제, 어떻게 메세지를 주고 받는지에 대한 규칙
  
  

• Web and HTTP
  : Web page 는 HTML file, JPEG image, Java applet, audio file 등의 객체들로 구성, HTML-file이 베이스
  : 각 객체들은 자체 주소(URL)을 가지고 있음
  
  
  
  - HTTP
   : HyperText Transfer Protocol
   : 웹 어플리케이션 레이어 프로토콜
   : client/server model
   : client? 브라우저가 requests, receives 한 웹 객체를 디스플레이 함
   : server? web server가 요청에 대한 응답으로 객체를 전송
   : http는 stateless protocol -> 서버는 클라이언트의 과거 요청을 유지하지 않음
   : RTT? RoundTripTime으로 클라이언트 요청이 서버로 응답이 오는 시간

    
  
  

    ■ TCP 사용
      1. 클라이언트는 TCP Connection을 초기화 함(소켓을 만듦), PORT 80
      2. 서버는 클라이언트로부터 TCP Connection을 받음
      3. 브라우저(HTTP clinet)와 웹서버(HTTP server)간 HTTP messages를 주고 받음
      4. TCP Connection 종료
  
    ■ Nonpersistent HTTP
      : 하나의 객체만 TCP를 통해 전송
      : HTTP 1.0에서 사용
      : Response time? total = 2RTT + transmit time
      : 객체(파일, 이미지 등)마다 2RTT와 TCP 연결에 대한 오버헤드 발생
      
  
  

    ■ Persistent HTTP
      : 다수의 객체를 TCP를 통해 전송
      : HTTP 1.1에서 default로 사용
      : 서버는 응답을 보낸 후에도 Connection을 열어둠
      : client는 참조 객체를 마주했을 때 요청을 보냄
      : 객체마다 1RTT의 오버헤드가 감소함
  
    
  
  
          :3RTT + 2transmit time                      :2RTT + 1transmit time
  
  
  - HTTP request message
  
      
    ■ Header (출처 : http://coffeenix.net/doc/network/http_1_0_vs_1_1.html)

  분 류	Massages	Header	설    명	지 원 버 전		생략여부
  				HTTP1.0	HTTP1.1
  Request	Requst-Line	Method※5	GET,POST,HEAD	○	○
  			OPTIONS,PUT,DELETE,TRACE	×	○
  		Request-URI	요청 데이터의 절대 주소나 상대주소. ex)http://www.isoft.co.kt/index.html or /test/helloworld.html	○	○
  		HTTP-Version	HTTP" + 0.9∼1.1(해당 프로토콜)	○	○
  	Request-Header	Authorization	사용자 인증정보 - 사용자 ID와 암호가 함께 Base64로 인코딩※6 ex)Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==	○	○
  		From	자원의 생성자나 웹마스터의 전자우편 주소 ex)From: psycho@isoft.co.kr	○	○
  		If-Modified-Since	GET 사용시-헤더 필드에 지정된 날짜보다 나중 자원만 전달(케시일자검색) ex)If-Modified-Since: Tue, 15 Nov 1994 12:45:26 GMT	○	○
  		Refer	한페이지에서 다른페이지를 요청할 때 (링크시) 이전 페이지 주소제공 ex)Referer: http://www.w3.org/hypertext/DataSources/Overview.html	○	○
  		User Agenter	browser 정보 ex)User-Agent: MyWebBroswer/0.5	○	○
  		Accept	클라이언트의 사용가능 미디어타입 ex)Accept: text/*, text/html, text/html;level=1, */*	×	○
  	(Content  Neogotation)	Accept-Charset	클라이언트에서 사용할 수 있는 문자 집합(생략시 모두인식) ex)Accepr: iso-8859-1, unicode-1-1	×	○
  	(Content  Neogotation)	Accept-Encoding	클라이언트에서 제공되는 인코딩 방법(압축) ex)Accept-Encoding: compress, gzip	×	○
  		Accept-Language	클라이언트가 인식할 수 있는 언어(우선순위가능) ex)Accept-Language: da, en-gb;q=0.8, en;q=0.7(독일어, 영국영어, 영어)	×	○
  		Host	서버의 기본URL(하나의 IP주소에 여러개의 이름을 가진 멀티 서버를 지원) ex)www.w3.org	×	○	×
  		If-Match	ETag값 비교-Method수행-(PUT 메소드:해당header무시),다르면 402에러발생 ex)If-Match: "0-556-343b9e36"	×	○
  		If-None-Match	ETag값 비교, 다를때-Method수행-(If-Match와 반대),같을 때 에러 ex)If-None-Match: "0-556-343b9e36","0-1e4-34367116"	×	○
  		If-Range	클라이언트 캐시 정보를 업데이트 정보 (ETag or Date 비교)	×	○
  		If-Unmodified-Since	헤더값에 지정된 날자로부터 수정이 없는경우 Method를 수행 ex) If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT	×	○
  		Max-Forwards	이 메시지가 거쳐 갈수 있는 최대 Proxy의 개수를 지정 ex)Max-Forwards: 7	×	○
  		Proxy-Authorization	비공개 프록시 서버 유저인증을 위한 코드	×	○
  		Range	자원의 일부분만 받을때(이어받기기능) 받을범위 지정 ex)bytes=0-499            : <- 0~499byte를 얻고자 할 때.	×	○

    ■ Method
  
     
  
  

    ■ GET vs. POST
     : GET? URL 필드를 이용하여 업로드
     : POST? entity body를 이용하여 업로드
     : GET은 해당 요청을 몇번을 수행해도 해당 요청에 대한 결과가 계속 동일하게 돌아오는 것을 의미하며, POST는 해당 요청이 수행되면 서버에서 무언가 바뀌고, 동일한 결과가 돌아오는 것을 보장할 수 없다는 것을 의미한다.
     : POST의 경우 GET과는 달리 쿼리스트링(query string)의 글자 수 제약이 없으며, 파일업로드 등의 동작이 가능하다. 그리고 POST의 경우 쿼리스트링이 URL에 포함되지 않기때문에 user에게 파라메터 값 등을 덜 노출한 상태로 요청이 가능하다. 하지만 결국 HTTP 요청은 SSL을 이용하는 https가 아닌경우 plain text로 이루어게되고, 그러다보니 요청을 열어보면 쿼리스트링이 동일하게 보이는것은 마찬가지라 특별히 보안상 더 뛰어나다고는 말하기 힘들다.

  GET 요청은 브라우저에서 캐시를 할 수 있다. 글을 작성하는 요청인데 GET 방식으로 글내용과 제목을 받아서 서버로 전송한다면, 해당 GET 요청과 그에 대한 응답이 브라우저에 의해 캐쉬가 되었다가 다시 사용될 우려가 있다. 이 경우 캐쉬에의해 자동으로 동일한 글을 또 작성하는 동작이 서버에서 발생될 수 있는데 이것은 심각한 오류이다. 검색봇(크롤러)으로 인한 문제 발생 구글이나 네이버의 검색봇(bot 혹은 crawler)들이 웹페이지 수집을 위해 해당 웹서버에 GET 요청을 할 수 있다. 이때 이러한 봇의 요청에 의해 게시판에 엉뚱한 데이터로 글이 작성되어 올라간다던지, 서버쪽의 데이터가 바뀐다면 당황스러운 일들이 발생할 가능성이 크다.  출처: http://www.letmecompile.com/get-post-%EB%B0%A9%EC%8B%9D-%EC%B0%A8%EC%9D%B4%EC%A0%90/

  
  

  - HTTP response
  
      
  

    ■ Header (출처 : http://coffeenix.net/doc/network/http_1_0_vs_1_1.html)
  

  분 류	Massages	Header	설    명	지 원 버 전		생략여부
  				HTTP1.0	HTTP1.1
  Response	Status-Line	HTTP-Version	HTTP" + 0.9∼1.1(해당 프로토콜)	○	○
  		Status-Code	수신상태코드-(4Page의 표참조.)	○	○
  		Respon-Phrase	수신 상태코드에 대한 간략한 설명-(4Page의 표참조.)	○	○
  	Response-Header	Location	요구한 정보 실제 위치. 옮겨지거나 다를경우-정보주소가 실제 위치 정보. (redirection,forwording 단, 절대주소만 가능.)	○	○
  		Server	서버 프로그램의 이름과 버전 정보 ex)Server: Apache/1.3a1	×	○
  		WWW-Authenticate	사용자 인증이 필요한 자원을 요구시, 필요데이터와 서버가 제공하는 인증 방식 ex)WWW-Authenticate: Basic realm="아이 소프트"	×	○
  		Age	요구후 원 서버(origin Server)에서 응답생성하지까지의 시간(초단위)	×	○
  		Proxy-Authenticate	서버가 프록시 서버일 경우 유저 인증을 요구하기 위한 헤더이다.	×	○
  		Public	서버에서 지원 가능한 Method의 리스트(제한의 의미는없음) ex)Public: OPTIONS, MGET, MHEAD, GET, HEAD	×	○
  		Retry-After	503 에러시 -몇초(시간)후에 다시 요구 메시지를 보내라는 정보 ex)Retry-After: Fri, 31 Dec 1999 23:59:59 GMT(Time)    Retry-After: 120   (Second)	×	○
  		Warning	상태코드와 응답 구문에 추가적인 경고	×	○
  		Vary		×	○

  
    ■ Status codes (출처 : http://coffeenix.net/doc/network/http_1_0_vs_1_1.html)

  1xx: Informational -  요구메시지를 받은 후  연결 중 작업할 때.	2xx: Success -  요구메시지를 제대로 받았을 때.	3xx: Redirection -  요구메시지를 수행하기 위해  다른 작업이 필요할 때.	4xx: Client Error -  요구 메시지의 형식이 틀리거나  빠진 부분이 있을 때.	5xx: Server Error - 서버에 문제가 있을 때.
  100 Continue	200 OK  성공처리	300 Multiple Choices  (실제 발생하지 않음)	400 Bad Request  요구가 올바르지 않음	500 Internal Server Error  예기치 못한 서버처리오류
  101 Switching Protocols	201 Created  요구에따라 새로운자원생성(PUT)	301 Moved Permanently  URL이 확정적으로 옮겨짐	401 Unauthorized  사용자 인증이 필요	501 Not Implemented  요구에 대한 지원불가  (transfer-Encoding)
  	202 Accepted  요구를 이해하였으며 진행중	302 Moved Temporarily  URL이 임시적으로 옮겨짐	402 Payment Require	502 Bad Gateway  게이트웨이·프락시의 응답오류
  	203 Non-Authoritative Information	303 See Other	403 Forbidden  요구는 이해하나 수행거절(PUT)	503 Service Unavailable  서버부하로 응답불가
  	204 No Content  요구자료에 정보가 없음(empty)	304 Not Modified(If-Modified-Since)  수정날짜에 수정되지 않음	404 Not Found  요구한 파일이 없음	504 Gateway Time-out
  	205 Reser Content	305 Use Proxy	405 Method Not Allowed  허락된 메소드가 아님	505 HTTP Version not supported  (요구를 무시할 수 있음..??)
  	206 Partial Content		406 Not Acceptable
  			407 Proxy Authentication Required
  			408 Request Time-out
  			409 Conflict
  			410 Gone
  			411 Length Required
  			412 Precondition Failed
  			413 Request Entity Too Large
  			414 Request-URI Too Large
  			415 Unsupported Media Type

  
  - Cookies
   : server는 response를 보내고 나면 그 client는 잊어버린다. 웹사이트가 user를 구별하기 원하거나, user access를 제한하기를 원한다면?
   : cookies에는 그 user를 위한 identifier가 담겨있다.
   1. set-cookie header 를 HTTP response message에 포함
   2. cookie header는 request message에 포함
   3. cookie 파일은 user의 host에 계속 있고, user의 브라우저에 의해 관리된다.
   4. Back-end Database는 웹 사이트에 있다.
   : 세션유지에 사용
  

   Persistent Cookie: 브라우저를 종료해도 사용자의 하드드라이브에 저장. 만료시기가 되면 삭제
   Session Cookie: 웹 클라이언트(IE) CASH에 임시 저장. 삭제 시기는 서버에서 만료되면 삭제

  
    
  
  - Session
  : 사전적 의미로 "시간"을 의미
  : 클라이언트와 웹 서버간에 통신 연결에서 두 개체의 활성화된 접속을 뜻함
  : 클라이언트가 웹서버에 요청하여 처음 접속하면 JSP나 ASP 엔진은 요청한 클라이언트에 대하여 유일한 ID를 부여하게 되는데 이 ID를 세션이라 부름
  : 세션 ID를 임시로 저장하여 페이지 이동 시 이용하거나, 클라리언트가 재접속 했을 때 클라이언트를 구분할 수 있는 유일한 수단
  : 각각의 클라이언트마다 고유의 ID부여, Session 객체들마다 저장해 둔 Data를 이용, 클라이언트 자신만의 고유한 페이지를 열어놓아서 생길 수 있는 보안상의 문제 해결 능력
  
  

  - Session vs. Cookie
   : Session은 서버 쪽에 정보를 저장하고, 쿠키는 클라이언트 쪽에 정보를 저장한다는 것이 가장 큰 차이점
  
  - Web caches(proxy server)
   : 클라이언트 요청에 대한 응답시간을 줄이고, 트래픽을 줄이기 위해 사용
   : cache 되지 않은 객체에 있어서는 낮은 성능, 또 cache 되어 있는 객체가 최신의 것이 아닐 수 도 있다. (해결 방안으로 If-Modified-Since)

    
  
  

• FTP
  : File Transfer Protocol, RFC 959
  : 다른 host로부터 혹은 다른 host로 file을 전송할 때 사용하는 프로토콜
  : stateful protocol
  : client - server model
  : transport protocol로 TCP 사용, FTP server는 PORT 21로 control connection(out-of-band), client는 PORT 20로 data connection
  : 암호화가 필요하여 최근에는 SFTP나 FTPS로 대체

    
  
  

• Electronic Mail
  : 주요 3가지 컴포넌트로 user agents, mail servers, SMTP(Simple Mail Transfer Protocol)로 구성
  : user agents? mail reader, mail을 읽고, 편집
  : mail servers? mailbox + message queue + SMTP
  
   
  
  : SMTP? mail server 사이에서 메시지 전달을 위해 적용되는 프로토콜
  : transport protocol로 TCP 사용, PORT 25
  : persistent connection(여러 메시지를 하나의 TCP connection에서 전송 가능)
  : handshaking(greeting) -> transfer of message -> closure
  
  

  
  
  - HTTP vs. SMTP
   : HTTP 1.1과 SMTP 둘다 persistent connection
   : 둘다 ASCII 커맨드, status code를 가짐 
   : HTTP는 pull로 client가 요청으로 정보를 끌어옴, SMTP는 push로 요청하지 않아도 server가 mailbox까지 정보를 줌.
   : HTTP는 각 개체가 캡슐화, SMTP는 한 msg안에 여러 객체가 담긴다.
  
  - Mail access protocols
   : POP? Post Office Protocol, TCP 사용, download-and-keep, stateless across sessions
   : IMAP4? Internet Mail Access Protocol, 메세지 ID와 폴더 이름 간 매핑하여 user에게 접근 허가, user stateful across sessions
   : HTTP? gmail, naver 등
   
  
  

• DNS
  : Domain Name System
  : IP 주소와 Name의 mapping가 필요함 -> name-address resolution
  : hostname을 ip주소로 변환, host aliasing, mail server aliasing, load distribution
  : UDP/TCP 둘 다 사용가능하지만 주로 UDP 사용, PORT 53
  : 트래픽, single point of failure, 거리, 확장성 등의 문제로 중앙 집권 구조로 구현하지 않고, 분산 데이터베이스로 많은 name server의 계층형태로 구현
  
  
  
  

  : www.amazon.com의 ip 주소를 얻는 과정
  1. client가 root server로 com DNS server를 찾기위해 query를 보낸다.
  2. client가 com DNS server로 amazon.com DNS server를 찾기위해 query를 보낸다.
  3. client가 amazon.com DNS server로 www.amazon.com의 ip 주소를 얻기 위해 query를 보낸다. -> 주소의 역순으로 접근하면서 ip주소를 찾아감
  : Root DNS server : 13개 (A~M) 세계적으로 존재
  : Top-level domain (TLD) servers? com, org, net, edu, etc, kr, uk, fr, ca, jp 등
  : Authoritative DNS servers? 어떤 단체에 대한 DNS 실제적인 IP주소
  : Local Name Server? 엄격한 계층구조가 아닌 각 ISP(default name server)를 하나씩 가지고 있음, host가 DNS query를 생성하면 query가 DNS server로 전송, 마치 프록시처럼 계층적으로 query 전달
  : caching and updating records
  
  - DNS name resolution
  

    
  :iterated query                                        :recursive query
  
  

• P2P
  
  
  - BitTorrent
   : File은 256KB chunks로 쪼개짐
   : peer joining torrent: 시간이 흐름에 따라 chunk가 쌓인다. tracker로 등록하여 주번 peer list를 얻음
   : 다운로드 하는 동안 peer는 chunk를 다른 chunk부터 요청하여 받음, 가장 귀한 chunk부터 요청하여 받음)
   : Free Riding 방지 -> Tit-for-tat -> 많이 주는 쪽을 top-four providers로 선정 
  
  
  - Centralized index
   : peer들의 정보(ip, content)를 중앙서버에서 찾는 구조
   : single point of failure, 병목현상등의 문제 발생

   
  - DHT
   : Distributed Hash Table = Distributed P2P database 
   : DB는 (id, value) pairs 를 가짐, 각 peer 들은 query를 이용하여 (key, value) peers을 얻어낼 수 있음
   : Shortcuts(peer를 찾는 가장 짧은 경로), Peer Churn(Peer가 떠날 경우 successor를 새로 지정)
    
  
  

• Summary