HTTP/3とは何か？−UDPベースの高速新プロトコルの概要

TL;DR

2018年11月、バンコクでIETF（Internet Engineering Task Force）が開催され、新しいインターネットドラフトが採択されました。また、HTTP/2の後継プロトコル、QUICトランスポートプロトコルは「HTTP/3」に名称変更されました。

HTTP/3はUDP（User Datagram Protocol）を使用する通信方式で、GoogleやFacebookなどの有名インターネット企業ですでに採用されています。Chromeを使ってGoogleのサービスに接続しているユーザーは、恐らく知らないうちにQUICを使用しているはずです。

新バージョンのHTTPプロトコルは、ベアメタルで低レベルのUDPプロトコルの恩恵を受けつつ、旧バージョンのTCP層にあった多くの新機能を定義します。つまり、既存のインターネットインフラの制約を解消する方法を提供します。

登場以来、HTTP/3は好意的に迎えられました。IETFによるインターネットドラフトの期限が切れる2021年8月には、HTTP/3が第3世代の新しいHTTP規格に昇格することが期待されます。

HTTP/2と同様に、HTTP/3もこれまでの成果を基に構築され、ウェブの高速化を実現します。🚀 クリックでつぶやく

HTTP/3の進展（2023年）

口の悪い人によれば、ウェブ業界の高速化と低レイテンシーへの欲求に匹敵するのは、Google Chromeのメモリーに対する欲求くらいだそうです。

数年前にHTTP/2に関する記事を公開していますが、W3Techs調べでは、HTTP/2は現在、世界で約45%の普及率に達しており、Can I Useによると、すべての主要ブラウザでサポートされています。しかし今回取り上げるのは、その次のバージョンであるHTTP/3について。

HTTP/3は、この記事の執筆時点で、IETFインターネットドラフト（Internet-Draft、ID）です。これは、Internet Engineering Task Force（IETF）が、今後のインターネット標準として検討していることを意味します。IETFは、国際的な「インターネット標準化団体」で、TCP、IPv6、VoIP、Internet of Things（IoT）など、合意されたインターネットプロトコル標準の定義と推進を担当します。

IETFは、ウェブ業界を結束させ、インターネットの方向性に関する議論を推進するオープンな標準化団体です。現在HTTP/3は、RFC（Request For Comments）に認定、つまり公式なインターネットプロトコルとして定義される一つ前の段階「インターネットドラフト」（ID）にあります。

ウェブブラウザのHTTP/3サポート

ウェブブラウザにおいては、Chrome v87、Firefox v88、Edge v87はすべてデフォルトでHTTP/3をサポートしています。Safariでは、Safari Technology Preview v104でHTTP/3サポートを有効にできますが、安定版では現在利用できません。

HTTP/3のライブラリサポート

HTTP/3を活用と考えている開発者向けに、主要ライブラリの多くではすでにHTTP/3をサポートしています。とは言え、現在はインターネットドラフトの段階にあるため、以下のライブラリで作業する際は、最新の状態であることを確認してください。

• Python─http3、aioquic
• Rust─quiche、neqo、quinn
• C─nghttp3、lsquic
• Go─quicgo
• JavaScript─Node.js

HTTP/3のインフラサポート

インフラ面では、Cloudflareはそのエッジネットワーク全体でHTTP/3のサポートを先導しています。つまり、Cloudflareが有効になっているサイトでは、手間をかけることなく、HTTP/3のセキュリティとパフォーマンスを強化することができます。

Kinstaのお客様のサイトは、無料のCloudflare統合で保護されます。エンタープライズレベルのファイアウォールとDDoS対策に加えて、HTTP/3もご利用いただけます。

自分のサイトでHTTP/3をサポートしているかどうかを確認するには、GeekflareのHTTP/3テストツールが便利です。ドメインを入力し、「Check HTTP/3」をクリックするだけで、HTTP/3サポートの有無を確認することができます。

サイトでHTTP/3をサポートしている場合は、以下のようなメッセージが表示されます。kinstalife.comはKinstaで運営されているため、Cloudflare統合の一環により、HTTP/3を完全サポートしています。

