Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — まず、QUICが実際に勝った場所
ところがリンクが速くなると逆転する
犯人捜し — 容疑者を一つずつ消していく
なぜ受信が高くつくのか — GROとユーザースペースACK
意外な点 — 暗号化は犯人ではない
送信側の話 — Googleが2倍まで削ってきた道のり
2026年の試み — QUICをカーネルへ
カーネルに入れれば速くなるのか — 自前ベンチマークを正直に読む
しかしまだメインラインにはない
その45.2%はまだ有効か
では、いつ使い、いつ使うべきでないか
おわりに
参考資料

はじめに — まず、QUICが実際に勝った場所

QUICの話はたいてい「TCPより速い」で始まり、「だからHTTP/3を有効にしよう」で終わります。本稿はその逆側、つまりQUICが負ける条件とその理由を扱います。ただし公平であるためには、まず勝った場所から確認しなければなりません。そしてこれは印象論ではなく、測定された数値があります。

GoogleがSIGCOMM 2017に出したThe QUIC Transport Protocol: Design and Internet-Scale Deploymentは、QUIC実験群とTLS/TCP対照群を同じ規模で並べて比較した結果を表にしています。論文のTable 1とTable 2の平均値を転記するとこうなります。

検索遅延(Search Latency)削減率 — 平均
  デスクトップ  8.0%      モバイル  3.6%

動画遅延(Video Latency)削減率 — 平均
  デスクトップ  8.0%      モバイル  5.3%

動画リバッファ率(Video Rebuffer Rate)削減率 — 平均
  デスクトップ 18.0%      モバイル 15.3%

この利得がどこから来たのかも論文が指摘しています。QUICハンドシェイクの約88%が0-RTTで完了し、その結果ハンドシェイク遅延はRTTにほとんど左右されなくなります。TCP/TLSの平均ハンドシェイク遅延がRTTに比例して直線的に上がる一方、QUICはほぼ平坦です。ここに損失回復の改善が加わり、論文の表現では損失に対する全般的な耐性が高まり、短い接続の遅延が下がるとされています。

3つの留保点を合わせて覚えておくとよいでしょう。第一に、これはGoogleが自社のトラフィックを自社で測定した値です(ベンダー自己測定)。測定対象の母集団はChromeとYouTubeを使うGoogleユーザーで、サーバーもGoogleのサーバーです。あなたのトラフィックミックスではありません。第二に、これはIETF QUICではなく、その前身であるgQUICです。第三に、論文自体が利得の限界を認めています — ハンドシェイク遅延が検索遅延と動画遅延に占める比重は20%に遠く及ばないため、ハンドシェイク遅延を完全になくしても全体の遅延削減はわずかな割合にとどまるということです。

そして同じTable 1には、あまり引用されないセルがあります。モバイル検索の1パーセンタイルと5パーセンタイルの削減率は、それぞれ-0.6%、-0.3%です。マイナスはQUICの方が遅かったという意味です。つまり、すでに最も速い条件にあったモバイルユーザーにとっては、Google自身の測定においてすらQUICはごくわずかに損だったということです。利得はテールに偏っています — デスクトップ検索の99パーセンタイルでは16.7%の削減です。QUICは平均を少し、最悪ケースを大きく改善するプロトコルです。

普及の水準も、もはや実験段階ではありません。W3Techsの2026年7月集計によれば、HTTP/3は全ウェブサイトの39.9%が使用しています(W3Techs自身の調査母集団による)。

ところがリンクが速くなると逆転する

問題は、こうした測定がどんな条件で行われたかです。WWW 2024の論文は既存のQUIC測定研究を洗い直したうえでこうまとめます — その結果は性能向上と(場合によっては)低下が入り混じっており、そのうち多くが低スループット(low-throughput)のケースに集中している、と。リンクが速くなるとどうなるでしょうか。

