A. Web Basic

1. Web Page

   • 단순히 단일 URL로 지정할 수 있는 하나의 파일인 Object(객체) 들로 구성된다.
   • Object는 HTML 파일, JPEG 이미지, 자바스크립트, CSS, 비디오 클립 등이다.
   • 대부분의 웹 페이지는 기본 HTML 파일과 여러 참조 객체로 구성된다.
   • 기본 HTML 파일은 다른 참조 객체를 그 객체의 URL로 참조할 수 있다.

2. URL

   • http://www.someschool.edu/someDepartment/picture.gif를 예시로 들어보자.
   • www.someschool.edu: 호스트 이름
   • /someDepartment/picture: 경로 이름

3. Web Browser

   • HTTP의 클라이언트 측을 구현하기 때문에, 웹의 관점에서 브라우저와 클라이언트(client)라는 용어를 혼용하여 사용한다.
   • 브라우저는 요구한 웹 페이지를 보여주고 여러가지 인터넷 항해와 구성 특성을 제공한다.

4. Web Server

   • URL로 각각을 지정할 수 있는 웹 객체를 갖고 있다.
   • 항상 켜져있고, 고정 IP 주소를 가지며, 다른 잠재적인 수백만 브라우저로부터의 요청을 서비스한다.

B. HTTP Introduction

HTTP(HyperText Transfer Protocol)은 웹의 애플리케이션 계층 프로토콜이다.

• HTTP는 각기 다른 종단 시스템에서 수행되는 서버 프로그램과 클라이언트 프로그램으로 이루어진다.

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

• HTTP는 TCP를 사용하고 포트 번호: 80을 이용한다/
  

위 그림은 HTTP가 웹 클라이언트가 웹 서버에게 웹 페이지를 어떻게 요청하는지와 서버가 클라이언츠로 어떻게 웹 페이지를 전송하는지를 보여준다.

• TCP를 전송 프로토콜로 사용한다.
  1. HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작한다.
  2. 연결이 이루어지면, 클라이언트와 서버 프로세스는 각각의 소켓 인터페이스를 통해 TCP로 접속한다.
  3. 클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 보내고, 소켓 인터페이스로부터 HTTP 응답 메시지를 받는다.
  4. 마찬가지로, HTTP 서버는 소켓 인터페이스로부터 요청 메시지를 받고 응답 메시지를 소켓 인터페이스로 보낸다.
• TCP는 신뢰적인 데이터 전송 서비스를 제공하기 때문에 모든 HTTP 요청/응답 메세지는 궁극적으로 서버에 잘 도착할 것이다.
  
• 서버가 클라이언트에게 요청 파일을 보낼 때, 서버는 클라이언트에 관한 어떠한 상태 정보도 저장하지 않는다.
  • 이를 Stateless Protocol(비상태 프로토콜) 이라고 하고 HTTP 또한 Stateless Protocol이다.
  • 예를 들면 클라이언트가 같은 객체를 2번 이상 요구해도, HTTP는 상태 정보를 저장하지 않기 때문에 같은 객체를 또 보낸다는 것이다.

C) Non-Persistent Connection and Persistent Connection

요청/응답 HTTP 메세지가 같은 TCP 연결상으로 보내져야 하는지 결정한다.

HTTP의 디폴트 모드는 Persistent Connection이다.

Non Persistent Connetion HTTP

요청/응답 HTTP 메세지가 분리된 TCP 연결상으로 보내지는 HTTP
multiple objects can be set over single TCP connection between client and that server

