▲

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

 (httptoolkit.com)
2P by GN⁺ 15일전 | ★ favorite | 댓글 1개
  • 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를 쉽게 사용할 수 있도록 도구와 표준 개선이 필요함
▲
GN⁺ 15일전  [-]
Hacker News 의견

  • 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를 빠르게 지원할 필요성을 느끼지 못함
답변달기