なぜ「Semantics」と「Transport」を分けるのか
奥氏がまず取り上げたのは、「HTTP Semantics」という概念だ。かつてHTTPがバージョン1.1しか存在しなかった頃、仕様はプロトコル全体を一体として定義していた。HTTP/2の登場以降、「バージョン間の差分」を管理する複雑さが増し、最終的にIETF（Internet Engineering Task Force）は「意味論（Semantics）」と「通信手法（Transport）」を明確に分離することを選んだ。
現在では、RFC 9110がHTTPの意味論を、RFC 9111がキャッシュを定義し、各バージョン（HTTP/1.1、2、3）はそのSemanticsをどのようにバイト列に変換して送るかを規定するという構造になっている。
この分離がなぜ重要なのか。奥氏は「HTTPプロキシがどう動くかを考えると分かりやすい」と述べた。クライアントからリクエストがHTTP/1、2、3のどれで届こうが、一旦これを内部的にSemanticsに変換し、次にサーバに繋ぐときにまた適切なバージョンに変換して送る。実際にFastlyの中でも、クライアントからHTTP/3で来て、内部でHTTP/2で転送し、Varnishなどのロジックを通ってまた転送し、最終的にオリジンサーバに届くという多段構成になることがある。
この多段構成において、「Hop（ホップ）」はそれぞれ独立したプロトコルのやり取りとして機能する。Connection: closeやTransfer-Encoding: chunkedといったヘッダは「Hop-by-Hop（ホップバイホップ）」の特性を持ち、その区間だけで完結する情報だ。
一方、HTTPメソッドやステータスコード、Content-Typeなどは「End-to-End（エンドツーエンド）」の特性を持ち、クライアントから最終的なオリジンまで引き継がれるSemanticsの一部である。
「今後、新しいアプリを書く際は、この『Semanticsのみ』を使って書くようにすると、将来のバージョン変更に対しても互換性の懸念がなくなります」
標準化が進む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ページの表示や動画の再生開始までの時間短縮が期待される。
Semanticsを軸に設計することが、将来のバージョン変更への備えになる
奥氏が強調したのは「アプリケーションの設計をSemanticsのみに依存させる」という原則だ。HTTPのバージョンはHop-by-Hopの特性を持つ。ConnectionやTransfer-EncodingといったヘッダもHop-by-Hopであり、その区間固有のものだ。対してメソッドやステータスなどはEnd-to-Endヘッダであり、Semanticsの一部として最後まで引き継がれる。
今後、新しいアプリを書く際にこの原則を意識することが、将来のバージョン変更に対しても互換性の懸念をなくす第一歩となる。
Semanticsは不変──変化する部分を標準化で前進させる
奥氏は講演のまとめとして「Semanticsは不変です」と述べた。HTTPのバージョンが変わっても、メソッドもステータスコードもContent-Typeも引き継がれる。変わるのはバイト列への変換方式だけだ。
「私たちは、Incremental HTTPなどの拡張を通じて、HTTPの応用範囲拡大、運用の容易化、そしてユーザー体験の向上に取り組んでいます」──奥氏はそう述べ、「Fastlyはこれらの標準化と対応において大きな役割を果たしています」とセッションを締めくくった。
Fastlyからのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
