高速インターネットでも十分に速くないQUIC技術

 (arxiv.org)
2 ポイント 投稿者 GN⁺ 2024-10-20 | 1件のコメント | WhatsAppで共有

QUICは高速インターネットでは十分に速くない

  • 研究背景

    • QUICはWebアプリケーションの性能向上に重要な役割を果たすと期待されている。
    • 本論文は高速ネットワークにおけるQUICの性能を体系的に調査している。

  • 主な発見

    • 高速インターネットでは、UDP+QUIC+HTTP/3スタックはTCP+TLS+HTTP/2と比べてデータ転送速度が最大45.2%低下する。
    • 基本帯域幅が増加するほど、QUICとHTTP/2の性能差は大きくなる。
    • この問題はファイル転送だけでなく、動画ストリーミング（最大9.8%の動画ビットレート低下）やWebブラウジングなど、さまざまなアプリケーションに影響する。

  • 分析方法

    • パケットトレース分析およびカーネル空間とユーザー空間のプロファイリングを通じて、問題の根本原因を特定している。
    • 受信側の処理オーバーヘッドが高く、特に過剰なデータパケットとQUICのユーザー空間ACKが原因となっている。

  • 改善に向けた推奨事項

    • 観測された性能問題を緩和するための具体的な推奨事項を提示している。

GN⁺のまとめ

  • この論文は、高速ネットワーク環境におけるQUICの性能問題を分析し、Webアプリケーションの性能向上に寄与しうる重要なインサイトを提供している。
  • QUICの性能低下の原因を受信側の処理オーバーヘッドとして明らかにし、それを解決するための具体的な方策を提示することで、ネットワークエンジニアや開発者に有用な情報を提供している。
  • 類似の機能を持つ別のプロトコルとしてはHTTP/2があり、これとの性能比較を通じてQUICの改善の方向性を示している。

関連記事

1件のコメント

 
GN⁺ 2024-10-20
Hacker Newsの意見

  • 業界は軽量なウェブサイトを作ること以外のあらゆることを試している。90年代後半には、高速なインターネット接続があれば、ページは小さく、JavaScript もほとんどなかった。今日でもこのような高速に読み込まれる軽量ページを見つけることができ、その体験はほとんど超現実的だ。ユーザー体験がもっと良ければ、もっと我慢できただろう。

  • Google で純粋な JS の Speedtest に取り組んでいた。当時、Ookla は Flash ベースだったので Chromebooks では動作しなかった。TCP がさまざまな要素にどう反応するかを多く学んだ。この記事を見て、結果は予想どおりだと思った。なぜなら、フロー制御をカーネルからユーザー空間へ押し出しているからだ。TCP はフロー制御とシーケンシングを持っている。QUIC はそれを自前で管理する。TCP の輻輳制御は現代の接続速度には合っておらず、BRR のような新しいアルゴリズムが必要だが、コストがかかる。最大の教訓は、ネットワークテストでレイテンシの重要性を見過ごしてはならないということだ。アジアやオーストラリアに住む人なら、100ms の RTT レイテンシがどれほど致命的か分かるだろう。QUIC のオーバーヘッドは実際には重要でないかもしれない。というのも、単一の TCP 接続や QUIC ストリームを通じた実効帯域幅は、生の帯域幅よりはるかに低い可能性があるからだ。

  • Curl の創始者でありメンテナーでもある Daniel Stenberg が、HTTP/3 についてブログに書いていた。HTTP/3 の高い CPU 使用率を強調し、CPU がスループットを制限しうると述べていた。これは実装の未成熟さによるものなのか、それとも QUIC の設計方式によるものなのか気になる。

  • 高速なインターネットでは、UDP+QUIC+HTTP/3 スタックは TCP+TLS+HTTP/2 と比べてデータ転送速度が最大 45.2% 低下するという。まだ論文を全部読んでいないが、600 Mbit/s 以下が「遅いインターネット」と見なされている。

  • QUIC は高速なインターネットでは十分に速くないという。quic+http3 で 900mbps の速度を達成したが、TLS 実装が悪いのか、初期実装が非効率なのか疑問だ。CPU 使用率は gen 2 epyc コアで平均 5% 程度だった。

  • ここでいう「高速なインターネット」は 500Mbps のことで、quic は CPU 依存だからだという。テストシステムが一般的なコンシューマー向けシステムなのか、高性能デスクトップでも問題なのかは確認していない。

  • QUIC はレイテンシ向けに最適化されていると思っていた。ウェブページやビデオゲームで小さなパケットを大量に読み込むのに最適化されている。総スループットだけを測る場合には不利かもしれない。プロトコルレベルで大容量ファイル転送や高帯域幅のビデオストリーミングを検出して、より CPU 集約度の低いものに切り替えられるのか気になる。QUIC は TCP よりもハードウェア/OS レベルでの最適化が少ないのだろうか。

  • QUIC に TLS なしモードがあればいいのにと思う。ローカルで開発していると、ときどき転送内容を見たいことがあり、これは不要な摩擦を追加している。