ミシガン大学などの研究陣によるQUIC is not Quick Enough over Fast Internet(Zhangら、WWW 2024)が、この問いを正面から掘り下げました。結論はタイトルそのままです。論文アブストラクトの文をそのまま移せば、速いインターネットにおいてUDP+QUIC+HTTP/3スタックはTCP+TLS+HTTP/2に対して最大45.2%のデータ転送率低下を被り、その差は基盤の帯域幅が大きくなるほど広がります。

数値は条件とセットで正確に押さえる必要があります。

コマンドラインクライアント(cURL、quic_client)で比較すると、帯域幅が低いとき(おおよそ600 Mbps未満)はQUICとHTTP/2が同程度の性能を出します。それより上に行くとQUICが遅れ始め、最大15.7%まで差が広がります。
ブラウザでは差がさらに大きくなります。Chrome基準で帯域幅がおよそ500 Mbpsを超えるとQUICが遅れ始め、1 Gbpsに達すると45.2%、遅くなります。
クライアントが非力なほど差はさらに広がります。

論文Table 1の1GBファイルダウンロードの予備実験がこの構図をよく示しています(10回平均)。

                       ダウンロード時間(s)     CPU使用率(%)
テストベッド           HTTP/2   HTTP/3       HTTP/2   HTTP/3
デスクトップ、Ethernet   9.32    18.60(+99%)   77.5     96.9
Pixel 5, low-band 5G   37.11    78.65(+112%)  121.55   161.77
Pixel 5, mmWave 5G     30.10    63.20(+110%)  128.43   165.20

注意点 — デスクトップのCPU数値はブラウザのネットワークサービスで測った値であり、スマートフォンの数値はブラウザプロセス全体です。100%を超えるのはマルチコアを使ったことを意味します。つまり、2つの行を直接比較してはいけません。

影響はバルク転送だけにとどまりません。DASH動画配信では最大9.8%のビットレート低下が現れ、代表的な100サイトの平均ページロード時間は3.0%長くなりました(ただしテールでは50%を超える差があります)。ここで論文の観察が鋭いのですが — この低下は4Gでは隠れていて、5Gで表面化します。リンクが遅ければボトルネックがリンク自体なので、QUICのコストが見えないだけなのです。

犯人捜し — 容疑者を一つずつ消していく

ここからがこの論文の本当の貢献です。研究陣は制御実験によって有力な容疑者を一つずつ消していきます。

UDP自体が遅いのか? 違います。同じネットワーク設定でiPerfで測り直すと、UDPとTCPはどちらも1 Gbpsリンクを目一杯埋めます — UDP 958 Mbps、TCP 944 Mbps。むしろUDPの方がわずかに高いのです。カーネルのUDPデータパスは無罪です。

サーバーソフトウェアのせいか? 違います。Nginx-quicに変えてもHTTP/2はほぼ同じで、QUICはむしろ18%遅くなりました。

HTTP文法? 暗号化? パラメータチューニング? クライアントOS? どれも違います。HTTP/3はHTTP/2と事実上同一の文法構造であり、両スタックとも同じTLS_AES_128_GCM_SHA256サイファーを使い、ペーシングとPMTUチューニングは目立った改善をもたらさず、macOSとWindowsの受信者でも同じ結果が出ました。

残る候補は受信側の処理です。2つの観察がここを指し示します。第一に、QUICを使うクライアントが受け取るパケット数がHTTP/2のときよりはるかに多いのです。第二に、QUICが高速で受信するとき、データパケットとそれに対応するACKの間の遅延が大きいのです。平均パケットRTTを測ると、HTTP/2が1.9msなのに対しQUICは16.2msまで跳ね上がります。2台のマシン間のping RTTはわずか0.23msなので、遅延の大部分は回線ではなくエンドポイントのパケット処理から来ているわけです。

