HTTP/2 HOL

HTTP/2는 요청 줄서기는 줄였지만 TCP 손실에는 함께 멈춘다

여러 스트림을 한 TCP 연결에 섞어 보내면 연결 수는 줄어든다. 하지만 TCP 바이트 하나가 손실되면 뒤에 온 프레임도 순서 복구를 기다린다.

HTTP/1.1요청마다 연결을 늘리거나 파이프라이닝 순서 대기를 감수한다.
HTTP/2프레임 멀티플렉싱으로 요청 줄서기는 줄지만 TCP 손실은 연결 전체에 전파된다.
HTTP/3QUIC 스트림 단위 복구로 한 스트림 손실이 다른 스트림을 덜 막는다.
상황HTTP/2에서 보이는 현상왜 문제인가
프레임 A2 손실같은 TCP 연결의 뒤 프레임이 대기스트림이 달라도 TCP 순서 복구 전까지 애플리케이션에 못 올라간다.
모바일 RTT 증가작은 손실도 체감 지연으로 확대재전송 왕복 시간이 길수록 전체 연결이 늦어진다.
HTTP/3 전환손실 범위가 스트림 단위로 축소모든 병목을 없애지는 않지만 연결 단위 멈춤은 줄인다.
개선된 점

브라우저 연결 수 제한과 요청 대기 줄이기에는 HTTP/2가 효과적이다.

남은 한계

TCP 순서 보장은 연결 전체 병목이므로 손실률과 RTT를 함께 봐야 한다.

한 줄 결론: HTTP/2 멀티플렉싱은 요청 큐를 줄이는 기술이지, TCP 손실 복구 병목까지 없애는 기술은 아니다.