[컴퓨터망] 2. Application Layer(Web과 HTTP)

Web과 HTTP

웹 페이지는 동영상, 이미지, 문서와 같은 많은 object로 구성되어 있다. 이것들은 서로 다른 웹 서버에 저장될 수 있다. 웹 페이지는  기본 HTML 파일과 여러 참조 객체로 구성된다. 예를 들어, 웹 페이지가 HTML 텍스트와 5개의 JPEG 이미지로 구성되어 있으면, 이 웹 페이지는 6개의 object를 갖는다.

 

HTTP

HTTP는 Hyper Transfer Protocol의 약자로, 웹의 애플리케이션 계층 프로토콜이다. 클라이언트/서버 모델로 동작하며 클라이언트(브라우저)가 HTTP 프로토콜로 object를 요청하면, 서버(웹 서버)가 요청을 받아 object를 보낸다. 

 

HTTP와 TCP

HTTP는 TCP를 사용하는데, 동작 과정은 다음과 같다.

• 클라이언트가 TCP 연결을 설정한다.
• 서버가 TCP 연결을 받는다.
• HTTP 메세지가 브라우저와 웹 서버 사이에 교환된다.

 

Stateless

HTTP는 Stateless 프로토콜이다. 특정 클라이언트가 몇 초 후에 같은 객체를 두 번 요청해도 서버는 전에 보냈다고 알려주지 않고 객체를 또 보낸다. HTTP 서버는 클라이언트에 대한 정보를 유지하지 않으므로, 비상태(stateless) 프로토콜이라고 부른다. 참고로, HTTP 프로토콜 자체는 State를 가지고 있지 않다. 

 

 

HTTP Connection

HTTP 연결 방식은 2가지 종류가 있다. Non-Persistent Connection과 Persistent Connection이다.

 

Non-persistent HTTP

하나의 TCP 연결에 하나의 object만 전송할 수 있다. 때문에, 여러 개의 object를 보낸다고 하면, TCP 연결을 설정하고 닫는데 시간이 소요된다. HTTP/1.0은 Non-persistent Connection을 지원한다.

아래 그림은 동작 과정이다.

• 클라이언트가 포트번호 80번으로 TCP 연결을 설정한다.
• 서버는 80번 포트에서 TCP 연결을 기다리고 있다.
• 클라이언트는 HTTP request 메세지를 소켓을 통해 전송한다.
• 서버는 request 메세지를 수신하고 response 메세지를 포함하여 요청한 object를 전송한다.
• 서버는 TCP 연결을 종료한다.
• 클라이언트는 response 메세지를 수신한다.

 

Response Time

이 과정의 Response Time을 계산해보자. 이를 위해서 RTT(Round-trip-time)을 알아야 한다. RTT란 패킷이 클라이언트에서 서버까지 갔다가 다시 클라이언트로 돌아오는데 걸리는 시간을 말한다. HTTP response time을 구해보면, 2RTT + file transmission time으로 계산된다.

 

 

Non-persistent HTTP는 약간의 단점이 있다. object 한개를 보낼 때마다 2RTT가 소요된다. 또한 각 요청에 대해 매번 TCP 연결을 설정해야 하기 때문에  OS는 TCP 연결에 오버헤드가 발생한다. 그래서 등장한 것이 Persistent HTTP 이다.

 

 

Persistent HTTP

TCP 연결이 설정되면 여러 object를 한 번에 보낼 수 있다. 즉, 서버가 response 메세지를 보내고 나서도 TCP 연결은 계속 유지된다. Non-Persisent HTTP에 비해 RTT 절반 가량 줄어든다. 이것이 등장하면서 HTTP/1.1에도 지원하기 시작했다. 

 

HTTP message type

RFC는 HTTP 메세지 타입을 2가지로 정의한다.

 

1. REQUEST 메세지

ASCII로 정의되며 request line, header, body 로 구성된다. request line에는 Method, URL, HTTP Version이 포함된다.

 

 

HTTP request 메시지에서 Method 종류에 대해서도 알아보자.

• GET : 원하는 정보를 서버에게 요청할 때 사용되는 메소드이다.
• HEAD : 서버의 각종 정보를 확인하기 위해 사용되는 메소드이다. 
  GET과 동일하지만, response에 Body가 없고 response code와 Head만 응답받는다.
• GET : 요청된 자원을 생성하기 위해 사용되는 메소드이다. 
  POST로 정보를 전송하면 URL에 파라미터가 나타나지 않으므로 각종 데이터를 전송하는데 쓰인다.
• PUT : 서버에 object를 올릴 때 사용되는 메소드이다.

 

2. RESPONSE 메세지

start line에 HTTP Version, status code, phrase를 전송한다.

 

HTTP Status Code는 아래와 같이 다양하다.

• 200 OK : 성공적으로 요청됨을 나타낸다.
• 301 Moved Permanently : 요청한 object가 이동되었기 때문에 새로운 location을 포함해서 보낸다.
• 400 Bad Request : 요청 메세지를 이해하지 못했다는 의미이다.
• 404 Not Found : 서버에서 해당 문서를 찾지 못했다는 것을 나타낸다.
• 500 HTTP Version Not Supported : 해당 버전을 지원하지 않을 때 사용한다. 예를 들어, 서버가 HTTP/1.0을 지원하는데 클라이언트가 HTTP/2.0을 요구하면 오류가 발생한다.

 

