標準化が進む5つの技術——HTTPの限界を超える試み
Semanticsの基礎を押さえた上で、奥氏は、IETFを中心に仕様化が進むものから、これから議論を深めていく段階のものまで、標準化途上にある5つの提案を紹介した。いずれもHTTPの応用範囲を広げ、運用の複雑さを解消し、ユーザー体験を底上げしようとする提案だ。
1. Incremental HTTP──双方向通信の「見えない障壁」を壊す
HTTPにはWebSocketへの切り替えや、VPNのような通信で使われる「CONNECT-UDP」など、トンネルを作る仕組みがいろいろある。さらに、通常のHTTP通信はリクエストが完結してからレスポンスを返すモデルだが、仕様上はPOSTデータが全部届く前にレスポンスを返し始めることができる「早期（Early）レスポンス」という仕組みも存在する。これを使えば、HTTPの上で双方向通信やイベント通知のようなことが可能になる。
しかし現実には、インターネット上のプロキシやCDNがこの動作を保証していない。RFCにも「サポートは必須ではない。バッファリングするかもしれないし、動作を保証しない」と明記されており、Fastlyでも1接続あたり最大100リクエストを受け付けるが、POSTの同時処理数には制限がある。制限を超えるとバッファリングされ、アプリ側ではタイムアウトが発生するが、その原因は見えにくい。
この問題に対してApple、Fastly、Mozillaの3社が提案しているのが「Incrementalヘッダ」だ。「リクエストやレスポンスの完了を待たずに転送を開始してくれ」という信号で、このヘッダが付いていれば、プロキシ側でリソース不足で処理できない場合に、ただ待たせるのではなくすぐにエラーを返すことができる。これにより、タイムアウトの原因が明確になり、デバッグや設定変更が容易になる。
2. PTTH（reverse HTTP）──サーバが「受け取りに行く」発想の転換
従来のHTTPは「クライアント→CDN→オリジン（Origin）」という順に繋ぐ流れが前提だった。PTTHはこれを逆転させる。オリジンサーバ側からCDNに接続し、「今は100リクエスト処理できる」と申告してリクエストを受け取りに行く仕組みだ。
「CDN側の設定変更やファイアウォールの穴あけをせずに自動的に負荷分散ができるようになります」と奥氏は説明した。負荷が上がればサーバを増やすだけで対応できる、より柔軟な運用を可能にする仕組みとして議論が進んでいる。
3. QMux──「QUICをどこでも動かす」ための互換レイヤー
QUICは速くて便利だが、UDPが使えない環境もあり、古いアプリはTCP（HTTP/1.1）を使い続けるケースもある。そうなると、開発者は常にTCP用とQUIC用の2つのプロトコルスタックをメンテナンスし続けなければならない。
「だったら、TCP/TLSの上でもQUICが動くようにすればいいじゃないか」というのがQMuxの提案だ。QUICの互換レイヤーをTCPの上に作ることで、すべての開発をHTTP/3（QUICベース）に集約できるようになる。QUICを念頭に、新たに開発されるプロトコルについても、TCP対応を自動的に行うことが可能となる。
4. SCONE──ネットワーク機器とエンドポイントの「協調」
SCONEはエンドポイント（クライアント・サーバ）とネットワーク機器（ルーターや基地局）が協調するためのプロトコルだ。現在のトラフィックの過半は動画配信であり、ネットワークが混雑してくると、ISPなどはIPアドレスなどを見て動画通信を制限（スロットリング）することがあるが、これは誤判定も多く、無線通信の効率も下げてしまう。
SCONEでは、QUICのパケットヘッダに特殊なビットを付け、基地局などのネットワーク機器がそのビットを書き換えることで「今はこれくらいの帯域（例：1.1Mbps）で通信してほしい」という情報をクライアントに伝える。クライアントはそれに合わせた画質の動画を要求するので、ネットワーク効率が上がり、ユーザーも動画の再生開始が早くなるなど、三者にとってメリットがある世界を目指している。
5. Rapid Start──「スロースタート」が動画体験を阻む問題への解答
HTTP/3によって通信開始時の遅延（Time To First Byte：TTFB）は最小限になったが、データが完全にダウンロードし終わるまでの時間（Time To Last Byte：TTLB）も重要だ。これに影響するのが、TCP/QUICの「スロースタート」という仕組みだ。最初は少しずつパケットを送り、確認が取れたら倍にしていく。しかし、日本の高速なモバイル回線などでは、最初からもっと送っても問題ないケースも多い。
Rapid Startは、過去の通信統計などを活用して最初から適切な量のパケットを送信する手法だ。実験では200〜400KBのデータ転送において完了時間が平均18%短縮されており、Webページの表示や動画の再生開始までの時間短縮が期待される。