페이지가 기본 HTML 파일( http://www.someschool.edu/someDepartment/home.index)과 10개의 JPEG 이미지로 구성되고, 모든 객체가 같은 웹 서버에 있다고 가정하자.

연결 수행 과정

1. HTTP 클라이언트는 HTTP 기본 포트 80을 통해 서버로 TCP 연결을 시도한다. TCP 연결과 관련하여 클라이언트와 서버에 각각 소켓이 있게 된다.

2. HTTP 클라이언트는 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지를 보낸다. 이 요청에 객체 경로도 포함된다.

3. HTTP 서버는 TCP 연결 소켓을 통해 요청 메시지를 받는다. 저장 장치로부터 경로의 객체를 추출한다. HTTP 응답 메시지에 그 객체를 캡슐화하여 소켓을 통해 클라이언트로 보낸다.

4. HTTP 서버는 TCP에게 연결을 끊으라고 한다. (그러나 실제로 클라이언트가 응답 메시지를 올바로 받을 때까지 끊지 않는다.)

5. HTTP 클라이언트가 응답 메시지를 받으면, TCP 연결이 중단된다. 메시지는 캡슐화된 객체가 HTML 파일인 것을 나타낸다. 클라이언트는 응답 메시지로부터 파일을 추출하고 HTML 파일을 조사하여 10개의 JPEG 객체에 대한 참조를 찾는다.

6. 참조되는 JPEG 객체에 대해 1 ~ 4단계를 반복한다.

• 다른 브라우저는 웹 페이지를 수신하며 각기 다른 방식으로 해석할 수 있다. 그러나 HTTP는 브라우저가 웹 페이지를 어떻게 해석하는지에는 관심이 없다.

• 각 TCP 연결은 하나의 요청 메세지와 하나의 응답 메세지만 전송한다. 위의 경우, 웹 페이지를 요청할 때 11개의 TCP 연결이 만들어진다.

• HTTP/1.0은 Non Persistent Connection을 지원한다.

동시 연결

사용자는 TCP 연결의 동시성 정도를 조절할 수 있도록 브라우저를 구성할 수 있다.

• 사용자는 하나의 TCP 연결으로 앞의 단계를 동시에 받을지 순차적으로 받을지의 동시성 정도를 조절할 수 있도록 브라우저를 구성할 수 있다.

• 브라우저는 여러 개의 TCP 연결을 설정하며 다중 연결상에서 웹 페이지의 각기 다른 원하는 부분을 요청할 수 있다.

• 동시 연결을 사용하면 응답 시간을 줄일 수 있다.

  • 하나의 TCP 연결으로 여러 요청을 처리할 수 있기 때문이다.

Round Trip Time

작은 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는데 걸리는 시간

• RTT는 패킷 전파 지연, 큐잉 지연, 처리 지연 등을 포함한다.

Three Way Handshake

클라이언트가 서버로 작은 TCP 메시지를 보내고, 서버는 작은 메시지로 응답하고, 마지막으로 클라이언트가 다시 서버에 응답한다.

1. Three Way Handshake 중 처음 두 부분이 경과하면 하나의 RTT가 계산된다. (TCP 연결 설정)
2. Three Way Handshake 중 처음 두 과정이 끝난 후에 클라이언트는 HTTP 요청 메세지를 TCP 연결로 보내면서 Handshake의 세 번째 과정(응답)을 함께 보낸다. (객체 요청)
3. 이 HTTP 요청/응답은 또 하나의 RTT를 필요로 한다.

Non Persistent Connection의 총 응답 시간(패킷 하나): 2RTT + HTML 파일을 서버가 전송하는데 설리는 시간

Persistent Connection의 총 응답 시간(패킷 n개): 1RTT + 1RTT * n + HTML 파일을 서버가 전송하는데 걸리는 시간

Non Persistent Connection HTTP의 단점

1. 각 요청 객체에 대한 새로운 연결이 매 경우 설정되고 유지되어야 한다.

   • TCP Buffer가 할당되어야하고 TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야한다.
   • 이는 수많은 클라이언트들의 요청을 동시에 서비스하는 웹 서버에게 부담이 된다.

2. 각 개체는 2RTT를 필요로 한다.

Persistent Connection HTTP

서버는 응답을 보낸 후에 TCP 연결을 그대로 유지한다.

• 같은 클라이언트와 서버 간의 연결은 하나의 TCP 연결을 통해 이루어진다.

• Pipelining(파이프라이닝): 이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 요청을 전송할 수 있다.

• 일반적으로 HTTP 서버는 일정 기간 사용되지 않으면 연결을 닫는다.

• HTTP의 디폴트 모드는 파이프라이닝을 이용한 지속 연결을 사용한다.

D) HTTP Message Format

HTTP Request Message

1. 메세지가 일반 ASCII 텍스트로 쓰여 있어 사람들이 읽을 수 있다.
2. 메세지가 다섯 줄로 되어있고 각 줄은 CR(carriage return)과 LF(Line Feed)로 구별된다.
3. 마지막 줄에 이어서 CR과 LF가 따른다.

