HTTP / 3とは–高速な新しいUDPベースのプロトコルの詳細

TL; DR

2018年11月、インターネット技術特別調査委員会（IETF）がバンコクで会合し、新しいインターネットドラフトが採択されました。 HTTP/2の後継であるQUICトランスポートプロトコルはHTTP/3に名前が変更されました。

HTTP / 3はユーザーデータグラムプロトコル（UDP）に基づいて構築されており、GoogleやFacebookなどの著名なインターネット企業ですでに使用されています。 Chromeを使用してGoogleサービスに接続している場合は、おそらくすでにQUICを使用しています。

新しいバージョンのHTTPプロトコルは、ベアメタルの低レベルUDPプロトコルの恩恵を受けており、TCP層で以前のバージョンのHTTPにあった多くの新機能を定義しています。 これは、既存のインターネットインフラストラクチャ内の制約を解決する方法を提供します。

最初の結果は有望であり、IETFによるインターネットドラフトの期限が切れると、2021年8月にHTTP/3が新しい第3世代のHTTP標準として宣伝されることが期待できます。

2022年のHTTP/3の進捗状況

より高速でより低いレイテンシーに対するウェブ業界の渇望は、より多くのRAMに対するGoogleChromeの渇望にのみ匹敵すると言う人もいます。

数年前、私たちはHTTP / 2に関する記事を公開しました。これは、W3Techsによると、現在、世界で約45％の採用率に達している標準です。 また、Can I Useによると、最新のすべてのWebブラウザーでもサポートされています。 しかし、ここでは、プロトコルの次のバージョンであるHTTP/3についての記事を書いています。

HTTP / 3は、この記事の執筆時点では、IETFインターネットドラフトまたはIDです。これは、インターネット技術特別調査委員会（国際インターネット標準化団体）が定義を担当する次のインターネット標準について現在検討中であることを意味します。 TCP、IPv6、VoIP、InternetofThingsなどの合意されたインターネットプロトコル標準を促進します。

これは、Web業界を統合し、インターネットの方向性についての議論を促進するオープンボディです。 現在、HTTP / 3の「インターネットドラフト」フェーズは、提案がRequest-for-Comments（RFC）のレベルに昇格する前の最後のフェーズであり、すべての目的と目的で、公式のインターネットプロトコル定義と見なすことができます。

HTTP / 3はまだ公式のインターネットプロトコルではありませんが、多くの企業やプロジェクトがすでにHTTP/3サポートを製品に追加し始めています。

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

Webブラウザーの前面では、Chrome v87、Firefox v88、およびEdgev87はすべてデフォルトでHTTP/3が有効になっています。 Safariユーザーの場合、HTTP/3を有効にするオプションがSafariTechnologyPreviewv104に追加されました。 ただし、HTTP / 3サポートは現在、Safariの安定バージョンでは利用できません。

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

HTTP / 3テクノロジーの活用を検討している開発者のために、多くの人気のあるライブラリがすでにHTTP/3のサポートを追加しています。 HTTP / 3はまだインターネットドラフトの段階にあるため、以下のライブラリのいずれかを使用する場合は、最新の更新に注意を払う必要があります。

• Python –http3およびaioquic
• さび–キッシュ、ネコ、クイン
• C –nghttp3およびlsquic
• Go – quicgo
• JavaScript – Node.js

HTTP/3のインフラストラクチャサポート

インフラストラクチャの面では、Cloudflareはエッジネットワーク全体でHTTP/3をサポートすることで先導してきました。 これは、Cloudflareが有効になっているサイトが、追加の作業なしでHTTP/3のセキュリティとパフォーマンスの強化を利用できることを意味します。

Kinstaでは、私たちがホストするすべてのサイトは、無料のCloudflare統合によって保護されています。 エンタープライズレベルのファイアウォールとDDoS保護に加えて、Kinstaのお客様はHTTP/3にもアクセスできます。

サイトがHTTP/3をサポートしているかどうかをテストするには、GeekflareのHTTP/3テストツールを使用できます。 ドメインを入力して[HTTP/3の確認]ボタンを押すだけで、サイトでHTTP/3が有効になっているかどうかがツールから通知されます。

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

