“これからのHTTP”は、どう進化する？ 「QUIC」がUDPで構築された背景を知ると見えてくる

　インターネット上でデータを転送するトランスポート層のプロトコルには、TCP[*1]とUDP[*2]の2種類が存在する。ウェブデータを転送するプロトコルとしては、これまで、信頼性のある通信を実現できるTCPが使われてきた。

　長年、運用を通じて改良が積み重ねられてきたTCPは、現在でも重要な通信プロトコルである。しかし、近年では特に「中継装置」と呼ばれる装置により「硬直化」[*3]と呼ばれる現象が発生し、単純なプロトコル拡張でさえ導入できないという事態が起きるようになってきた。

　そのような状態を脱するために誕生したのが、UDPを使用した「QUIC」である。GoogleやMetaなどが自身のサービスに積極的に使用していることもあり、現時点ですでにインターネットの主要なプロトコルの1つとなっている。こうした状況から、今後その使用率がさらに上がってくると考えられるため、インターネット上でサービスを提供しているエンジニアの方々には必須の知識となるであろう。

　米国の公開会社Fastly（ファストリー）の奥一穂（おくかずほ）氏による「QUIC+HTTP/3と、これからのHTTP」は、TCP/IPネットワークの運用経験を持つ技術者を想定し、QUIC誕生の背景から今後の計画までの広範囲な話題と、QUICを前提とするHTTP/3を扱かったものだ（図1）。本座学の内容は技術的によく整理されているため、技術者であればとても参考になると思う。今回は、この記事執筆を機会とし、筆者がQUICについて多くの人に知っていただきたい部分を中心に取り上げていくことにする。

図1　目次

　本チュートリアルでは、最初にTCPがどのようなプロトコルで、どのような機能を持ち、動作を含めてどのようなことをしているかを詳しく述べている。ただし、この話題は後半への伏線で、より理想的な次世代のHTTPを考えた場合、中継装置によって硬直化したTCPというプロトコルは選択肢から外れ、もう1つの選択肢であるUDP上に構築されたQUICを選択することになったこと、そして、どのような目標を持ってそれを実装していくかといった話題に移っていくかたちを取っている。

　解説が「TCPの進化史」から始まるのは、HTTP（HTTP/1からHTTP/2まで）がTCP上で転送されることを前提にしたプロトコルであったからであろう。HTTPのプロトコルがHTTP/2になり、より効率の良い転送や「ヘッドオブラインブロッキング」（以降、HoLブロッキングと呼ぶ）の軽減といった課題については概ね解消されたが、一方で、TCP由来の課題は残されたままとなっていた。

　具体的には、送信側と受信側が実際のデータ送受信を始める前に行う「接続確立ハンドシェイク」と呼ばれる準備のために一定の時間が消費されること、通信中に起きたパケットロスからのリカバリーのために別のリクエストが待たされること（TCPにおける「HoLブロッキング」）などである（図2）。これらは全て、通信に遅延をもたらすものだ。

図2　ヘッドオブラインブロッキング

　もちろん、技術者は、これらの課題に対してさまざまな検討や工夫を行ってきた。しかし、世の中に数多く存在している中継装置が妨げとなり、単純な拡張でさえ通せないことがあるという事実により、TCPの改良や拡張が不自由になってきている（図3、図4）。奥氏は、この点について「ファイアウォールにしてもIDS（攻撃検知システム）にしても、当然、目的があって設定しているわけです。ただ、どうしても、これらの装置というのはTCPの現在の挙動に依存するので、TCP Fast Openのような単純な拡張ですら通らない。通らないだけならまだマシで、変な動きをしてTCPの接続自体が張れなくなってしまうといった問題を引き起こすかもしれない」と述べている。

図3　TCPを「理解」する中継装置

図4　TCPの「硬直化」

