HTTP/3は広くサポートされているのに、実際にはほとんど使われていない理由

 (httptoolkit.com)
2 ポイント 投稿者 GN⁺ 2025-03-18 | 1件のコメント | WhatsAppで共有
  • HTTP/3は2016年から開発されており、基盤プロトコルであるQUICは2013年にGoogleで初めて導入された
  • 現在は標準化されており、次のような幅広いサポートを受けている
    • ブラウザの95%でサポート
    • CloudflareのHTTPリクエストの32%がHTTP/3を使用
    • Webサイトの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は高レイテンシなWebブラウザおよび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では最初の1バイトまでの時間が18%短縮された

HTTP/3のサポート不足問題

  • HTTP/3はブラウザおよびCDNでは広くサポートされているが、一般の開発者には使いにくい
  • 現在のWebトラフィックには2つのタイプがある:
    • ハイパースケールWeb: 主要ブラウザと大規模サーバー基盤（Google、Meta、Amazonなど）
    • ロングテールWeb: 中小規模サーバーおよびクライアント基盤（バックエンドAPI、モバイルアプリ、IoTなど）
  • 主な違い:
    • ロングテールトラフィックが全体トラフィックの**67%**を占める
    • ハイパースケールは迅速な開発と適用が可能だが、ロングテールはリソース不足と安定性優先
    • オープンソースツールへの依存度が高い

OpenSSLとQUICの問題

  • OpenSSLはほとんどのオープンソースネットワーキングツールの基盤
  • BoringSSLは2018年にQUICサポートAPIを公開したが、OpenSSLは独自のQUIC APIを導入した
  • 主な問題:
    • 既存のBoringSSLベース実装と互換性がない
    • Curlおよび主要言語ではOpenSSL依存関係を変更しにくい
    • Node.jsはOpenSSLの代わりにBoringSSLの採用を検討したが実現しなかった

今後の見通し

  • ハイパースケールWebがHTTP/3を導入することで、ロングテールWebとの性能格差が生じる可能性がある
  • HTTP/3サポート不足により、次のような問題が発生する可能性:
    • ハイパースケールサイトの速度と安定性の優位がさらに強まる
    • HTTP/3ベースのフレームワークが一般化すると、ロングテールWebはアクセスしにくくなる
    • HTTP/3非対応がクライアント遮断の基準として使われる可能性がある
  • 解決策:
    • OpenSSLのQUIC API問題の解決が必要
    • 既存のQUICおよびHTTP/3実装との互換性を高めるツールやアダプターの開発が必要
    • オープンソースツールのHTTP/3サポート拡大への取り組みが必要

結論

  • HTTP/3は明確な性能および安定性の利点を提供するが、現状ではハイパースケール企業だけが容易に利用できる状態にある
  • ロングテールWebでもHTTP/3を簡単に利用できるよう、ツールと標準の改善が必要

関連記事

1件のコメント

 
GN⁺ 2025-03-18
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でサードパーティのQUICスタック向けAPIが提供されるようになった

  • HTTP/2とHTTP/3はもはやアプリケーションレイヤープロトコルではなく、TCPとTLSレベルのものとして認識されている

    • 開発者は依然として「プレーンテキストのHTTP 1.1」の世界に生きている

  • nginxは今なお本番運用に耐えるHTTP/3サポートを提供していない

  • Pythonではniquestsを使用しており、HTTP/3をサポートしている

    • Pythonエコシステムは惰性によりrequestsパッケージにとどまっていた

  • Node.jsはQUICの状況に関する更新を公開しており、OpenSSLのAPIサポートの遅れに苦しんでいる

  • パブリッククラウドプロバイダーのロードバランサーを使う場合、デフォルトでHTTP/3を利用している

    • 自前サーバーを使うサイトはHTTP/3の利点を享受できていない

  • すべてのプロジェクトはある程度オープンソースとコミュニティ主導で進められている

    • HTTP/3を迅速にサポートする必要性を感じていない