HTTP 요청 메시지의 첫 줄은 요청 라인이라 부르고, 이후의 줄들은 헤더 라인이라고 부른다.

Request Line

• 3개의 필드(Method field, URL field, HTTP version field)를 갖는다.
• Method field: GET, POST, HEAD, PUT, DELETE를 포함하는 여러 가지 값을 갖는다.
• 위의 그림에서는 /somedir/page.html 객체를 요청하고 있다.

Header Line

• Host: www.someschool.edu는 객체가 존재하는 호스트를 명시하고 있다.
  • 이미 호스트까지 TCP 연결이 맺어져 있어 불필요하다고 생각될 수 있지만, 웹 프록시 캐시에서 필요로 한다
• Connection: close는 브라우저가 서버에게 지속 연결 사용을 원하지 않다는 것을 말하고 있다.
• User-agent: Mozilla/5.0는 사용자 에어전트, 즉 서버에게 요청을 하는 브라우저 타입을 명시하고 있다.
  • 다른 타입의 서버 에이전트한테 전송할 시 필요하다.
• Accept-language: fr는 헤더는 사용자가 객체의 프랑스어 버전을 원하고 있음을 나타낸다.

Entity Body

GET 방식에서는 비어있고 POST 방식에서 사용된다.

• POST 방식에서 Entity Body는 사용자가 Form field에 입력한 것을 포함한다.

POST Method

• 주로 사용자가 폼을 채워 넣을 때 사용된다.
• POST 메세지는 사용자가 서버에 웹 페이지를 요청하고 있으나, 웹 페이지의 특정 내용은 사용자가 폼 필드에 무엇을 입력하는가에 달려 있다.

HEAD Method

서버가 HEAD 방식을 가진 요청을 받으면 HTTP 메세지로 응답하는데, 요청 객체는 보내지 않고 Header만 보낸다.

PUT Method

웹 서버에 업로드할 객체를 필요로 하는 애플리케이션 의해 사용된다.
Entity Body의 존재하는 내용으로 교체한다.

DELETE Method

사용자 또는 애플리케이션이 웹 서버에 있는 개체를 지우는 것을 허용한다.

HTTP Response Message

Status Line, 6개의 Header Line, Entity Body로 이루어져있다.

Status Line

• HTTP/1.1: version field
• 200: status code
• OK: status message

Status code & message

200 OK: 요청이 성공했고, 정보가 응답으로 보내졌다.
301 Moved Permanently: 요청 객체가 영원히 이동되었다. 이때, 새로운 URL은 응답 메시지의 Location 헤더에 나와있다.
400 Bad Request : 서버가 요청을 이해할 수 없다.
404 Not Found : 요청한 문서가 서버에 존재하지 않는다.
505 HTTP Version Not Supported : 요청 HTTP 프로토콜 버전을 서버가 지원하지 않는다.

Header Line

• Connection : 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫을지 말지 결정한다.
• Date : HTTP 응답이 서버에 의해 생성되고 보낸 날짜와 시간을 나타낸다.
• Server : 메시지가 어떤 웹 서버에 의해 만들어졌는지 나타낸다.
• Last-Modified : 객체가 생성되거나 마지막으로 수정된 시간과 날짜를 나타낸다.
• Content-Length : 송신되는 객체의 바이트 수를 나타낸다.
• Content-Type : 개체 몸체 내부(Entity body)의 객체가 어떤 타입인지 나타낸다.

브라우저는 브라우저 타입과 여러 설정, 캐싱하고 있는지에 따라 헤더 라인을 동적으로 생성하고 웹 서버도 비슷하다.

E) Interaction between user and server

Cookie

서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하기 원하는 등의 이유로 웹사이트가 사용자를 확인하기 위해 사용한다.

Cookie의 네 가지 요소

1. HTTP 응답 메시지 쿠키 헤더 라인

2. HTTP 요청 메세지 쿠키 헤더 라인

3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일

   • cookie file kept on user's host, managed by user's browser

4. 웹사이트의 백엔드 데이터베이스

위 그림을 이용한 쿠키 동작 과정

과거에 수잔이 이베이 사이트를 방문한 적이 있다고 가정한다.