　TCPというプロトコルが柔軟性を失い、変化に対応できなくなり、拡張性が失われた状態（＝硬直化している）というのは、逃げられない事実であろう。だからこそ、新しいHTTPを考える際に「UDP上に新しいプロトコルを構築する」という結論になったということである。奥氏は、その理由として、TCPの「中継装置による硬直化」「カーネル実装であるがゆえに進歩が遅い」と「TCP/UDP以外はNAT/ファイアウォールを越えられない」ことの3つを挙げた（図5、図6）。

図5　性能要件

図6　実装基盤

　ここで、QUICの主要な目標（図7）を確認してみよう。この内容を噛み砕いて解説すると、以下のようになる。オリジナルのスライドに番号はないが、今回は説明のために仮で付けていることをお断りしておく。

• （1）接続の高速化を実現すること
• （2）HoLブロッキングなしの多重化を実現すること
• （3）サーバーとクライアントだけ対応させればいいこと（中継装置に手を加えなくてもいいこと）
• （4）誤り訂正技術（FEC：Forward Error Correction）により受信側がリアルタイムに誤りを検出・訂正できること、複数の異なる経路（マルチパス）を使えること
• （5）デフォルトでTLS 1.3を使用した、常に安全なトランスポートを提供すること

図7　Key Goals for QUIC

　（1）と（2）と（5）は、HTTPを使ってきた人にはおなじみのものであろう。遅延の最小化はもとより、通信の内容を第三者に知られないということは重要である。ビジネス分野では、ユーザーが遅延を感じると通信量や売り上げが低下するという話もある（図8）から、その実現は強く要望されることになる。

図8　遅延削減の重要性

　筆者は特に（3）に注目していて、今後の動向を注視している。なぜなら、この件は影響範囲が大きく、うまくいけばHTTPだけでなくDNSなどでも積極的に使われる可能性があるからだ。この基本的な仕組みは、中継装置が見ていい情報をQUICのヘッダーにある「バージョン」と「送信・受信のConnection ID」に限定し、余計な処理をさせないというものである。単純だが、実現されればそれなりのインパクトがあるはずである。

　（4）については、FECとマルチパスに対応できるように設計することを求めている（QUICのバージョン1では見送りになった）。FECについて議論は活発化していないが、マルチパス拡張については標準化が佳境である。

　QUICでは、「Connection ID」というものを使って通信するため、図9のようなメリットも得ることができる。本当に、便利なプロトコルだと感じる。

図9　Invariants

　QUICはUDPを利用し、カーネルではなくユーザーランド[*4]上にTCP同様の信頼性のあるトランスポートを構築する。TCPの長い歴史の中で培われた輻輳制御やロスリカバリー制御の仕組みを継承し、現在のインターネット状況に合った制御を行うかたちになるわけだ。ユーザーランド上で動作することにより、OS側の実装を待つことなく、新しいバージョンを展開できることもメリットだろう。

　企業のように社内ネットワークの通信を監視するような場合、既存のセキュリティ製品による通信監視が困難になることからQUICを使わせないようにすることもありえるが、それは個別に判断すればいいことである。重要なのは、いま目の前にある新しい技術をどう使うか考えることである。そして、考えるためには情報を集めることであろう。

図10　まとめ

　QUICは、とても大きな仕様である。単なる通信ではなく暗号の知識も必要とされるうえ、全体をきちんと理解するためには広範な知識と実装経験が必要と言われるぐらい難解な面を持つプロトコルである。今回チュートリアルを行った奥氏は、その実装経験を持つ日本でも数少ない技術者の一人である。その奥氏がまとめた資料は、ここを理解して欲しいというポイントをきちんと選んでいることから、とても有用だと思う。技術者であれば、ぜひ読んでみていただきたい。

　Internet Weekの講演で使われた資料は一部プログラムを除き、原則、一定期間を経たあとにJPNICのウェブサイトで公開される。今回のInternet Week 2025の講演資料もちょうど先週公開されたところで、「QUIC+HTTP/3と、これからのHTTP」の講演資料（PDF）もダウンロードできる。