また、ブラウザの検証機能を使用して確認することも。HTTP/3をサポートするGoogle Chromeの最新バージョンを使った例を見てみましょう。

検証機能を開くには、ページを右クリックし、「検証」＞「ネットワーク」タブに移動します。HTTPプロトコルは、「プロトコル」列で確認することができ、HTTP/2接続は「h2」、HTTP/3接続は「h3-XX」と表示されます（XXは特定のHTTP/3ドラフト）。以下のスクリーンショットでは、kinstalife.comは「h3-29」、つまり「HTTP/3 Draft 29」での接続をサポートしていることがわかります。

HTTP/3の現状について理解したところで、続いてはHTTP/2とHTTP/3の違いに迫ります。

HTTP/2の概要

HTTP/2では、ノンブロッキングダウンロード、パイプライン、サーバープッシュなどの大きな改善が行われ、下層のTCPプロトコルの制限を克服しました。この結果、リクエストレスポンスのサイクルやハンドシェイクの数を最小限に抑えています。

HTTP/2では、1つのTCP接続で複数のリソースをプッシュできるようになりました。これを「マルチプレキシング」（多重化）と呼びます。静的ダウンロードの順番も柔軟になり、単一のダウンロードの進捗によってページが制約されることもなくなりました。

具体的には、もはや1つの大きなJavaScriptリソースのダウンロードが、順番待ちをしている他のすべての静的リソースのボトルネックにはなりません。

加えて、HTTP/2のヘッダーHPACK圧縮と、データ転送のデフォルトがバイナリ形式になったことにより、多くの場合で大幅に効率の良いプロトコルになりました。

しかし、主要なブラウザの実装では、HTTP/2のメリットを享受するには、Webサイトに暗号化（SSL）を実装する必要があり、計算のオーバーヘッドが発生するため速度の改善が目に見えないこともありました。また、HTTP/2への移行後にユーザーから速度低下の報告を受けるケースもありました。

HTTP/2が採用された当初は、心臓の弱いサーバー管理者向けではありませんでした。

Nginxの実装も、サーバープッシュ機能がなく、モジュールに頼っていました。しかも、Nginxのモジュールは、慣れ親しんだApacheのドロップインモジュールとは異なり、コピーだけでは済まずに再コンパイルが必要でした。

現在、問題のいくつかは解決されていますが、プロトコルスタック全体を眺めると主要な制約はHTTP/2が闘っているレイヤーよりも低いレベルにあることがわかります。

問題を詳しく説明するために、今日のインターネットプロトコルスタックを最下層から最上層まで解剖してみましょう。HTTP/2の背景についてもっと知りたい方は、「究極のHTTP/2ガイド」をご覧ください。

インターネットプロトコル（IP）

インターネットプロトコル（IP）は、インターネットトポロジー全体の下層部分を定義しています。インターネットスタックの一部を成しており、その事実に議論の余地はありません。IPをスタックから外すには、ルーターからサーバー、エンドユーザーのマシンまで、すべてを変更しなければなりません。

したがって、プロトコルの見直しは必要かもしれませんが、現時点ではそのような大規模な取り組みは考えられていません。実行可能で、革新的で、かつ下位互換性のある代替手段がまだ見つかっていないことが主な理由です。

IPの始まりは、1974年にIEEE（Institute of Electrical and Electronics Engineers）から発表されたVint Cerf氏とBob Cahn氏の論文にまでさかのぼります。この論文では、ネットワーク上で送信されるパケットやIPアドレス越しのパケットルーティング、ネットワークやネットワーク内で数値的に定義されたノードアドレスを詳述しました。プロトコルは、パケットのフォーマットあるいはデータグラム、つまりヘッダーとペイロードを定義します。

1980年にRFC760で定義された後、IETFはRequest For Comments 791で、今日まで広く使われている定義に落ち着きました。これはプロトコルの4番目のバージョンですが、最初の製品版と言って良いでしょう。

IPでは32ビットアドレスを使用するため、アドレス数は約40億に制限されています。ビジネス以外のインターネットユーザーがISPから「動的IPアドレス」を割り当てられ、静的IPは「付加価値」とみなされて追加料金が発生する不可思議な仕様は、この制約のためです。

