HTTP/2 손실 지연

여러 요청을 섞어 보내도 TCP의 빠진 조각은 모두를 기다리게 한다

HTTP/2는 하나의 연결 안에서 여러 스트림의 프레임을 교차 전송한다. 그래서 요청별 줄서기는 줄지만, 아래 TCP 바이트 흐름에서 조각 하나가 사라지면 뒤에 도착한 프레임도 순서가 맞을 때까지 멈출 수 있다.

중간 TCP 세그먼트 손실: 뒤 프레임은 도착해도 처리 대기

스트림 1

헤더 At0

데이터 A1t1

데이터 A2손실

데이터 A3대기

재전송복구

완료전달

스트림 3

헤더 Bt0

데이터 B1t1

도착버퍼

대기같은 연결

풀림순서 회복

완료전달

스트림 5

아이콘요청

응답도착

대기빈칸 뒤

대기렌더 지연

풀림그리기

완료캐시

HTTP/1.1은 연결 안 요청 순서가 문제였다 여러 연결을 열어 우회했지만 연결 비용과 브라우저 제한이 부담이었다.

HTTP/2는 앱 계층 대기를 줄였다 프레임을 섞어 보내지만 TCP 순서 복구 지연은 연결 전체로 전파된다.

HTTP/3는 손실 전파를 줄이는 방향이다 QUIC 기반이라 스트림별 복구가 더 독립적이지만 장비 지원도 확인해야 한다.

waterfall에서 같은 연결의 동시 지연을 본다 여러 요청이 같은 순간 밀리면 손실이나 혼잡 제어의 영향을 의심한다.

손실률과 RTT를 함께 측정한다 로컬망에서는 차이가 작아도 모바일망에서는 체감 차이가 커질 수 있다.

자산 쪼개기는 무조건 답이 아니다 많은 작은 프레임이 손실 구간 뒤에서 한꺼번에 밀릴 수 있다.