[Network] 하향식 접근 네트워크 - 2. Application Layer - (2) HTTP

이 글은 이화여자대학교 이미정 교수님의 2014년 2학기 컴퓨터 네트워크 강의를 기반으로 재구성한 것입니다. 삽화는 링크를 출처로, 저작권은 J.F Kurose and K.W. Ross에게 있다는 것을 밝힙니다.

 Application Layer에서는 크게 3가지를 살펴본다.

1. application principle
   
   • client-server 구조
   • peer-to-peer (P2P) 구조
   • transport layer service model
2. internet protocol - HTTP, electronic mail(SMTP, POP3, IMAP), DNS, P2P
3. network application의 작성을 위한 interface - socket, UDP, TCP

 이 글에서는 internet protocol 중 HTTP를 살펴본다.

 

 

 

HTTP & Web

Web

 web page는 object들로 구성되어 있으며, 구체적으로는 하나의 base HTML file과 여러 개의 referenced object로 구성되어 있다. 이 때 referenced object는 URL의 형태로 작성된다.

URL에 관한 내용은 1%의 네트워크 - 1. 웹 브라우저가 하는 일 포스팅에도 있으니 필요 시 참고하면 좋다.

 

 

HTTP : HyperText Transfer Protocol

 HTTP는 web을 지원하기 위한 protocol이다. 다음과 같은 특징들을 가진다

• client-server model
• use TCP
• stateless
• persistent? - 최초의 HTTP는 non-persistent, 현재는 persistent하다.

 

client-server model

HTTP oeverview

 HTTP는 client-server model이다.

• client process : web browser로, server로 request를 보내고 응답이 오면 화면에 띄우는 역할을 한다.
• server process : web server로, client process가 접속하기를 기다렸다가 접속이 오면 응답을 보낸다.

위 예시에서, Apache web server는 HTTP를 사용하기 때문에 firefox를 사용하는 PC든 Safari를 사용하든 iPhone이든 상관없이 HTTP가 정의하는 syntax, semantics가 모두 같기 때문에 모두 해석하고 응답할 수 있다.

 

TCP 사용

 HTTP는 data integrity가 중요하기 때문에 TCP를 사용한다.

1. client가 server의 80번 port로 TCP connection 요청을 보낸다.
2. server가 TCP connection을 수락한다.
3. client가 server로 HTTP request message를 보낸다. server는 client로 HTTP response message를 보낸다.
4. TCP conneciton을 종료한다.

 

stateless

 HTTP는 user가 보낸 message를 기억하지 않는다.

 때문에 HTTP를 state하게 만들기 위해서는 overhead가 많이 발생하고, 어렵다. history의 보관할 때는 overhead가 발생하고, 또 crash가 날 때는 state가 망가지기 때문에 재조정해야 하기 때문이다.

 

persistent?

 non-persistent는 하나의 응답을 보내면 바로 close하는 것, persistent는 여러 object를 나누고 종료하는 것을 의미한다.

• non-persistent HTTP : 최초의 HTTP는 이 방식이었다. web server가 하나의 response를 보내면 바로 TCP close를 하는 방식이었다. web은 하나의 base HTML file과 여러 개의 object file로 구성되어 있는데 이 object file들을 받기 위해서는 여러 번의 TCP가 필요했다.
• persistent HTTP : 현재의 방식이다. 한 번의 TCP 연결로 여러 개의 object들을 받을 수 있다.

 

 non-persistent HTTP 시절 flow를 한 번 보자.

1. 전송 전에 TCP connection을 진행한다. server와 server process는 항상 실행 중인 상태이며, 언제 client가 요청할지 모르기 때문에 항상 대기 상태이다.
2. client가 port 80으로 TCP connection 요청을 보낸다.
3. server는 port 80에서 대기하다가 TCP connection 요청이 오면 accept한다.
4. client가 URL을 포함한 HTTP request message를 보낸다.
   • 이 때 HTTP request message는 TCP connection socket을 통해 server로 도착한다.
5. server socket으로 message가 도착한다. server는 request message를 보고 요청된 object를 포함해 response message를 작성하고 보낸다.
   • 마찬가지로 HTTP response message는 TCP connection socket을 통해 client로 도착한다.
6. server가 TCP connection을 끊는다. (non-persistent이기 때문)
7. client socket으로 message가 도착한다. web browser는 HTML을 화면에 띄우고, 추가적으로 object reference를 모두 찾고 모든 object에 대해 server에게 HTTP request를 보한다.

 

