[Network] HTTP/1.0 vs HTTP/1.1 vs HTTP/2

1. HTTP/1.0 vs HTTP/1.1 (이동)
    1. 커넥션 유지 (Persistent Connection)
    2. 파이프라이닝 (Pipelining)
    3. 그 결과
        - HTTP/1.1 의 문제 1 : HTTP HOL (Head Of Line) Blocking 문제
        - HTTP/1.1 의 문제 2: Header 구조의 중복
2. HTTP/1.1 vs HTTP/2 (이동)
    - 메시지 전송 방식의 변화
    - Terminology
    1. 멀티플렉싱 (Multiplexing)
    2. 우선순위 지정 (Stream Prioritization)
    3. 서버 푸쉬 (Server Push)
    4. 헤더 압축 (Header Compression)
        - HTTP/2 의 문제 : TCP HOL (Head Of Line) Blocking 문제
3. HTTP/3 과 QUIC (이동)

 

1. HTTP/1.0 vs HTTP/1.1

---

1. 커넥션 유지 (Persistent Connection)

HTTP 1.0 은 서버로의 request 가 있을 때마다 TCP 연결을 맺어야 하지만, HTTP 1.1 은 Persistent 기능을 이용하여 한 번의 TCP 연결을 통해 여러 번의 request 가 가능하다. 이러한 차이점으로 인해 서버는 TCP 연결로 인한 부하를 줄일 수 있고, 클라이언트는 그만큼 응답속도 개선을 기대할 수 있다. (persistence 는 HTTP 1.0 에서 소개되었으나, 모든 시스템이 이를 지원할 수 있는 것은 아니었다고 함. HTTP 1.1 은 기본적으로 persistence 를 지원.)

2. 파이프라이닝 (Pipelining)

파이프라이닝 기능이 없는 경우 하나의 request 와 response 가 모두 진행된 후, 다음 request 와 response 가 진행된다. 때문에 request 가 많으면 많을수록 매 연결마다 TCP 연결이 필요하므로 응답지연이 늘어날 수 있다. 또한 앞의 request, response 에서 문제가 발생한다면, 다음 request 와 response 는 진행되지 못하게 되는 문제가 발생할 수도 있다. 파이프라이닝은 이를 개선한 것으로 각 request 에 대해 각각 response 를 반환하는 방식으로 앞의 문제를 해결한다.

3. 그 결과

HTTP 1.0, HTTP 1.1(Persistence), HTTP 1.1(Persistence + Pipelining) 을 비교하면 위 이미지 같다고 한다.

HTTP/1.1 의 처리 성능 향상 방법

• 연결지속 (Persistent Connection)
• 파이프라이닝 (Pipelining)

※  HTTP/1.1 의 문제 1 : HTTP HOL (Head Of Line) Blocking 문제

HTTP/1.0 에서 HTTP/1.1 로 넘어오며 연결지속과 파이프라이닝 덕분에 성능측면에서의 큰 향상이 있었다. 하지만 응답순서는 요청 순서에 따라야 하는 HTTP 프로토콜의 규칙으로 인해 HOL 블로킹 문제가 발생하게 되었다.

예를 들어 첫 번째 요청에 대한 응답이 오래걸릴 경우, 두 번째, 세 번째 응답이 함께 지연되는 문제가 발생한다. 이게 HOL Blocking 이다.

※ HTTP/1.1 문제 2 : Header 구조의 중복

HTTP/1.1 헤더에는 많은 정보들이 저장되어 있는데, 사용자가 웹페이지를 이용하며 HTTP request 를 보낼 때 매 request 마다 중복된 헤더값을 전송하게 된다. 때문에 어떠한 경우에는 request 를 통해 전송하려는 값보다 헤더 값이 더 큰 경우도 발생한다고 한다.

 

2. HTTP/1.1 vs HTTP/2

---

▸ 메시지 전송 방식의 변화

기존의 HTTP 메시지는 Plain Text (평문) 을 사용하고, 개행으로 구분되었었다. 하지만 HTTP/2.0 에서는 메시지를 프레임이라는 단위로 나누고, 각 프레임을 바이너리로 인코딩함으로써 파싱, 전송 속도가 더 빨라졌다.

Terminology

• Stream : 하나 혹은 그 이상의 HTTP messages 를 옮기는 TCP 연결 안에서의 양방향 데이터 흐름
• Message : 하나의 완전한 논리적 (request, response) HTTP message 를 이루는 전체 frames
• Frame : HTTP/2 에서의 가장 작은 통신 단위로, 각각 프레임 헤더를 가지며, 프레임 헤더는 프레임이 속한 스트림을 식별한다.

