- 高速有線ネットワーク、WiFi 6/7、5Gのように接続あたり500Mbps〜1Gbps以上が可能な環境で、UDP+QUIC+HTTP/3スタックはTCP+TLS+HTTP/2より最大45.2%低いデータ転送率を示す
- 単純なファイルダウンロードにとどまらず、Chrome、Edge、Firefox、Opera、およびデスクトップ・モバイル環境で、帯域幅が高くなるほどQUICとHTTP/2の性能差が広がる
- パケットトレースとカーネル・ユーザー空間のプロファイリングの結果、ボトルネックは送信側よりも受信側の処理オーバーヘッドに近く、QUIC受信時にはより多くのパケットとユーザー空間でのACK処理が発生する
- アプリケーションへの影響は、DASH動画の最大9.8%のビットレート低下、代表的な100サイト平均で3.0%長いページロード時間につながる
- 緩和には受信側のUDP GROの導入、GSO/GROのQUIC向け改善、受信ロジックの改善、複数CPUコアの活用が必要だが、クライアント端末とOSの多様性が実現を難しくしている
高速ネットワークで明らかになったQUICの性能差
- QUICはUDP上の多重化されたトランスポート層プロトコルであり、HTTP/3のトランスポート基盤としてIETFで標準化された
- Google、Akamai、Meta、Cloudflareなど複数の企業が2013年以降QUICを商用展開しており、HTTP/3とともにWeb性能を変える候補として注目されてきた
- 既存のQUIC性能研究は実装、コンピューティング環境、ネットワーク条件が多様で、その多くは低スループットのユースケースに集中していた
- 測定の焦点は、高速有線リンク、WiFi 6/7、5Gのように接続あたり500Mbps以上または1Gbps以上に達する高速ネットワークでのQUICの挙動である
- 比較対象は単一プロトコルではなく、スタック全体である
- QUIC側: UDP+QUIC+HTTP/3
- 従来側: TCP+TLS+HTTP/2
- 要約上、それぞれQUICとHTTP/2と呼ぶ
ファイルダウンロード実験で確認された違い
- cURLとChromiumベースの
quic_clientを使った単純なファイルダウンロード実験で、輻輳制御アルゴリズム、サーバー構成、ネットワーク条件をそろえて比較した
- 帯域幅が比較的低い約600Mbps未満ではQUICとHTTP/2の性能は似ていたが、より高い帯域幅ではQUICのスループットがHTTP/2より最大15.7%低い
- 帯域幅が大きくなるほど性能差はより明確になり、パケット受信中にQUICは最新のクライアントホストでHTTP/2よりはるかに高いCPU使用率を示した
- 主要ブラウザーでの実験では差がさらに大きくなる
- 対象ブラウザーはChrome、Edge、Firefox、Opera
- Chromeでは帯域幅が約500Mbpsを超えるとQUICが遅れ始める
- 帯域幅が1Gbpsに達すると、QUICはHTTP/2より45.2%遅くなる
- モバイルのようなより非力なクライアントでは差がさらに広がる
Webアプリケーションでの影響
- 性能低下は大容量ファイル転送だけに限られず、断続的なトラフィックパターンを持つアプリケーションでも現れる
- DASH動画チャンクを高速Ethernetと5Gで配信する際、QUICはHTTP/2に比べて最大9.8%低い動画ビットレートを示した
- このQoE低下は、基盤となる帯域幅が十分に高い場合にのみ明らかになる
- Webブラウジング実験では、代表的な100サイト平均でQUICのページロード時間（PLT）がHTTP/2より3.0%長くなる
- ロングテールでは、ページロード時間の差が50%を超えるケースもある
ボトルネックの原因: 受信側処理とユーザー空間ACK
- パケットトレースと性能データを見ると、QUICクライアントはHTTP/2ダウンロード時よりはるかに多くのパケットを受信する
- QUICが高いデータ転送率で受信する際、入力データパケットと対応するACKパケットの間の遅延が大きくなり、QUICパケット処理時間が増える
- 2つの観察結果は、高速インターネットでのQUIC性能低下の原因が受信側の処理能力の限界にあることを示している
- 受信側がボトルネックと指摘される理由は2つある
- サーバーは一般にデスクトップ、ノートPC、スマートフォンのようなクライアントより強力である
- QUICの設計上、データ受信処理には固有の難しさがある
- 詳細なプロファイリングで2つの主な原因が確認された
- 過剰なデータパケット
- 同じファイルをダウンロードする際、カーネル内部のUDPスタックはTCPよりはるかに多くの
netif_receive_skbパケット読み取りを発生させる
- 調査したQUIC実装のいずれも、UDP generic receive offload、すなわちUDP GROを使用していない
- UDP GROは、リンク層モジュールが複数の受信UDPデータグラムをトランスポート層へ渡す前に、1つの大きなデータグラムにまとめる方式である
- これはTCP segmentation offloadが広く展開され、UDP送信側オフロードであるGSOが近年注目されている状況と対照的である
- ユーザー空間ACK処理
- ユーザー空間でQUICは、受信パケット処理と応答生成により高いオーバーヘッドを持つ
- 原因には、カーネルから渡される過剰なパケット、QUIC ACKのユーザー空間処理、QUICのdelayed ACKのような一部最適化の欠如が含まれる
予備測定と緩和の方向性
- Chromeブラウザーで1GBファイルをダウンロードした予備実験では、QUIC有効時にダウンロード時間がおおむね2倍になる様子が見られた
- サンプル結果は10回実行の平均である
- デスクトップEthernet: HTTP/2 9.32秒、HTTP/3 18.60秒で99%増加、CPU使用率は77.5%から96.9%に増加
- Pixel 5 low-band 5G: HTTP/2 37.11秒、HTTP/3 78.65秒で112%増加、CPU使用率は121.55%から161.77%に増加
- Pixel 5 mmWave 5G: HTTP/2 30.10秒、HTTP/3 63.20秒で110%増加、CPU使用率は128.43%から165.20%に増加
- デスクトップのCPU使用率はブラウザーのネットワークサービス基準であり、スマートフォンの測定はブラウザープロセス全体基準である
- CPU使用率が100%を超える値は、マルチコアシステムでブラウザープロセスが1つ以上のコアを使用したことを意味する
- 提案された緩和策は、受信側のUDP GROの導入、GSOとGROのQUIC向け改善、受信側QUICロジックの改善、複数CPUコアによるQUICデータ受信である
- クライアントホストはPC、モバイル機器、組み込み機器と多様なOSで構成され、サーバーより異質性が大きいため、緩和策の実現には実務上の難しさがある
- 測定データとソースコードは当該研究とともに公開されている
1件のコメント
Hacker Newsでの意見
業界は軽いサイトを作ること以外なら何でもやろうとしているように見える
90年代後半でも、高速回線さえあればインターネットは瞬時に反応し、ページは小さく、JavaScriptもほとんどなかった
今でもそうした高速で軽量なページを見つけることはでき、マウスボタンを離す前にページがすべて読み込まれたように感じられて、ほとんど超現実的ですらある
ユーザー体験が良くなっているなら我慢もできただろうが、それすら得られていない
より速く、はるかに堅牢になり、フロントエンドとバックエンド間の状態不整合もなくなった
利便性のために最小限のJavaScriptは認めており、現状は数百行程度で、単一ページアプリのように見えるようにするため、さらに少し追加する予定
これによりReact約4万行とKotlin約2万行をなくせるが、バックエンドコードは約3万行書き直す必要がある
それでも気に入っている
そこで自分のホームページを静的なVUE.JS版に移して経験を積んでみたが、変数名を文字列として渡してビューと状態を結びつけるやり方は奇妙で、ビルド環境の拡張は不必要に複雑で、すべてが遅く、特定のやり方でしかできなかった
皆が使っているのだから正しいのだろうと思っていたが、今ではその考え方から抜け出し、新バージョンは素のHTMLと静的サイトジェネレーターのテンプレートだけで仕上げた
HTMLサイズは90%減り、JS使用量は97%減り、ビルド時間は20秒から2秒になった
ユーザー体験も良くなり、新バージョン以降、訪問数も30%増えた
Webをあまり使わなければ、Webはずっと素晴らしいものになり得る
バックエンドでも、最近の金の卵はAPIで接続するheadless SaaS製品を通じてマイクロサービスを売ることで、性能は当然良くなるだろう、という具合だ
https://macharchitecture.com/
人々がそういうシャベルを買おうとするなら、こちらもそういうシャベルを積み上げるしかないのがITの世界だ
ブログは静的にレンダリングされるHugoサイトなのでJSはまったくなく、プロジェクトはRailsとサーバーレンダリングHTMLベースで、あると便利な機能だけを足す最小限のJSしかない
JSがなくても動く
自分のサイトだからそう言っているだけかもしれないが、Webの大半より体験はずっと良く、私たちはあまりにも多くのものを失ってしまった
Google が純粋な JS ベースの Speedtest を作ったことがある
当時 Ookla はまだ Flash ベースだったため Chromebook では動作せず、設置担当者が設置状態を検証する際に問題になっていた
その過程で、TCP がさまざまな要因にどう反応するかを多く学んだ
この記事の結果はほぼ予想どおりで、フロー制御をカーネル、そしておそらくネットワークアダプタからユーザー空間へ押し出したためだ
TCP にはフロー制御と順序保証があり、QUIC はそれを自前で管理させるものだと言える
もちろん、そうするだけの十分な理由もある
TCP の輻輳制御は現代的な接続速度に追いついていないことで有名で、BBR のような新しいアルゴリズムも登場しているが、代償はある [1]
ネットワークテストや Web アプリケーションテストであまりに頻繁に見落とされる核心は レイテンシ だ
アジアやオーストラリアに住んでいる人なら、100ms の往復遅延がどれほど致命的か分かるはずだ
完全に反応の良かったものをまったく使い物にならないほどにでき、ウィンドウのせいで接続がサポートできる帯域幅を下げ、エラーや輻輳制御にも鈍感にする
ネットワークや Web アプリをテストするなら、ランダムにレイテンシへ 100ms を追加するテストを強く勧める [2]
だから QUIC のオーバーヘッドは実際には重要ではないかもしれない
単一の TCP 接続または QUIC ストリームでの実効帯域幅は、実際の生の帯域幅よりずっと低くなり得るからだ
言い換えれば、45% の追加データがあっても、輻輳制御を直接管理することで 2 地点間の実効速度がより高くなるなら、得になる可能性がある
[1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
[2]: https://bencane.com/simulating-network-latency-for-testing-i...
振り返れば当然だが、TCP では「カーネル、この巨大なバッファを送っておいて」と言えば済む一方、UDP はパケット交換方式なので、0 を送るだけでも多くの OS と一般消費者向けハードウェアではモード切り替えのために CPU コストが大きい
回避策はあるが簡単ではなく、自分の経験ではまだ準備不足で、使える言語・ライブラリ・プラットフォームの選択肢も制限される
おまけに MacBook をバッテリー駆動で使っているとスループットが大きく落ちるのを見たが、おそらく効率コアと関係していそうだ
第二に、QUIC は輻輳制御がうまくなかった
quic-go を使っていたので環境によって異なるかもしれないが、どんなチューニングも大きな助けにはならず、TCP ストリームと同居すると TCP のほうがより多くの帯域を持っていった
第三に、API が妙だ
QUIC 自体は複数のストリームを持つため、TCP のそのまま差し替えられる代替ではない
ただし HTTP/3 をより高いレイヤーで差し替え可能な代替にしようという意図はあるが、それは試していないので語れない
ストリームレベルで作業するなら、念頭に置いておく価値がある
結論としてはかなり敗北した気分だったが、同時に古い友人である TCP の最適化と復元力に改めて敬意を抱いた
本当に驚くべき技術で、OS が常に無料で提供してくれる
TCP の主な問題の一部も、設計上の欠陥というより、保守的またはレガシーなデフォルト値によるものだ
Linux のバッファ制限や Nagle などだ
車輪を再発明するより、単に TCP を改善できればいいと思う
[1]: https://payload.app/
QUIC が出発するには必要な決定だったが、いまや存在するようになった以上、再検討することもできる
QUIC をカーネルで実装するうえで技術的な障害はなく、性能上の利点が大きければ、近いうちに誰かがほぼ確実にやるだろう
差は天と地ほどある
Slow/Fast 4G、3G のプリセットがあり、ダウンロード・アップロード速度、ms 単位のレイテンシ、パケットロス率、パケットキュー長を自分で指定し、パケットの並べ替えも有効にできるカスタムプリセットを作成できる
curl の作者でありメンテナーでもある Daniel Stenberg が、数か月前に curl の HTTP/3 について書いた記事がある: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
彼が強調していたことの一つは HTTP/3 の CPU 使用率の高さで、CPU がスループットを制限するほどだった
このうちどれだけが実装の未成熟さによるもので、どれだけが QUIC の設計そのものの性質なのか気になる
三つ目の提言は UDP GROで、受信 UDP パケットをまとめ、パケット単位の作業を減らしてグループ単位の作業に置き換えるよう、カーネル、理想的には NIC ハードウェアを修正するもの
TCP にはすでにあり、送信側にも TSO や Linux の GSO のような似たものがある
これも未成熟に感じられるが、ハードウェア機能の不足の可能性を考えると、修正はより難しいかもしれない
アブストラクトでは QUIC の ACK 方式のコストに触れているが、その主張は詳しく見ていない
現代の TCP ベースのサーバーで見られる別の機能として、TLS をハードウェアにオフロードするものがある
同時に多くの TCP ストリームを送るサーバーでは、より重要に見える
Linux ではユーザー空間ネットワーキングを使うか、「kernel tls」を通じて可能で、可能な場合はハードウェアにオフロードされる
この機能は、TCP ストリームを「メッセージ」に分割して別スレッドへ送れるようにする Linux 特有の機能とも関係しているが、先行するパケットが失われたときに後続のメッセージを先に渡せるのかは分からない
すべての接続をより高速にする意図だったという印象は受けていない
そういう観点で見れば、トレードオフは筋が通っている
専門家ではないので、詳しい人に訂正してほしい
QUIC は、インターネット中のあらゆるハードウェアやミドルウェアを含めて、新しい TCP や TLS 標準をサポートさせる方法がまったくないために作られた
そのため QUIC は、UDP 上の新しいトランスポート標準をレガシーなインターネットハードウェアの上に載せる、エレガントな解決策である
理想的な世界なら、新しい TCP と TLS の標準を作り、世界中のすべてのインターネットルーターとハードウェアを交換または更新して、より低い CPU 使用率で実装していただろう
テストで CPU に縛られた quiche は 200MB/s 未満で、nghttp2 は 900MB/s を超えていた
CPU がスロットリングされていたのか気になる
HTTP/3 実装が CPU を 4 倍使うなら興味深いが、絶対値がそもそも非常に低かったなら、必ずしも大きな問題ではないかもしれない
「高速なインターネットでは UDP+QUIC+HTTP/3 スタックは TCP+TLS+HTTP/2 と比べてデータ速度が最大 45.2% 低下する」という部分が核心だが、まだ論文全体は読んでいないものの、序論では 600Mbit/s 未満を 低速なインターネットと見ているようだ
Cloudflare を例にすると、クライアント <> エッジ間でのみ QUIC をサポートし、オリジン接続ではサポートしていない
エッジ <> オリジン接続が再利用可能で安定しており「速い」なら筋が通る
https://developers.cloudflare.com/speed/optimization/protoco...
プロトコル自体に根本的な問題があるようには聞こえない
ただしこうした遅延の問題は、CPU をブーストさせる CPU 使用の問題と違って、バッテリー使用量を大きく増やすわけではない
サーバー間通信でも問題ではない
基本的にはエンドユーザー機器で、2024年時点でも非常に高速な接続を使う場合に、高帯域幅転送が「遅くなる」程度の話
ここでいう速度は、広告で買った速度ではなく、実際の端末からサーバーまでの実効速度基準である
論文が役に立たないという意味ではなく、ブラウザー実装は改善されるべきであり、その点をよく示している
ただし論文タイトルはほぼ 100% クリックベイトだ
ギガビットインターネットが普及する時点で、より遅い転送方式へ切り替えるのは明らかに間違いだ
30年後にはもっと速くなっているはずで、回線速度を使い切るためにより古いプロトコルを使わなければならないなら、それは愚かなことだ
9月にも同じ記事が投稿されていた: QUIC is not quick enough over fast internet (acm.org)
https://news.ycombinator.com/item?id=41484991（コメント 327 件）
Brave/Vivaldi/Opera などは意識的に選ぶ必要がある
広告さえ速く届けば、残りは重要ではないという具合だ
これは本当にかなり奇妙に聞こえる
QUIC+HTTP/3 だけでも、単なる QUIC だけでも 900mbps の速度を達成したことがある
悪い TLS 実装か、効率的でない初期実装のように思える
CPU 使用率は第2世代 EPYC コアで約 5% 程度と、かなり平均的だった
余談として、wordpress.org への接続に問題があった
Wordpress を使い始めた頃はドキュメントを問題なく読めていたが、ある時点からウェブサイトにまったく接続できなくなった
Linux とデュアルブートしていたので Windows の問題でもなく、ping は通り、ブラウザを3つ替えても同じだった
サイトに入ると固まったまままったくロードされないか、たまにページが途中でロードを止めた
今日解決策を見つけたが、Chrome の設定で Experimental QUIC Protocol をオフにすることだった
数か月間 wordpress.org への接続問題があったのに、それが QUIC のせいだという表示がまったくなく、不安に感じた
開発者ツールに QUIC 関連のエラーがたまにだけ出ていたおかげで、かろうじて気づけた
このプロトコルのせいでアクセス不能になっているのに、ユーザーには原因が分からないウェブサイトがほかにどれほどあるのか気になる
ここでいう 高速インターネット は 500Mbps のことで、その理由は QUIC がそれ以上では CPU に縛られているように見えるため
テストシステムが一般消費者向けなのか、高性能デスクトップでもなお問題になるのかを確認できるほど詳しくは見ていない
面白いのは、私たちは詳しい内容をよく知らないまま、速い = 良い という理由で「QUIC が新しい HTTP/2 だ」のような考えを暗黙のうちに受け入れている点
新しい 5G スマートフォンは 4G より何倍も速いと言われて買うのと似ている
実際には 1) 私の 4G スマートフォンは一度も 4G の最大速度で動作したことがなく、2) 接続問題はほとんどの場合、インターネット回線の速度ではなく、DNS サーバー、接続先のウェブサイト、通信事業者側の接続多重化装置がトラブルを起こしている場合である
それでも「でも 5G だから」となる
「光ファイバー broadband」の広告で、人々がテレビを見ながら髪が風になびくように演出されているのも笑える
実際にはそんなふうには動作しない
以前は 8Mb 接続でもストリーミングできていたので、300Mb は何かには良いのだろうが、大きな違いを体感できるかは疑問だ
QUIC に 非 TLS モード があればよいと思う
ローカル開発中は、ときどきワイヤ上を何が行き来しているのかをただ見たいだけなのに、これが不要な摩擦をかなり増やしている
そのため、それなしでは動作できない