HTTP/3가 널리 지원되지만 실제로는 거의 사용되지 않는 이유

15 hours ago 5

HTTP/3는 2016년부터 개발되었고, 기반 프로토콜인 QUIC은 2013년에 Google에서 처음 도입됨
현재 표준화되어 있고 다음과 같은 폭넓은 지원을 받음
- 95%의 브라우저에서 지원됨
- Cloudflare의 HTTP 요청 중 32%가 HTTP/3 사용
- 웹사이트의 35%에서 HTTP/3 지원이 표시됨 (alt-svc 또는 DNS를 통해)
그러나 주요 언어의 표준 라이브러리에서는 QUIC 및 HTTP/3 지원이 부족함
- Node.js, Go, Rust, Python, Ruby 등에서 표준 라이브러리에 포함되지 않음
- Curl은 최근 HTTP/3 지원을 추가했으나 실험적 상태이며 기본적으로 비활성화됨
- 인기 있는 서버인 Nginx는 실험적 지원 상태이며 기본적으로 비활성화됨
- Apache는 HTTP/3 지원 계획이 없음
- Kubernetes의 Ingress-Nginx는 HTTP/3 지원 계획을 포기함

HTTP/1.1 이후의 필요성

HTTP/3는 높은 대기 시간의 웹 브라우저 및 CDN 트래픽에 유용함
HTTP/2와 HTTP/3가 제공하는 주요 이점:
- 멀티플렉싱으로 응답 대기 시간 감소
- HTTP 헤더 압축으로 트래픽 감소 (HPACK, QPACK 사용)
- 양방향 스트리밍으로 클라이언트와 서버 간의 실시간 데이터 교환 가능
- 우선순위 지정을 통해 중요한 요청을 먼저 처리 가능
HTTP/3의 추가 이점:
- 독립적인 스트림 처리로 패킷 손실이 다른 스트림에 영향을 주지 않음
- 0-RTT TLS 핸드셰이크로 연결 초기화 속도 개선
- 연결 마이그레이션으로 IP 주소 변경 시 연결 유지 가능
- 혼잡 제어 개선으로 성능 및 안정성 향상

HTTP/3의 성능 향상 효과

RequestMetric 벤치마크 결과:
- HTTP/3가 HTTP/1.1 및 HTTP/2보다 빠른 응답 속도 제공
Fastly의 실제 사례:
- HTTP/3에서 첫 바이트까지의 시간이 18% 단축됨

HTTP/3의 지원 부족 문제

HTTP/3는 브라우저 및 CDN에서 폭넓게 지원되지만 일반 개발자가 사용하기 어려움
현재 웹 트래픽의 두 가지 유형:
- 하이퍼스케일 웹: 주요 브라우저와 대형 서버 기반 (Google, Meta, Amazon 등)
- 롱테일 웹: 중소형 서버 및 클라이언트 기반 (백엔드 API, 모바일 앱, IoT 등)
주요 차이점:
- 롱테일 트래픽이 전체 트래픽의 67% 차지
- 하이퍼스케일은 빠른 개발 및 적용 가능, 롱테일은 자원 부족 및 안정성 우선
- 오픈소스 도구에 대한 의존도가 높음

OpenSSL과 QUIC 문제

OpenSSL은 대부분의 오픈소스 네트워킹 도구의 기반임
BoringSSL은 QUIC 지원 API를 2018년에 출시했지만 OpenSSL은 독자적인 QUIC API를 도입함
주요 문제:
- 기존 BoringSSL 기반 구현과 호환되지 않음
- Curl 및 주요 언어는 OpenSSL 의존성을 변경하기 어려움
- Node.js는 OpenSSL 대신 BoringSSL 사용을 검토했지만 실현되지 않음

앞으로의 전망

하이퍼스케일 웹이 HTTP/3를 도입하면서 롱테일 웹과 성능 격차 발생 가능성
HTTP/3 지원 부족으로 다음과 같은 문제 발생 가능:
- 하이퍼스케일 사이트의 속도와 안정성 우위 강화
- HTTP/3 기반 프레임워크가 보편화되면 롱테일 웹은 접근 어려움
- HTTP/3 미지원이 클라이언트 차단 기준으로 사용될 가능성
해결 방안:
- OpenSSL의 QUIC API 문제 해결 필요
- 기존 QUIC 및 HTTP/3 구현과 호환성을 높이는 도구 및 어댑터 개발 필요
- 오픈소스 도구의 HTTP/3 지원 확대 노력 필요

결론

HTTP/3는 분명한 성능 및 안정성 이점을 제공하지만, 현재 하이퍼스케일 기업만이 쉽게 사용할 수 있는 상태임
롱테일 웹에서도 HTTP/3를 쉽게 사용할 수 있도록 도구와 표준 개선이 필요함

Read Entire Article