웹과 HTTP

2.2 웹과 HTTP

2.2.1 HTTP 개요

HTTP(HyperText Transfer Protocol)

 

클라이언트 프로그램과 서버 프로그램은 서로 HTTP 메시지를 교환하여 통신한다. HTTP는 메시지의 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는지에 대해 정의하고 있다.

 

HTTP는 TCP를 전송 프로토콜로 사용한다. HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작한다. 일단 연결이 이루어지면, 브라우저와 서버 프로세스는 그들의 소켓 인터페이스를 통해 TCP로 접속한다.

 

HTTP는 TCP를 사용하기 때문에, 신뢰적인 데이터 전송 서비스를 제공한다.

 

HTTP 서버는 클라이언트에 대한 정보를 유지하지 않는다. HTTP는 비상태 프로토콜(stateless protocol)이다.

2.2.2 비지속 연결과 지속 연결

각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내지면 비지속 연결(non-persistent connection)이라고 한다.

 

모든 요구와 해당하는 응답들이 같은 TCP 연결상으로 보내지면 지속 연결(persistent connection)이라고 한다.

 

HTTP는 비지속 연결과 지속 연결을 사용할 수 있다. HTTP는 기본적으로 지속 연결을 사용하지만 비지속 연결을 사용하도록 설정할 수 있다.

비지속 연결 HTTP

HTTP/1.0은 비지속 연결을 지원한다. HTML 파일 하나와 JPG 파일 10개, 즉 11개의 객체가 같은 서버에 있다고 가정하면, 객체 하나당 TCP 연결 및 객체를 전송하고 연결을 끊는다. 즉 11개의 TCP 연결이 만들어진다.

 

각 객체는 2RTT를 필요로 한다.(TCP 연결 설정, 객체를 요청하고 받을 때)

• RTT(round-trip time) : 작은 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는데 걸리는 시간

지속 연결 HTTP

비지속 연결의 단점

• 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 한다.
  • TCP 버퍼가 할당되어야 하고 TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 한다. 이는 수많은 클라이언트들의 요청을 동시에 서비스하는 웹 서버에 심각한 부담을 줄 수 있다.
• 각 객체는 2RTT를 필요로 한다.

HTTP/1.1 지속 연결에서 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지한다. 같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내진다.

 

같은 서버에 있는 여러 웹 페이지들을 하나의 지속 TCP 연결을 통해 보낼 수 있다.

 

객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어 질 수 있다.(파이프라이닝(pipelining))

 

서버가 연속된 요구를 수신할 떄, 서버는 객체를 연속해서 보낸다. HTTP의 기본 모드는 파이프라이닝을 이용한 지속 연결을 사용한다.

2.2.3 HTTP 메시지 포맷

HTTP 명세는 HTTP 메시지 포맷을 정의한다. HTTP 메시지는 '요청 메시지'와 '응답 메시지'가 있다.

HTTP 요청 메시지

GET /somedir/page.html HTTP/1.1
HOST: www.someschool.edu
Connection: close
User-agen: Mozilla/5.0
Accept-language: fr

 

HTTP 요청 메시지 첫 줄은 요청 라인(request line)이라고 부른다.

• 메서드 필드, URL 필드, HTTP 버전 필드를 가진다.
• 메서드 값은 GET, POST, HEAD, PUT, DELETE등을 가진다.

이후 줄들은 헤더 라인(header line)이라고 부른다.

 

헤더 라인과 CR,LF 이후에 개체 몸체(entity body)가 있다. GET에서는 비어 있고, POST 방식에서 사용한다.

HTTP 응답 메시지

 

HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:05 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html

(데이터 데이터 데이터 데이터 데이터 ...)

 

상태 라인, 헤더 라인, 개체 몸체로 이루어져 있다.

 

상태라인

• 버전, 상태코드, 상태 메시지를 갖는다.

2.2.4 사용자와 서버 간의 상호작용: 쿠키

HTTP 서버는 상태를 유지 하지 않아서 서버 설계를 간단히 하고, 수천개의 TCP 연결을 다를 수 있는 웹 서버를 개발하게 해주었다.

 

그러나 웹 서버를 개발하다 보면 사용자의 접속을 제한하거나, 사용자 별로 다양한 콘텐츠를 제공하기 원할 때가 있다. 이 목적으로 HTTP는 쿠키(cookie)를 사용한다. RFC 6265에 정의된 쿠키는 사이트가 사용자를 추적하게 해준다.

 

