CH2. Application Layer

1. Priciples of network applications

 - Possible structure of applications

ㅁ	Client-server architecture Server : 1. always-on host 2. IP주소는 항상 고정된 값을 사용한다. 3. server farms for scailing(server farms : 여러개의 server를 두고 사용한다는 것을 의미). Client : 1. communicate with servers 2. may have dynamic IP address 3. client간에는 직접적인 통신이 불가능하다.

Pure P2P architecture   - 각각의 peer들이 server가 될수도 있고 client가 될수도 있다.  - 서버가 항상 켜져 있는 것이 아니다.  - 다른 peer들에거 서비스를 요청하고 그에대한것을 받는다. 또한 자신이 요청을 받고 요청받은 데이터를 넘겨줄수가 있다.  - IP는 항상 변하고, 항상 서로 연결되어 있는것이 아니다.

Hybrid of client-server and P2P - Skype  - voice-over-IP P2P application  - Centralized server : 자신의 IP와 타인의 IP를 서로 확인하여 연결을 시켜주는 역할을 한다.  - client-client connection : direct(not throuh server)

- Instant messaging  - P2P를 이용하는 유저간의 chatting  - presence detection/location centralized

 - Process communicating

Process : host에서 실행되고 있는 program을 의미한다.

-> 같은 host에서 실행되는 process간의 통신은 OS에서 제공하는 내부 통신을 이용한다

-> 다른 host에서 실행되는 process간의 통신은 message를 교환을 한다.

 

 - Socket

socket interface : 어플리케이션 레이어와 Transport 레이어 사이에 존재하게 되는 것으로 소켓을 통해 프로세스들은 message를 주고 받게 된다.

 

 - addressing 

 -> 각각에 맞는 프로세스로 들어가기 위해서 IP주소만있어서는 안된다. (한 host에 여러가지 process가 실행이 되기 때문이다.)

 -> port #을 추가로 알아서 해당 host에서 어떤 process와 통신을 해야 하는지를 알려주게 된다.

example -> transport layer에서 자신의 IP를 구분하기 위해서 IP address를 demux key로 사용을 하게 된다. -> TCP/UDP로 나누기 위해서는 IP header에 protocol 부분이 demux key가 되게 된다. -> 받은 message통신을 원하는 process로 보내기 위해서는 port #이 demux key가 되게 된다.

 - App-layer protocol

-> message 교환의 방식 : ex) requnest&response message

-> Syntax of message : message안에 field가 무엇이 있고 field가 어떻게 구분이 되어지는가

-> Semantics of the fields : 각각의 field가 어떤 의미를 가지고 있는가

-> Rules for when and how processes send & respond to messages

 

 - Internet Transport Protocol Services

TCP Service  -> 신뢰 가능한 protocol이다  -> flow control이 가능하다 : receiver가 받을수 있는 데이터 보다 많은 양을 보내지 않는다.  -> congestion control : network내에서 처리가능한 양보다 더 많은 데이터를 보내지 않는다(router등에 있는 사용할수 있는 대기 queue를 넘지 않는 양만큼 보낸다.)  -> Connection oriented : client와 server사이에서는 무조건 connection과정이 필요가 하다.

UDP Service  -> Unreliable data trasfer between sendding and receiving process -> does not provide : reliability, flow control, congestion, timing, bandwidth, guarantee or connection setup

 

---

 

2. Web and HTTP

 - HTTP(Hyper Text Trasfer Protocol) overview

-> Web's application layer protocol

     : Web clients가 어떻게 Web server로 페이지를 요청하고, Web server가 Web clientdprp 어떻게 page를 보내는지에 대해 정의한다.

-> Client/Server model

     => client : HTTP protocol을 이용하여 page를 요청하고 page를 받아 Web object를 보여주게 된다.

     => server : HTTP Protocol을 이용하여 요청받은 page를 client에게 보내는 역할을 한다. 

-> HTTP는 Stateless protocol이다.

     : 동일한 요청에 대해 서버는 저장을 하지 않는다(이전 정보를 저장하고 있지 않다, 한번 directory를 옮긴후에 서버는 다시 초기화 된다.)

-> HTTP는 TCP를 사용한다 : connection oriented로 로스없이 데이터를 전송이 가능하게 한다.

-> HTTP는 80번 port #을 사용한다(well-known port #를 이용한다.)

 

 -HTTP Connections

-> Non-Persistent HTTP connections

Non-Persistent HTTP connections -> 한번의 connection에 대해 하나의 object가 전송되어진다. -> HTTP/1.0 를 사용한다. -> TCP connection연결을 병렬로 여러개를 연결하여 여러 object를 보내게 된다. (hand shaking과정이 한번에 여러개 일어남으로 시간을 줄일수가 있다, connection수가 늘어나는 것이기 때문에 server의 부담이 커지게 된다.)

-> Persistent HTTP connections

Persistent HTTP Connections -> 한번의 TCP connection에서 여러개의 object를 요청하고 전송할수가 있다. (server는 계속해서 연결을 유지하고 있게 되고, 그 결과 같은 client/server사이에서 message를 계속 주고 받을수가 있게 된다.) -> HTTP/1.1 uses persistent connections in defalut mode.