ブラウザのインス​​ペクタを使用して、HTTP/3サポートを確認することもできます。 この例では、HTTP/3をサポートする最新バージョンのGoogleChromeを使用します。

インスペクターを開くには、ページを右クリックして「検査」をクリックし、「ネットワーク」タブに移動します。 「プロトコル」列には、接続に使用されているHTTPプロトコルが表示されます。 HTTP / 2接続は「h2」として表示され、HTTP / 3接続は「h3-XX」として表示されます（XXは特定のHTTP / 3ドラフトを指します）。 下の画像でわかるように、kinstalife.comは、「HTTP/3ドラフト29」を意味する「h3-29」を介した接続をサポートしています。

HTTP / 3の現在のステータスについて説明したので、HTTP/2とHTTP/3の違いについて詳しく見ていきましょう。

少し背景– HTTP/2から始まりました

HTTP / 2は、ノンブロッキングダウンロード、パイプライン、サーバープッシュによっていくつかの重大な改善をもたらし、基盤となるTCPプロトコルのいくつかの制限を克服するのに役立ちました。 これにより、要求と応答のサイクルとハンドシェイクの数を最小限に抑えることができました。

HTTP / 2は、単一のTCP接続で複数のリソースをプッシュすることを可能にしました–多重化。 また、静的ダウンロードの順序の柔軟性が向上し、ダウンロードの直線的な進行によってページが制約されなくなりました。

実際には、これは、1つの大きなjavascriptリソースが、順番を待っている他のすべての静的リソースのチョークポイントと必ずしも等しくないことを意味します。

これらに加えて、HTTP / 2のヘッダーHPACK圧縮とデータ転送のデフォルトのバイナリ形式があり、多くの場合、はるかに効率的なプロトコルがあります。

主要なブラウザの実装では、Webサイトが暗号化（SSL）を実装してHTTP / 2のメリットを享受できるようにする必要がありました。これにより、計算のオーバーヘッドが発生し、速度の向上が目立たなくなることがありました。 HTTP/2に移行した後にユーザーが速度低下を報告する場合さえありました。

このバージョンの採用の初期は、心の弱い人のためではなかったとだけ言っておきましょう。

Nginxの実装には、モジュールに依存するサーバープッシュ機能もありませんでした。 また、Nginxモジュールは、コピーできる通常のApacheドロップインモジュールではありません。NGINXはこれらを使用して再コンパイルする必要があります。

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

これを詳しく説明するために、今日のインターネットプロトコルスタックを最下層から最上層まで分析します。 HTTP / 2の背景について詳しく知りたい場合は、究極のHTTP/2ガイドを確認してください。

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

インターネットプロトコル（IP）は、インターネットトポロジ全体の下部を定義します。 これはインターネットスタックの一部です。つまり、ルーターからサーバー、さらにはエンドユーザーのマシンまで、ハードウェアインフラストラクチャ全体の交換を含め、すべてを変更せずに交渉することはできません。

したがって、プロトコルのオーバーホールが予定されている可能性がありますが、主に実行可能で画期的でありながら下位互換性のある代替案を考え出していないため、現時点ではそのような広範囲にわたる取り組みは予定されていません。

IPプロトコルの始まりは、1974年にさかのぼり、米国電気電子学会が発行し、VintCerfとBobCahnが執筆した論文にまでさかのぼることができます。 ネットワークを介して送信されるパケット、IPアドレスを介してルーティングするパケット、およびネットワーク内のノードの数値的に定義されたアドレスについて詳しく説明しました。 プロトコルは、これらのパケットまたはデータグラムの形式（ヘッダーとペイロード）を定義しました。

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

32ビットアドレスを使用するため、アドレス数は約40億に制限されます。 この制限は、ビジネス以外のインターネットユーザーがISPによって「動的IPアドレス」を取得する理由の謎の説明であり、静的IPは「付加価値」と見なされ、多くの場合追加料金が発生します。

彼らは配給制です。