HTTP/2 의 모든 통신은 여러개의 양방향 스트림을 전송하는 단일 TCP 연결에서 수행되며, 각 스트림은 고유의 식별자와 우선순위 정보를 가진다. 또한 스트림에 포함된 각 메시지들은 request, response 와 같은 하나의 논리적 HTTP message 이며, 하나 혹은 그 이상의 프레임들로 구성된다.

1. 멀티플렉싱 (Multiplexing)

HTTP/1.1 은 파이프라이닝을 통해 여러 개의 요청을 한 번에 받을 수 있게 되었다. 하지만 응답순서는 요청순서에 따라야 하기 때문에, 앞선 요청에 대한 응답이 늦어질 경우 전체적으로 지연이 발생할 수 있는 HTTP HOL Blocking 문제가 발생할 수 있었다.

HTTP/2 는 메시지를 독립적인 프레임으로 나누고, 받는 쪽에서 재조립할 수 있도록 하는 multiplexing 을 통해 이러한 한계를 제거했다.

멀티플렉싱은 바이너리 프레임의 스트림 전송 방식을 통해 응답 순서에 무관하게 데이터를 처리한다. 즉 하나의 TCP 연결 안에서 여러 데이터를 병렬적으로 처리할 수 있게 된 것이다. HTTP/1.1 의 파이프라이닝과 HTTP/2 의 멀티플렉싱의 가장 큰 차이는 순차적 응답 처리로 인해 발생할 수 있는 HOL Blocking 문제를 해결했다는 것이다.

2. 우선순위 지정 (Stream Prioritization)

HTTP/1.1 에서는 웹페이지 렌더링에 대해 우선 순위를 정의할 수 없었기 때문에 예를 들어 HTML, CSS, JS, JPG 등 리소스 중 어느 하나가 늦게 전달되는 경우 페이지 렌더링에 지연이 발생하였다.

하지만 HTTP/2 에서는 변화된 HTTP 메시지 전송방식을 통해 덕분에 응답으로 전달될 리소스의 우선순위를 정의함으로써 이러한 문제를 해결하였다.

3. 서버 푸쉬 (Server Push)

HTTP 통신은 클라이언트의 요청으로부터 시작되며, 요청한 컨텐츠에 대해서만 응답으로 전송하게 된다. 때문에 웹페이지 하나를 구성하기 위해서 클라이언트는 예를 들어 HTML, CSS, JS, JPG 등 구성에 관련된 모든 컨텐츠들을 요청해야 했다.

HTTP/2 에서는 서버 푸쉬 기능을 통해 클라이언트가 요청하지 않은 데이터에 대해 서버가 스스로 전송해줄 수 있다.

위 이미지 예시에서는 서버 푸쉬를 통해 HTTP 트랜잭션이 기존 3개에서 1개로 줄임으로써 RTT 가 감소하여 응답속도가 개선될 수 있다.

4. 헤더 압축 (Header Compression)

HTTP/1.1 은 요청과 응답에서 헤더를 이용하여 여러 기능을 지원하였다. 하지만 헤더는 다방면으로 활용할 수 있는 좋은 요소이기도 하면서, 요청/응답마다 같은 정보를 반복해서 전달해야 하는 비효율적인 측면도 존재한다.

때문에 HTTP/2 에서는 중복되는 헤더의 반복 전송을 효율적으로 줄이기 위해 압축을 이용한다. Static/Dynamic Header Table 과 huffman Encoding 기법을 이용하며, Header Table 을 이용하여 HTTP 메시지의 중복 header 를 검출하고, 중복 header 는 header 의 인덱스값만 전송하고, 그렇지 않은 header 는 Huffman Encoding 기법으로 인코딩하여 전송한다. 이러한 방식을 HPACK 압축방식이라 부른다.

※ HTTP/2 문제 : TCP HOL (Head Of Line) Blocking 문제

HTTP/2 에서 request 와 response 는 프레임 단위로 나누어지고, 이러한 프레임은 stream 을 통해 전달된다. 이 때 stream 은 TCP layer 에서는 단순한 패킷이므로, 패킷의 일부가 손실되었을 때 패킷에 포함된 다른 일부 데이터들은 정상적으로 처리될 수 있음에도 불구하고, TCP 는 해당 패킷을 전부 정상적으로 수신할 때까지 해당 패킷을 처리하지 않는다.

우리는 A 와 B 가 처리될 수 있다는 것을 알지만, TCP 는 A, B, C 의 데이터가 담긴 패킷이 전부 정상적으로 도착해야 처리를 할 수 있는 것이다. 이것이 바로 TCP HOL Blocking 문제이다.

 

3. HTTP/3 과 QUIC

---

https://my-codinglog.tistory.com/81

[Network] HTTP/3 과 QUIC 에 대해서

QUIC 에 대한 내용이 상당히 긴 편이어서 글을 따로 분리하였다.