ISPは「配給」しているわけです。

その後、32ビットアドレスでは十分でないことがすぐに判明しますが、不足の危機が目前に迫っていたため、問題に対処する多くのRFCが発行されました。これらの解決策は現在も広く使われ、日常生活の一部となっていますが、それでも一時的な対症療法には違いありません。

インターネットプロトコルバージョン6（IPv6）は、この制限に対処する目的で登場し、前のバージョンから徐々に採用されてきています。1998年にIETFのドラフト標準文書となり、2017年にインターネット標準に引き上げられました。

IPv4のアドレス空間は、32ビットのアドレス長で制限されていましたが、IPv6では128ビット、つまり3.4 x 10の38乗個のアドレスが可能になりました。これでしばらくの間は十分でしょう。

GoogleとそのユーザーのIPv6接続状況によると、2021年6月現在、IPv6の普及率は35％強となっています。

IPはインターネットスタックの基本レイヤーであり、最も基本的な部分を定義しますが、配信やデータの整合性、送信パケットの順序などは保証しません。これでは信頼性に欠けるため、IPv4のヘッダ形式にはヘッダチェックサムがあり、送信ノードはこれを使用してヘッダの整合性を確認します。IPv6バージョンはこの部分を下のリンク層に依存することで、高速性を実現しています。

TCPとUDPの役割を理解する

さて、いよいよHTTP/3がTCPやUDPとどのような関係にあるのかを探ってみましょう。

TCP

IPが今日のオンライン通信のすべての基礎となる層であるのに対し、TCP（Transmission Control Protocol）はインターネットプロトコルスイートの上位部分であり、ウェブ、メール、ファイル転送（FTP）など、インターネットのアプリケーション層やプロトコルに必要な信頼性を提供します。

TCPには、ハンドシェイクによるマルチステップの接続確立、パケット順の保証、失われたパケットの再送などが含まれます。送信者への配信のフィードバック（Acks）などもあり、また、エラーを検出するチェックサム計算もあります。

この多くのステップがTCPを信頼性の高いプロトコルにしており、今日利用されている有名なインターネットサービスの基盤となっています。

TCPの仕様は1974年（RFC 675）と1981年（RFC 793）にさかのぼり、現在まで大きな変更はありません。

しかし、TCPが提供する信頼性にはコストがかかります。ハンドシェイクや配信フィードバック、順序保証、脆弱で冗長な面もあるチェックサムで求められる、すべてのラウンドトリップがオーバーヘッドです。TCPは、現代のプロトコルスタックのボトルネックであり、HTTP/2は、TCPの上で達成可能な速度の限界に達しています。

UDP

User Datagram Protocol（UPD）もインターネットプロトコルスイートの一つであり、その仕様は1980年（RFC 768）にさかのぼります。

名前が示すようにUDPは、データグラムベースのコネクションレスプロトコルです。ハンドシェイクはなく、順序や配送の保証もありません。つまり、配信やデータの整合性などを確保する手順は、すべてアプリケーション層に委ねられています。つまり、UDP上に構築されたアプリケーションは、具体的なケースに応じて採用する戦略を選ぶことができ、また、オーバーヘッドを避けるためにチェックサムのようなリンク層の要素も活用できます。

UDPはTCPと同様に広く普及しており、インターネットに接続されているさまざまな機器のファームウェアの更新や、オペレーティングシステムの大幅な変更なしで、改善を実現することができます。

ユーザーと到達先のサーバーとの間には、TCPまたはUDPしか許可しないファイアウォール、NAT、ルーターなどの中間機器が多数存在するため、新しいプロトコルの導入は難しくなっています。−HTTP/3の説明

新しいHTTPバージョンを構築するにあたり再発明するのではなく、既存のネットワークスタックの上に構築した理由を理解するには、Hacker Newsのこのスレッドをご覧ください（それ以外の内容も有用です）。

UDPのパケットフォーマットは最小限の仕様で、そのヘッダは、送信元ポート、宛先ポート、パケット長（バイト）、パケットデータ、チェックサムからなります。チェックサムは、パケットのヘッダ部とデータ部の両方についてデータの整合性の確認に使用できます。