32ビットアドレスでは不十分であり、不足が迫っていることに気付くまで長くはかからなかったため、これに対処するために多くのRFCが公開されました。 これらのソリューションは今日広く使用されており、私たちの日常生活の一部ですが、これらはハッキングに相当すると言っても過言ではありません。

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

IPv4アドレス空間は32ビットアドレス長によって制限されていましたが、IPv6標準には128ビット、つまり3.4 * 10^38の可能なアドレスが与えられました。 これはかなり長い間私たちを持続させるのに十分なはずです。

Googleとそのユーザー間のIPv6接続によると、IPv6の採用は2021年6月の時点で35％強です。

IPはインターネットスタックの基本的な層であり、配信、データの整合性、または送信されたパケットの順序を保証することなく、最も基本的なものを定義します。 それ自体は信頼できません。 IPv4のヘッダー形式は、送信ノードがヘッダーの整合性を検証するために使用するヘッダーチェックサムを提供します。 これにより、下のリンク層に依存するIPv6バージョンとは異なり、より高速になります。

TCPとUDPの役割を理解する

次に、HTTP/3がTCPおよびUDPとどのように適合するかを探ります。

TCP

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

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

これらすべてのことは、TCPを信頼できるプロトコルにする多くのステップを示しており、TCPを今日使用している最も悪名高いインターネットサービスの基盤にしています。

1974（RFC 675）および1981（RFC 793）にさかのぼるその仕様は、今日まで実質的に変更されていません。

ただし、TCPが提供する信頼性には、コストがかかります。 ハンドシェイク、配信フィードバック、注文保証、およびチェックサムに必要なすべてのラウンドトリップのオーバーヘッド。これらは弱く冗長であると見なされる可能性があります。 これにより、TCPは最新のプロトコルスタックのボトルネックになっています。 HTTP / 2は、TCP上で達成できる速度改善のプラトーに達しました。

UDP

ユーザーデータグラムプロトコル（UDP）もインターネットプロトコルスイートの一部であり、その仕様は1980年（RFC 768）にまでさかのぼります。

名前が示すように、これはデータグラムベースのコネクションレス型プロトコルです。 つまり、握手はなく、注文や配達の保証もありません。 これは、配信、データの整合性、およびその他のことを保証するための可能な手順はすべて、アプリケーション層に任されていることを意味します。 つまり、UDP上に構築されたアプリケーションは、具体的なケースに応じて採用する戦略を選択するか、チェックサムなどのリンク層の要素を活用してオーバーヘッドを回避することができます。

UDPはTCPと同じように普及しているため、インターネットに接続されているさまざまなデバイスでファームウェアを更新したり、オペレーティングシステムを大幅に変更したりすることなく、改善を実現できます。

新しいプロトコルの展開は、TCPまたはUDPのみを許可する多くのファイアウォール、NAT、ルーター、およびその他のミドルボックスによって、ユーザーとユーザーが到達する必要のあるサーバーの間に展開されることによって妨げられます。 – HTTP/3の説明

Hacker Newsのこのスレッドは、新しいHTTPバージョンを再発明するのではなく、既存のネットワークスタックの上に構築する理由を理解するのに役立ちます（それ以上のものがあります）。

UDPパケット形式の指定はかなり最小限であり、そのヘッダーは、送信元ポート、宛先ポート、長さ（バイト単位）、パケットヘッダーとパケットデータ、およびチェックサムで構成されます。 チェックサムは、パケットのヘッダー部分とデータ部分の両方のデータ整合性を検証するために使用できます。

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

QUICとHTTP/3

QUIC（Quick UDP Internet Connections）は、2012年にGoogleによって最初に導入されました。これは、ネットワークレイヤーの境界を再定義し、低レベルのUDPプロトコルに依存し、ハンドシェイク、信頼性機能、および「ユーザースペース」のセキュリティ機能を再定義します。インターネット全体のシステムのカーネルをアップグレードします。

GoogleのSPDYまたはスピーディーによって先導された進歩であるHTTP/2と同様に、HTTP/3はこれらの成果に基づいて構築されます。