1. 아마존 웹 서버에 HTTP 요청 메시지를 전달한다.

2. 아마존 웹 서버는 유일한 식별 번호를 만들고 이 식별 번호로 인덱싱 되는 백엔드 데이터 베이스 안에 엔트리를 만든다.

3. 이후 아마존 웹 서버는 HTTP 응답 메시지에 Set-cookie: 1678 식별 번호의 헤더를 포함해서 전달한다.

4. 브라우저는 그 헤더를 보고, 관리하는 특정한 쿠키 파일에 그 라인을 덧붙인다. 이때, 수잔이 과거에 이베이 사이트를 방문했기 때문에 쿠키 파일을 이베이에 대한 엔트리를 갖고 있다.

5. 다시 동일 웹 서버에 요청을 보낼 때, 브라우저는 쿠키 파일을 참조하고 이 사이트에 대한 식별번호를 발췌하여 Cookie : 식별 번호의 헤더를 요청과 함께 보낸다.

이렇게 웹 서버는 사용자를 식별할 수 있고 서버는 사용자별로 제품을 추천할 수 있게 된다.

Cookie는 stateless HTTP 위에서 사용자 세션 계층을 생성하는 데 이용되고 사용자 식별에 사용할 수 있다.

F) Web Caching

Web Cache

Proxy server라고도 하며 Origin Web Server를 대신하여 HTTP 요청을 충족시키는 네트워크 개체

• 자체 저장 디스크를 가지고 있어 최근 호출된 객체의 사본을 저장 및 보존한다.
• 일반적으로 ISP가 구입하고 설치한다.

위 그림에서는 브라우저가 사용자의 모든 HTTP 요청이 웹 캐시에 가장 먼저 보내지도록 구성되어있다.

브라우저가 http://www.someschool.edu/canpus.gif라는 객체를 요구한다고 생각해보자.

1. 브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다.

2. 웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인한다. 저장되어 있다면 웹 캐시는 클라이언트 브라우저로 HTTP 응답 메세지와 함께 객체를 전송한다.

3. 웹 캐시가 객체를 가지고 있지 않다면, 웹 캐시는 기점 서버인 www.someschool.edu로 TCP 연결을 설정한다. 그리고 나서 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 이러한 요청을 받은 후에 기점 서버는 웹 캐시로 HTTP 응답 메세지와 함께 객체를 보낸다.

4. 웹 캐시의 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메세지와 함께 객체의 사본을 (클라이언트 브라우저와 웹 캐시 사이에 이미 설정된 TCP 연결을 통해) 보낸다.

캐시(cache)는 요청과 응답을 모두 하는 클라이언트이면서 서버이다.
server for original requesting client
client to origin server

Web Cache의 장점

1. Web Cache는 클라이언트의 요구에 대한 응답 시간을 줄일 수 있다.

   • 클라이언트와 기점 서버 사이의 병목 대역폭이 클라이언트와 캐시 사이의 병목 대역폭에 비해 매우 작을 때 효과적이다.
   • 클라이언트와 캐시 사이에 높은 속도의 연결이 설정되어 있고 캐시가 요청된 객체를 갖고 있다면, 캐시는 그 객체를 클라이언트로 매우 신속하게 전달할 수 있다.

2. Web Cache는 한 기관에서 인터넷으로의 접속하는 링크상의 웹 트래픽을 대폭으로 줄일 수 있다.

   • 트래픽을 실질적으로 줄임으로써 성능을 개선할 수 있다.

평균 객체의 크기가 1 Mb, 기관 브라우저로부터 기점 서버에 대한 평균 요청 비율이 초당 15 요청이라고 가정하자. 네트워크나 접속 회선에 어떤 트래픽도 발생시키지 않는다. 또한 위 그림에서 접속 회선의 인터넷 부분 라우터가 HTTP 요청을 전달하고 응답을 받을 때까지 평균 소요 시간(인터넷 지연)은 2초라 가정하자.

총 응답 시간

브라우저의 요청으로부터 객체 수신까지 걸리는 시간