論文はこの点を自らの貢献として明示しています — ユーザースペース実装が一般に性能を削ることは知られており、送信側の最適化努力もあったが、受信側がより有力なボトルネックであると突き止めたのは自分たちが初めてだと。理由も添えています。サーバーは通常、デスクトップ・ノートパソコン・携帯電話より強力だからです。私たちが習慣的に「QUICはサーバーCPUを食う」と言うとき、実際に痛むのはユーザーの手元にあるデバイスの方だという意味です。

なぜ受信が高くつくのか — GROとユーザースペースACK

perfでカーネルとChromiumをプロファイリングした結果、2つの根本原因が見えてきます。

第一に、カーネルがパケットを触りすぎている。 1GBファイルを1回受信する間、netif_receive_skbの呼び出しがQUICでは231K回、HTTP/2では15K回でした。15倍の差です。do_syscall_64も17K対4Kで広がります。理由は単純です — TCPはGRO(Generic Receive Offload)で複数セグメントをまとめて上に渡しますが、論文が調査したQUIC実装のうちUDP GROを使っているものは一つもありませんでした。

論文のTable 3がこれを裏付けます。

設定                  送信パケット  受信パケット  時間(s)
QUIC (offload on)         743K         743K     18.60
QUIC (offload off)        744K         744K     18.82
HTTP/2 (offload on)        19K          53K      9.36
HTTP/2 (offload off)      744K         744K     10.84

読み方: HTTP/2はオフロードを有効にするとカーネルが触るパケットが744Kから53Kに減り、時間も10.84秒から9.36秒に落ちます。QUICはオンでもオフでも743K/744Kで変わらず、時間も18.60秒対18.82秒で差がありません。QUICはGRO/GSOの恩恵をまったく受けていません。

ではなぜ単純にオンにすればいいというわけにはいかないのでしょうか。論文は構造的な理由を3つ挙げます。TCPはバイトストリームモデルなのでペイロードを自由に再パケット化できますが、UDPのオフロードロジックはパケット境界を保存しなければなりません。そのため既存のUDP GSO/GROは長さが同一のUDPパケット列のみをオフロードできます。ところがQUICは生まれつきマルチプレクシングなので、異なるストリームのフレームサイズがまちまちで、暗号化後に多重化されます。長さが不揃いなデータグラム列は既存のGSO/GROでは処理できません。さらに、UDPデータグラムを無造作にまとめて一気にバーストで送ると輻輳損失と公平性の問題が生じ、QUICの派生実装が多様なのでNIC側ハードウェアにオフロードロジックを組み込むのも複雑になります。

第二に、ACKをユーザースペースで作っている。 Chromiumネットワーキングスタックの時間分解がTable 4です。

Chromiumネットワーキングスタックの段階       QUIC(8.5s)   HTTP/2(4.1s)
ソケットからUDP/TCPパケットを読む            0.248s        0.037s
UDP/TCPパケットからペイロードを抽出         0.310s        0.084s
QUIC/TLS暗号化パケットを復号                0.660s        0.814s
復号済みQUIC/HTTP2フレームをパース          3.468s        3.182s
QUIC応答(ACKなど)を生成                    2.972s          --
その他                                      0.859s        0.001s

この表からは2つのことを読み取るべきです。

一つは、ACK生成だけで2.972秒がまるごとかかっているという点です。HTTP/2の列にはこの項目自体がありません — TCPのACKはカーネルが作り、遅延ACK(delayed ACK)と受信オフロードといった最適化のおかげでずっと少なく、効率的に出ていきます。QUICはこの作業をユーザースペースで、パケットごとに、しかも遅延ACKのような最適化なしに行います。ダウンロード全体20.6秒のうちQuicChromiumPacketReaderが8.7秒を食い、そのうち3.0秒が応答生成です。

意外な点 — 暗号化は犯人ではない

先ほどの表をもう一度見てください。復号段階ではQUICが0.660秒、HTTP/2が0.814秒です。QUICの方がむしろ速いのです。