チェックサムは、基礎となるプロトコル層がIPv4の場合はオプション、IPv6の場合は必須となります。これまでUDPは、コンピュータシステムの時刻同期（NTP）、VoIPアプリケーション、ビデオストリーミング、DNSシステム、DHCPなどに使用されてきました。

QUICとHTTP/3

QUIC（Quick UDP Internet Connections）は、2012年にGoogleにより初めて導入されました。ネットワーク層の境界を再定義し、下位レベルをUDPに依存し、ハンドシェイク、信頼性機能、セキュリティ機能を「ユーザー空間」で再定義することで、インターネットシステム全体のカーネルのアップグレードを不要としました。

HTTP/2の前進にはGoogleのSPDYが先鞭をつけましたが、同様にHTTP/3もこれらの成果を基にしています。

HTTP/2は多重化を実現し、ヘッドオブラインブロッキング（先頭のパケットの転送エラー時、再送するまで後続のパケットがブロックされること）を緩和しましたが、TCPによる制約は残ります。データ転送の際、多重化した複数ストリームは単一のTCPコネクションを使用できますが、ストリームの1つでパケットロスが発生すると、TCPが失われたパケットを再送するまで、接続全体およびそのすべてのストリームが人質に取られた状態になります。

これは、たとえ宛先ノードのバッファに、すでに送信されて待機しているパケットがあったとしても、失われたパケットが再送されるまで、すべてのパケットがブロックされることを意味します。Daniel Stenberg氏は、http/3に関する著書の中で、これを「TCPベースのヘッドオブラインブロック」と呼んでいます。彼は、2%のパケットロスがある場合、ユーザーがこのリスクを回避するには、HTTP/1の6つの接続の方が良いと主張しています。

QUICにこの制約はありません。QUICはコネクションレスのUDPをベースにしているため、コネクションの概念にTCPのような制限はなく、1つのストリームの障害が他のストリームに影響を与えることはありません。

Cloudflare社のLucas Pardue氏のコメントです。

UDPストリームを使用するQUICは、1つのTCPコネクションに依存せずに多重化を実現します。QUICは、TCPよりも高いレベルでコネクションを構築します。QUICコネクションでは、新しいストリームが他のストリームの終了を待つことはありません。また、QUICコネクションでは、TCPのハンドシェイクのオーバーヘッドが不要なため、レイテンシーが減少するメリットもあります。

Ciscoが、TCPの3ウェイハンドシェイクを説明する面白いビデオを作っています。

QUICではTCPの信頼性機能がない代わりに、UDP層以上でパケットの再送や順序付けを提供しています。Google Cloud Platformでは、2018年にロードバランサーのQUIC対応を導入し、平均ページロードタイムがグローバルで8％、レイテンシーの高い地域では最大13％改善されました。

Google Chrome、YouTube、Gmail、Google検索、その他のサービス間で、Googleは、IETFを待たずに、インターネット上のかなりの部分でQUICを導入しました。2017年、Googleのエンジニアは、インターネットのトラフィックの7％がすでにQUICで行われていると主張しています。

GoogleバージョンのQUICは、HTTP/2の構文を使用したHTTPトランスポートのみにフォーカスしていましたが、QUICの標準化を担うIETFは、IETFバージョンのQUICを、HTTP以外のトランスポートでも利用できるようにすべきと決定しました。しかし、現在のところ、QUICを使用したHTTP以外のプロトコルに関する作業は保留されています。

さらに、IETFのワーキンググループは、標準化バージョンでは、Googleのカスタムソリューションではなく、TLS 1.3の暗号化を使用することを決定しました。TLS 1.3は、古いバージョンと比較してハンドシェイクのラウンドトリップが少ないため、プロトコル速度を向上します。KinstaではすべてのサーバーとKinsta CDNでTLS 1.3をサポートしています。

現在もGoogleは、製品に独自のQUICを使い続けていますが、一方でIETFの規格に向けた開発にも努めています。他のインターネット企業のほとんどは、IETFのバージョンをベースに開発を進めています。なお、この2つのバージョンは暗号化以外の面でも異なる点があります。