Persistent Without Pipelining -> client는 이전의 요청에 대한 response가 와야지만 새로운 요청을 server로 보낼수가 있다. ->하나의 데이터를 주고 받는데    1RTT만큼이 걸리게 된다.

Persistent With Pipelining -> 이전의 request에 대한 response가 오지 않더라도 request를 보낼수가 있다. -> defaulut in HTTP/1.1

 - HTTP Message

-> HTTP message 에는 두가지 타입이 존재하게 된다.

• HTTP Request Message

General format of Request message -> method : 어떤 것을 할지 정한다. -> URL : 어디에 요청을 할것인가 -> Version : HTTP의 버전 -> Header lines : 각각의 header 의이름과 값들이 들어가는 부분 -> entity body

-> Method of Request line in a request message

      (Web 구현의  architecture중 하나인 RESTful 중점)

     CRUD제공 : create (post), read (get), update (put), delete (delete)

    => POST : sends some information from the client to the server

    => GET : Request a document from the server

    => PUT : Sends a document from the client to the server

    => DELETE : Removes the web page

 

-> Header names of Reques line in a request message

    => User-agent : Identifies the client program

    => Host : The host and port number of the resource being requested

    => Cookie : Return the cookie to the server (HTTP가 stateless임을 보완하기 위해 등장한 개념이다.)

등이 있다.

 

• HTTP Response Message

General format of Response message -> Version : response하는 쪽의 HTTP의 version을 의미 -> Status Code : 3자리 십진수로 request에 대한 응답에 대한 상태를  표현한다. -> Status Phrase : Status Code에 대한 간단한 설명을 제공한다.   1XX : infromational  2XX : Success (ex. 200 OK 요청을 받고 적절히 데이터를 보냄)   3XX : Redirection (ex . 301 Moved Permanently : 요청한 데이터가 다른 위치로 옮겨짐을 의미한다.) 4XX : Cleint Error(client쪽에서의 문제)     (ex. 400 Bad Request : 요청상에 syntax error의 발생            404 Not Found : 요청한 데이터가 server에 존재하지 않는다.) 5XX : Server Error

-> Header name in Response Message

     => Set-Cookie : The server asks the client to save a cookie

     => Content-Length : Shows the length of the document

     => Content-Type : Specifies the media type

     => Location : To ask the client to send the reques to another site

등이 존재한다.

 

 - User-server State : cookies

-> 쿠키는 과거의 event에 따라 다르게 행동하게 해주기 위해서 사용디 되는 것이다. (ex. 위메프등의 추천품목)

-> HTTP는 Stateless Protocol로 client에서 오는 요청에 대한 응답을 보낸뒤에 바로 초기화 된다. => client에 대한 정보를 알수가 없다.

-> Issues to statelsee behavior

     => 접속한 user가 누군지 알수가 없다.

     => user의 접근을 제대로 제한할수가 없다.

-> Cookie technology

     => server가 새로운 유저를 파악했을때 response데이터에 Set-Cookie header (해당 user를 구분하기 위한 ID)를 설정하여 보낸다.

     => 클라이언트는 Set-Cookie 헤더의 정보를 디스크에 저장하고 동일한 서버에 대한 요청할때 사용이 된다.

-> Cookie는 그냥 데이터일뿐 실행가능한파일은 아니다. 

-> Privacy의 문제가 생긴다.(개인용 컴퓨터에서만 사용할것을 권장한다.)

-> Four component of cookie

1. Set-cooke header line in the HTTP response message 2. Cookie header line in HTTP request message 3. cookie fine kept on user's host (client쪽에 저장) and managed by user's browser 4. back-end database at Web site (해당 cookie에 대한 entry를 만들고 정보를 저장한다.)

 - Web caches(proxy server)

Web cache/Proxy server -> server와 client사이에 존재하는 server로  -> 모든 request가 web cache로 먼저 가도록 구성이 되어야 한다.     => web cache에 정보가 있을때          1. web cache로 request한다.          2. web cache에서 response를 해준다.     => web cache에 정보가 없을때          1. web cache에 request를 한다.          2. web cache는 server로 client가 원하는 정보를 request          3. server는 web cache로 해당 데이터를 response          4. web cache는 client에게 response해준다

-> web cache에 원하는 정보가 있다면 response 시간을 줄일수 있고, server의 traffic도 줄일수가 있다.

-> proxy server에 정보가 없으면 시간이 더 걸리게 된다.

 

 - Web Cache Challenge

- Problem Cache에 있는 데이터가 server의 데이터와 다를때 문제가 생기게 된다. -> cache에 있는 데이터가 옛날것이라면 server에서 받아와 보내도록 한다.    - Solution  If-modified-since header의 조건에 따라 cache의 값을 받을것인지 server에서 값을 새로이 받을 것인지 결정을 한다. -> server에 last modified date가 있게 되고 그 날짜보다 If-modified-since날짜가 더 옛날이라면 cache server의 데이터를 바꾼후 보낸다.