「QUICが遅いのは暗号化のせい」というよくある説明は、少なくともこの測定では事実ではありません。QUICはTLS 1.3を、HTTP/2はTLS 1.2を使い、サイファーは同一で、研究陣は別のサイファースイートでもベンチマークしましたが性能への有意な影響はなかったと記しています。コストは暗号演算ではなく、パケットをあまりに多く、あまりに頻繁に、ユーザー・カーネル境界をまたいで触ることにあるのです。

この誤解はかなり広まっているので、指摘しておく価値があります。カーネルバイパスだのハードウェア暗号アクセラレーションだのを検討する前に、自分のボトルネックが本当にAESなのかをまずプロファイリングすべきです。

ただし、対称暗号が永遠に無罪というわけではありません — 後で見るように、送信経路を十分に最適化し切ったあとには、暗号が浮上してきます。順序の問題なのです。

送信側の話 — Googleが2倍まで削ってきた道のり

受信側が新しい発見だとすれば、送信側は古い戦場です。GoogleのIan SwettがSIGCOMM EPIQ 2020で発表したQUIC CPU Performanceのスライドは、この戦いの実測記録です。副題が正直です — 「HTTP/3はHTTP/2やHTTP/1.1と同じくらい効率的になり得るか?」

出発点: 2017年1月時点でQUICのCPUはHTTPS 1.1の2倍でした。初期実装は3.5倍で、明白な修正(高価な関数の重複呼び出しの除去、データパスからのアロケーション除去、コピーの最小化、ワークロード特化のデータ構造)によって2倍まで下がっていた状態です。

ボトルネックの位置も明確です。スライドによればUDP送信がこのワークロードのCPUの25%を占め、一部の環境やベンチマークでは50%を超えます。Linux上でUDPのsendmsgはTCP比で最大3.5倍のcycle/byteを使います。

その後に適用した最適化と、それぞれの実測効果です(すべてGoogle自身の測定)。

UDP GSO                        TCP GSOより7%速い
UDP GSO + ハードウェアオフロード さらに2-3倍
  累積の加速                    理想的には約10倍、通常5倍
  => 最悪50% CPUが5%に、全体で2倍の改善
UDP GRO (パッチ)                受信CPUが35%改善
パケットあたりSTREAMフレーム1個の最適化  単独で5%削減
ACKを少なく送る                 25%削減
  - Quiclyベンチマークで TCPと同等になるのに決定的だった
FDO + ThinLTO                   15% CPU削減

ここで2つのことが目を引きます。

第一に、ACKを減らすだけで25%削減であり、スライドはこれがQuiclyベンチマークでTCPと同等になるのに決定的だったと記しています。WWW 2024の論文が受信側で見つけたACKボトルネックと、まさに同じ場所を指しています。送信者であれ受信者であれ、QUICのACKはコストが高いのです。

第二に、送信を十分速くしたあとは、対称暗号がCPUの約30%を占めるようになります。そしてIETF QUICはヘッダー保護(header protection)のために2パス暗号化が必要で、スライドの表現では小さな暗号演算はバルク暗号化よりはるかに高くつきます。プライバシーのためにCPUを支払う、設計上のトレードオフです。

スライドの見通しも条件付きです — 対称暗号オフロードがあればQUICはkTLSと同じくらい速くなるはずだとしつつ、同時に開かれた問いも残しています。「QUICオフロードはそれだけの価値があるのか? TSOは特に低帯域幅で効果がまちまちだ」と。2020年の発表であることも踏まえて読む必要があります。

2026年の試み — QUICをカーネルへ

ここまで来ると自然な疑問が浮かびます。問題がユーザースペースでパケットを一つずつ触ることにあるなら、そのままカーネルに入れればいいのではないか。

それが今まさに進行中のことです。Xin Longが、Linuxカーネルに QUIC を実装するパッチシリーズを投稿しています。LWNが2025年7月22日にQUIC for the kernelとしてまとめ、その後net: introduce QUIC infrastructure and core subcomponentsとしてv2が上がりました — 15パッチ、9,081行追加、5部作のうち第1〜2部に相当し、EXPERIMENTALと表示されています。