• LAN 지연과 접속 지연(라우터 간의 지연), 인터넷 지연의 합과 같다.
• LAN 지연(La/R): (15 요청/초) X (1 Mb/요청) / (100 Mbps) = 0.15
• 접속 회선 지연: (15 요청/초) X (1 Mb/요청) / (15 Mbps) = 1
  • 접속 회선 지연의 경우, 트래픽 강도가 1에 가까움으로 회선의 지연은 매우 커지고 한없이 증가한다.

  2.12 그림에서 접속 회선 지연 해결 방법

1. 접속률을 15 Mbps에서 100 Mbps로 늘리는 방법

   • 접속 회선 지연이 0.15까지 트래픽 지연을 낮출 수 있다.
   • 이 경우에 총 응답 지연은 약 2초이다.

2. 접속 회선을 증설하지 않고 기관 네트워크에 웹 캐시를 설치하는 방법

캐시가 만족시킨 요청의 비율(hit rate)은 일반적으로 0.2 ~ 0.7이며, 이 예시에서는 0.4의 적중률(캐시가 만족시킨 요청의 비율)을 가진다고 가정하자.

• 캐시와 클라이언트는 고속 LAN으로 연결되어 있어, 요청의 40%는 캐시에 의해(0.01초 이내) 즉시 만족된다.

• 나머지 60%의 요청은 여전히 기점 서버에 의해 만족되어야 하므로 트래픽 강도는 1.0에서 0.6으로 감소한다. (1.0 * 0.6)

• 이 경우의 평균 지연은 0.4 X (0.01초) + 0.6 X (2.01초) = 1.2초이다.

Content Distribution Network

CDN 회사는 인터넷 전역을 통해 많은 지역적으로 분산된 캐시를 설치하고 있으며 이를 통해 많은 트래픽을 지역화하고 있다.

Conditional GET

복사본이 클라이언트의 캐싱된 이후에 웹 서버에 있는 객체가 갱신되었을 수도 있다. 이런 경우에 클라이언트가 브라우저로 전달되는 모든 객체가 최신의 것임을 확인하면서 캐싱을 하게 해주는 방식

Conditional GET의 특징

1. GET 방식 사용
2. If-Modified-Since: 헤더 라인을 포함

Conditional GET 작동 과정

1. 브라우저의 요청을 대신해서 프록시 캐시는 요청 메시지를 웹 서버로 보낸다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com

2. 웹 서버는 캐시에게 객체를 가진 응답 메시지를 보낸다.

HTTP/1.1 200 OK
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(data data data data data ...)

캐시는 요청하는 브라우저에게 객체를 보내주고 자신에게도 객체를 저장한다.
중요한 것은 캐시가 객체와 더불어 마지막으로 수정된 날짜를 함께 저장한다는 것이다.

3. 일주일 후에 다른 브라우저가 같은 객체를 캐시에게 요청하면 캐시에 저장되어 있다. 이 객체는 지난주에 웹 서버에서 수정되었으므로, 브라우저는 조건부 GET으로 조사를 수행한다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 9 Sep 2015 09:23:24

If-modified-since 값이 일주일 전에 서버가 보낸 Last-Modified 값과 완벽히 일치한다. 이 조건부 GET은 서버에게 If-modified-since에 명시된 값 이후 수정된 경우에만 그 객체를 보내라고 한다.

4. 만약 수정되지 않았다면

HTTP/1.1 304 Not Modified
Date: Sat, 10 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
(empty entity body)

위와 같은 응답을 보낸다.
데이터가 변화가 없어도 객체를 보내는 것은 대역폭을 낭비하는 것이고, 특히 그 개체가 크다면 사용자가 느끼는 응답 시간이 증가된다. 304 Not Modified라는 status line은 클라이언트에게 요청 객체의 캐싱된 복사본을 사용하라는 것을 의미한다.

HTTP/2

HTTP/2의 주요 목표는 하나의 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간을 줄이는 데 있으며, 요청 우선순위화, 서버 푸시, HTTP 헤더 필드의 효율적인 압축 기능 등을 제공한다.

HOL Blocking Problem

비디오 아래 수많은 작은 객체들을 포함할 때 서버와 클라이언트 사이에 저속에서 중간 속도의 병목 링크가 있다고 하자.

비디오 클립은 병목 링크를 통과하는데 오래 걸리는 반면, 작은 객체들은 비디오 클립 뒤에서 기다림이 길어진다.

즉, 비디오 클립이 객체들을 블로킹하게 된다.

