HTTP / 3：実用的な展開オプション（パート3）

こんにちは。新しいHTTP/3およびQUICプロトコルに関するこの3部構成のシリーズの最終回へようこそ！ 前の2つの部分（HTTP/3の履歴とコアの概念およびHTTP/3のパフォーマンス機能）の後で、新しいプロトコルの使用を開始することは良い考えであると確信している場合（そしてそうすべきです！）、この最後の部分にはすべてが含まれます始めるには知っておく必要があります！

最初に、新しいプロトコルを最適に使用するためにページとリソースに加える必要のある変更について説明します（これは簡単な部分です）。 次に、サーバーとクライアントのセットアップ方法を見ていきます（コンテンツ配信ネットワーク（CDN）を使用している場合を除いて、これは難しい部分です）。 最後に、新しいプロトコルのパフォーマンスへの影響を評価するために使用できるツールを確認します（少なくとも今のところ、これはほとんど不可能な部分です）。

ページとリソースの変更

いくつかの良いニュースから始めましょう。すでにHTTP/2を使用している場合は、HTTP / 3に移行するときに、ページやリソースに何も変更する必要はないでしょう。 。 これは、パート1とパート2で説明したように、HTTP/3は実際にはHTTP/2-over-QUICに似ており、2つのバージョンの高レベルの機能は同じままであるためです。 そのため、HTTP / 2に対して行われた変更または最適化は、HTTP / 3に対しても機能し、その逆も同様です。

ただし、まだHTTP / 1.1を使用している場合、HTTP / 2への移行を忘れている場合、またはHTTP / 2の調整を実際に行ったことがない場合は、これらの変更が何であり、なぜ必要なのか疑問に思うかもしれません。 ただし、微妙なベストプラクティスを詳しく説明した優れた記事を見つけるのは、今日でも難しいでしょう。 これは、パート1の冒頭で述べたように、初期のHTTP / 2コンテンツの多くは、実際にどれだけうまく機能するかについて過度に楽観的であり、率直に言って、大きな間違いや悪いアドバイスがあったためです。 悲しいことに、この誤った情報の多くは今日も続いています。 これは、HTTP / 3でこのシリーズを書く際の私の主な動機のひとつであり、それが再び起こらないようにするのに役立ちます。

現時点で私がお勧めできるHTTP/2の最高のオールインワンのニュアンスのあるソースは、BarryPollardによる本HTTP/ 2inActionです。 ただし、これは有料のリソースであり、ここで推測したくないので、以下にいくつかの主要なポイントと、それらがHTTP/3とどのように関連しているかを示します。

1.単一接続

HTTP/1.1とHTTP/2の最大の違いは、6から30の並列TCP接続から単一の基盤となるTCP接続への切り替えでした。 パート2では、輻輳制御によって接続数が増えるとパケット損失が増える可能性があるため、単一の接続が複数の接続と同じくらい高速になる方法について少し説明しました（これにより、集約された高速開始の利点が失われます）。 HTTP / 3はこのアプローチを継続しますが、「ただ」1つのTCP接続から1つのQUIC接続に切り替えます。 この違い自体はそれほど多くはありませんが（主にサーバー側のオーバーヘッドを削減します）、次の点のほとんどにつながります。

2.サーバーのシャーディングと接続の合体

多くのページが異なるホスト名やサーバー（ img1.example.comやimg2.example.comなど）にまたがってシャーディングされたため、単一接続設定への切り替えは実際には非常に困難でした。 これは、ブラウザが個々のホスト名ごとに最大6つの接続しか開かなかったため、複数の接続でより多くの接続が許可されたためです。 このHTTP/1.1設定を変更しなくても、HTTP / 2は複数の接続を開き、優先順位付け（以下を参照）などの他の機能が実際に機能する可能性を減らします。

そのため、当初の推奨事項は、サーバーシャ​​ーディングを元に戻し、リソースを可能な限り単一のサーバーに統合することでした。 HTTP / 2は、接続合体と呼ばれる、HTTP/1.1セットアップからの移行を容易にする機能も提供しました。 大まかに言えば、2つのホスト名が（DNSを使用して）同じサーバーIPに解決され、同様のTLS証明書を使用する場合、ブラウザーは2つのホスト名間でも単一の接続を再利用できます。

実際には、接続の合体は、たとえばCORSに関連するいくつかの微妙なセキュリティ問題のために、正しく行うのが難しい場合があります。 適切に設定したとしても、2つの別々の接続になってしまう可能性があります。 問題は、それは必ずしも悪いことではないということです。 まず、優先順位付けと多重化の実装が不十分なため（以下を参照）、単一の接続は2つ以上を使用するよりも簡単に遅くなる可能性があります。 次に、使用する接続が多すぎると、競合する輻輳コントローラが原因でパケット損失が早期に発生する可能性があります。 ただし、少数（ただし、複数）を使用すると、特に高速ネットワークで、輻輳の増加とパフォーマンスの向上のバランスをうまくとることができます。 これらの理由から、HTTP / 2を使用している場合でも、少しのシャーディング（たとえば、2〜4つの接続）は依然として良い考えだと思います。 実際、最新のHTTP / 2セットアップのほとんどは、クリティカルパスにいくつかの追加の接続またはサードパーティの負荷が残っているため、同じように機能すると思います。

3.リソースのバンドルとインライン化

HTTP / 1.1では、接続ごとにアクティブなリソースを1つだけ持つことができ、HTTPレベルのヘッドオブライン（HoL）ブロッキングが発生していました。 接続数はわずか6〜30に制限されていたため、リソースのバンドル（小さなサブリソースを1つの大きなリソースに結合する）は、長年のベストプラクティスでした。 これは今日でもWebpackなどのバンドラーで見られます。 同様に、リソースは他のリソースにインライン化されることがよくありました（たとえば、重要なCSSはHTMLにインライン化されました）。

ただし、HTTP / 2を使用すると、単一の接続でリソースが多重化されるため、ファイルに対する未処理の要求をさらに多く持つことができます（言い換えると、単一の要求が貴重な数少ない接続の1つを占有することはなくなります）。 これは元々、「 HTTP/2のリソースをバンドルまたはインライン化する必要がなくなった」と解釈されていました。 このアプローチは、各サブリソースを個別にキャッシュでき、いずれかが変更された場合にバンドル全体を再ダウンロードする必要がないため、きめ細かいキャッシュに適していると宣伝されました。 これは真実ですが、比較的限られた範囲にすぎません。

たとえば、より多くのデータでより効果的に機能するため、圧縮効率を下げることができます。 さらに、追加のリクエストやファイルはそれぞれ、ブラウザとサーバーで処理する必要があるため、固有のオーバーヘッドがあります。 これらのコストは、たとえば、いくつかの大きなファイルと比較して、数百の小さなファイルに追加される可能性があります。 私たち自身の初期のテストでは、約40ファイルで収穫逓減が大幅に減少していることがわかりました。 これらの数値はおそらく今は少し高くなっていますが、HTTP / 2でのファイル要求は、当初の予測ほど安くはありません。 最後に、リソースをインライン化しないと、ファイルを要求する必要があるため、遅延コストが増加します。 これは、優先順位付けとサーバープッシュの問題（以下を参照）と組み合わされて、今日でも重要なCSSの一部をインライン化する方が良いことを意味します。 いつかリソースバンドルの提案がこれに役立つかもしれませんが、まだです。