Chromeデベロッパーツールを開き、「ネットワーク」タブの「プロトコル」列にGmailなどのGoogleの製品をロードすると、GoogleバージョンのQUICプロトコルで多くのリソースが読み込まれていることがわかります。これは、アナリティクスやGoogle Tag ManagerなどのGoogle製品についても同様です。

Cloudflareは最近、標準化の進捗状況について非常に広範なアップデートを発表しました。

UDPはQUICとHTTP/3に特定のメリットをもたらす一方で、いくつかの懸念点もあります。

TCPは何年もの間、主流のプロトコルであったのに対し、UDPはそうではなく、オペレーティングシステムとそのソフトウェアスタックは、完全に最適化されているわけではありません。その結果、QUICのCPU負荷や要件は、HTTP/2の2倍という試算もあるほど。

最適化は、オペレーティングシステムのカーネルや、さまざまなルーターやデバイスのファームウェアにまで深く及びます。技術的な興味がある方は、より詳細な情報として「Red Hatチューニングガイド」をご覧ください。

QUICは、よりミニマルで柔軟なプロトコルの上に、TCPの機能を再構築しようとしていると言えます。

先に紹介したQUICコネクションは、TLSとトランスポートのハンドシェイクの組み合わせです。接続が確立されると、固有のCID（コネクションID）によって識別されます。このIDは、IPが変更されても保持されるため、例えば4GからWiFiに変更した場合でも、ダウンロードが中断されません。これは、インターネットトラフィックがますますモバイル機器で行われることを考えると、特に重要です。逆にこの要素は、異なるコネクションやインターネットプロバイダ間でのユーザー追跡を容易にするためにGoogleが考案したものではないかという疑問が生じるかもしれません。

TLSは必須であり、中間に位置するデバイスによるトラフィックの改ざんや盗聴を困難にします。ファイアウォールプロバイダーや、CiscoのようなベンダーがUDPを問題視し、無効にする方法を提供しているのは不思議ではありません。中間にいる人がQUICのトラフィックを検査、監視、フィルタリングすることは困難です。

QUICストリームは、単方向または双方向のQUICコネクションを介して送信されます。ストリームにはIDがあり、イニシエーターや、ストリームが単方向か双方向かを識別し、ストリーム内のフロー制御にも使用されます。

QUICがトランスポート層プロトコルであるのに対し、HTTPはその上の層であるアプリケーション層プロトコル、または単にアプリケーションプロトコルです。

後方互換性が最も重要であるため、IETFが推進するHTTP/3の実装では、レスポンスに古いバージョン（HTT1またはHTTP/2）が含まれます。また、RFC7838にあるように、ポートやホスト情報とともに、HTTP/3が利用可能であることをクライアントに通知するヘッダーも含まれます。

これは、TLSハンドシェイク内でトランスポートをネゴシエートできるHTTP/2とは異なります。しかし、IETFがQUICベースのHTTP/3を次期標準としてほぼ採用したことから、WebクライアントはますますHTTP/3をサポートするでしょう。クライアントは、以前のHTTP/3接続からのデータをキャッシュし、同じホストに次回アクセスする際には直接接続（ゼロラウンドトリップ、0-RTT)が可能です。

まとめ

HTTP/2規格がまだ完全に採用されていない状況で、HTTP/3を推進するのは時期尚早ではないかと考える人もいます。これは妥当な指摘ですが、先に述べたように、このプロトコルはすでに大規模なテストと実装が行われています。Googleは2015年にテストを開始し、2017年にはFacebookもテストを開始しています。

2023年は、Google ChromeやBraveのような主要ブラウザがHTTP/3をサポート。インフラ面では、LitespeedやNginxのようなウェブサーバーがHTTP/3を実装しており、CloudflareのようなネットワークプロバイダーはHTTP/3に完全対応しています。

現時点では、HTTP/3はまだインターネットドラフトの段階にあり、最新の改訂版は2021年8月に期限切れとなります。今年は主要ソフトウェアベンダーが新しい標準を実装し始めることが予想されるため、注目したいところです。