HTTPが全てを飲み込む（前編）～HTTPの2層構造と、HTTP Semanticsとは何か？

今回は「HTTPが全てを飲み込む（前編）～HTTPの2層構造と、HTTP Semanticsとは何か？」についてご紹介します。

関連ワード（ホップ、先頭、小文字等）についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

Webを構成する重要な要素の1つであるHTTPは、その最新仕様で2層構造となり、バージョンに関係なく使えるSemanticsと、特徴の異なる通信仕様を定めたHTTP/1.1、2、3に分割されました。

さらに現在では、HTTPの上にあらためてUDPやIP、イーサネットなどのプロトコルを実装する提案が行われており、まさにHTTPは通信の全てを飲み込む勢いで進化しつつあります。

こうしたHTTPの最新動向の解説が、大手CDNベンダのFastlyが2023年11月8日開催したイベント「Yamagoya 2023」で同社シニアプリンシパルエンジニアの奥一穂氏が行ったセッション「HTTPが全てを飲み込む」にて行われました。

本記事ではこのセッションをダイジェストで紹介していきます。記事は以下の3つに分かれています。

HTTPが全てを飲み込む（前編）～HTTPの2層構造と、HTTP Semanticsとは何か？
HTTPが全てを飲み込む（中編）～HTTPの上にIPやイーサネットが実装されて便利になること
HTTPが全てを飲み込む（後編）～アップロードのレジューム機能標準化など開発中の新機能

今お読みの記事は「HTTPが全てを飲み込む（前編）～HTTPの2層構造と、HTTP Semanticsとは何か？」です。

HTTPが全てを飲み込む

Fastly シニアプリンシパルエンジニア奥一穂氏。

皆さん、こんにちは。今日は「HTTPが全てを飲み込む」というタイトルで、チェコ共和国のプラハから話をしたいと思ってます。

なぜ私がプラハに来ているのかというと、IETFの総会に参加しているためです。

IETFは「Internet Engineering Task Force」といって、インターネットを管理しているIANA（Internet Assigned Numbers Authority）という団体の下部組織です。

インターネットで使われる通信プラットフォーム、TCPとかIPとかHTTPとか、そういったものを標準化している団体です。

この団体の118回目の総会が先週末から始まっています。まずハッカソンを2日間やって、通信プロトコルの実装や相互運用試験をやりました。

その後今週金曜日まで会議をやって、既存の仕様のメンテナンスであったり新しいものの開発であったり、そういうことをやっています。

今日はそういった中で、HTTPを中心に今何が起きているのか、という話をさせていただきたいと思います。

HTTP Semanticsとは何か？

まず、HTTP Semanticsとは何か、について改めて整理したいと思います。

従来のHTTP/1.1に対して、2015年にHTTP/2をRFC7540という形で定義したときは、HTTP/1.1との差分を定義する形でした。

そして2022年の6月に新しいRFCが出まして、この中でHTTPの意味論、つまりSemanticsと、通信手段であるHTTP/1.1、2、3を分離しました。

具体的にSemanticsとは何か。これはRFC 9110のドキュメントの中で、「aspects of the protocl that are shared by all versions」つまり、プロトコルのバージョンに依存しない特性のことである、それを「Semantics」と呼ぶと定義されています。

ではここで、4択クイズです。次のものはHTTP Semanticsに含まれるでしょうか？

まず「HTTメソッド」。これはSemanticsでしょうか、それとも各バージョン依存の機能でしょうか。

難しいと思った人は、フィフティフィフティを言ってくれてもいいんですよ（笑）。

はい、そうですね、HTTPメソッドはどのHTTPバージョンでも使える、ですからSemanticsに含まれる機能です。

では次、「ステータスコード」。これはSemanticsでしょうかそれとも各バージョンの機能でしょうか？

もちろんこれもSemanticsに含まれます。HTTPステータスコードはどのバージョンでも使えます。

では次、「Content-Type」はどうでしょう。