もちろん、これはすべてHTTP/3にも当てはまります。 それでも、同時にアクティブな独立したストリームが多いほど、HoLブロッキングの削除による利益が増えるため、多くの小さなファイルの方がQUICよりも優れていると人々が主張していることを読みました（パート2で説明しました）。 これにはある程度の真実があると思いますが、パート2でも見たように、これは非常に複雑な問題であり、多くの移動パラメーターがあります。 メリットが議論された他のコストを上回るとは思わないが、さらなる研究が必要である。 （HoLブロッキングを完全にバイパスして、各ファイルを1つのQUICパケットに収まるように正確なサイズにすることは、とんでもない考えです。これを行うリソースバンドラーを実装するスタートアップからの使用料を受け入れます。;））

4.優先順位付け

1つの接続で複数のファイルをダウンロードできるようにするには、何らかの方法でそれらを多重化する必要があります。 パート2で説明したように、HTTP / 2では、この多重化は優先順位付けシステムを使用して操作されます。 これが、同じ接続でできるだけ多くのリソースを要求することが重要である理由です。つまり、リソースを相互に適切に優先順位付けできるようにするためです。 ただし、これも見てきたように、このシステムは非常に複雑であり、実際には不適切に使用および実装されることがよくありました（下の画像を参照）。 これは、HTTP / 2に関する他のいくつかの推奨事項（リクエストが安価であるためのバンドルの削減、単一接続を最適に利用するためのサーバーシャ​​ーディングの削減（上記を参照）など）が、練習。

残念ながら、これは主にブラウザとサーバー自体の問題であるため、平均的なWeb開発者としてはあまりできないことです。 ただし、個々のファイルをあまり多く使用せず（優先順位が競合する可能性が低くなります）、シャーディングを（制限付きで）使用することで、問題を軽減することができます。 もう1つのオプションは、遅延読み込み、JavaScriptのasyncとdefer 、 preloadなどのリソースヒントなど、優先度に影響を与えるさまざまな手法を使用することです。 内部的には、これらは主にリソースの優先順位を変更して、リソースが早くまたは遅く送信されるようにします。 ただし、これらのメカニズムにはバグが発生する可能性があります（実際に発生します）。 さらに、大量のリソースにpreloadをかけ、処理を高速化することを期待しないでください。すべてが突然優先度が高くなった場合、何も起こりません。 preloadなどを使用することで、実際に重要なリソースを遅らせることも非常に簡単です。

パート2でも説明したように、HTTP/3はこの優先順位付けシステムの内部を根本的に変更します。 これにより、実際の展開でバグや問題が大幅に減少することを願っています。したがって、少なくともいくつかは解決する必要があります。 ただし、現在、このシステムを完全に実装しているHTTP / 3サーバーとクライアントはほとんどないため、まだ確信が持てません。 それでも、優先順位付けの基本的な概念は変わりません。 リソースの優先順位が誤っている可能性があるため、内部で何が起こっているのかを実際に理解しないと、 preloadなどの手法を使用することはできません。

5.サーバープッシュと最初のフライト

サーバープッシュを使用すると、サーバーは最初にクライアントからの要求を待たずに応答データを送信できます。 繰り返しになりますが、これは理論的には優れているように思われ、リソースをインライン化する代わりに使用できます（上記を参照）。 ただし、パート2で説明したように、プッシュは、輻輳制御、キャッシング、優先順位付け、およびバッファリングの問題のため、正しく使用するのが非常に困難です。 全体として、自分が何をしているのかを本当に理解していない限り、一般的なWebページの読み込みには使用しないのが最善です。それでも、おそらくマイクロ最適化になります。 ただし、ウォームアップされた接続で（JSON）応答にリンクされたサブリソースをプッシュできる（REST）APIを使用できる場所があると思います。 これは、HTTP/2とHTTP/3の両方に当てはまります。

少し一般化すると、TCP + TLS経由でもQUIC経由でも、TLSセッションの再開と0-RTTについて同様の意見を述べることができると思います。 パート2で説明したように、0-RTTは、ページの読み込みの最初の段階を加速しようとするという点で、サーバープッシュ（通常使用される）に似ています。 ただし、それは、その時点で達成できることも同様に制限されていることを意味します（セキュリティ上の懸念から、QUICではさらに制限されます）。 このように、マイクロ最適化は、繰り返しになりますが、実際にそれから利益を得るには、おそらく低レベルで物事を微調整する必要がある方法です。 そして、私がかつてサーバープッシュと0-RTTを組み合わせて試してみることに非常に興奮していたと思います。

それはどういう意味ですか？

上記のすべては、簡単な経験則に帰着します。オンラインで見つけた典型的なHTTP / 2の推奨事項のほとんどを適用しますが、極端にしないでください。

HTTP/2とHTTP/3の両方に主に当てはまるいくつかの具体的なポイントは次のとおりです。

1. 必要に応じてpreconnectとdns-prefetchを使用して、クリティカルパス上の約1〜3の接続でリソースをシャードします（ユーザーがほとんど低帯域幅のネットワークを使用している場合を除く）。
2. パスや機能ごと、または変更頻度ごとにサブリソースを論理的にバンドルします。 1ページあたり5〜10個のJavaScriptと5〜10個のCSSリソースで十分です。 重要なCSSをインライン化することは、依然として優れた最適化です。
3. preloadなどの複雑な機能は慎重に使用してください。
4. HTTP/2の優先順位付けを適切にサポートするサーバーを使用してください。 HTTP / 2の場合、H2Oをお勧めします。 ApacheとNGINXはほとんど問題ありませんが（ただし、もっとうまくいく可能性があります）、HTTP/2ではNode.jsは避けてください。 HTTP / 3の場合、現時点では状況はあまり明確ではありません（以下を参照）。
5. HTTP /2WebサーバーでTLS1.3が有効になっていることを確認してください。

ご覧のとおり、単純ではありませんが、HTTP / 3（およびHTTP / 2）用にページを最適化することはロケット科学ではありません。 ただし、さらに難しいのは、HTTP / 3サーバー、クライアント、およびツールを正しく設定することです。

サーバーとネットワーク

ご存知かもしれませんが、QUICとHTTP/3は非常に複雑なプロトコルです。 それらを最初から実装するには、7つ以上のドキュメントにまたがる何百ものページを読む（そして理解する）必要があります。 幸いなことに、複数の企業が5年以上にわたってオープンソースのQUICとHTTP / 3の実装に取り​​組んできたため、成熟した安定したオプションをいくつか選択できます。

最も重要で安定したものには、次のものがあります。

ただし、これらの実装の多く（おそらくほとんど）は、主にHTTP/3およびQUICのものを処理します。 それら自体は、実際には本格的なWebサーバーではありません。 典型的なサーバー（NGINX、Apache、Node.jsなど）に関しては、いくつかの理由で状況が少し遅くなっています。 まず、開発者の中には最初からHTTP / 3に関与していた人はほとんどいませんでしたが、今では追いつく必要があります。 多くの場合、上記の実装の1つをライブラリとして内部的に使用することでこれを回避しますが、その統合でさえ困難です。

