なぜ「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のみ』を使って書くようにすると、将来のバージョン変更に対しても互換性の懸念がなくなります」

