[컴퓨터네트워크] CH2. Application Layer (#2)

HTTP connection establishment

1. Non-persistent HTTP

개요

1a. Http 클라이언트가 HTTP 서버로 TCP 연결을 initiate, 시작한다. (www.someSchool.edu on port 80)
1b. HTTP 서버가 TCP 연결을 기다린다. 연결을 "accepts" 하고 클라이언트에게 알린다
2. HTTP 클라이언트가 TCP 연결 소켓을 통해 URL 정보가 포함된 request message를 전송한다.
메시지는 클라이언트가 "someDepartment/home"에서 원하는 object가 뭔지 적혀있음
3. HTTP 서버는 request message를 받고 response message를 구성한다.
여기엔 요청받은 object가 포함되고, 이 메시지를 소켓을 통해 전송한다.
4. HTTP 서버가 TCP connection을 닫는다(close)
5. HTTP 클라이언트는 html file을 포함한 response message를 받고, 이 html을 사용자에게 보여준다.
Html 파일을 구문분석(parsing) 해서 10개의 참조된 jpeg objects를 찾는다.
6. 각 10개의 jpeg objects에 대해 1-5 단계를 반복한다.
(10개의 분리된 각각의 연결을 열어서 parallel하게 진행)

TCP connection은 다음과 같은 resource를 필요로 함

• port number
• TCB (look-up table)
• Send buffer
• Receive buffer

Response Time

RTT(definition) : 작은 패킷이 client로부터 서버로 갔다가 다시 돌아오는데 소요되는 시간

• HTTP Connection response time
  1. TCP connection을 시작하는데 1RTT
  2. TCP connection을 establishment하고 HTTP request하는데 걸리는 시간 1/2RTT
  3. 요청받은 파일을 전송하는데 걸리는 시간 1/2RTT + transmission time
• 즉 non-persistent HTTP response time = 2*RTT + file TX time

2. Non-Persistent vs Persistent

Non-Persistent HTTP issue

1. response를 보내고 나서 서버가 connection을 close함.
   • 그래서 한 object당 최소 2 RTTs가 걸림
   • 각 TCP connection마다 OS overhead가 발생함 (간접적인 처리 시간 · 메모리)
   • 브라우저는 referenced object를 가져오기 위해서 병렬적으로 TCP connection을 연다.
2. Shortcomings (결점)
   • 모든 obj마다 새로운 TCP connection을 열기 때문에 그 때마다 client와 server 양 쪽에 새로운 버퍼와 변수들이 필요함
   • 새로운 TCP connection을 열 때 마다 additional delay가 발생함.

Persistent HTTP

1. sending response가 끝난 이후에도 connection을 열린 채로 내버려둠
   • 이어지는 HTTP messages가 같은 client/server 사이의 open connection으로 왔다 갔다 함
   • 클라이언트는 referenced object를 발견하자 마자 request를 보낸다
   • 참조된 모든 object에 대해 최소 1 RTT !

HTTP Multiplexing : 요청을 한 번에 보내고 답변을 하나씩 순서대로 받는다.

HTTP server architecture

1. Single-Threaded Web Server

• 요청을 보내면 main thread에서 response 를 보냄. 다른 요청을 보내서 응답을 받으려면 그 이전의 것이 처리 완료 되어있어야 함

2. Multi Threaded Web Server

• 요청을 보내면 main thread에서는 connection만 하고 worker thread를 하나 파서 그 쪽에서 응답을 처리하고 thread를 닫음.
• 여러 요청이 오면 thread가 여러개 열려서 병렬적으로 처리 가능
• 즉, main thread는 request의 handling만 집중하고, worker thread에서 Data transfer을 관리한다.

3. Thread Pool Web server

• worker thread를 열고 닫는게 아니라 고정된 thread의 pool 안에서 재사용 한다. (destroy X)
• request들을 linked list로 묶어서 관리하고, worker thread에서 하나씩 응답할 때마다 해당 request를 리스트에서 지우면서 관리한다.

HTTP message formats

1. Request message

• ASCII

• \r = carriage return character = cr
• \n = line-feed character = lf

Uploading Form Input

1. POST method
   • Web page는 보통 form input을 포함하고 있다
   • input은 entity body 안에 담겨서 server에 업로드 된다.
2. URL method
   • GET method 를 사용한다
   • input은 request line의 URL Field에 담겨 업로드 된다.
     ex. www.somesite.com/animalsearch?monkeys7banana

Method Type

1. HTTP/1.0
   • GET
   • POST
   • HEAD
     • 서버에게 요청된 object를 응답없음으로 놔두라고 요청함(?)
2. HTTP/1.1
   • GET, POST, HEAD
   • PUT ; entity body에 있는 파일을 url field에 있는 특정 경로에 업로드한다
   • DELETE ; url field에 있는 특정 파일을 지운다.

2. Response message

HTTP Response Status Code

• Status code 는 response message의 첫번째 line에 있음
• 200 OK
  : 성공적으로 요청했고, 이 메시지에 요청한 object가 담겨 있다.
• 301 Moved Permanently
  : 요청한 object가 이동되었다. 이 메시지에 새로운 위치를 보내주겠다. (Location : )
• 400 Bad Request
  : Request 메시지를 server가 이해하지 못했다
• 404 Not Found
  : 요청한 문서가 이 서버에서 찾을 수 없다.
• 505 HTTP Version Not Supported.

Cookies ; To Keep "STATES"

Recall : HTTP는 연결 정보를 저장하지 않는다.

• 서버는 모든 request를 처음 받는 request로 간주한다. ( 이전 데이터가 전혀 없으니 모르는게 당연 )
• 그렇다면 맞춤형 광고는 어떻게 나의 관심사를 파악했을까?

-> 많은 웹사이트가 쿠키를 활용한다.

4가지 구성요소가 있다

1. HTTP response message의 Cookie header line
2. 다음 HTTP request message의 Cookie header line
3. 사용자의 호스트에서 보관하고, 사용자의 브라우저에서 관리하는 쿠키 파일.
4. 웹 사이트에 있는 백엔드 데이터베이스

예시 :

1. 수잔은 언제나 인터넷을 PC로 들어간다
2. 어떤 특정한 이커머스 사이트에 처음 접속한다
3. 사이트에 initial HTTP requests가 도착하면 사이트는 다음을 만들어낸다.
   • unique ID
   • 백엔드 데이터베이스에 ID에 대한 entry

1. What cookies can be used for :

• Authorization
• Shopping carts
• Recommendations
• User session state (Web e-mail)

2. How to keep "state"

• Protocol endpoints : 여러 transactions에 대해서 sender/receiver의 상태를 유지한다.
• Cookies : http message가 state를 운반(?)함

3. Cookies and privacy

• 쿠키는 당신에 대한 많은 정보를 사이트에게 제공한다
• 특히 사이트에 이름과 이메일을 제공할 수도 있다.

Web cashing (Proxy Server)

Goal : origin 서버에 접근하지 않고 client request를 해결하기 위해!

1. 유저는 캐시를 통해 웹에 접근하도록 브라우저를 설정한다.
2. 브라우저는 모든 HTTP 요청을 캐시로 보낸다
   • 만약 캐시에 object가 존재하면 캐시가 object를 반환해준다
   • 만약 없으면 cashe가 origin server로 object를 요청하고, 이를 받아서 client에게 보내준다.

Why Web caching ?

• client request에 대해 응답하는 시간을 줄이기 위해
• link에 접근하는데 소요되는 traffic을 줄이기 위해

Caching Example

1. 가정

• 평균 obj size : 100K bits
• browser -> origin server request rate : 15/sec
• data rate to browsers : 1.50 Mbps
• router -> server RTT : 2 sec
• access link rate : 1.54 Mbps

2. 결과

• LAN Utilization : 0.15%
• access link utilization = 99%
• total delay = Internet delay + access delay + LAN delay = 2sec + minutes + usecs