設計はlxin/quicリポジトリにまとめられています。核心はハンドシェイクだけをユーザースペースに残し、残り全部をカーネルに入れることです。

ユーザースペース: 生のTLSハンドシェイクメッセージの処理と生成のみ。GnuTLSのようなTLSライブラリが担当し、カーネルとはsendmsg/recvmsgでメッセージをやり取りし、暗号情報はcmsgで渡します。
カーネル: それ以外のQUICプロトコル全体。ULP層を使う代わりにIPPROTO_QUICタイプのソケットを作り(IPPROTO_MPTCPに似た方式)、UDPトンネルの上で動作します。
カーネル消費者: 既存のnet/handshakeネットリンクを使って、カーネルからユーザースペースへハンドシェイクを要求します。

動機は性能だけではありません。LWNが指摘する点が2つあります。一つはハードウェアプロトコルオフロードを使えるようにすることです — 先ほど見たGSO/GROと暗号オフロードの話がここにつながります。もう一つはカーネル消費者です。Sambaのサーバー・クライアントにQUICサポートを追加するプルリクエストが開かれており、カーネル内のSMBとNFSファイルシステムにもそのサポートを入れようという関心があります。ブラウザはユーザースペースのQUICライブラリをリンクすればそれで済みますが、カーネルNFSクライアントはそうはいきません。

カーネルに入れれば速くなるのか — 自前ベンチマークを正直に読む

では実際に速くなったのでしょうか。lxin/quicリポジトリのREADMEは、100G物理NICで測ったiperf数値を公開しています。これはプロジェクト自身の測定であり、合成ベンチマークであり、実際のワークロードではありません。

まずカーネルQUIC対kTLSです。

UNIT        size:1024      size:4096      size:16384     size:65536
Gbits/sec   QUIC | kTLS    QUIC | kTLS    QUIC | kTLS    QUIC | kTLS
--------------------------------------------------------------------
mtu:1500    1.67 | 2.16    3.04 | 5.04    3.49 | 7.84    3.83 | 7.95
no GSO           | 1.73         | 3.12         | 4.05         | 4.28
--------------------------------------------------------------------
mtu:9000    2.17 | 2.41    5.47 | 6.19    6.45 | 8.66    7.48 | 8.90
no GSO           | 2.30         | 5.69         | 8.66         | 8.82

表面的には惨憺たる結果です。MTU 1500、64KBメッセージでカーネルQUICは3.83 Gbpsなのに対しkTLSは7.95 Gbps — 2倍以上の差で負けています。カーネルに入れても負けているのです。

ところがno GSOの行を見てください。TCP GSOを切ったkTLSは同条件で4.28 Gbpsまで落ちます。カーネルQUICの3.83とほぼ並びます。MTU 9000ではさらに鮮明です — kTLSは8.90からGSOを切っても8.82とほとんど落ちず、QUICは7.48ですでに近づいています。

つまりカーネルQUICとkTLSの差の大半はGSOなのです。 READMEもこれを明記しています — TCP GSOはMTU 1500と大きなメッセージでTCPとkTLSの性能に大きく寄与しており、TCP GSOを切ったあとに残るわずかな差の原因は3つだと。

QUICはTX経路にコピーが一つ多い。
QUICはヘッダー保護のための暗号化が一つ多い。
QUICのストリームDATAのヘッダーがより長い。

暗号化を切ってTCPと並べた表も同じことを語っています。

UNIT        size:1024      size:4096      size:16384     size:65536
Gbits/sec   QUIC | TCP     QUIC | TCP     QUIC | TCP     QUIC | TCP
--------------------------------------------------------------------
mtu:1500    2.17 | 2.49    3.59 | 8.36    6.09 | 15.1    6.92 | 16.2
no GSO           | 2.50         | 4.12         | 4.86         | 5.04
--------------------------------------------------------------------
mtu:9000    2.47 | 2.54    7.66 | 7.97    14.7 | 20.3    19.1 | 31.3
no GSO           | 2.51         | 8.34         | 18.3         | 22.3