쿠키 기술의 네 가지 요소

1. HTTP 응답 메시지 쿠키 헤더 라인
2. HTTP 요청 메시지 쿠키 헤더 라인
3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
4. 웹 사이트의 백엔드 데이터베이스(쿠키 관련 정보 저장)

웹 서버는 사용자(클라이언트)가 웹 서버에 접속하면 그 사용자에 대한 식별번호 값을 만들고, 이 식별번호로 인덱싱되는 백엔드 데이터베이스 안에 엔트리를 만든다. 그리고 응답으로 Set-cookie: 헤더에 쿠키 값을 설정해서 반환한다. 브라우저는 관리하는 특정한 쿠키 파일에 서버의 호스트 이름과 Set-cookie: 헤더와 식별번호를 포함하는 라인을 덧붙이게 된다.

 

사용자가 웹 페이지를 요청 할 떄 사용자의 브라우저는 쿠키 파일을 참조하고 접속한 사이트에 대한 사용자의 식별번호를 발췌하고, HTTP 요청에 식별번호를 포함한 쿠키 헤더 파일을 넣는다.

 

HTTP 요청에서 다음과 같은 헤더 라인을 포함한다.

Cookie: 식별번호

2.2.5 웹 캐싱

웹 캐시(Web Cache) 또는 프록시 서버(proxy server)는 기점 웹 서버(origin Web server)를 대신하여 HTTP 요구를 충족시키는 네트워크 개체다. 웹 캐시는 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존한다.

 

웹 캐시 요청 순서

1. 브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 개체에 대한 HTTP 요청을 보낸다.
2. 웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인한다. 만일 저장되어 있다면 웹 캐시는 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.
3. 만약 웹 캐시가 객체를 갖고 있지 않다면, 웹 캐시는 기점서버에 TCP 연결을 설정한다. 그러고 나서 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 이러한 요청을 받은 후에 기점 서버는 웹 캐시로 HTTP 응답 메시지와 함께 객체를 보낸다.
4. 웹 캐시의 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지와 함께 객체 사본을 보낸다.

만약 기관 네트워크와 기관 라우터 사이의 회선은 100Mbps이고 기관 라우터와 공중 인터넷 라우터 사이의 회선이 15Mbps일때 기관 네트워크에서 많은 데이터를 보내면 인터넷 지연이 커질 것이다.

 

이 때 15Mbps의 접속률을 100Mbps로 증가시키면 문제가 해결되지만 비용이 많이 들게된다.

 

웹 캐시를 사용하면 적은 비용으로 인터넷 지연을 줄일 수 있을 것이다.

조건부 GET

웹 캐시를 사용하면 캐시 내부에 있는 객체의 복사본이 새것인지 아닌지 판단할 수 있어야 한다. HTTP는 클라이언트가 브라우저로 전달되는 모든 객체가 최신인지 확인하면서 캐싱을 하게 해주는 방식을 갖고 있다. 이러한 방식을 조건부 GET(conditional GET)이라고 한다.

 

HTTP 요청 메시지가 GET 방식을 사용하고, If-Modified-Since: 헤더 라인을 포함하고 있다면 조건부 GET 메시지다.

 

브라우저가 요청을 보냈을 때, 프록시 캐시는 요청 메시지를 웹 서버에 보낸다. 웹 서버는 프록시 캐시에게 Last-Modifed: 날짜정보 헤더를 포함한 응답을 보낸다. 프록시 캐시는 브라우저에 요청 객체를 보내주고 자신도 객체를 저장한다.

 

브라우저가 또 다시 GET 요청을 보낼때, If-Modifed-Since: 날짜정보 값을 포함한 요청을 웹 서버에 보낼 때, 전에 응답했던 헤더 Last-Modified: 의 날짜정보 값과 일치하면 웹 서버는

HTTP/1.1 304 NotModifed

상태 라인과 함께 빈 개체 몸체를 반환한다. 이는 클라이언트에게 요청 객체의 캐싱된 복사본을 이용하라는 것을 의미한다.

2.2.6 HTTP/2

2015년에 표준화된 HTTP/2는 1997년에 표준화된 HTTP/1.1 이후 새로운 첫번째 HTTP 버전이다.