RTT, Round Trip Time

 RTT는 아주 작은 packet이 client와 server를 왕복하는 데 걸리는 시간을 의미한다. 아주 작은 packet인 만큼 transmission delay는 무시한다.

 

 HTTP의 경우 TCP handshake 과정에서 1RTT, 그리고 하나의 object file을 요청하고 받는 과정에서 1RTT가 필요하다.

 

- non-persistent HTTP에서 RTT

 non-persistent의 경우 한 번에 하나의 object만 받을 수 있는데 하나의 object를 받기 위해서 2RTT가 필요하다. overhead가 너무 크다!

 이를 막기 위해 TCP connection을 parallel하게 여는 방법도 있는데, 그러면 socket도 그만큼 열리며, 그러면 그만큼의 buffer도 추가되기 때문에 OS가 너무 많은 부담을 지게 된다.

 

- persistent HTTP에서 RTT

 persistent HTTP의 경우 object를 보내도 connection을 유지한다. client가 base HTML을 받은 후 여러 개의 HTTP request를 보내면 1RTT + alpha만큼의 시간에 모든 object들을 수신할 수 있다.

 

 

HTTP Message

 HTTP message는 request, response 2종류가 있다. 둘 다 사람이 읽을 수 있는 ASCII 문자로 구성된다.

비슷한 내용이 1%의 네트워크 - 1. 웹 브라우저가 하는 일 포스팅에도 있으니 필요 시 참고하면 좋다.

 

 

HTTP request message

HTTP request example

 HTTP request message는 request line, heade lines, body 3가지 부분으로 나뉜다.

• request line : method, url, HTTP version이 있다.
  • method는 작업 요청 종류를, URL은 자원의 위치를 의미한다.
• header line : header와 header value가 있다.
  • header line 끝에는 \r\n (개행)을 덧붙여 body와 구분한다.
• request body : message 본문으로, method가 POST인 경우 사용하며 나머지의 경우 사용하지 않는 경우가 대부분.

 

HTTP method

 HTTP method는 client가 어떤 동작을 하고 싶은지를 의미한다. HTTP request method 목록

 HTTP 1.0에는 GET, POST, HEAD 3가지만 있었지만 HTTP 1.1로 오면서 여러 종류가 추가되었다.

method	HTTP 1.0	HTTP 1.1	의미
GET	O	O	client가 server에게 데이터 요청 입력한 내용이 query string의 형태로 URL 안에 들어간다.
POST	O	O	client에서 server로 데이터 송신 입력한 내용이 request body에 들어간다.
PUT		O	resource 치환 (전체 변경)
PATCH		O	resource 갱신 (일부 변경)
DELETE		O	resource 삭제
HEAD	O	O	response는 보내되, response body는 보내지 말라는 것을 의미한다. (test용)

 

 

HTTP response message

HTTP response example

 HTTP response message는 status line, header line, response body 3부분으로 나뉜다.

• status line : HTTP version, status code, status phrase 3가지가 있다.
• header line : request message와 동일하게 header와 value가 있다.
  • header line 끝에는 \r\n(개행)으로 header line과 response body를 구분한다.
• response body : request message가 요청한 data가 들어 있다.

 

Status Code

 status code는 server가 client에게 응답할 때 응답 상태를 의미한다. 200번대는 응답이 성공적일 때, 400번대는 잘못된 요청을, 500번대는 서버 오류가 발생했을 때를 의미한다. HTTP response status code 목록

• 200 Ok : request의 성공을 의미하며, body에 내용이 있다.
• 301 Moved Permaently : resource의 위치가 바뀌었다는 것을 의미한다. 이 경우 Location header를 사용해 redirect한다.
• 400 Bad Request : 잘못된 요청임을 의미한다.
• 404 Not Found : 해당 위치에 resource가 없다는 것을 의미한다.
• 505 HTTP Version Not Supported : client HTTP version을 지원하지 않는다는 것을 의미한다.

 

 

 

Cookie

 HTTP는 stateless이다. 그러나 server가 client의 transaction history를 유지해야 하는 경우가 있는데, 이 때 cookie를 사용해 state를 저장한다. cookie를 사용하기 위해 다음 과정을 거친다.

1. server가 HTTP response message의 cookie header에 값을 넣어 client에게 보낸다.
2. 그 response message를 받은 client는 다음 번 request부터 cookie header에 값을 넣어 server에게 보낸다.
3. browser는 cookie file을 계속 유지한다.
4. server는 backend DB에 해당 state를 계속 저장한다.

 

 cookie는 크게 2가지를 위해 사용된다.