次に、多くのサーバーはOpenSSLなどのサードパーティのTLSライブラリに依存しています。 繰り返しになりますが、TLSは非常に複雑で安全でなければならないため、既存の検証済みの作業を再利用するのが最善です。 ただし、 QUICはTLS 1.3と統合されていますが、TLSとTCPの相互作用とは大きく異なる方法でQUICを使用しています。 これは、TLSライブラリがQUIC固有のAPIを提供する必要があることを意味します。これは、開発者が長い間気が進まなかったか、実行に時間がかかりました。 ここでの問題は特に、QUICサポートを延期したOpenSSLですが、多くのサーバーでも使用されています。 この問題は非常に悪化したため、アカマイはquictlsと呼ばれるOpenSSLのQUIC固有のフォークを開始することを決定しました。 他のオプションと回避策が存在しますが、QUICのTLS 1.3サポートは依然として多くのサーバーのブロッカーであり、しばらくの間その状態が続くと予想されます。

箱から出してすぐに使用できる完全なWebサーバーの部分的なリストと、現在のHTTP/3サポートは次のとおりです。

• Apache
  現時点ではサポートは不明です。 何も発表されていません。 OpenSSLも必要になる可能性があります。 （ただし、Apache Traffic Serverの実装があることに注意してください。）
• NGINX
  これはカスタム実装です。 これは比較的新しく、まだ非常に実験的です。 2021年末までにメインラインのNGINXに統合される予定です。これは比較的新しく、まだ非常に実験的です。 NGINXでもCloudflareのキッシュライブラリを実行するためのパッチがあることに注意してください。これはおそらく今のところより安定しています。
• Node.js
  これは、内部でngtcp2ライブラリを使用します。 OpenSSLの進行状況によってブロックされますが、QUIC-TLSフォークに切り替えて、何かをより早く機能させることを計画しています。
• IIS
  現時点ではサポートは不明であり、何も発表されていません。 ただし、内部でMsQuicライブラリを使用する可能性があります。
• ハイパーコーン
  これにより、aioquicが実験的なサポートと統合されます。
• キャディー
  これは、完全にサポートされたquic-goを使用します。
• H2O
  これは、完全なサポートで、迅速に使用します。
• ライトスピード
  これは、完全にサポートされたLSQUICを使用します。

いくつかの重要なニュアンスに注意してください。

• 「完全なサポート」でさえ、必ずしも「本番環境に対応」しているわけではなく、「現時点で可能な限り優れている」ことを意味します。 たとえば、多くの実装は、接続の移行、0-RTT、サーバープッシュ、またはHTTP/3の優先順位付けをまだ完全にはサポートしていません。
• Tomcatなど、リストされていない他のサーバーは、（私の知る限り）まだ発表していません。
• リストされているWebサーバーのうち、Litespeed、CloudflareのNGINXパッチ、およびH2Oのみが、QUICおよびHTTP / 3の標準化に深く関わっている人々によって作成されたため、これらは早い段階で最もよく機能する可能性があります。
  

ご覧のとおり、サーバーランドスケープはまだ完全にはありませんが、HTTP/3サーバーをセットアップするためのオプションはすでにあります。 ただし、サーバーを実行することは最初のステップにすぎません。 それとネットワークの残りの部分を構成することはより困難です。

ネットワーク設定

パート1で説明したように、QUICはUDPプロトコル上で実行され、展開を容易にします。 ただし、これは主に、ほとんどのネットワークデバイスがUDPを解析および理解できることを意味します。 悲しいことに、 UDPが普遍的に許可されているという意味ではありません。 UDPは攻撃によく使用され、DNS以外の通常の日常業務には重要ではないため、多くの（企業）ネットワークとファイアウォールがプロトコルをほぼ完全にブロックします。 そのため、 UDPはおそらくHTTP/3サーバーとの間で明示的に許可する必要があります。 QUICは任意のUDPポートで実行できますが、ポート443（通常はHTTPS over TCPでも使用されます）が最も一般的であると予想されます。

ただし、多くのネットワーク管理者は、UDPホールセールを許可したくないでしょう。 代わりに、彼らは特にQUICoverUDPを許可したいと思うでしょう。 問題は、これまで見てきたように、QUICがほぼ完全に暗号化されていることです。 これには、パケット番号などのQUICレベルのメタデータだけでなく、たとえば、接続の閉鎖を示す信号も含まれます。 TCPの場合、ファイアウォールはこのメタデータをすべてアクティブに追跡して、予想される動作を確認します。 （データ伝送パケットの前に完全なハンドシェイクが見られましたか？パケットは予想されるパターンに従っていますか？開いている接続はいくつありますか？）パート1で見たように、これがTCPが実質的に進化できなくなった理由の1つです。 ただし、 QUICの暗号化により、ファイアウォールはこの接続レベルの追跡ロジックをはるかに少なくすることができ、ファイアウォールが検査できるいくつかのビットは比較的複雑です。

そのため、多くのファイアウォールベンダーは現在、ソフトウェアを更新できるようになるまでQUICをブロックすることを推奨しています。 ただし、その後でも、ファイアウォールのQUICサポートは、以前のTCP機能よりもはるかに少ないため、多くの企業はそれを許可したくない場合があります。

これはすべて、接続移行機能によってさらに複雑になります。 これまで見てきたように、この機能を使用すると、接続ID（CID）を使用して、新しいハンドシェイクを実行しなくても、新しいIPアドレスから接続を続行できます。 ただし、ファイアウォールにとって、これは、最初にハンドシェイクを使用せずに新しい接続が使用されているように見えます。これは、攻撃者が悪意のあるトラフィックを送信する可能性もあります。 ファイアウォールは、ユーザーのプライバシーを保護するために時間の経過とともに変化するため、QUICCIDを使用することはできません。 そのため、 CIDが予想されるファイアウォールとサーバーが通信する必要がありますが、これらはまだ存在しません。

大規模なセットアップのロードバランサーにも同様の懸念があります。 これらのマシンは、着信接続を多数のバックエンドサーバーに分散します。 もちろん、1つの接続のトラフィックは、常に同じバックエンドサーバーにルーティングする必要があります（他の接続はそれをどう処理するかわかりません！）。 TCPの場合、これは4タプルに基づいて簡単に実行できます。これは、変更されないためです。 ただし、QUIC接続の移行では、それはもはやオプションではありません。 繰り返しになりますが、サーバーとロードバランサーは、決定論的なルーティングを可能にするために、どのCIDを選択するかについて何らかの形で合意する必要があります。 ただし、ファイアウォール構成とは異なり、これを設定する提案はすでにあります（ただし、これは広く実装されているわけではありません）。