서버와 유저의 상태 유지 : cookies

다시 떠올려 보면, HTTP는 클라이언트의 state를 가지고 있지 않다. 즉, 클라이언트가 이전에 요청한 메세지에 대해서는 전혀 기억하지 않는다. 그러나, 서버는 클라이언트에게 맞는 정보를 제공하고 경우에 따라 클라이언트를 제한하기도 하기 때문에 상태가 필요하다.

 

쿠키는 아래의 과정으로 동작한다.

• 클라이언트가 HTTP Request 메세지를 서버로 전송한다.
• 서버는 Request 메세지를 수신하고 클라이언트의 식별 번호를 설정해 DB에 저장한다.
• HTTP Response 메세지에 식별 번호를 포함해 전송한다.
• 이후에 클라이언트가 다시 웹 서버에 접속하려고 Request 메세지를 전송한다.
•  브라우저는 쿠키 파일을 참조하고 식별 번호를 헤더에 포함해서 전송한다.

 

Web caches

원래 서버에 접속하지 않고도 클라이언트 요청을 충족시키기 위해 만들어졌다. Proxy server는 기존의 웹 서버를 대신해 HTTP 요청을 충족시키는 것이다. 이 방법은 기존의 웹 서버에 접속해 object를 가져오는 것보다 훨씬 빠르다는 장점이 있다.

또, 액세스 링크의 트래픽을 줄이고 더욱 효과적인 전송을 할 수 있다.

 

 

Conditional GET

웹 캐싱이 사용자가 느끼는 응답 시간을 줄일 수 있지만, 웹 캐시 내부에 있는 복사본이 새 것이 아닐 수 있다는 문제를 야기한다. HTTP는 클라이언트가 브라우저로 전달되는 모든 객체가 최신의 것임을 확인하면서 캐싱해주는데, 이러한 방식을 조건부 GET(conditional GET) 이라고 한다.

 

동작 과정

1. 클라이언트(브라우저)가 웹 캐시로 object request 메세지를 보낸다.
2. 캐시는 서버에 object request 메세지를 전달한다.
3. 웹 서버는 캐시에 object를 포함해 response 메세지를 보낸다. 이때, Last-modified라는 필드를 포함해서 마지막으로 수정한 날짜를 함께 보낸다.
4. 캐시와 브라우저는 객체를 수신한다.
5. 일주일 후에 다시 브라우저가 같은 object를 요청한 경우, 캐시에 object가 저장되어 있다. 캐시는 조건부 GET으로 마지막으로 수정된 날짜를 서버에 묻는다.
6. 수정되지 않았다면 서버는 캐시로 object를 전송하지 않고 수정되었다면 수정된 object를 전송한다.

 

HTTP/2

HTTP/2는 하나의 TCP 연결에 여러 개의 object를 전달해 요청/응답 지연 시간을 줄이는 데 있다. HTTP/2를 알아보기 전에, 이전 버전들에 대해 잠시 살펴보자.

 

HTTP/1.1

HTTP/1.1은 지속적인 연결을 사용할 때 웹 페이지당 오직 하나의 TCP 연결을 가진다. 서버는 순서대로 들어오는 GET 요청에 응답하는데, 이때 Head-of-Line(HOL) blocking 문제가 발생한다. 크기가 서로 다른 object가 다를 때 큰 object가 처리될 때까지 작은 object들이 오랫동안 기다려야 하는 문제이다. 이를 해결하려면, 각각의 object 별로 서로 다른 소켓을 사용해야 한다.

 

다시 HTTP/2로 돌아가서, HTTP/1.1에 비해 서버에서의 유연성이 증가한 양상이다. HTTP/1.1과. method, status code, header field는 같다. 차이점은 선입선출 구조로 전송하는 것이 아니라, client-oriented object priority를 부여해 전송하며, 클라이언트가 요청하지 않아도 object 요청 양상을 보고 미리 예상해 object를 전송해 효율적이다. 가장 중요한 것은, HOL blocking 문제를 해결하기 위해 object를 프레임 단위로 잘라 보낸다.

 

 

왼쪽) HOL blocking / 오른쪽) 프레이밍으로 HOL blocking을 완화

차이를 보면, 기존의 HTTP/1.1은 하나의 큰 object를 보내기 위해서 뒤의 object 2, 3, 4가 오랫동안 대기해야 했다. 그러나 HTTP/2에서는 작은 프레임 단위로 잘라서 보내기 때문에 뒤의 object가 오랫동안 대기하지 않아도 된다.

 

HTTP/3

HTTP/2는 HTTP/1.1에서 발생하는 패킷 손실을 줄인다. 이때 등장한 HTTP/3은 HTTP2에 보안을 추가하고 object에 대한 에러 제어, 혼잡 제어 기능을 추가한 것이다. 최근에 표준화되어 사용되고 있다.