MTU 1500、64KBでTCPは16.2 Gbpsで圧倒しますが、GSOを切ると5.04まで沈みます。同じ欄のQUICは6.92です — GSOなしのTCPよりカーネルQUICの方が速いのです。

ここから得るべき結論は「カーネルが答えだ」ではありません。オフロードこそが答えであり、カーネルに入ることはオフロードを使う資格を得ることだ、ということです。TCPが速いのはカーネルにあるからではなく、30年分のオフロードエコシステム(TSO/GSO/GRO、NICハードウェアサポート)を背負っているからです。QUICをカーネルに入れることは、そのエコシステムに並ぶ最初の一歩であって、到着ではありません。

しかしまだメインラインにはない

最も重要な事実をはっきりさせておきます。LWNは2025年7月の記事で「メインラインで見られるようになるのは、どんなに早くても2026年のどこかより前ではなさそうだ」と書きました。

今日(2026年7月16日)時点で直接確認してみました。カーネルツリーにnet/quicディレクトリがあるかどうかを見ればわかります。

# メインライン (torvalds/linux)
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/quic"
# => 404

# net-next (次のマージウィンドウ対象ブランチ)
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/net/quic"
# => 404

# 対照群: すでにマージ済みのnet/mptcp
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/mptcp"
# => 200

メインラインにも、net-nextにもありません。対照群であるnet/mptcpが200を返しているので、URLパターンが間違っているわけでもありません。Linux 7.0が2026年4月に出た今なお、カーネルQUICは外にあります。使いたければout-of-treeモジュールを自分でビルドする必要があり、リポジトリは依然としてEXPERIMENTALを掲げ、5部作のうち第1〜2部しか上がっていません。

LWNが比較対象として挙げた事例が示唆的です — Homaプロトコルは9か月の間に11回のリビジョンを重ねてもマージされませんでした。カーネルネットワーキングサブシステムに新しいプロトコルを入れる作業は、もともとこれくらい遅いのです。「もうすぐカーネルQUICが来るから待とう」は計画にはなり得ません。

その45.2%はまだ有効か

もう一つ正直に触れておくべきことがあります。WWW 2024の論文はChromium v102で測定しました。2022年のビルドです。実装はその後も動いています。

論文の推奨リストの一つが「Chromiumは現在recvmsgでUDPパケットを一つずつ読んでいるが、recvmmsgで複数を一回のシステムコールで読めば受信性能が改善しうる」というものでした。今日Chromiumのソースを開くと、net/socket/udp_socket_posix.hにrecvmmsgをサポートするプラットフォーム(Linux、ChromeOS、Android)ではそれを使うというコメントがあります。推奨事項の一部は反映されたようです。

一方で、同じファイルとnet/socket/udp_socket_posix.ccを見渡した限りでは、UDP_GROを有効にするコードは見当たりませんでした。これは特定の時点で特定の2つのファイルを確認した結果にすぎず、Chromiumにはソケット経路が複数あるので断定の根拠としては弱いのですが、直接確認できる点なので記録しておきます。

したがって45.2%という数字を今日のChromeにそのまま当てはめないでください。その数字が語っているのは正確な倍率ではなくメカニズムです。ユーザースペーストランスポートはカーネルが代わりにやってくれていた仕事(パケットの結合、ACK生成、遅延ACK)を自分でやらなければならず、リンクが速くなってボトルネックが回線からCPUへ移る瞬間にそのコストが表面化する、ということ — このメカニズムは実装が変わっても残ります。倍率はあなた自身の環境で測り直す必要があります。

では、いつ使い、いつ使うべきでないか

ここまでの一次資料を総合すると、判断基準はかなり明確になります。

QUIC/HTTP3が価値を発揮する場合

