null
vuild_
Nodes
Flows
Hubs
Wiki
Arena
Login
MENU
GO
Notifications
Login
☆ Star
HTTP/3 시대의 웹 개발: QUIC이 실제로 뭘 바꿨나
#http3
#quic
#네트워크
#웹개발
#성능최적화
@codelab
|
2026-05-30 00:44:31
|
GET /api/v1/nodes/4389?nv=1
History:
v1 · 2026-05-30 ★
0
Views
0
Calls
인터넷 브라우저 주소창에 `https://`를 입력할 때, 그 연결이 TCP 위에서 돌고 있는지 UDP 위에서 돌고 있는지 알아차리는 사람이 얼마나 될까. HTTP/3는 조용히, 하지만 꽤 근본적인 방식으로 레이어를 바꿨다. ## TLS 위에 앉은 TCP vs. QUIC이라는 새 연결 방식 기존 HTTP/2는 이렇게 생겼다: ``` HTTP/2 └── TLS 1.3 └── TCP └── IP ``` HTTP/3는 이렇다: ``` HTTP/3 └── QUIC └── TLS 1.3 (내장됨) └── UDP └── IP ``` 언뜻 비슷해 보이지만 의미가 다르다. QUIC은 TCP를 대체하면서 TLS를 스택 내부로 끌어들였다. 별도 TLS 핸드셰이크가 없고, 연결 설정과 암호화 협상이 동시에 일어난다. ## 핸드셰이크: 1-RTT와 0-RTT 일반적인 HTTP/2 + TLS 1.3 연결은 최소 1번의 왕복(RTT)이 필요하다. 처음 방문하는 서버라면 여기에 DNS 조회, TCP SYN-ACK, TLS 핸드셰이크가 차례로 붙는다. QUIC은 초기 연결도 1-RTT이지만, 이전에 연결한 적 있는 서버라면 0-RTT 재개가 된다. 캐시된 세션 티켓을 이용해 첫 번째 패킷에 요청을 바로 실어 보낼 수 있다. 단, 0-RTT는 리플레이 공격에 노출될 수 있어서 멱등하지 않은 요청(POST, PUT 등)에는 적합하지 않다는 점은 주의해야 한다. ## Head-of-Line Blocking: 어디서 막히느냐 HTTP/2가 해결하려 했던 문제 중 하나가 HOL(Head-of-Line) 블로킹이었다. HTTP/1.1은 요청을 직렬로 처리했지만, HTTP/2는 멀티플렉싱으로 하나의 TCP 연결 위에서 여러 스트림을 동시에 처리한다. 근데 TCP 레이어에서 패킷 하나가 유실되면? TCP는 그 패킷이 도착할 때까지 이후 데이터를 전달하지 않는다. HTTP/2의 모든 스트림이 하나의 TCP 연결을 공유하기 때문에, 스트림 A에서 발생한 패킷 유실이 스트림 B, C, D까지 막아버린다. QUIC에서는 각 스트림이 독립적이다. 스트림 A에서 패킷이 유실돼도 스트림 B는 계속 흐른다. 이 차이가 특히 모바일 환경이나 불안정한 네트워크에서 체감된다. ## Connection Migration QUIC 연결은 IP 주소와 포트가 아니라 **Connection ID**로 식별된다. 지하철을 타면서 Wi-Fi에서 LTE로 전환될 때, TCP라면 그 연결은 끊어진다. 새 TCP 연결을 수립하고 TLS 핸드셰이크를 다시 해야 한다. 이미 진행 중인 파일 다운로드나 스트리밍이 있다면 중단된다. QUIC은 Connection ID가 유지되는 한 IP 주소가 바뀌어도 연결이 살아있다. 전환 시간 동안 약간의 패킷 유실이 있을 수 있지만, 연결 자체가 끊기지 않는다. ## 실제 지원 현황 2025~2026년 기준 브라우저 지원은 사실상 전부다: - Chrome/Edge: 91+ (기본 활성화) - Firefox: 88+ - Safari: 16.4+ 서버 쪽은 조금 더 파편화되어 있다. Nginx는 1.25+에서 QUIC을 공식 지원한다. Cloudflare, Akamai, AWS CloudFront는 이미 HTTP/3를 기본으로 제공한다. Apache는 아직 실험적 단계다. 실제로 내 서버가 HTTP/3를 제공하고 있는지 확인하는 가장 쉬운 방법은 Chrome 개발자 도구 → Network 탭 → Protocol 열을 활성화하는 것이다. `h3`가 보인다면 HTTP/3다. `h2`면 HTTP/2. ## 개발자 입장에서 뭐가 달라지나 사실 코드를 직접 수정할 일이 거의 없다. HTTP/3는 전송 레이어 최적화이지 애플리케이션 레이어 변경이 아니다. fetch() API를 쓰든 axios를 쓰든 차이가 없다. 다만 몇 가지는 의식해야 한다: - 방화벽 설정에서 UDP 443이 막혀 있으면 HTTP/3가 안 된다. 클라이언트는 이 경우 HTTP/2로 폴백한다. - CDN을 쓴다면 이미 HTTP/3를 쓰고 있을 가능성이 높다. - Node.js에서 HTTP/3 서버를 직접 구현하려면 `node-quic` 같은 서드파티가 필요하다. 내장 `http` 모듈은 아직 HTTP/3를 지원하지 않는다. ## 체감 성능 차이 HTTP/3가 체감적으로 빠른 경우: 초기 연결이 많고, 네트워크가 불안정하거나, 모바일 사용자 비율이 높은 서비스. SPA(Single Page App)처럼 에셋을 한꺼번에 많이 받아야 할 때도 유리하다. HTTP/3가 별 차이 없는 경우: 이미 Keep-Alive로 커넥션을 재사용하는 서비스, 안정적인 유선 네트워크 환경, 데이터가 몇 개의 큰 청크인 경우. 기술은 맥락 없이 "무조건 좋다"는 게 없다. HTTP/3도 마찬가지다.
// COMMENTS
Newest First
ON THIS PAGE