最後に、他にも、主に0-RTTおよび分散型サービス拒否（DDoS）攻撃に関する、より高いレベルのセキュリティ上の考慮事項があります。 パート2で説明したように、QUICにはすでにこれらの問題に対するかなりの数の緩和策が含まれていますが、理想的には、ネットワーク上で追加の防御線も使用します。 たとえば、プロキシサーバーまたはエッジサーバーは、リプレイ攻撃を防ぐために、特定の0-RTT要求が実際のバックエンドに到達するのをブロックする場合があります。 または、最初のハンドシェイクパケットのみを送信してから応答を停止するリフレクション攻撃またはDDoS攻撃（TCPではSYNフラッドと呼ばれる）を防ぐために、QUICには再試行機能が含まれています。 これにより、サーバーは、その間状態を維持することなく（TCP SYN Cookieと同等）、正常に動作するクライアントであることを検証できます。 もちろん、この再試行プロセスは、バックエンドサーバーの前のどこか（たとえば、ロードバランサー）で発生するのが最適です。 繰り返しになりますが、これにはセットアップのための追加の構成と通信が必要です。

これらは、ネットワークおよびシステム管理者がQUICおよびHTTP/3で抱える最も顕著な問題にすぎません。 他にもいくつかありますが、そのうちのいくつかについて話しました。 これらの問題とそれらの可能な（部分的な）緩和策について説明しているQUICRFC用の2つの別個の付属文書もあります。

それはどういう意味ですか？

HTTP / 3とQUICは、多くの内部機構に依存する複雑なプロトコルです。 バックエンドに新しいプロトコルをデプロイするためのいくつかのオプションがすでにありますが、そのすべてがまだプライムタイムの準備ができているわけではありません。 ただし、最も著名なサーバーと基盤となるライブラリ（OpenSSLなど）が更新されるまでには、おそらく数か月から数年かかるでしょう。

それでも、プロトコルを安全で最適な方法で使用できるようにサーバーやその他のネットワーク仲介者を適切に構成することは、大規模なセットアップでは簡単ではありません。 この移行を正しく行うには、優れた開発および運用チームが必要です。

そのため、特に初期の段階では、プロトコルのセットアップと構成を大規模なホスティング会社またはCDNに依存するのがおそらく最善です。 パート2で説明したように、QUICがとにかく報われる可能性が最も高いのはここであり、CDNの使用は実行可能な主要なパフォーマンス最適化の1つです。 CloudflareまたはFastlyは標準化プロセスに密接に関与しており、最も高度で適切に調整された実装が利用できるため、個人的にはCloudflareまたはFastlyを使用することをお勧めします。

クライアントとQUICディスカバリー

これまで、新しいプロトコルのサーバー側およびネットワーク内のサポートを検討してきました。 ただし、クライアント側でもいくつかの問題を克服する必要があります。

その前に、いくつかの良いニュースから始めましょう。人気のあるブラウザのほとんどは、すでに（実験的な）HTTP / 3をサポートしています！ 具体的には、執筆時点で、サポートのステータスは次のとおりです（caniuse.comも参照）。

• Google Chrome（バージョン91以降） ：デフォルトで有効になっています。
• Mozilla Firefox（バージョン89以降） ：デフォルトで有効になっています。
• Microsoft Edge（バージョン90以降） ：デフォルトで有効になっています（内部でChromiumを使用します）。
• Opera（バージョン77以降） ：デフォルトで有効になっています（内部でChromiumを使用します）。
• Apple Safari（バージョン14） ：手動フラグの背後にあります。 現在テクノロジープレビュー中のバージョン15ではデフォルトで有効になります。
• 他のブラウザ：私が認識しているシグナルはまだありません（ただし、Braveなど、内部でChromiumを使用する他のブラウザでも、理論的には有効化を開始できます）。

いくつかのニュアンスに注意してください：

• ほとんどのブラウザは段階的に展開されているため、すべてのユーザーが最初からデフォルトでHTTP/3サポートを有効にするわけではありません。 これは、見落とされた単一のバグが多くのユーザーに影響を及ぼしたり、サーバーの展開が過負荷になるリスクを制限するために行われます。 そのため、最近のブラウザバージョンでも、デフォルトでHTTP / 3を取得できず、手動で有効にする必要がある可能性がわずかにあります。
• サーバーと同様に、HTTP / 3のサポートは、現時点ですべての機能が実装されている、または使用されていることを意味するものではありません。 特に、0-RTT、接続の移行、サーバープッシュ、動的QPACKヘッダー圧縮、およびHTTP / 3の優先順位付けがまだ欠落しているか、無効になっているか、控えめに使用されているか、構成が不十分である可能性があります。
• ブラウザの外部（たとえば、ネイティブアプリ）でクライアント側のHTTP / 3を使用する場合は、上記のライブラリの1つを統合するか、cURLを使用する必要があります。 AppleはまもなくネイティブHTTP/3とQUICのサポートをmacOSとiOSの組み込みネットワークライブラリに導入し、MicrosoftはQUICをWindowsカーネルとその.NET環境に追加しますが、同様のネイティブサポートは（私の知る限り）そうではありませんでしたAndroidのような他のシステム向けに発表されました。

Alt-Svc

HTTP / 3互換サーバーをセットアップし、更新されたブラウザーを使用している場合でも、 HTTP/3が実際に一貫して使用されていないことに驚かれるかもしれません。 その理由を理解するために、あなたがしばらくの間ブラウザであると仮定しましょう。 ユーザーからexample.com （これまでにアクセスしたことのないWebサイト）に移動するように要求され、DNSを使用してそれをIPに解決しました。 1つ以上のQUICハンドシェイクパケットをそのIPに送信します。 今、いくつかのことがうまくいかない可能性があります：

1. サーバーがQUICをサポートしていない可能性があります。
2. 中間ネットワークまたはファイアウォールの1つが、QUICやUDPを完全にブロックする可能性があります。
3. ハンドシェイクパケットは転送中に失われる可能性があります。

しかし、これらの問題の1つが発生したことをどのようにして知ることができますか？ 3つのケースすべてで、ハンドシェイクパケットへの応答を受信することはありません。 あなたができる唯一のことは、応答がまだ届くのを期待して待つことです。そして、しばらく待ってから（タイムアウト）、HTTP/3に実際に問題があると判断するかもしれません。 その時点で、HTTP/2またはHTTP/1.1が機能することを期待して、サーバーへのTCP接続を開こうとします。

ご覧のとおり、このタイプのアプローチでは、特に多くのサーバーとネットワークがまだQUICをサポートしていない最初の年に、大幅な遅延が発生する可能性があります。 簡単ですが単純な解決策は、QUIC接続とTCP接続の両方を同時に開き、最初に完了したハンドシェイクを使用することです。 この方法は「コネクションレーシング」または「ハッピーアイボール」と呼ばれています。 これは確かに可能ですが、かなりのオーバーヘッドがあります。 失われた接続はほぼ即座に閉じられますが、クライアントとサーバーの両方でメモリとCPU時間を消費します（特にTLSを使用している場合）。 その上、IPv4ネットワークとIPv6ネットワーク、および前述のリプレイ攻撃（私の話で詳しく説明します）に関連するこの方法には、他にも問題があります。

