HTTP/3は大きな変化と課題をもたらす

HTTP/2 は、一時的な流行に過ぎない技術だったようです。 批准された規格は、2015 年に大々的に発表されました。 これは 1999 年以来、インターネットの共通言語に起きた最初の大きな変化でした。

そして突然、静かになりました。 いくつかの著名な大学の研究者によって作成および保守されていたHTTP/2 ダッシュボードは、2016 年末に停止しました。 それ以来、養子縁組の統計は更新されていません。 もう誰もそれについて話しません。 どうやら、その15分間の名声は過ぎ去ったようだ。

しかし、それは水面下で勢いを増し続けています。 ゆっくりではありますが、確実に HTTP/2 がアプリ スタックに導入されつつあります。

HTTP/2 は依然として IPv6 を上回っている

アプリケーション、特に HTTP バリアント上で実行されるアプリケーションに依存して存在する組織として、私たちは HTTP/2 の採用を注意深く見守ってきました。 私たちは、2018 年にアプリケーション サービスの現状に関する調査で HTTP/2 ゲートウェイ サービスの追跡を開始しました。 2018 年には、回答者の 40% が HTTP/2 ゲートウェイを導入したと回答しました。 2019年には33%に減少しました。 パブリック クラウドでは、回答者の 19% が一部のアプリケーションに HTTP/2 ゲートウェイを使用しています。 2019 年の回答者の 25% が導入を計画しており、今後 1 年間に導入されるアプリケーション サービスのトップ 5 のリストに 2 年連続でランクインしています。

HTTP/2 ダッシュボードでは、2016 年 11 月 16 日時点で 250,000 を超えるドメインが HTTP/2 のサポートを発表したことが報告されています。 こうしたことを追跡している Netcraft によれば、インターネット上には 18 億を超えるサイトがあるそうです。 W3Techs は、すべての Web サイトの 33% で HTTP/2 の使用状況を測定しています。これは、インターネットを上位 100 万サイトに限定した場合、2016 年に記録された 250,000 ドメインとよく一致しています。 この制限を考慮すると、HTTP/2 を採用しているサイトの割合は 25 ～ 35% 程度になると思われます。

これでは速度が十分でないと思われる場合は、IPv6 はずっと前から存在しており、 2019 年 1 月時点では Web サイトの 13.4% しか IPv6 に対応していないことを考慮してください。 

HTTP/3の登場

そして現在、内部的にさらに劇的な変化を伴った HTTP/3 が登場しています。 HTTP/3 に詳しくない場合は、Google の HTTP-over-QUIC を HTTP/3 としてリブランドするIETF 承認提案を確認することをお勧めします。 SPDY が HTTP/2 の基盤となったのと同じように、 QUIC はHTTP/3 の基盤となります。

しかし、HTTP/2 への変更が劇的だと思ったなら、まだ何も見ていないことになります。

ご存知のとおり、QUIC (つまり HTTP/3) は UDP に基づいています。 これは、古き良き信頼性の高い TCP に依存することからはかなり劇的な変化です。 また、HTTP/2 では暗号化の要件が撤廃されましたが (ブラウザー開発者は暗号化された HTTP/2 のみをサポートすることに決めたため、これは議論の余地があります)、HTTP/3 では暗号化が必要になります。  

それは確かに正当な、そしておそらくは崇高な意図ですが、その影響はインフラストラクチャとアーキテクチャ、特にサービス プロバイダーに多大な影響を及ぼすでしょう。 暗号化をスタックの上位に移動してほぼすべてのものを網羅し、TCP から UDP への移行と相まって、すべてが変わります。 ほとんどのセキュリティ システムは、UDP によって伝送されるコンテンツを詳細に検査することに慣れていません。 UDP を使用するトラフィックのほとんどは、DNS や NTP などのユーティリティおよびインフラストラクチャ サービスです。 HTTP/3 の新しい世界では、ペイロードを綿密に検査しないと危険な場合があります。 結局のところ、通過するコンテンツは悪意のあるものである可能性が非常に高いのです。 ボットかもしれません。 それは攻撃である可能性があります。 それは何でもあり得ます。

暗号化要件も、「中間ボックス」によるトラフィックの検査を困難にします。 このような検査は、アプリケーションとデータのセキュリティを維持するために重要です。 トランスポート層プロトコルの変更も問題となる可能性があります。 セキュリティ サービスは、多くの場合、アプリケーション (ほとんどの場合 HTTP) トラフィックが TCP 経由で転送されるという前提に基づいて構築されます。 TCP は信頼性の高い接続指向のプロトコルです。 UDP への変更は、UDP がデータグラムベース (パケット) のプロトコルであり、信頼性が低い可能性があるため、セキュリティ インフラストラクチャがアプリケーション トラフィックを解析および分析する能力に大きな影響を与える可能性があります。  

ゆっくりとした導入への道 

HTTP/3 の採用は遅くなると思われますが、HTTP/2 はゆっくりながらも着実に普及を続けています。 結局のところ、Web の大部分は古き良き HTTP/1.x に依存し続けています。 HTTP/2 が HTTP/1.x を追い抜くまでにはしばらく時間がかかり、インフラストラクチャとアプリケーション スタック全体をすぐに HTTP/2 に移行する可能性は低いです。

セキュリティ インフラストラクチャへの影響もあって、セキュリティ サービス プロバイダーが適応できるようになるまで、導入は遅くなる可能性があります。 ゼロトラストイニシアチブデバイス ID やレピュテーションなど、クライアントからのより詳細なコンテキストを組み込んだ は、セキュリティがアプリケーションを保護するためのより包括的な戦略に移行するにつれて、最終的にはここで恩恵となる可能性があります。 ゼロ トラスト テクノロジーの成熟と採用は、HTTP/3 のセキュリティ上の課題に対処するための答えを提供する可能性があります。 セキュリティ サービスが不正行為者をリアルタイムで特定することにますます依存するようになると、悪意のあるアクティビティのペイロードを簡単に精査できないリスクが軽減されます。  

HTTP/3 は 2019 年の夏までリリースされない予定です。 HTTP/2 の導入はゆっくりだが着実に進んでいること、そして HTTP/3 がもたらすセキュリティ上の課題を考えると、HTTP/3 の導入は当面、長く困難な道のりとなる可能性が高い。