[HTTP] HTTP/2는 정말로 HOL blocking를 해결했을까?

HOLB(Head of line blocking)

HOLB란 패킷을 전송하고 싶은데 이전 패킷을 전송하는데 지연이 발생해 패킷을 전송하지 못하는 상황을 의미한다. 말 그대로 패킷을 보내고 싶은데 blocking이 발생한 것이다.

HOLB in HTTP/2

HTTP/2는 클라이언트와-서버 간 하나의 연결을 사용한다. 그리고 요청-응답을 스트림으로 관계를 맺어 병렬로 데이터를 전송한다. HTTP 상에서는 병렬로 데이터를 전송하기 때문에 HOLB가 없다. 단, 애플리케이션 레이어 한정이다.

HOLB in TCP

그런데, HTTP가 어느 layer 위에서 동작하는지 생각해보자. HTTP(L7)는 TCP(L4)/IP(L3) 기반에서 동작한다. TCP는 패킷이 유실되거나, 오류가 있을 때 재전송한다. 재전송 과정에서 패킷의 지연이 발생하게 된다. 결국 TCP는 HOLB를 해결하지 못한다.

HTTP는 애플리케이션 레이어의 프로토콜이다. HTTP에서 아무리 HOLB를 해결했다고 주장해도, TCP에서 HOLB를 해결하지 못하면 HOLB를 해결했다고 말하기 어렵다. 물론 HTTP/2에서는 병렬 스트림 기반으로 패킷을 주고받아 성능이 개선된 것은 사실이다.

HOLB in QUIC(Quick UDP Internet Connections)

출처 : https://peering.google.com/#/learn-more/quic

QUIC은 L7과 L4 사이에 위치한 프로토콜이며, UDP 위에서 동작된다. 앞서 살펴본 것과 같이 TCP는 패킷의 신뢰성 때문에 HOLB를 해결할 수 없다. HOLB를 해결하기 위해서는 L4의 프로토콜을 UDP로 바꾸거나, 개선된 TCP가 필요하다.

QUIC은 UDP 기반에서 동작하지만 TCP의 특성도 가지고 있다. QUIC에서 각 스트림은 독립적이다. 그래서 패킷의 순서와 신뢰성 보장을 스트림 단위로 처리한다. 만약 특정 스트림에서 HOLB가 발생하더라도, 다른 스트림에는 영향을 미치지 않는다!

Ref.

• https://m.blog.naver.com/parkjy76/220886731736
• https://stackoverflow.com/questions/45583861/how-does-http2-solve-head-of-line-blocking-hol-issue
• https://www.youtube.com/watch?v=iR9pV4Z4Sr4&t=2096s