HTTP/2 framing

각 메세지를 작은 프레임으로 나누고, 같은 TCP 연결에서의 요청과 응답 메세지를 끼워넣는다.

HTTP/2의 주요 목표 중 하나는 하나의 웹 페이지를 전송하기 위한 병렬 TCP 연결의 수를 줄이거나 제거하는 데 있다.

이는 서버에서 열고 유지되는 데 필요한 소켓의 수를 줄일 뿐만 아니라 목표한 대로 TCP 혼잡 제어를 제어할 수 있게 하는 데 있다.

그러나 웹 페이지를 전송하기 위해 오직 하나의 TCP 연결만을 사용하게 될 경우에 HTTP/2는 HOL 블로킹을 피하기 위해 신중하게 구현된 메커니즘이 필요하다.

HTTP/2 프레이밍(framing)이란, HTTP 메시지를 독립된 프레임들로 쪼개고, 인터리빙(interleaving)하고, 반대편 사이트에서 재조립하는 것이다.

예를 들어, 비디오 클립과 크기가 작은 객체 8개의 요청이 들어오면, 서버는 9개의 객체를 보내기 위한 TCP 병렬 요청을 받게된다.

1. 첫 번째 프레임 전송

   • 비디오 클립의 첫 번째 프레임 전송.
   • 첫 번째 작은 객체의 첫 번째 프레임 전송.

2. 두 번째 프레임 전송

   • 비디오 클립의 두 번째 프레임 전송.
   • 두 번째 작은 객체의 첫 번째 프레임 전송.

3. 이러한 패턴 반복

   • 비디오 클립의 프레임과 작은 객체의 프레임을 번갈아 가며 전송합니다.
   • 이를 통해 모든 객체의 프레임이 고르게 전송되도록 합니다.

4. 서버에서 재조립

   • 수신 측에서는 각 프레임을 재조립하여 원래의 비디오 클립과 작은 객체들을 복원합니다.

HTTP 메시지를 독립된 프레임들로 쪼개고 인터리빙하고 반대편 사이트에서 재조립하는 것이야말로 HTTP/2의 가장 중요한 개선점이다.

응답 프레임들은 서버의 프레이밍 서브 계층에 의해 인터리빙된 후 하나의 지속적인 TCP 연결상에서 전송된다.

프레임들이 클라이언트에 도착하면 프레이밍 서브 계층에서 처음 응답메시지로 재조립되며 브라우저에 의해 처리된다. (클라이언트에서 서버로 요청할 때도 마찬가지이다.)

각 HTTP 메시지를 독립적인 프레임으로 쪼개는 것 외에도 프레이밍 서브 계층은 프레임을 바이너리 인코딩한다.

바이너리 프로토콜은 파싱하기에 효율적이고, 더 작은 프레임 크기를 갖고, 에러에 강하다.

메시지 우선순위화

메시지 우선순위화는 개발자들로 하여금 요청들의 상대적 우선 순위를 조정할 수 있게 함으로써 애플리케이션의 성능을 최적화할 수 있게 해준다.

클라이언트가 하나의 특정 서버로 동시에 여러 개의 요청을 할 때, 각 메시지에 1에서 256 사이의 가중치를 부여함으로써 요청에 우선순위를 매길 수 있다.

높은 수치일수록 높은 우선순위를 갖는다.

서버는 가장 높은 우선순위의 요청을 위한 프레임을 제일 먼저 보낼 수 있다.

클라이언트 또한 각 의존도에 따라 메시지의 ID를 지정하여 서로 다른 메시지들 간의 의존성을 나타낼 수 있다.

서버 푸싱

HTTP/2의 또 다른 특징은 서버로 하여금 특정 클라이언트 요청에 대해 여러 개의 응답을 보낼 수 있게 해주는 데 있다.

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

해당 객체들에 대한 요청이 도착하기도 전에 그 페이지와 함께 필요한 추가 리소스들을 클라이언트로 보낸다.

서버는 해당 요청들을 기다리는 데 소요되는 추가 지연을 없앤다.

HTTP/3

트랜스 프로토콜인 QUIC(3장에서 다룬다) 위에서 작동하도록 설계된 새로운 HTTP 프로토콜로서, 완전히 표준화된 상태는 아니다.