そのため、QUICとHTTP / 3の場合、ブラウザは安全に再生し、サーバーがQUICをサポートしていることがわかっている場合にのみQUICを試してみることを好みます。 そのため、新しいサーバーに初めて接続するとき、ブラウザはTCP接続を介してHTTP/2またはHTTP/1.1のみを使用します。 サーバーは、後続の接続でHTTP/3もサポートしていることをブラウザーに通知できます。 これは、HTTP/2またはHTTP/1.1を介して返送される応答に特別なHTTPヘッダーを設定することによって行われます。 このヘッダーはAlt-Svcと呼ばれ、「代替サービス」を表します。 Alt-Svcを使用して、特定のサービスが別のサーバー（IPおよび/またはポート）を介して到達可能であることをブラウザーに通知できますが、代替プロトコルの表示も可能です。 これは下の図1で見ることができます。

HTTP / 3サポートを示す有効なAlt-Svcヘッダーを受信すると、ブラウザーはこれをキャッシュし、それ以降、QUIC接続のセットアップを試みます。 一部のクライアントは（最初のページのロード中であっても）これをできるだけ早く実行しますが、他のクライアントは既存のTCP接続が閉じられるまで待機します。 これは、ブラウザが最初にHTTP/2またはHTTP/1.1を介して少なくともいくつかのリソースをダウンロードした後にのみ、HTTP/3を使用することを意味します。 それでも、スムーズな航海ではありません。 ブラウザはサーバーがHTTP/3をサポートしていることを認識しますが、それは中間ネットワークがHTTP/3をブロックしないという意味ではありません。 そのため、実際には接続レースが依然として必要です。 そのため、ネットワークがQUICハンドシェイクを十分に遅らせると、HTTP/2になってしまう可能性があります。 さらに、QUIC接続が連続して数回確立されない場合、一部のブラウザは、しばらくの間HTTP / 3を試行せずに、 Alt-Svcキャッシュエントリをしばらくの間拒否リストに入れます。 そのため、問題が発生している場合は、ブラウザのキャッシュを手動でクリアすると、 Alt-Svcバインディングも空になるため便利です。 最後に、 Alt-Svcはいくつかの深刻なセキュリティリスクをもたらすことが示されています。 このため、一部のブラウザでは、使用できるポートなどに追加の制限があります（Chromeでは、HTTP/2サーバーとHTTP/3サーバーの両方が1024未満のポートにあるか、両方が1024以上のポートにある必要があります） 1024まで。それ以外の場合、 Alt-Svcは無視されます）。 このロジックはすべてブラウザ間で大きく異なります。つまり、一貫性のあるHTTP / 3接続を取得するのは難しい場合があり、新しいセットアップのテストも困難になります。

この2段階Alt-Svcプロセスをいくらか改善するための進行中の作業があります。 アイデアは、SVCBおよびHTTPSと呼ばれる新しいDNSレコードを使用することです。これには、 Alt-Svcにあるものと同様の情報が含まれます。 そのため、クライアントは、サーバーがDNS解決ステップ中にHTTP / 3をサポートしていることを検出できます。つまり、最初にHTTP/2またはHTTP/1.1を経由する代わりに、最初のページの読み込みからQUICを試すことができます。 これとAlt-Svcの詳細については、HTTP/2に関する昨年のWebAlmanacの章を参照してください。

ご覧のとおり、 Alt-SvcとHTTP / 3検出プロセスは、すでに困難なQUICサーバーの展開に複雑さの層を追加します。理由は次のとおりです。

• HTTP/2サーバーやHTTP/1.1サーバーの隣にHTTP/3サーバーをデプロイする必要があります。
• HTTP/2サーバーとHTTP/1.1サーバーを構成して、応答に正しいAlt-Svcヘッダーを設定する必要があります。

これは本番レベルのセットアップでは管理可能である必要がありますが（たとえば、単一のApacheまたはNGINXインスタンスが3つのHTTPバージョンすべてを同時にサポートする可能性があるため）、 （ローカル）テストセットでははるかに煩わしい場合があります- ups （ Alt-Svcヘッダーを追加するのを忘れているか、それらを台無しにしているのをすでに見ることができます）。 この問題は、ブラウザーのエラーログとDevToolsインジケーターの（現在の）不足によって悪化します。つまり、セットアップが正確に機能しない理由を理解するのは難しい場合があります。

その他の問題

それだけでは不十分であるかのように、別の問題によりローカルテストがより困難になります。Chromeでは、QUICに自己署名TLS証明書を使用することが非常に困難になります。 これは、企業が非公式のTLS証明書を使用して、従業員のTLSトラフィックを復号化することが多いためです（たとえば、暗号化されたトラフィック内でファイアウォールをスキャンできるようにするため）。 ただし、企業がQUICでそれを開始する場合は、プロトコルについて独自の仮定を行うカスタムミドルボックスの実装が再びあります。 これにより、将来的にプロトコルサポートが破損する可能性があります。これは、そもそもQUICを非常に広範囲に暗号化することで、まさに防止しようとしたことです。 As such, Chrome takes a very opinionated stance on this: If you're not using an official TLS certificate (signed by a certificate authority or root certificate that is trusted by Chrome, such as Let's Encrypt), then you cannot use QUIC . This, sadly, also includes self-signed certificates, which are often used for local test set-ups.

It is still possible to bypass this with some freaky command-line flags (because the common --ignore-certificate-errors doesn't work for QUIC yet), by using per-developer certificates (although setting this up can be tedious), or by setting up the real certificate on your development PC (but this is rarely an option for big teams because you would have to share the certificate's private key with each developer). Finally, while you can install a custom root certificate, you would then also need to pass both the --origin-to-force-quic-on and --ignore-certificate-errors-spki-list flags when starting Chrome (see below). Luckily, for now, only Chrome is being so strict, and hopefully, its developers will loosen their approach over time.

If you are having problems with your QUIC set-up from inside a browser, it's best to first validate it using a tool such as cURL. cURL has excellent HTTP/3 support (you can even choose between two different underlying libraries) and also makes it easier to observe Alt-Svc caching logic.

それはどういう意味ですか？

Next to the challenges involved with setting up HTTP/3 and QUIC on the server-side, there are also difficulties in getting browsers to use the new protocols consistently. This is due to a two-step discovery process involving the Alt-Svc HTTP header and the fact that HTTP/2 connections cannot simply be “upgraded” to HTTP/3, because the latter uses UDP.

Even if a server supports HTTP/3, however, clients (and website owners!) need to deal with the fact that intermediate networks might block UDP and/or QUIC traffic. As such, HTTP/3 will never completely replace HTTP/2 . In practice, keeping a well-tuned HTTP/2 set-up will remain necessary both for first-time visitors and visitors on non-permissive networks. Luckily, as we discussed, there shouldn't be many page-level changes between HTTP/2 and HTTP/3, so this shouldn't be a major headache.

What could become a problem, however, is testing and verifying whether you are using the correct configuration and whether the protocols are being used as expected. This is true in production, but especially in local set-ups. As such, I expect that most people will continue to run HTTP/2 (or even HTTP/1.1) development servers , switching only to HTTP/3 in a later deployment stage. Even then, however, validating protocol performance with the current generation of tools won't be easy.

Tools and Testing

As was the case with many major servers, the makers of the most popular web performance testing tools have not been keeping up with HTTP/3 from the start. Consequently, few tools have dedicated support for the new protocol as of July 2021, although they support it to a certain degree.