HTTP / 2は多重化を提供し、行頭ブロッキングを軽減しましたが、TCPによって制約されています。 多重化された複数のストリームに単一のTCP接続を使用してデータを転送できますが、これらのストリームの1つでパケット損失が発生すると、接続全体（およびそのすべてのストリーム）が人質になります。つまり、TCPが処理を実行するまで（失われたパケットを再送信します）。

これは、宛先ノードのバッファで、すでに送信されて待機している場合でも、失われたパケットが再送信されるまで、すべてのパケットがブロックされていることを意味します。 http /3に関する彼の本のDanielStenbergは、これを「TCPベースのヘッドオブラインブロック」と呼んでいます。 彼は、2％のパケット損失で、ユーザーはこのリスクをヘッジするために6つの接続を使用してHTTP/1でよりうまくいくと主張しています。

QUICはこれに制約されません。 QUICはコネクションレス型UDPプロトコルに基づいて構築されているため、接続の概念にはTCPの制限がなく、1つのストリームの障害が残りのストリームに影響を与える必要はありません。

CloudflareのLucasPardueが言ったように：

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を展開することができました。 Googleのエンジニアは、2017年には、インターネットトラフィックの7％がすでにQUICを介して行われたと主張しています。

GoogleのバージョンのQUICは、HTTP / 2構文を使用して、HTTPトランスポートのみに焦点を当てていました。 IETFの人々（QUICの標準化を担当する人々）は、QUICのIETFバージョンはHTTP以上のものを転送できるべきであると決定しました。 ただし、当面の間、QUICを介した非HTTPプロトコルでの作業は保留されます。

IETFのワーキンググループが決定したもう1つのことは、標準化されたバージョンがGoogleのカスタムソリューションの代わりにTLS1.3暗号化を使用することです。 TLS 1.3は、以前のバージョンと比較して、ハンドシェイクに必要なラウンドトリップが少ないため、プロトコル速度にも貢献します。 Kinstaは、すべてのサーバーとKinstaCDNでTLS1.3をサポートしています。

現在、Googleは製品に独自のバージョンのQUICを使用し続けており、開発努力をIETF標準に向けています。 他のインターネットプレーヤーのほとんどは、IETFバージョンの上に構築されています（2つは、暗号化以外のいくつかの点で異なります）。

Chrome Dev Toolsを開き、GmailなどのGoogleの製品の一部を[ネットワーク]タブの[プロトコル]列に読み込むと、GoogleのバージョンのQUICプロトコルを介して多くのリソースが読み込まれていることがわかります。 これは、Analytics、GoogleTagManagerなどのGoogleの製品にも当てはまります。

Cloudflareは、標準化の進捗状況に関する非常に広範なアップデートを公開しました。

UDPはQUICとHTTP/3にいくつかの固有の利点を提供しますが、いくつかの課題ももたらします。

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

最適化は、オペレーティングシステムのカーネル、およびさまざまなルーターとデバイスのファームウェアにまで及びます。 このRedHatチューニングガイドは、技術的に傾倒している人のために、このトピックにさらに光を当てる可能性があります。

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）を含めます。 RFC 7838で説明されているように、ポート/ホスト情報とともに、HTTP/3が利用可能であることをクライアントに通知するヘッダーが含まれます。

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

概要

HTTP / 2標準がまだ完全に採用されていないため、HTTP/3を広く普及させるには時期尚早かもしれないと考える人がいます。 これは有効なポイントですが、前述したように、このプロトコルはすでに大規模なテストと実装を行っています。 Googleは早くも2015年にテストを開始し、Facebookは2017年にテストを開始しました。

2022年には、GoogleChromeやBraveなどの主要なブラウザからHTTP/3がサポートされます。 インフラストラクチャの面では、LitespeedやNginxなどのWebサーバーはどちらもHTTP / 3の実装が機能していますが、CloudflareなどのネットワークプロバイダーはすでにHTTP/3の完全なサポートを展開しています。

現時点では、HTTP / 3はまだインターネットドラフト段階にあり、最新のリビジョンは2021年8月に期限切れになる予定です。主要なソフトウェアベンダーによる新しい実装の動きが期待できるため、今年はエキサイティングです。標準。