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