HTTPは30年以上も前からWebの基盤であり、ブラウジングや動画視聴、音楽鑑賞だけでなく、アプリやマシン間通信、さらには他のプロトコルを構築するための基盤として、インターネットの砂時計図における「第二の腰部」とも呼ばれるほど、インターネットにおいて最も人気のあるプロトコルの1つとなっています。
HTTPがこれほど成功した理由は何でしょうか？1つの答えは、アプリケーションプロトコルを必要とするほとんどのアプリケーションの「スイートスポット」を突いていることです。「Building Protocols with HTTP」（HTTPによるプロトコルの構築」（2022年に最良の現行の実践RFCとしてHTTPワーキンググループが発行）は、HTTPの成功は次のような要因に起因すると論じています。
- 実装者、仕様策定者、管理者、開発者、利用者に親しまれている- クライアント、サーバー、プロキシなど様々な実装が可能である- 使いやすさ- Webブラウザの可用性- 認証や暗号化などの既存の仕組みを再利用できる- ターゲット環境におけるHTTPサーバーとクライアントの存在- ファイアウォールを通過する能力
もう一つの重要な要素は、HTTPを使用し、実装し、標準化する人々のコミュニティです。私たちは、プロトコルの相互運用性と今日のニーズを満たすために、積極的にプロトコルの維持と開発に協力しています。HTTPが停滞すれば、別のプロトコルが（当然のことながら）それに取って代わり、コミュニティの投資、理解の共有、相互運用性のすべてを失うことになるでしょう。
Cloudflareや他の多くの企業は、エンジニアを派遣して、IETFに参加しています。ここでは、ほとんどのインターネットプロトコルが議論され、標準化されています。また、HTTPワークショップのようなコミュニティのイベントにも参加し、スポンサーとなって、人々がどんな問題を抱えていて、何を必要としているかを話し合い、どんな変更が彼らを助けることができるかを理解するようにしています。
では、2022年に開催されたワーキンググループ会議、仕様書、サイドイベントなどでは何が起こったのでしょうか？Webのプロトコルの実装者、展開者は何をしているのでしょうか？そして、次に来るのは？
新しい仕様：HTTP/3
仕様面では、2022年にHTTP/3が公開されたことが最大の出来事でした。これは、ネットワークをより効率的に利用してWebパフォーマンスをブロックしないことで、最新のアプリケーションやサイトの要件に対応するための大きな一歩となったからです。
90年代当時、HTTP/0.9とHTTP/1.0はリクエストのたびに新しいTCPコネクションを使用しており、ネットワークの使用効率が驚くほど悪かったのです。HTTP/1.1は持続的な接続を導入しました（これは「Connection: Keep-Alive」ヘッダーとともにHTTP/1.0に遡って実装されました）。これは、サーバーとネットワークがWebの爆発的な普及に対処するのに役立った改良でしたが、当時から、業界はこの技術には大きな限界、特に、ヘッドオブラインブロッキング（1つの接続で1つのリクエストが完了すると、他のリクエストがブロックされる現象）があることがわかっていました。
これは、90年代から2000年代初頭にかけてはあまり問題になりませんでしたが、今日のWebページやアプリケーションは、これらの制限をパフォーマンス上重要なものにするような要求をネットワークに突きつけています。ページには何百ものアセットがあり、それらがすべてネットワークリソースを奪い合うことがよくありますが、HTTP/1.1はそのタスクに対応できていなかったのです。いくつかの誤ったスタートを切った後、コミュニティはついに2015年にHTTP/2でこれらの問題に対処しました。
しかし、HTTPのヘッドオブラインブロッキングを解除すると、1層下のTCPでも同じ問題が発生することがわかりました。TCPは順次配信の信頼性の高いプロトコルであるため、フローの中の1つのパケットが失われると、それ以降のパケットがOSのバッファに格納されていたとしても、アクセスを遮断する可能性があります。これは、HTTP/2の展開、特に最適でないネットワーク上での展開において問題となることが明らかになりました。
もちろん、その答えは、TCP-インターネットの多くがその上に構築されている由緒あるトランスポートプロトコルを置き換えることでした。QUICワーキンググループで多くの議論と草案の提出がなされた後、QUICバージョン1がその置き換えとして発行されました。
HTTP/3は、QUICを使用するHTTPのバージョンです。ワーキンググループはQUICとともに2021年に事実上終了しましたが、その公開は他の文書の公開と同期させるため2022年まで保留されました（下記参照）。2022年は、HTTP/3の展開にとってマイルストーンの年でもありました。Cloudflareでは新しいプロトコルの採用と信頼が高まっていることを確認しました。
HTTP/2とHTTP/3の間には数年の短いギャップしかありませんでしたが、コミュニティではすぐにHTTP/4に取り組もうという意欲はあまり感じられません。QUICとHTTP/3はどちらも新しいプロトコルであり、どのように実装し、どのように運用し、どのようにサイトやアプリケーションを構築するのがベストなのか、世界はまだ学んでいる最中でもあるのです。将来的に新しいバージョンが必要になる可能性は否定できませんが、IETFは最新のネットワークに関する幅広い業界経験に基づいてこれらのプロトコルを構築しており、必要な変更を容易にするための重要な拡張性を備えています。
新しい仕様です：HTTP "core"
2022年のHTTP仕様のもう1つの注目すべきイベントは、HTTPの仕様の中心となる「core」ドキュメントの公開でした。HTTP Semantics（セマンティクス）－メソッド、ヘッダー、ステータスコードおよびメッセージフォーマットなど。HTTP Caching－HTTPのキャッシュの仕組み。HTTP/1.1－誰もが知っていて好きなフォーマットを使って、Semanticsをワイヤーにマッピングする。
さらに、HTTP/2が再発行され、セマンティクス文書と適切に統合し、いくつかの未解決の問題が修正されました。
これは、これらの文書の長い一連の改訂の中で最新のものです。過去には、RFC 723xシリーズ、（おそらく最もよく知られている）RFC 2616、RFC 2068、そしてすべての祖先であるRFC 1945があります。改訂のたびに、読みやすさの向上、誤りの修正、概念の説明、プロトコルの動作の明確化などを目指してきました。仕様の悪い（または実装された）機能は非推奨とし、プロトコルの動作を改善する新しい機能を追加しています。詳細については、各ドキュメントの付録の「変更点（Changes from...）」をご覧ください。そして、重要なことは、古いRFCはもう時代遅れのため、常に上記のリンク先の最新改訂版を参照することです。
Early Hintsのデプロイ
HTTP/2には_server push_という機能が含まれています。これは、クライアントが何かを必要とすることがわかっているときに、サーバーがリクエストとレスポンスのペアをクライアントに「プッシュ」できるように設計されており、リクエストを行いレスポンスを待つというレイテンシーのペナルティを回避できるようにするものです。
2015年にHTTP/2が完成した後、Cloudflareや他の多くのHTTP実装は、すぐにserver pushを展開し、大きなパフォーマンスの勝利を期待しました。残念なことに、これは想定よりも困難であることが判明しました。server pushは、クライアントが送信するリクエストだけでなく、ネットワークの状態も含めて、サーバーが未来を予測することを効果的に必要とします。そして、サーバーがそれを誤ると（「オーバープッシュ」）、プッシュされたリクエストはブラウザが行っている実際のリクエストと直接競合し、パフォーマンスを助けるというよりむしろ害を与える可能性のある重大な機会コストとなります。ブラウザがすでにキャッシュにコピーを持っていて、プッシュをまったく必要としない場合、その影響はさらにひどくなります。
その結果、Chromeは2022年にHTTP/2 server pushを削除しました。他のブラウザやサーバーはまだサポートしているかもしれませんが、コミュニティは、現状ではブラウザ通知専用のWeb Pushプロトコルのような特殊な用途にしか適さないということで意見が一致しているようです。
とはいえ、あきらめたわけではありません。103（Early Hints）ステータスコードは、2017年にHTTPワーキンググループによって実験的RFCとして公開されました。これは、サーバーが「本当の」最終レスポンスの前に、非最終レスポンスで_ヒント_をブラウザに送信することを可能にします。これは、コンテンツにブラウザが取得するリソースへのリンクがいくつか含まれることがわかっているが、クライアントへのレスポンスの取得に時間が必要な場合（生成に時間がかかるため、またはCDNが行うように、サーバーがどこかから取得する必要があるため）に便利です。
Early Hintsは、server pushが設計された多くの状況で使用できます。例えば、ページが読み込む必要のあるCSSやJavaScriptがある場合です。理論的には、server pushほど最適ではありません。なぜなら、未処理のリクエストがあるときだけヒントを送ることができ、ヒントをクライアントに送って処理するまでに多少の遅延が生じるからです。
しかし実際には、Cloudflareと当社のパートナー（ShopifyやGoogleなど）は2022年をかけてEarly Hintsを実験し、より安全に使用できることを確認しました。Early Hintsでは、主なウェブパフォーマンス指標の大幅な削減を含むパフォーマンス上の利点が期待できます。
Cloudflare Pagesに統合するほど、私たちはEarly Hintsが示す可能性に興奮しています。また、このプロトコルの新機能を使ってパフォーマンスを向上させる新しい方法を評価しています。
プライバシーを重視した仲介
2022年のHTTPプロトコル拡張の中で最もエキサイティングだったのは、プロキシ、ゲートウェイ、および同様のコンポーネントをプロトコルに挿入して特定の目標を達成する機能、つまり多くの場合プライバシーの向上に焦点を当てた仲介機能でした。
MASQUEワーキンググループなどは、HTTPに新しいトンネリング機能を追加するための取り組みであり、仲介者がトンネリングしたトラフィックを別のサーバーに渡すことができるようにしようとしています。
CONNECTは以前からTCPトンネルを可能にしていましたが、MASQUEはUDPトンネルを可能にし、QUICやHTTP/3を含む、より効率的にトンネルできるプロトコルを増やしています。
Cloudflareでは、Appleと協力してMASQUEを使用し、iCloud Private Relayを実装し、1社だけに頼ることなく彼らの顧客のプライバシーを強化できることを熱烈に歓迎しています。また、MASQUEベースのVPNを可能にするIPトンネリングなど、ワーキンググループの今後の活動にも大きな関心を持っています。
仲介に焦点を当てたもうひとつの仕様は、Oblivious HTTP（OHTTP）です。OHTTPは、サーバーがコネクションやIPアドレスを使用してクライアントを追跡することを防ぐために、一連の仲介者を使用し、遠隔測定やその他の機密データを収集するような場合に、より高いプライバシー保証を提供します。この仕様は標準化プロセスを終えたばかりですが、私たちはこの仕様を使って重要な新製品、Privacy Gatewayを構築し、当社の顧客のプライバシーを保護しています。
私たちをはじめ、インターネットコミュニティの多くの人たちは、これがまさに始まったばかりだと考えています。なぜなら、仲介はコミュニケーションを仕切り、プライバシーを改善するための貴重なツールになるからです。
プロトコルの安全性
最後に、2022年はHTTPのセキュリティ関連の側面で多くの取り組みが行われました。Digest Fields仕様は、今では古くなった「Digest」ヘッダーフィールドを更新し、メッセージに整合性ダイジェストを追加できるようにしたものです。HTTP Message Signatures仕様はリクエストとレスポンスに暗号署名を可能にするものです。これはアドホックに広く展開されているものですが、今までは標準がありませんでした。どちらの仕様も標準化の最終段階にあります。
Cookie仕様の改訂も2022年に多くの進展があり、間もなく最終版になるはずです。すぐに完全になくすことはできないので、新しい「SameSite」属性など、プライバシーとセキュリティを向上させるために、操作方法を制限するための多くの取り組みが行われました。
Cloudflareが長年にわたって投資してきたセキュリティ関連の仕様のもう一つのセットはプライバシーパス（プライベートアクセストークン）です。これは暗号化されたトークンで、クライアントがボットではなく本物の人間であることを、邪魔なCAPTCHAを使わずに、またユーザーのオンラインでの行動を追跡することなく保証することができるものです。これはHTTPでは、新しい認証スキームの形式をとります。
プライバシーパスはまだ標準化プロセスを完全に経てはいませんが、2022年にはAppleによる広範な展開が見られ、大きな前進となりました。またCloudflareはCAPTCHAの代替手段としてTurnstileでプライバシーパスを使用しているため、ユーザーは今日より良いエクスペリエンスを得ることができます。
2023年はどうでしょうか？
さて、次は何でしょうか？QUERYメソッド（GETと同じだがボディがある）、Resumable Upload（tusに基づく）、Variants（キャッシュ用の改良型Varyヘッダー）、Structured Fields（新しい日付タイプを含む）、および既存のヘッダーをStructured Fieldsに後付けする方法など、いくつかの取り組みが進行中です。これらについては、2023年に進展があれば、また書きたいと思います。
2022年のHTTPワークショップでは、コミュニティはプロトコルを改善するためにどのような新しい作業を引き受けることができるかについても話しました。議論されたいくつかのアイデアには、共有プロトコルテストインフラストラクチャの改善（現在、いくつかのリソースがありますが、はるかに優れている可能性があります）、よりインテリジェントで正確な接続管理をするための代替サービスの改善（または置き換え）、そしてヘッダーの代替バイナリシリアル化のような根本的な変更を含んでいます。
また、HTTPがpub/subに対応すべきか、あるいはWebSocket（将来的にWebTransport）上で動作するように標準化すべきかについて、コミュニティで継続的に議論が行われています。今すぐというわけにはいきませんが、最近始まったMedia over QUICは、これを推進する機会を提供してくれるかも_しれません_。
もちろん、それがすべてではありませんし、2023年（以降）のHTTPがどうなるかは未知数です。HTTPは、史上最大の分散型ハイパーテキストシステムであるWorld Wide Webと互換性を保ちながら、今もなお進化を続けています。