• authorization
• session state
  • stateless인 HTTP는 1번의 통신이 끝나면 정보가 사라지기 때문에 user를 식별할 수 없다. 그러나 cookie를 사용해 user를 식별하고, 그 정보를 계속 남길 수 있다.
  • 이 경우 server는 사용자가 뭘 하는지 계속 볼 수 있기 때문에 유의미한 데이터를 추론할 수도 있다.

 

 즉, HTTP는 stateless이지만 cookie를 사용해 web server가 transaction history를 관리할 수 있다.

 

예시

 위 예시에서 client의 첫 번째 요청에는 amazon cookie가 없어 server가 인증 과정을 거치고 내부 DB에 그 값을 넣고, cookie에 값을 써서 client에게 돌려준다.

 그 다음번 요청은 client가 보낸 request message의 cookie header를 보고, 그 값으로 사용자를 판별한다.

 

 

 

Web Cache (Proxy Server)

 기존 방식대로라면 client의 모든 request는 web server에 도착하고, web server의 응답을 client에게 되돌려 주어야 한다. 그러나 중간에 web cache를 두어 server까지 갈 필요가 없게 만들 수 있다. 일종의 cache로 작동하기 때문에 web cache라고도 하며, server의 proxy처럼 행동하기 때문에 proxy server라고도 한다. web cache는 server의 주체가 ISP에게 산다.

 

 client web browser가 모든 접근 시 web cache를 들르게 설정하면, client의 모든 request는 web cache를 거친다.

• hit라면 web cache에 있는 값을 바로 가져온다.
• miss라면 web cache가 server에 request를 보내고, 저장한다. 이후 client에게 return한다.

비슷한 내용이 1%의 네트워크 - 5. Firewall, Proxy, Load Balace 포스팅에도 있으니 필요 시 참고하면 좋다.

 

 web cache는 client로도, server로도 행동하기 때문에 내부적으로 client process와 server process가 모두 있어야 한다.

web cache가 origin server와 통신할 때는 client처럼 행동하고, browser와 통신할 때는 server처럼 행동한다.

 

장점

 web cache를 사용하는 다음과 같은 장점이 있다.

• user 입장에선 web cache로부터 결과를 받는 것이 web server로부터 결과를 받는 것보다 훨씬 빠르다.
• web server로의 traffic을 줄일 수 있다. - 사실상 제일 중요한 이유이다.
• poor content provider인 경우 server를 빌려 자신의 service deliver를 효과적으로 할 수 있다.

 

어떻게 traffic을 줄이나?

 이전 포스팅에서 설명했지만, 어떤 기관이 internet에 연결되기 위해서는 access link를 거쳐야 한다. 그러나 해당 기관의 구성원이 사용하는 network의 총량이 access link bandwidth와 비슷하다고 해 보자. 그러면 delay가 발생한다!

 이를 해결하는 첫 번째 방법이 access link bandwidth를 늘이는 방법이다. 그러나 이 경우 delay가 줄지만, 너무 비싸다!

 

 때문에 web cache를 사용한다. local web cache를 해당 기관에 설치하면, 구성원들의 요청이 일단 web cache를 무조건 한 번 들른다. 만약 hit라면 인터넷으로 packet이 나가지 않기 때문에 network 총량을 줄일 수 있게 된다! 이 때, web cache의 설치 비용이 access link bandwidth를 늘이는 것보다 훨씬 싸게 친다.

 

 

Conditional GET

 web cache의 문제점은, origin server의 내용이 갱신된 경우 web cache가 갱신되기 전 값을 줄 수 있다는 것이다.

 이러한 현상을 막기 위해 web cache는 자신이 가지고 있는 내용이 최신인지 확인한다. 이를 위해 if-modified-since [date] header를 request message에 넣어 server에게 보내는데, server는 [date] 이후로 내용이 수정되었는지 여부를 응답해 준다.

• 수정되지 않은 경우 server는 304 Not Modified를 response한다.
• 수정되었다면 server는 200 Ok와 response body에 수정된 object를 보낸다.

 

 만약 이 요청을 모든 request에 대해 실행하면 user는 항상 최신 정보를 받아올 수 있지만, 그만큼의 delay가 필요하다. (사실상 모든 요청이 server로 가기 때문에 web cache를 사용하는 이유도 많이 떨어진다.) 때문에 web cache는 몇 분에 1번씩 conditional GET 요청을 server에게 보낸다. 이 경우 사용자가 항상 최신 정보를 받아올 수 있는 것은 아니지만, delay를 합리적으로 줄일 수 있다.

 

 

 

 

 

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.