16장 HTTP/2와 QUIC가 기다림을 바꾸는 방식

웹페이지 하나를 열기 위해 문서, 스타일, 스크립트, 이미지, 글꼴을 따로 받는 경우가 많다. 각 자원을 매번 새 연결로 순서대로 요청한다면 준비와 기다림의 비용이 커진다. HTTP의 발전에는 이 여러 요청을 효율적으로 운반하려는 고민이 담겨 있다. 숫자가 높은 버전이라는 이유보다 어떤 기다림을 줄이는지 이해하는 편이 유용하다.

HTTP/1.1에서는 연결 재사용이 가능하지만 여러 요청을 처리하는 방식에 제약이 있다. 브라우저는 여러 연결을 사용해 자원을 병렬로 가져오기도 한다. 연결 수를 늘리면 준비 비용과 서버 자원도 늘어난다. 사이트에 작은 파일이 수십 개 생겼을 때 파일 수와 연결 구조가 성능에 영향을 주는 이유다. 다만 현대의 최적화는 프로토콜과 캐시, 압축을 함께 고려해야 한다.

하나의 연결 안에 여러 흐름

HTTP/2는 하나의 연결 안에서 여러 스트림을 다중화한다. 서로 다른 요청과 응답의 프레임을 교차해 전달할 수 있다. 헤더 압축도 사용한다. 이 구조는 응용 계층에서 한 요청의 응답 때문에 다른 요청을 순서대로만 기다려야 하는 부담을 줄인다. 그러나 일반적인 HTTP/2 연결은 TCP 위에서 동작하므로 TCP의 순서 있는 바이트 전달 특성은 남는다.

TCP에서 앞부분의 데이터가 손실되면 뒤쪽에 도착한 바이트도 응용 계층에 바로 전달되지 못할 수 있다. 여러 HTTP/2 스트림이 같은 TCP 연결에 담겨 있다면 한 손실이 여러 스트림의 진행에 영향을 줄 수 있다. “다중화했으니 서로 전혀 영향을 주지 않는다”는 말은 전송 계층을 빠뜨린 설명이다. 계층 사이의 관계가 성능으로 드러나는 지점이다.

UDP 위에 만든 새로운 전송

QUIC는 UDP 위에서 동작하면서 연결 관리, 신뢰성, 혼잡 제어, 암호화 통합 등 전송 기능을 제공한다. HTTP/3는 HTTP 의미를 QUIC 위에서 사용한다. 따라서 UDP를 사용한다는 사실만으로 HTTP/3가 파일 손실을 그냥 무시한다고 생각하면 안 된다. 필요한 데이터를 신뢰성 있게 전달하는 기능은 QUIC에 있다.

QUIC의 스트림은 서로 독립적으로 순서 있는 바이트를 전달할 수 있다. 한 스트림의 빠진 데이터가 다른 스트림의 데이터 전달을 반드시 같은 방식으로 막지는 않는다. 이것은 TCP 연결 전체의 순서 대기와 다른 점이다. 하지만 연결이 공유하는 혼잡 제어와 대역폭, 서버 처리 자원은 여전히 있다. 한 흐름의 문제가 다른 흐름에 어떤 영향도 주지 않는다는 뜻은 아니다.

HTTP/1.1     HTTP/2          HTTP/3
   |            |              |
 TCP          TCP            QUIC
   |            |              |
   IP           IP             UDP
                                |
                                IP

TLS protects HTTPS connections.
QUIC integrates TLS 1.3 into its connection establishment.

이동하면서 연결을 유지할 때

휴대전화가 와이파이에서 이동통신으로 바뀌면 주소와 경로가 달라진다. QUIC의 연결 식별자는 이런 주소 변화와 연결의 관계를 더 유연하게 다룰 수 있게 한다. 실제 이동 지원과 동작은 구현과 정책에 따라 달라진다. 통신이 언제나 끊김 없이 유지된다는 보장은 아니지만, 기존의 주소·포트 조합에만 연결을 묶는 방식과 다른 설계 가능성을 제공한다.

빠른 재연결이나 조기 데이터 전송에도 조건이 있다. 특히 0-RTT 데이터에는 재전송 공격 가능성처럼 별도로 고려해야 하는 성질이 있다. 상태를 바꾸는 민감한 요청을 단지 빠르다는 이유로 무조건 조기 전송 대상으로 삼으면 안 된다. 성능 기능은 보안과 업무 의미를 함께 검토해야 한다. 왕복 하나를 줄이는 것보다 중복 결제를 막는 일이 중요하다.

최신 프로토콜이 느린 페이지를 모두 고치지는 않는다

수십 메가바이트의 불필요한 이미지와 오래 걸리는 데이터베이스 질의를 그대로 둔 채 프로토콜만 바꾸어도 효과에는 한계가 있다. HTTP/3의 이점은 경로의 손실과 지연, 클라이언트 지원, 서버 구현 등 조건에 따라 다르게 나타난다. 실제 사용자의 성공률과 응답 시간을 측정해야 한다. 단일한 벤치마크를 모든 사이트의 미래로 읽지 말자.

일부 네트워크에서는 UDP 트래픽이 제한될 수 있다. 서비스와 브라우저는 지원 가능한 다른 방식으로 연결을 시도할 수 있지만 구체적인 동작은 환경에 따라 다르다. 새 프로토콜을 도입할 때는 주요 사용자 환경에서 성공하는지, 실패 시 어떤 경로를 사용하는지 관찰한다. 지원한다고 표시하는 것과 실제 사용자가 안정적으로 이용하는 것은 다른 지표다.

운영자는 프로토콜별 요청 수와 오류, 지연을 나누어 보고 변경 전후를 비교할 수 있다. 단, 버전 외에 CDN 설정과 캐시 정책, 서버 위치까지 한꺼번에 바꾸면 결과의 원인을 구분하기 어렵다. 가능하면 변경을 작게 나누고 같은 사용자 집단에서 비교한다. 새로운 기술을 도입하는 능력에는 효과가 없을 때 차분히 되돌리는 능력도 포함된다.

HTTP 버전의 변화는 웹의 의미가 매번 완전히 새로 만들어진다는 뜻이 아니다. 요청과 응답이라는 약속을 어떤 전송 구조로 효율적으로 전달할지 발전해 온 것이다. 앞 장에서 배운 메서드, 상태 코드, 캐시, 인증은 계속 중요하다. 오래가는 지식과 바뀌는 구현을 구분하면 새 버전이 나올 때 처음부터 다시 공부하는 느낌이 줄어든다.