HTTP/2가 제공하는 기능

• 하나의 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간 줄이기
• 요청 우선순위화
• 서버 푸시
• HTTP 헤더 필드의 효율적인 압축

하나의 TCP 상에서 웹 페이지에 있는 모든 객체를 보내면 HOL(Head of Line) 블로킹 문제가 발생할 수 있다.

• HTML 페이지 상단에 큰 비디오 클립이 있고, 아래의 작은 크기의 객체들이 여러개 있는 웹 페이지의 경우 비디오 클립이 TCP 연결의 병목 링크를 통과하는 데 오랜 시간이 걸리는 반면, 작은 객체들은 비디오 클립 뒤에서 기다리는 시간이 길어진다. 비디오 클립이 작은 객체들을 블로킹하게 된다.

HTTP/1.1 에서 브라우저는 6개까지 병렬 TCP를 연결 할 수 있다. 이는 HOL 문제를 막을 뿐만 아니라 더 많은 대역폭을 사용할 수 있게 해준다.

 

HTTP/2의 주요 목표 중 하나는 하나의 웹 페이지를 전송하기 위한 병렬 TCP 연결의 수를 줄이거나 제거하는 데 있다. 이는 관리해야 하는 소켓의 수를 줄일 뿐만 아니라 TCP 혼잡 제어를 제어할 수 있게 해준다.

 

TCP를 하나만 사용할 경우 HTTP/2는 HOL 블로킹을 피하기 위한 매커니즘이 필요하다.

HTTP/2 프레이밍

HOL 블로킹 문제의 해결책으로 등장한 HTTP/2는 각 메시지를 작은 프레임으로 나누고, 같은 TCP 연결에서의 요청과 응답 메시지를 인터리빙한다.

 

모든 프레임은 고정된 길이를 갖고, 비디오 클립은 1000개의 프레임, 8개의 작은 객체들은 2개의 프레임을 갖는다고 가정하자. 비디오 클립으로부터 하나의 프레임을 전송한 이후 프레임 인터리빙을 이용하여 작은 객체들의 첫 번째 프레임을 보낸다. 이후 두 번쨰 비디오 클립 프레임을 보내고 나서 작은 객체들의 마지막 프레임을 전송하면, 모든 작은 객체들은 18개의 프레임을 보낸 후에 전송된다.

 

만약 인터리빙을 사용하지 않는다면 작은 객체들은 1016개의 프레임이 보내진 후에야 전송될 것이다.

 

프레이밍은 HTTP/2 프로토콜의 프레임으로 구현된 다른 프레이밍 서브 계층에 의해 이루어진다.

• 서버가 HTTP 응답을 보내고자 할 때, 응답은 프레이밍 서브 계층에 의해 처리되며 프레임들로 나눠진다.
• 응답의 헤더 필드는 하나의 프레임이 되며 메시지 본문은 하나의 프레임으로 쪼개진다.
• 응답 프레임들은 서버의 프레이밍 서브 계층에 의해 인터리빙된 후 하나의 지속적인 TCP 연결상에서 전송된다.
• 프레임들이 클라이언트에 도착하면 프레이밍 서브 계층에서 처음 응답 메시지로 재조립되며 브라우저에 의해 처리된다.

마찬가지로, 클라이언트의 HTTP 요청은 프레임으로 쪼개지고 인터리빙 된다.

메시지 우선순위화 및 서버 푸싱

메시지 우선순위화(message prioritization)

• 클라이언트가 하나의 특정 서버로 동시에 여러 개의 요청을 할 때, 각 메시지에 1에서 256사이의 가중치를 부여함으로써 요청에 우선순위를 매길 수 있다.
• 높은 수치일수록 우선순위가 높다. 서버는 가장 높은 우선순위 요청 프레임을 제일 먼저 보낼 수 있다.

서버 푸싱

• 처음 요청에 대한 응답 외에도, 서버는 클라이언트의 요청 없이도 추가적인 객체를 클라이언트에게 푸시하여 보낼 수 있다.

HTTP/3

트랜스포트 프로토콜인 QUIC는 UDP 프로토콜 위에 위치하는 애플리케이션 계층에 구현되어 있다.

QUIC는 메시지 멀티플렉싱(인터리빙), 스트림별 흐름제어, 저지연 연결 확립과 같은 HTTP에 의미 있는 여러 특징을 갖는다.