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

> Clean Markdown view of GeekNews topic #19816. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=19816](https://news.hada.io/topic?id=19816)
- GeekNews Markdown: [https://news.hada.io/topic/19816.md](https://news.hada.io/topic/19816.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-03-18T11:10:37+09:00
- Updated: 2025-03-18T11:10:37+09:00
- Original source: [httptoolkit.com](https://httptoolkit.com/blog/http3-quic-open-source-support-nowhere/)
- Points: 2
- Comments: 1

## Summary

HTTP/3는 높은 성능과 안정성을 제공하지만, 주요 언어의 표준 라이브러리에서의 지원 부족으로 일반 개발자들이 사용하기 어려운 상황입니다. 하이퍼스케일 웹에서는 HTTP/3가 널리 도입되고 있지만, 롱테일 웹에서는 자원 부족과 안정성 문제로 인해 도입이 어려워 성능 격차가 발생할 가능성이 있습니다. 이를 해결하기 위해 OpenSSL의 QUIC API 문제 해결과 오픈소스 도구의 HTTP/3 지원 확대가 필요합니다.

## Topic Body

- 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를 쉽게 사용할 수 있도록 도구와 표준 개선이 필요함

## Comments



### Comment 36037

- Author: neo
- Created: 2025-03-18T11:10:37+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43360251) 
- HTTP/3를 완전히 지원하는 인기 있는 오픈 소스 도구를 찾기 어렵다는 의견이 있음
  - IT 관리자와 DevOps 엔지니어들은 주로 로드 밸런서에서 HTTP/3 연결을 종료하고, SSL을 종료한 후 HTTP 1.1을 백엔드 서비스로 전달함
  - HTTP/3와 IPv6는 모바일 중심 기술로, 데이터 센터보다는 일시적이고 불안정한 연결에서 더 유용함

- 주요 언어의 표준 라이브러리에 QUIC나 HTTP/3가 포함되어 있지 않음
  - .NET은 HTTP/3에 대한 괜찮은 지원을 제공하고 있음
  - 대부분의 개발 팀은 네트워킹 중심 제품을 구축하지 않기 때문에 HTTP/3는 우선순위가 낮음

- HTTP/3의 대규모 배포에서 가장 큰 문제는 잠재적으로 취약한 코드의 표면적이 증가한다는 점임
  - 운영 체제가 안전한 소켓 레이어와 동적으로 연결된 SSL 라이브러리를 제공하는 것이 더 바람직함
  - 대부분의 클라이언트 애플리케이션에서는 요청의 몇 밀리초의 지연이 큰 문제가 되지 않음

- QUIC의 느린 채택은 OpenSSL이 기존 QUIC 구현에 필요한 기본 요소를 제공하지 않았기 때문임
  - 최근 OpenSSL 3.5가 제3자 QUIC 스택을 위한 API를 제공하게 됨

- HTTP/2와 HTTP/3는 더 이상 애플리케이션 레이어 프로토콜이 아니라 TCP와 TLS 수준으로 인식됨
  - 개발자들은 여전히 "평문 HTTP 1.1" 세계에 살고 있음

- nginx는 아직도 프로덕션 준비가 된 HTTP/3 지원을 제공하지 않음

- Python에서 niquests를 사용 중이며, HTTP/3를 지원함
  - Python 생태계는 inertia로 인해 requests 패키지에 머물러 있었음

- Node.js는 QUIC의 상태에 대한 업데이트를 게시했으며, OpenSSL의 느린 API 지원으로 어려움을 겪고 있음

- 퍼블릭 클라우드 제공업체의 로드 밸런서를 사용하는 경우 기본적으로 HTTP/3를 사용함
  - 자체 서버를 사용하는 사이트는 HTTP/3의 이점을 누리지 못하고 있음

- 모든 프로젝트는 어느 정도 오픈 소스 및 커뮤니티 주도로 이루어짐
  - HTTP/3를 빠르게 지원할 필요성을 느끼지 못함