HTTP/2로 여러 요청을 한 TCP 연결에서 동시에 보냅니다. 패킷 하나가 유실됐을 때 왜 다른 요청까지 지연될 수 있나요?

HTTP/2는 하나의 연결에서 여러 스트림의 프레임을 섞어 보내므로 HTTP/1.1의 응답 순서 제약을 줄이지만, TCP 위에 있다는 사실까지 없애지는 못합니다. TCP는 하나의 순서 있는 바이트 스트림이므로 그 연결의 앞쪽 세그먼트가 유실되면 뒤의 바이트가 도착해도 애플리케이션에 순서대로 전달되지 않습니다. 따라서 한 스트림의 패킷 손실이 같은 TCP 연결의 다른 스트림까지 지연시킬 수 있습니다.

두 계층의 선두 지연

HTTP/1.1 파이프라이닝에서는 앞 응답이 늦어 뒤 응답이 대기하는 프로토콜 수준의 문제가 컸습니다. HTTP/2의 스트림 다중화는 스트림 ID와 프레임으로 응답을 구분하고 서버가 여러 스트림을 interleave할 수 있게 합니다. 하지만 아래 TCP는 스트림을 모른 채 연결 전체의 바이트 순서를 보장합니다. 앞 구간이 비어 있으면 뒤쪽에 다른 스트림의 프레임이 있어도 TCP 수신 버퍼에서 애플리케이션으로 넘길 수 없습니다. 이를 전송 계층 선두 지연(transport-level head-of-line blocking)이라고 설명하겠습니다.

예를 들어 큰 다운로드 스트림의 프레임과 짧은 RPC 프레임이 같은 연결에서 섞였다고 하겠습니다. 큰 다운로드 앞부분의 세그먼트가 손실되면 TCP가 재전송을 기다리는 동안 RPC 프레임도 읽기 API에서 보이지 않을 수 있습니다. 서버 핸들러가 빠른데도 클라이언트의 여러 요청 p99가 함께 튄다면 스트림별 애플리케이션 시간만 보지 말고 패킷 손실·재전송·RTT와 TCP 수신 대기를 확인해야 합니다. 반대로 한 요청의 처리 큐가 모든 스트림을 막는다면 이는 별도의 애플리케이션 공정성 문제입니다.

HTTP/3와 선택 기준

HTTP/3의 QUIC은 스트림별 전달 상태를 분리해 한 스트림의 손실이 다른 스트림의 바이트 전달을 직접 막는 영향을 줄입니다. 그러나 연결 수준의 혼잡 제어, 암호화 처리, 대역폭, 서버의 동시 스트림·작업 큐는 공유합니다. QUIC이라고 모든 요청이 완전히 독립되거나 손실 비용이 사라지는 것은 아닙니다. HTTP/2에서도 연결을 여러 개로 나누면 영향 범위를 줄일 수 있지만 핸드셰이크·혼잡 제어·서버 연결 수 비용이 커지고, 무작정 연결을 늘리면 공정성이 나빠질 수 있습니다.

검증은 손실·지연·재정렬을 주는 동일한 네트워크 경로에서 작은 요청과 큰 응답을 섞어 HTTP/1.1, HTTP/2, 필요하면 HTTP/3를 비교합니다. 스트림별 응답 시간, 연결별 재전송, TCP·QUIC 혼잡 창, 서버 CPU, 내부 큐를 같은 시간축으로 기록하겠습니다. 프로토콜 선택은 평균이 아니라 짧은 요청의 p99와 전체 자원 비용을 포함해 정하고, 서버 내부의 긴 작업은 별도 큐·실행 예산으로 격리합니다.

여기서 ‘다른 요청이 지연된다’는 말은 서버 핸들러가 실행되지 않는다는 뜻과 네트워크에서 받은 프레임을 애플리케이션이 읽지 못한다는 뜻을 구분해야 합니다. TCP 수신 버퍼에 뒤 스트림의 바이트가 쌓여도 빠진 앞 바이트를 채우기 전까지 순서 있는 스트림으로 내보내지 못하는 것이 핵심입니다. 다만 HTTP/2의 우선순위, 연결별 흐름 제어, 클라이언트의 읽기 스케줄러도 영향을 줄 수 있으므로 패킷 손실 하나만으로 원인을 확정하지 않습니다. 짧은 RPC를 별도 연결에 둘지는 이 비용과 연결 수 증가를 비교해 결정하겠습니다.

연결을 분리하는 대안도 요청 유형별로 제한하겠습니다. 큰 다운로드를 별도 연결에 보내면 짧은 RPC의 손실 영향을 줄일 수 있지만, 연결마다 TLS 상태와 혼잡 제어가 생기고 서버의 연결당 자원이 증가합니다. 따라서 연결 분리는 손실 환경에서 p99가 실제로 좋아지는지, 전체 CPU와 대역폭 예산을 넘지 않는지 확인한 뒤 채택하겠습니다.