HTTP/3를 이해하려면 먼저 HTTP가 왜 TCP에서 UDP 기반의 QUIC으로 이동했는지를 봐야 한다. HTTP/1.1과 HTTP/2는 TCP 위에서 동작했다. TCP는 신뢰성 있는 전송을 제공하지만, 연결을 맺고 복구하는 과정에서 지연이 생길 수 있다. 특히 모바일 환경처럼 네트워크가 자주 바뀌는 상황에서는 이 비용이 더 크게 느껴진다.
HTTP/3는 이 문제를 해결하기 위해 QUIC 위에서 동작한다. QUIC은 UDP를 기반으로 하지만, UDP를 그대로 쓰는 것은 아니다. UDP 위에 연결 관리, 손실 복구, 스트림 처리, TLS 1.3을 얹어서 웹에 필요한 신뢰성을 애플리케이션 계층에서 제공한다.
TCP와 UDP의 차이
TCP는 연결 지향적이다. 데이터를 보내기 전에 3-way handshake로 연결을 만들고, 패킷 손실이 발생하면 재전송을 통해 순서를 맞춘다. 이 덕분에 신뢰성은 높지만, 연결 수립과 복구 과정에서 시간이 든다. HTTP/1.1과 HTTP/2는 이 TCP 위에서 동작한다.
UDP는 연결을 만들지 않고 데이터를 보낸다. 그만큼 가볍고 빠르지만, 기본적으로 패킷 순서나 손실 복구를 보장하지 않는다. 스트리밍, 게임, DNS처럼 빠른 전송이 중요한 영역에서 자주 사용된다.
HTTP/3는 TCP 대신 UDP를 선택했지만, 신뢰성을 포기한 것은 아니다. QUIC이 패킷 손실 복구와 순서 제어를 직접 처리하고, TLS 1.3도 프로토콜 안에 포함한다. 그래서 HTTP/3는 UDP의 빠른 연결 특성을 활용하면서도 웹에서 필요한 안정성을 함께 가져간다.
HTTP/2의 한계와 HTTP/3의 개선
HTTP/2는 하나의 TCP 연결 안에서 여러 요청과 응답을 동시에 처리할 수 있다. 이것을 멀티플렉싱이라고 한다. 하지만 TCP 레벨에서 패킷 하나가 손실되면, 같은 연결 위의 다른 스트림도 영향을 받을 수 있다. 이를 Head-of-Line Blocking이라고 부른다.
HTTP/3는 QUIC의 스트림 단위 멀티플렉싱을 사용한다. 특정 스트림에서 패킷 손실이 발생해도 다른 스트림 전체가 함께 막히지 않도록 설계되어 있다. 그래서 네트워크 품질이 불안정한 환경에서 더 안정적인 응답성을 기대할 수 있다.
또 하나의 장점은 연결 복구다. TCP 연결은 IP나 포트가 바뀌면 기존 연결을 유지하기 어렵다. 반면 QUIC은 Connection ID를 사용하기 때문에, 와이파이에서 LTE로 바뀌는 상황에서도 연결을 더 빠르게 이어갈 수 있다. 모바일 환경에서 HTTP/3가 특히 의미 있는 이유다.
TLS와 연결 비용
HTTPS에서는 TLS 핸드셰이크가 필요하다. 서버 인증서를 확인하고, 비대칭키를 이용해 대칭키를 교환한 뒤, 이후 데이터는 대칭키로 암호화한다. 기존 HTTP/2에서도 TLS 세션 재사용을 통해 이 비용을 줄일 수 있지만, TCP 연결과 TLS 연결이 따로 쌓이는 구조라 초기 연결 비용이 남아 있다.
QUIC은 TLS 1.3을 프로토콜에 내장한다. 연결 수립과 암호화 협상을 더 밀접하게 묶어서 처리하기 때문에, 새 연결을 만들거나 기존 연결을 재개할 때 지연을 줄일 수 있다.
Keep-Alive와 연결 재사용
HTTP 성능에서 연결 재사용은 계속 중요했다. HTTP/1.0은 요청마다 연결을 닫는 방식이었고, HTTP/1.1에서는 Keep-Alive를 통해 하나의 연결에서 여러 요청을 처리할 수 있게 됐다. HTTP/2는 멀티플렉싱으로 동시에 여러 요청과 응답을 처리했고, HTTP/3는 이 흐름을 QUIC의 스트림 모델로 가져간다.
API 서버 부하가 크다면 애플리케이션 코드만 볼 것이 아니라, Nginx나 AWS ALB 같은 앞단에서 Keep-Alive, 커넥션 풀, 타임아웃 설정도 함께 확인해야 한다. 연결을 매번 새로 맺는 구조라면 서버 로직이 빨라도 전체 응답 시간은 느려질 수 있다.
인증 토큰과 Stateless 구조
HTTP 자체는 Stateless한 프로토콜이다. 서버는 기본적으로 이전 요청의 상태를 기억하지 않는다. 그래서 인증 정보를 유지하려면 쿠키, 세션, JWT 같은 방식을 사용한다.
쿠키는 브라우저에 저장되고 요청마다 자동으로 전송된다. 세션은 서버에 상태를 저장하기 때문에 제어하기 쉽지만, 서버를 여러 대로 늘릴 때 세션 공유가 필요하다. JWT는 인증 정보를 토큰 안에 담아 클라이언트가 보관하므로 스케일아웃에는 유리하지만, 탈취되면 만료 전까지 취소가 어렵다는 단점이 있다.
Refresh Token을 함께 쓰는 이유도 여기에 있다. Access Token은 짧게, Refresh Token은 상대적으로 길게 가져가면서 재발급 시점에 로그를 남기거나 이상 행동을 감지할 수 있다.
Access Token: 15~30분
Refresh Token: 2주~1달
Refresh 시 서버에서 재발급 및 로그 기록실무에서 “사용자는 로그인했는데 특정 API에서만 401이 난다”는 문제가 생기면 네트워크 프로토콜보다 인증 흐름을 먼저 확인해야 할 때가 많다. Access Token 만료, 서버와 클라이언트의 시계 차이, 로드밸런서의 Authorization 헤더 필터링, HTTPS에서 HTTP로 리다이렉트되며 쿠키가 빠지는 문제 등이 원인이 될 수 있다.
HTTP/3의 핵심은 단순히 “UDP라서 빠르다”가 아니다. UDP 위에 QUIC이 필요한 기능을 다시 설계했고, 그 결과 연결 수립, 네트워크 전환, 스트림 단위 처리에서 기존 HTTP/2보다 나은 선택지를 제공한다. 다만 성능은 프로토콜 하나로 결정되지 않는다. CDN, TLS, Keep-Alive, 인증 구조까지 함께 봐야 실제 서비스의 응답성이 좋아진다.