ネットワーク

QUIC、教科書が第3のトランスプロトコルとして戴冠

ネットワーク分野の標準教科書の著者が、次版でQUICの重要度をTCPと同格に扱うと宣言した。ついにRPCのためのトランスプロトコルが来たという技術史的含意がある。ただし採用率は現場で足踏みしている。

情報の灯台

2026年4月17日

教科書の著者が「TCPと同等」と書いた意味

4月16日、The Registerにブルース・デイビーの寄稿が載った。デイビーはラリー・ピーターソン(Larry Peterson)と組んで『Computer Networks: A Systems Approach』を書いている人物で、ACMフェロー、元シスコのフェロー、MPLSの設計陣のひとりだ。彼が自分たちの教科書の次版で、QUICの扱いをTCPと同等の分量まで引き上げると書いた。これは軽い宣言ではない。

この教科書は第5版までがオープンソース化されており、オンライン版とGitHubで公開されている。第6版でもQUICは触れられていたが、セクション拡張レベルだった。それが次版ではTCPと釣り合う厚みで書き直される。新しいプロトコルが教科書の紙幅を塗り替える瞬間は、そう頻繁には訪れない。

デイビーは寄稿の中で、RFCが4本・数百ページに及ぶQUICを説明するのは「盲人が象を触るようだ」と書いている。可変長フィールドだらけで、32ビット境界にも揃わない。RFC 9000のパケットヘッダ図はテキストベースで、彼は自分で図を描き直したという。教科書の著者ですら格闘するほどには、この仕様は重い。

この教科書はGitHubとオンラインで公開されており、Creative Commonsライセンスで誰でも読める。新しいプロトコルが長年の標準テキストに大きな紙幅を割り当てられる、という事実の重みは小さくない。

ネットワーク業界が30年待った「第3の椅子」

TCPとUDPの2択で30年以上やってきたインターネットに、第3のトランスプロトコルを加える試みは何度もあった。SCTPが代表例だが、どれも広範な普及には至らなかった。ミドルボックス(NAT、ファイアウォール、ロードバランサ)が既知のプロトコル番号しか通さないからだ。新しいプロトコル番号を名乗ると、途中で落とされる。

QUICはこの壁をUDPの上に自分を隠すことで回避した。外から見ればUDPパケット、中身はQUICという構造だ。デイビーも寄稿で「ミドルボックスのおかげでTCP/UDPの複占は生き延びた」と皮肉を込めて書いている。つまりQUICは、既存の土管を突破したのではなく、土管の中に偽装して入り込んだ。

設計面でQUICが持ち込んだ革新は3つに整理できる。第一にTLSハンドシェイクの吸収。従来はTCPハンドシェイク→TLSハンドシェイク→HTTP、と3段階だった接続確立が、QUICでは1 RTTに圧縮される。条件が揃えば0-RTTでデータ送信まで可能になる。第二に、コネクションIDによる接続の継続。IPアドレスが変わっても(WiFiから4Gに切り替えても)同じ接続が生き続ける。第三に、1つの接続内に複数のストリームを持てる構造だ。

ストリーム分離が解いた「HoLブロッキング」

3つの中で、デイビーが今回の記事で最も紙幅を割いたのがストリームの設計だ。

HTTP/1.1時代、並列リクエストをさばくにはTCPコネクションを複数張るしかなかった。各コネクションはそれぞれ独自の輻輳制御ループを回し、互いの状況を知らずに帯域を取り合う。HTTP/2で多重化が導入されても、下のTCPが順序保証のバイト列である以上、1パケットの損失が同じコネクション上のすべてのリクエストを止める。これが「Head-of-Line(HoL)ブロッキング」と呼ばれる積年の問題だった。

QUICは1コネクションの中に複数のストリームを収め、各ストリームを独立に進行させる。パケットが落ちても、影響はそのパケットに含まれていたストリームだけに限定される。しかも輻輳制御は接続単位でまとめて動くので、帯域の取り合いも起きない。

リクエスト/レスポンス型アプリケーションに向いたプロトコルが、ようやく登場したと言える。デイビーとピーターソンは、この主張を2023年の記事でも繰り返していた。

ここが重要で、QUICは「Webを速くするための改良」として語られがちだが、デイビーの視点は違う。彼らが長年主張してきた「RPCのためのプロトコルはどこにあるのか」という積年の問いへの、ようやくの答えとしてQUICを位置づけている。gRPCのような現代的なRPCフレームワークがHTTPSの上で動いている以上、その下のトランスポートがRPCに最適化されていないと筋が悪い。QUICはその穴を埋めた。