Google灯台

First, there is the Google Lighthouse tool suite. While this is an amazing tool for web performance in general, I have always found it somewhat lacking in aspects of protocol performance. This is mostly because it simulates slow networks in a relatively unrealistic way, in the browser (the same way that Chrome's DevTools handle this). While this approach is quite usable and typically “good enough” to get an idea of the impact of a slow network, testing low-level protocol differences is not realistic enough. Because the browser doesn't have direct access to the TCP stack, it still downloads the page on your normal network, and it then artificially delays the data from reaching the necessary browser logic. This means, for example, that Lighthouse emulates only delay and bandwidth, but not packet loss (which, as we've seen, is a major point where HTTP/3 could potentially differ from HTTP/2). Alternatively, Lighthouse uses a highly advanced simulation model to guesstimate the real network impact, because, for example, Google Chrome has some complex logic that tweaks several aspects of a page load if it detects a slow network. This model has, to the best of my knowledge, not been adjusted to handle IETF QUIC or HTTP/3 yet. As such, if you use Lighthouse today for the sole purpose of comparing HTTP/2 and HTTP/3 performance, then you are likely to get erroneous or oversimplified results, which could lead you to wrong conclusions about what HTTP/3 can do for your website in practice. The silver lining is that, in theory, this can be improved massively in the future, because the browser does have full access to the QUIC stack, and thus Lighthouse could add much more advanced simulations (including packet loss!) for HTTP/3 down the line. For now, though, while Lighthouse can, in theory, load pages over HTTP/3, I would recommend against it.

WebPageTest

Secondly, there is WebPageTest. This amazing project lets you load pages over real networks from real devices across the world, and it also allows you to add packet-level network emulation on top, including aspects such as packet loss! As such, WebPageTest is conceptually in a prime position to be used to compare HTTP/2 and HTTP/3 performance. However, while it can indeed already load pages over the new protocol, HTTP/3 has not yet been properly integrated into the tooling or visualizations . For example, there are currently no easy ways to force a page load over QUIC, to easily view how Alt-Svc was actually used, or even to see QUIC handshake details. In some cases, even seeing whether a response used HTTP/3 or HTTP/2 can be challenging. Still, in April, I was able to use WebPageTest to run quite a few tests on facebook.com and see HTTP/3 in action, which I'll go over now.

First, I ran a default test for facebook.com , enabling the “repeat view” option. As explained above, I would expect the first page load to use HTTP/2, which will include the Alt-Svc response header. As such, the repeat view should use HTTP/3 from the start. In Firefox version 89, this is more or less what happens. However, when looking at individual responses, we see that even during the first page load, Firefox will switch to using HTTP/3 instead of HTTP/2 ! As you can see in figure 2, this happens from the 20th resource onwards. This means that Firefox establishes a new QUIC connection as soon as it sees the Alt-Svc header, and it switches to it once it succeeds. If you scroll down to the connection view, it also seems to show that Firefox even opened two QUIC connections: one for credentialed CORS requests and one for no-CORS requests. This would be expected because, as we discussed above, even for HTTP/2 and HTTP/3, browsers will open multiple connections due to security concerns. However, because WebPageTest doesn't provide more details in this view, it's difficult to confirm without manually digging through the data. Looking at the repeat view (second visit), it starts by directly using HTTP/3 for the first request, as expected.

Next, for Chrome, we see similar behavior for the first page load, although here Chrome already switches on the 10th resource, much earlier than Firefox. It's a bit more unclear here whether it switches as soon as possible or only when a new connection is needed (for example, for requests with different credentials), because, unlike for Firefox, the connection view also doesn't seem to show multiple QUIC connections. For the repeat view, we see some weirder things. Unexpectedly, Chrome starts off using HTTP/2 there as well , switching to HTTP/3 only after a few requests! I performed a few more tests on other pages as well, to confirm that this is indeed consistent behaviour. This could be due to several things: It might just be Chrome's current policy, it might be that Chrome “raced” a TCP and QUIC connection and TCP won initially, or it might be that the Alt-Svc cache from the first view was unused for some reason. At this point, there is, sadly, no easy way to determine what the problem really is (and whether it can even be fixed).

Another interesting thing I noticed here is the apparent connection coalescing behavior. As discussed above, both HTTP/2 and HTTP/3 can reuse connections even if they go to other hostnames, to prevent downsides from hostname sharding. However, as shown in figure 3, WebPageTest reports that, for this Facebook load, connection coalescing is used over HTTP/3 for facebook.com and fbcdn.net , but not over HTTP/2 (as Chrome opens a secondary connection for the second domain). I suspect this is a bug in WebPageTest, however, because facebook.com and fbcnd.net resolve to different IPs and, as such, can't really be coalesced.

The figure also shows that some key QUIC handshake information is missing from the current WebPageTest visualization.

Note : As we see, getting “real” HTTP/3 going can be difficult sometimes. Luckily, for Chrome specifically, we have additional options we can use to test QUIC and HTTP/3, in the form of command-line parameters.

On the bottom of WebPageTest's “Chromium” tab, I used the following command-line options:

 --enable-quic --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

The results from this test show that this indeed forces a QUIC connection from the start, even in the first view, thus bypassing the Alt-Svc process. Interestingly, you will notice I had to pass two hostnames to --origin-to-force-quic-on . In the version where I didn't, Chrome, of course, still first opened an HTTP/2 connection to the fbcnd.net domain, even in the repeat view. As such, you'll need to manually indicate all QUIC origins in order for this to work !

We can see even from these few examples that a lot of stuff is going on with how browsers actually use HTTP/3 in practice. It seems they even switch to the new protocol during the initial page load, abandoning HTTP/2 either as soon as possible or when a new connection is needed. As such, it's difficult not only getting a full HTTP/3 load, but also getting a pure HTTP/2 load on a set-up that supports both ! Because WebPageTest doesn't show much HTTP/3 or QUIC metadata yet, figuring out what's going on can be challenging, and you can't trust the tools and visualizations at face value either.

So, if you use WebPageTest, you'll need to double-check the results to make sure which protocols were actually used. Consequently, I think this means that it's too early to really test HTTP/3 performance at this time (and especially too early to compare it to HTTP/2). This belief is strengthened by the fact that not all servers and clients have implemented all protocol features yet. Due to the fact that WebPageTest doesn't yet have easy ways of showing whether advanced aspects such as 0-RTT were used, it will be tricky to know what you're actually measuring. This is especially true for the HTTP/3 prioritization feature, which isn't implemented properly in all browsers yet and which many servers also lack full support for. Because prioritization can be a major aspect driving web performance, it would be unfair to compare HTTP/3 to HTTP/2 without making sure that at least this feature works properly (for both protocols!). This is just one aspect, though, as my research shows how big the differences between QUIC implementations can be. If you do any comparison of this sort yourself (or if you read articles that do), make 100% sure that you've checked what's actually going on .

Finally, also note that other higher-level tools (or data sets such as the amazing HTTP Archive) are often based on WebPageTest or Lighthouse (or use similar methods), so I suspect that most of my comments here will be widely applicable to most web performance tooling. Even for those tool vendors announcing HTTP/3 support in the coming months, I would be a bit skeptical and would validate that they're actually doing it correctly. For some tools, things are probably even worse, though; for example, Google's PageSpeed Insights only got HTTP/2 support this year, so I wouldn't wait for HTTP/3 arriving anytime soon.

Wireshark、qlog、qvis

上記の説明が示すように、この時点でLighthouseまたはWebPageTestを使用するだけでHTTP/3の動作を分析するのは難しい場合があります。 幸いなことに、これを支援する他の低レベルのツールが利用可能です。 まず、優れたWiresharkツールはQUICを高度にサポートしており、HTTP/3も実験的に分析できます。 これにより、どのQUICおよびHTTP/3パケットが実際にネットワークを通過しているかを監視できます。 ただし、これを機能させるには、特定の接続のTLS復号化キーを取得する必要があります。ほとんどの実装（ChromeおよびFirefoxを含む）では、 SSLKEYLOGFILE環境変数を使用して抽出できます。 これはいくつかの場合に役立ちますが、特に長い接続の場合、何が起こっているのかを実際に把握するには、多くの手作業が必要になる可能性があります。 また、プロトコルの内部動作についてかなり高度な理解が必要になります。

幸い、2番目のオプションであるqlogとqvisがあります。 qlogは、QUICおよびHTTP / 3専用のJSONベースのログ形式であり、QUIC実装の大部分でサポートされています。 qlogは、ネットワークを通過するパケットを確認する代わりに、クライアントとサーバーでこの情報を直接キャプチャします。これにより、いくつかの追加情報（たとえば、輻輳制御の詳細）を含めることができます。 通常、 QLOGDIR環境変数を使用してサーバーとクライアントを起動するときに、qlog出力をトリガーできます。 （Firefoxでは、 network.http.http3.enable_qlogプリファレンスを設定する必要があることに注意してください。AppleデバイスとSafariは代わりにQUIC_LOG_DIRECTORYを使用します。Chromeはまだqlogをサポートしていません。）

これらのqlogファイルは、qvis.quictools.infoのqvisツールスイートにアップロードできます。 そこでは、 QUICおよびHTTP/3トラフィックの解釈を容易にする高度なインタラクティブな視覚化が多数提供されます。 qvisは、Wiresharkパケットキャプチャ（ .pcapファイル）のアップロードもサポートしており、Chromeのnetlogファイルを実験的にサポートしているため、Chromeの動作を分析することもできます。 qlogとqvisの完全なチュートリアルはこの記事の範囲を超えていますが、詳細はチュートリアル形式、論文、さらにはトークショー形式で見つけることができます。 私はqlogとqvisの主要な実装者なので、直接質問することもできます。 ;）

ただし、これらは非常に低レベルのツールであるため、ここのほとんどの読者がWiresharkまたはqvisを使用する必要があるという幻想はありません。 それでも、現時点では選択肢がほとんどないため、このタイプのツールを使用せずにHTTP / 3のパフォーマンスを広範囲にテストしないことを強くお勧めします。これにより、ネットワーク上で何が起こっているのか、そして表示されている内容が実際に次のように説明されているかどうかを確認できます。プロトコルの内部であり、他の要因によるものではありません。

それはどういう意味ですか？

これまで見てきたように、QUICを介したHTTP / 3の設定と使用は複雑な作業になる可能性があり、多くのことがうまくいかない可能性があります。 残念ながら、適切な抽象化レベルで必要な詳細を公開する優れたツールや視覚化は利用できません。 これにより、ほとんどの開発者は、現時点でHTTP / 3がWebサイトにもたらす可能性のある利点を評価したり、セットアップが期待どおりに機能することを検証したりすることが非常に困難になります。

高レベルのメトリックのみに依存することは、これらが多数の要因（非現実的なネットワークエミュレーション、クライアントまたはサーバーの機能の欠如、部分的なHTTP / 3の使用のみなど）によって歪められる可能性があるため、非常に危険です。 パート2で見たように、すべてがうまく機能したとしても、ほとんどの場合、HTTP/2とHTTP/3の違いは比較的小さいため、高レベルから必要な情報を取得することはさらに困難になります。ターゲットを絞ったHTTP/3サポートのないツール。

そのため、 HTTP/2とHTTP/3のパフォーマンス測定値をあと数か月そのままにして、代わりにサーバー側のセットアップが期待どおりに機能していることを確認することに集中することをお勧めします。 このため、WebPageTestをGoogle Chromeのコマンドラインパラメータと組み合わせて使用​​するのが最も簡単で、潜在的な問題を解決するためのフォールバックがあります。これは現在、私が見つけることができる最も一貫した設定です。

結論とポイント

親愛なる読者の皆さん、3部構成のシリーズ全体を読んでここで作成した場合は、敬意を表します。 ほんの数セクションしか読んでいない場合でも、これらの新しくエキサイティングなプロトコルに関心をお寄せいただきありがとうございます。 ここで、このシリーズの重要なポイントを要約し、今後数か月および1年の重要な推奨事項をいくつか示し、最後に、詳細を知りたい場合に備えて、いくつかの追加リソースを提供します。

概要

まず、パート1では、主に新しい基盤となるQUICトランスポートプロトコルのためにHTTP/3が必要であることを説明しました。 QUICはTCPの精神的な後継者であり、TLS1.3だけでなくすべてのベストプラクティスを統合しています。 これが主に必要だったのは、TCPがユビキタスに展開され、ミドルボックスに統合されているため、柔軟性が低くなりすぎて進化できないためです。 QUICがUDPとほぼ完全な暗号化を使用しているということは、（願わくば）将来、新しい機能を追加するためにエンドポイントを更新するだけでよいことを意味します。 ただし、QUICにはいくつかの興味深い新機能も追加されています。 まず、QUICのトランスポートと暗号化ハンドシェイクの組み合わせはTCP + TLSよりも高速であり、0-RTT機能をうまく利用できます。 第二に、QUICは複数の独立したバイトストリームを伝送していることを認識しており、損失と遅延をどのように処理するかについてより賢くなり、行頭ブロッキングの問題を軽減できます。 第三に、QUIC接続は、各パケットに接続IDのタグを付けることで、ユーザーが別のネットワークに移動する（接続移行と呼ばれる）後も存続できます。 最後に、QUICの柔軟なパケット構造（フレームを採用）により、QUICはより効率的になりますが、将来的にはより柔軟で拡張可能になります。 結論として、 QUICが次世代のトランスポートプロトコルであり、今後何年にもわたって使用および拡張されることは明らかです。

次に、パート2では、これらの新機能、特にパフォーマンスへの影響について少し批判的に検討しました。 まず、QUICがネットワークの過負荷を防ぐためにTCPと非常によく似た輻輳制御メカニズムを使用しているため、QUICがUDPを使用しても魔法のように速く（または遅く）ならないことがわかりました。 第二に、より高速なハンドシェイクと0-RTTは、よりマイクロ最適化されています。これは、最適化されたTCP + TLSスタックよりも実際には1ラウンドトリップしかないためです。また、QUICの真の0-RTTは、制限される可能性のあるさまざまなセキュリティ上の懸念の影響をさらに受けます。その有用性。 第三に、接続の移行は実際にはいくつかの特定の場合にのみ必要であり、輻輳制御は新しいネットワークが処理できるデータの量を知らないため、送信レートをリセットすることを意味します。 第4に、QUICのヘッドオブラインブロッキング除去の有効性は、ストリームデータの多重化と優先順位付けの方法に大きく依存します。 パケット損失から回復するために最適なアプローチは、Webページの読み込みパフォーマンスの一般的な使用例に悪影響を与えるように見えますが、その逆も同様ですが、さらに調査が必要です。 第5に、UDP APIは成熟度が低く、QUICは各パケットを個別に暗号化するため、QUICはTCP + TLSよりもパケットの送信が簡単に遅くなる可能性がありますが、これは時間内に大幅に軽減できます。 第6に、HTTP / 3自体は実際には主要な新しいパフォーマンス機能をテーブルにもたらしませんが、主に既知のHTTP/2機能の内部を作り直して簡素化します。 最後に、QUICが許可する最もエキサイティングなパフォーマンス関連機能のいくつか（マルチパス、信頼性の低いデータ、WebTransport、前方誤り訂正など）は、コアQUICおよびHTTP / 3標準の一部ではなく、利用できるようになるまでもう少し時間がかかります。 結論として、これは、 QUICが高速ネットワークのユーザーのパフォーマンスをあまり改善しないことを意味しますが、主に低速で安定性の低いネットワークのユーザーにとって重要です。

最後に、このパート3では、 QUICとHTTP/3を実際に使用してデプロイする方法について説明しました。 まず、HTTP/2から学んだほとんどのベストプラクティスと教訓はHTTP/3に引き継がれるべきであることがわかりました。 バンドルまたはインライン化戦略を変更したり、サーバーファームを統合またはシャーディングしたりする必要はありません。 サーバープッシュはまだ使用するのに最適な機能ではなく、 preloadも同様に強力なフットガンになる可能性があります。 次に、既成のWebサーバーパッケージが完全なHTTP / 3サポートを提供するまでに時間がかかる可能性があることを説明しました（一部はTLSライブラリサポートの問題が原因です）。いくつかの主要なCDNには成熟した製品があります。 第三に、ほとんどの主要なブラウザが（基本的な）HTTP / 3をサポートしていることは明らかであり、デフォルトで有効になっています。 ただし、実際にHTTP / 3とその新機能を使用する方法と時期には大きな違いがあるため、それらの動作を理解するのは難しい場合があります。 第4に、LighthouseやWebPageTestなどの一般的なツールに明示的なHTTP / 3サポートがないためにこれが悪化し、現時点でHTTP/3のパフォーマンスをHTTP/2およびHTTP/1.1と比較することが特に困難になっていることを説明しました。 結論として、 HTTP / 3とQUICはおそらくまだプライムタイムの準備が整っていませんが、間もなく準備が整います。

推奨事項

上記の要約から、QUICまたはHTTP/3の使用に反対しているように思われるかもしれません。 しかし、それは私が言いたいこととは正反対です。

まず、パート2の最後で説明したように、「平均的な」ユーザーは（ターゲット市場によっては）パフォーマンスが大幅に向上することはないかもしれませんが、オーディエンスのかなりの部分で目覚ましい改善が見られる可能性があります。 0-RTTは1回の往復しか節約できない可能性がありますが、それでも一部のユーザーにとっては数百ミリ秒を意味する可能性があります。 接続の移行は、一貫して高速なダウンロードを維持できない可能性がありますが、高速列車でそのPDFを取得しようとする人々には間違いなく役立ちます。 ケーブルでのパケット損失はバースト性がある可能性がありますが、ワイヤレスリンクはQUICのヘッドオブラインブロッキング除去の恩恵を受ける可能性があります。 さらに、これらのユーザーは、通常、製品のパフォーマンスが最も低く、その結果、製品の影響を最も大きく受けるユーザーです。 それがなぜ重要なのか疑問に思われる場合は、ChrisZachariasの有名なWebパフォーマンスの逸話を読んでください。

第二に、 QUICとHTTP / 3は、時間の経過とともにより良く、より速くなるだけです。 バージョン1は、基本的なプロトコルを実行することに重点を置いており、後で使用できるように、より高度なパフォーマンス機能を維持しています。 そのため、プロトコルと新機能が将来利用可能になったときに最適な効果を発揮できるように、今すぐプロトコルへの投資を開始することは有益だと思います。 プロトコルとその展開の側面の複雑さを考えると、それらの癖に精通するための時間を自分自身に与えるのは良いことです。 まだ手を汚したくない場合でも、いくつかの主要なCDNプロバイダーは、成熟した「スイッチを切り替える」HTTP / 3サポート（特にCloudflareとFastly）を提供しています。 CDNを使用している場合にそれを試さない理由を見つけるのに苦労しています（パフォーマンスを気にする場合は、実際にそうする必要があります）。

そのため、QUICとHTTP / 3をできるだけ早く使い始めることが重要だとは言えませんが、すでに多くのメリットがあり、今後も増えると思います。

参考文献

これは長いテキストですが、残念ながら、QUICやHTTP/3のような複雑なプロトコルの技術的な表面をかじっただけです。

以下に、継続的な学習のための追加リソースのリストを、技術的な深さの昇順で示します。

• 「HTTP/3の説明」DanielStenberg
  この電子書籍は、cURLの作成者によるもので、プロトコルを要約しています。
• 「HTTP/2の動作」、バリー・ポラード
  HTTP / 2に関するこの優れたオールラウンドな本には、再利用可能なアドバイスとHTTP/3に関するセクションがあります。
• @ programmingart、Twitter
  私のツイートは主にQUIC、HTTP / 3、およびWebパフォーマンス（ニュースを含む）全般に捧げられています。 たとえば、QUIC機能に関する最近のスレッドを参照してください。
• 「YouTube」、ロビン・マルクス
  私の10以上の詳細な講演では、プロトコルのさまざまな側面について説明しています。
• 「Cloudlareブログ」
  これは、サイドでCDNも実行している会社の主な製品です。
• 「ファストリーブログ」
  このブログには、より広い文脈に埋め込まれた、技術的な側面に関する優れた議論があります。
• QUIC、実際のRFC
  IETFQUICおよびHTTP/3RFCドキュメントおよびその他の公式拡張機能へのリンクがあります。
• IIJエンジニアブログ：QUIC機能の詳細に関する優れた詳細な技術的説明。
• HTTP / 3およびQUICの学術論文、Robin Marx
  私の研究論文は、ストリームの多重化と優先順位付け、ツール、および実装の違いをカバーしています。
• QUIPS、EPIQ 2018、およびEPIQ 2020
  学術ワークショップからのこれらの論文には、プロトコルのセキュリティ、パフォーマンス、および拡張に関する詳細な調査が含まれています。

それで、親愛なる読者の皆さん、この勇敢な新しい世界についての理解が大幅に改善されたことを願っています。 私はいつでもフィードバックを受け付けていますので、このシリーズについての感想をお聞かせください。