もちろんどのバージョンでも使えますね、Semanticsに含まれています。

では次、「Cache-Control」はSemanticsにに含まれているでしょうか？それともバージョン依存でしょうか。

もちろんCache-ControlもSemanticsに含まれています。

HTTP Cache-Controlは正確に言うと、HTTP Semanticsの上に乗っている機能といったら良いのかもしれないですね。

では「Connection:close」、これはSemanticsに含まれているでしょうか？

はい。これは含まれていません。Connection:closeというのは、HTTP/1.1専用のヘッダで、HTTP/1.1接続の終了を意味します。

HTTP/2とHTTP/3では、GOAWAYフレームという別の方式を使って、接続の終了を宣言します。

では次、「Transfer-Encoding:chunked」。これはSemanticsに含まれるでしょうか？

これも含まれません。

では最後に、Content-Lengthはどうでしょう？

Content-Lengthは、Semanticsに含まれています。Content-Lengthヘッダはボディのサイズを表します。HTTP/2でも3でも同じ機能を持ちます。

もし、Content-Lengthが実際に受信したデータのサイズと違えば、それはボディが壊れているということです。受信者はボディが壊れてる以上HTTPメッセージを破棄すべきですが、ただ実際には先頭からストリーミングで処理していたりとかそういったことがあるかもしれないから、破棄できないこともありますね。

HTTP/1.1においては、Content-Lengthヘッダはたまたま違う目的のためにも使われます。それは次のHTTPメッセージの開始位置を特定するためにも使われる、ということです。

ただ、そういった特性があるからといって、Content-Lengthヘッダはバージョン依存なわけではなくて、あくまでもどのバージョンでもボディのサイズを表します。ですからContent-Lengthは、Semanticsに含まれています。

表を見てみましょう。

ほとんどのヘッダはSemanticsです。一方で、keep-aliveであるとか、upgrade、transfer-encoding、こういったものはHTTP/1.1専用で、upgradeはHTTP/2以降では廃止され、またkeep-aliveやtransfer-encodingはHTTP/2や3では、フレームとFINという別の方式に切り替わっています。

Semanticsは維持されるが、通信プロトコルは変化する

でもここで「ほとんど」というのはちょっと曖昧ですよね。どういうことなんでしょうか？

これを考えるためにはまず、プロキシの動作に注目してみましょう。

こちらは私どもが使ってるh2oというHTTPプロキシの動作を表している概念図です。

これはクライアントからHTTPリクエストを受け取ると、それがHTTP/1.1であれHTTP/2であれHTTP/3であれ、まず内部的なHTTP Semanticsの表現に変換し、そして次にこれをサーバーに送るときにHTTP/1.1、2、3のいずれかの方式でエンコードして送り出すという形になります。

HTTP/3で入ってきたリクエストがHTTP 1.1で出ていくかもしれません。

このようにSemanticsは維持されますが、通信プロトコルは変化します。ただ1つ例外があって、HTTP/1.1のヘッダ名における大文字小文字だけは、われわれは維持するようにしています。

なぜかというと、昔のアプリケーションで、HTTP/1.1で例えばContent-LengthヘッダのCは大文字じゃないと動かない。そういったアプリケーションがどうしてもあるので、互換性維持のために大文字小文字情報は維持するようにしています。

ですがHTTP/2と3ではヘッダは常に小文字で転送する規格になっていますので、このことを踏まえると、お客様のアプリケーションも全部小文字でも受け、動くようにしていくべきだ、と言えるかと思います。

ホップとエンドツーエンド

そしてFasltyの中でHTTPを中継しているのはh2oだけではありません。

例えばクライアントから入ってきたHTTP/3クエストを最初にh2oが受けて、それを別のh2oに転送され、次にvarnishに転送され、それがまたh2oに転送されて、またvarnishに転送され、最後にオリジンに届く、そういった複数のホップをポンポン飛んでいくということも実際に起こりますし、またその中で使われるHTTPのバージョンがそれぞれ違うこともあります。