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

TL;DR

2018年11月、バンコクでIETF（Internet Engineering Task Force）が開催され、新しいインターネットドラフトが採択されました。また、HTTP/2の後継プロトコル、QUICトランスポートプロトコルは「HTTP/3」に名称変更されました。UDPで構築されたHTTP/3は、すでにGoogleやFacebookなどの著名なインターネット企業で採用されています。Chromeを使ってGoogleのサービスに接続しているユーザーは、恐らく知らないうちにQUICを使用しているはずです。

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

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

• HTTP/3がやってくる
• HTTP/3とは−一般的な用語で
• 背景について−それはHTTP/2で始まった
• インターネットプロトコル（IP）
• TCPとUDPの役割を理解する
• QUICとHTTP/3

HTTP/3 Is Coming

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

2016年、KinstaではHTTP/2に関する記事を掲載しましたが、この規格は現在、W3Techsによると世界で約34％の普及率です。また、Can I useによれば、すべてのモダンなWebブラウザでサポートされています。しかし、ここではプロトコルの次のバージョンであるHTTP/3をご紹介します。

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

IETFはWeb業界を束ね、インターネットの方向性を議論するオープンな組織です。

現在、HTTP/3の「ID」フェーズは、提案がRFC（Request-for-Comments）のレベルに昇格する前の最後のフェーズであり、あらゆる意味において公式のインターネットプロトコル定義とみなせます。今後、すべての主要なインターネットプレーヤーによってHTTP/3が実装されます。

今年末（2019年6月）にドラフトの期限が切れると、HTTP/3は正式な規格になることでしょう。

HTTP/3とは−一般的な用語で

Kinstaでは通信スタックから最後の1ミリ秒の無駄をも削ぎ落とすため、最新バージョンのPHPの活用、Google Cloud Platformのプレミアムティアネットワークでのデータ配信、HTTP/2 CDNでのアセットのキャッシュなどを実施しています。

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接続状況によると、2019年3月現在、IPv6の普及率は25％強となっています。

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の上で達成可能な速度の限界に達しています。

TCPを大幅に変更するのは簡単なことではありません。なぜなら、このプロトコルは70年代にさかのぼるTCP/IPスタックの一部だからです。TCPはOSや機器のファームウェアなどに深く組み込まれています。

UDP

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

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

UDPはTCPと同様に広く普及しているため、インターネットに接続されているすべての機器のファームウェアを大幅に変更したり、OSを大きく変更したりすることなく改善を実現できます。

ユーザーと到達先のサーバーとの間には、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（バージョン3）を推進するのは時期尚早ではないかと考える人もいます。これは妥当な指摘ですが、先に述べたように、このプロトコルはすでに大規模なテストと実装が行われています。Googleは2015年にテストを開始し、2017年にはFacebookもテストを開始しています。

その後、AkamaiやMozillaなど、他のプレイヤーも標準化活動に参加しています。2018年11月に開催された前回のIETFハッカソンの参加者リストを見ると、Facebook、Apple、Google、Mozilla、NetApp、LiteSpeed Techなどの企業がQUICに興味を示しています。いくつかの有望なテストも行われていて、LiteSpeedは動作するHTTP/3サーバーを提供する、最初の主要サーバーベンダーになるかもしれません。Cloudflareも現在、QUICのベータ版を運用しています。

IETFのインターネットドラフト内でQUICはHTTP/3に名称が変更されました。インターネットドラフトは2019年6月末に期限切れとなり、7月中にはRFC、または最終的な規格になるものと思われます。

今年は、主要なソフトウェアベンダーに新しい規格を導入する動きが出てくることが期待されます。

KinstaでHTTP/3が利用できるようになるのはいつですか？

KinstaではNginxを使用しているため、NginxがQUICを正式にサポートするまで待つ必要があります。現在、作業中で、Nginx 1.17ブランチの一部になると予定されています。リリース後、Kinstaチームは、プラットフォームへのQUICサポートの追加を検討します。