クライアントが損失のある、RTTの長いネットワークにいる。モバイル、遠距離、不安定な無線。Google測定で利得がテール(99パーセンタイル)に偏っていた理由はこれです。
接続が短くて多い。0-RTT/1-RTTのハンドシェイク利得が相対的に大きくなります。
コネクションマイグレーションが実際に必要である。セルラーとWi-Fiを行き来するクライアント。
リバッファのように最悪区間がユーザー体験を支配する指標を改善したい。

過剰、あるいは損になる場合

リンクが速く、損失がない。データセンター内部、ギガビット有線。WWW 2024論文の条件はまさにこれです。回線がボトルネックでなくなった瞬間、QUICのCPUコストだけが残ります。
大容量バルク転送が主なワークロードである。ファイルダウンロード、バックアップ、大型アーティファクト。
クライアントが非力である。組み込み機器、低価格Android。論文Table 1で差が最も大きかった場所です。
カーネル消費者が必要である。カーネルNFS/SMBはユーザースペースのQUICライブラリをリンクできず、カーネルQUICはまだメインラインにありません。

すでにQUICを使っていて遅いなら、この順番で見てください。暗号アクセラレーションやカーネルバイパスは最後です。

ボトルネックが本当にCPUなのかを確認する。回線がボトルネックならQUICのCPUコストは見えません。
送信側であればUDP GSOから。Google測定ではハードウェアオフロードまで加えれば通常5倍です。
ACKの頻度を見る。送受信いずれも25%前後がかかっています。
その次に暗号を疑う。WWW 2024の測定では、復号はQUICの方がHTTP/2よりむしろ速かったのです。

おわりに

まとめるとこうなります。QUICはハンドシェイクと損失回復で実際に勝ち、その利得は平均よりもテールで大きくなります。そしてリンクが速くなると負けます — ボトルネックが回線からCPUへ移る500〜600 Mbps付近が分岐点で、それより上ではユーザースペーストランスポートが払うコストがそのまま表面化します。

コストの正体は暗号ではなく、パケットを触る回数です。カーネルがGROでまとめてくれないので15倍多いパケットがユーザースペースに上がってきて、カーネルが作ってくれていたACKを、遅延ACKの最適化なしに自分で作らなければなりません。だからこそ2026年の答案が「カーネルに入れよう」なのであり、その答案はまだレビュー中です — メインラインにもnet-nextにもありません。

そのパッチの自前ベンチマークが最後の教訓を与えてくれます。カーネルに入れてもkTLSにほぼ2倍差で負けます。ところがTCPのGSOを切ってみると、差はほとんど消えます。結局これはカーネルかユーザースペースかの問題ではなく、オフロードを使えるかどうかの問題だったのです。TCPが速いのは古いからではなく、古い分だけハードウェアが助けてくれているからです。

QUICにその助けがつくまでには、もう少し時間がかかるでしょう。それまでは、プロトコルを選ぶ前に、あなたのボトルネックが回線なのかCPUなのかをまず測ってください。その答え次第で正解は逆転します。

参考資料

QUIC is not Quick Enough over Fast Internet (Zhangら、WWW 2024、arXiv 2310.09423) — 45.2%の低下、受信側ボトルネック、GRO/ACKの根本原因分析
The QUIC Transport Protocol: Design and Internet-Scale Deployment (Langleyら、SIGCOMM 2017) — Google自身の測定、検索・動画指標の改善
QUIC CPU Performance (Ian Swett、SIGCOMM EPIQ 2020) — Google自身の測定、送信側CPU最適化の実測
QUIC for the kernel (LWN、2025-07-22) — カーネルQUICの動機とタイムライン
net: introduce QUIC infrastructure and core subcomponents (LWN) — v2パッチシリーズ
lxin/quic — In-kernel QUIC implementation with Userspace handshake — 設計とiperfベンチマーク表
HTTP/3 Usage Statistics (W3Techs) — 採用率
HTTP/3とQUICプロトコルの進化 (関連記事)