現実は「21%で停滞」

ただし、仕様の完成度と採用率は別の話だ。

Cloudflare Radarの最新データでは、HTTP/3のシェアは21%前後で横ばいになっている。2026年1月に22.16%でピークを打った後、微減している月もある。2023年5月に28%を記録した後、高値を更新できないまま3年が経った格好だ。

技術チェッカーの集計によれば、TLS上のQUIC利用は22.19%、HTTP/3は21.11%で、ほぼ一致する。地理的な偏りも大きい。イタリア30.20%、ブラジル29.27%、インド29.13%と、モバイル中心の新興国で高い。一方でシンガポール7.96%、オランダ10.82%と、データセンター間トラフィックが多い国では低い。

HTTP/3の採用が止まっている理由は、先延ばしではなく物理だ。

この停滞の背景を最も鋭く指摘したのが、2024年のACM Web Conferenceで発表された論文「QUIC is not Quick Enough over Fast Internet」だ。Xumiao Zhangらの研究チームは、500〜600Mbpsを超える回線ではQUICのスループットがHTTP/2を下回り始め、1GbpsではChromeで最大45.2%も遅くなると測定した。根本原因として論文が特定したのは、受信側の処理オーバーヘッドの高さ、とくにQUICがユーザー空間でACKを扱うことによるCPU負荷と、過剰なデータパケット処理だ。

つまり、高速光回線が普及した先進国市場では、QUICの「遅延に強い」という売りが活きない。短いパケットロスや高レイテンシのモバイル回線ならQUICが有利。Akamaiはそうしたシナリオで約30%のレイテンシ削減を測っている。だが帯域が太ければ太いほど、OSカーネルと深く統合されたTCPスタックの方が速くなる局面が増える。

教科書と現場のズレ

ここに興味深いズレがある。教科書の著者は「TCPと同等の重要度を持つ」と書き、一方で現場の測定値は「高速回線ではHTTP/2の方が速い」と言う。どちらも正しい。

デイビーが評価しているのは設計思想の完成度とRPC時代への適合性だ。ストリーム、コネクションマイグレーション、TLS統合といった抽象レベルの価値は、帯域が太かろうが細かろうが変わらない。gRPCのような分散システムの下回りに組み込まれたとき、アーキテクチャとして筋が良いのはQUICの方だ。

一方、Cloudflareのシェア統計が示すのはデプロイの摩擦だ。ファイアウォールがUDPをレート制限する運用慣習、ロードバランサのQUIC非対応、受信側処理のCPUコストの高さ。これらは仕様ではなく、実装とオペレーションの問題であり、時間をかけて解消していくしかない。

教科書が「第3のトランスプロトコル」として正式に認定したことは、この摩擦を押し流す力にはならない。ただし、新しい世代のネットワークエンジニアがQUICをTCPの選択肢としてではなく、TCPと並ぶ基本教養として学ぶようになる。その教育上の影響は、10年単位で表れてくるはずだ。

RFCが4本ある技術は、なぜこうも浸透しにくいか

デイビーが寄稿で触れた「RFCが4本ある」という事実そのものが、QUICの性格をよく表している。RFC 9000(トランスポート)、9001(TLS統合)、9002(輻輳制御)、9114(HTTP/3)と、仕様は細かく分割されている。読むのに相当な体力が要る。

しかも可変長フィールドが至るところに使われているため、パケットヘッダの図を一枚で描くことすら難しい。デイビーが自分で図を描き直さざるを得なかったのはそのためだ。これは仕様のミスではなく、効率と将来対応性のトレードオフを引き受けた結果だと彼は書いている。TCPが32ビット境界に縛られて後悔した歴史を、QUICは繰り返したくなかった。コネクションIDが160ビットまで許容されているのも、この延長線上にある。

設計の緻密さは、そのまま学習コストになる。一次ソースを読み切れる技術者の数は限られる。ここで教科書の役割が浮かび上がる。デイビーとピーターソンがやろうとしているのは、数百ページのRFCを学生が1学期で吸収できる章に圧縮することだ。この翻訳作業がうまくいけば、QUICは次世代のエンジニアにとって「読んで当然のプロトコル」になる。

30年続いたTCP/UDPの複占に、第3の椅子が用意された。座り心地はまだ場所によって硬く、光回線の上ではむしろ居心地が悪い。それでも、標準テキストがTCPと同じ紙幅を割いたという事実は、技術が「辺境」から「共通語」に移ったことの小さくない証拠だ。

参照元