パフォーマンスと効率：HTTP/3での作業

HTTP / 3は、HTTP / 2に続いて注目を集めています。これは、おそらくまだ非常に若いものです。 HTTP/1.1からHTTP/2に移行するのに16年かかったとすると、誰かが本当にHTTP / 3に関心を持つべきでしょうか？

簡単な答え：はい、それは重要です、そしてあなたはそれに慣れる必要があります。 これは、HTTP/2がASCIIからバイナリに切り替えることでHTTP/1.1から大幅な変更を加えたのと同じです。 HTTP / 3は、基盤となるトランスポートをTCPからUDPに切り替えることにより、ここでも重要な変更を加えます。

HTTP / 3はまだ設計段階にあり、公式仕様はドラフトですが、すでに展開されており、今日ネットワーク上で実行されているバージョンが見つかる可能性があります。

しかし、HTTP/3がどのように機能するかによってもたらされるいくつかの新しいジレンマがあります。 また、メリットは何ですか？ そして、ネットワークエンジニア、システム管理者、および開発者は何を知る必要がありますか？

主な問題：パフォーマンスと効率

サイトおよびアプリの開発者は通常、自分の作品が実際に使用されることを意図して構築します。 オーディエンスベースが有限である場合もありますが、多くの場合、アイデアはできるだけ多くのユーザーを獲得することです。 当然のことながら、ウェブサイトの人気が高まるほど、より多くの収益を上げることができます。

ウェブサイトの読み込み時間が100ミリ秒遅れると、コンバージョン率が7％低下する可能性があります。

Akamai Online Retail Performance Report：ミリ秒が重要（2017）

言い換えれば、1日あたり40,000ドルの売り上げがあるeコマースサイトは、そのような遅れのために年間100万ドルを失うことになります。

また、サイトの人気が高まるためには、サイトのパフォーマンスが絶対的に重要であることも周知の事実です。 オンラインショッピングの調査では、バウンス率の増加と読み込み時間の延長、およびショッピング体験中の買い物客の忠誠心とWebサイトのパフォーマンスとの関連性が引き続き明らかになっています。

調査によると、次のことがわかりました。

• 消費者の47％は、Webページが2秒以内に読み込まれることを期待しています。
• 40％の人が、読み込みに3秒以上かかるWebサイトを放棄しています。

そして、それは10年以上前のオンライン買い物客の忍耐の状態でした。 したがって、パフォーマンスは重要であり、HTTP/2とHTTP/3はどちらもWebサイトのパフォーマンスが向上することを意味します。

HTTP / 2？ …あれは何でしょう？

HTTP / 3を理解するには、HTTP/2プロトコルをよく理解することが重要です。 まず第一に、なぜHTTP / 2が必要だったのですか？

HTTP / 2は、SPDYと呼ばれるGoogleプロジェクトとして始まりました。これは、Webでの最大のパフォーマンスの問題がレイテンシーであると報告した調査の結果です。 著者は、「帯域幅を増やすことは（それほど）重要ではない」と結論付けました。

配管とインターネットを例えると、インターネットの帯域幅は水道管の直径のように考えることができます。 パイプが大きいほど大量の水が運ばれるため、2点間でより多くの水を送ることができます。

同時に、パイプの大きさに関係なく、パイプが空で、ある場所から別の場所に水を入れたい場合は、水がパイプを通過するのに時間がかかります。 インターネット用語では、水がパイプの一方の端からもう一方の端に移動して再び戻るのにかかる時間は、往復時間またはRTTと呼ばれます。

マイク・ベルシュ

この調査では、ページの読み込み時間を短縮することが目標でした。 1Mbpsから2Mbpsに移行するとページの読み込み時間が半分になるため、帯域幅を増やすと最初は役立つことがわかりました。 ただし、メリットはすぐに頭打ちになります。

対照的に、レイテンシーを減らすことには一定の利点があり、最良の結果が得られます。

HTTP HOL：ヘッドオブラインブロッキングの問題

HTTP / 1プロトコル内の遅延の主な原因は、ヘッドオブラインブロッキングの問題です。 Webページ（ほとんどの場合）には、CSS、JavaScript、フォント、画像、AJAX / XMRなどの複数のリソースが必要です。これは、Webブラウザーがサーバーに対して複数の要求を行う必要があることを意味します。 ただし、ページが役立つようになるためにすべてのリソースが必要なわけではありません。

HTTP / 1.0では、次のリクエストを開始する前に、ブラウザがレスポンスを完全に受信することを含め、リクエストを完全に完了する必要がありました。 すべてを順番に行う必要がありました。 各リクエストはリクエストの行をブロックするため、名前が付けられます。

HOLブロッキングの問題を補うために、Webブラウザは単一のサーバーに複数の同時接続を確立します。 ただし、この動作を任意に制限する必要がありました。サーバー、ワークステーション、およびネットワークは、接続が多すぎると過負荷になる可能性があります。

HTTP / 1.1は、この問題に取り組むのに役立ついくつかの改善を導入しました。 主なものはパイプライン化であり、Webブラウザーは、前の要求が完了するのを待たずに新しい要求を開始できます。 これにより、低レイテンシ環境での読み込み時間が大幅に改善されました。

ただし、それでもすべての応答が作成された順序で順番に到着する必要があるため、行の先頭はブロックされたままになります。 驚いたことに、多くのサーバーはまだこの機能を利用していません。

興味深いことに、HTTP / 1.1ではキープアライブも導入されました。これにより、ブラウザはHTTPリクエストごとに新しいTCP接続を作成するオーバーヘッドを回避できます。 これは、TCPから派生したパフォーマンスの問題を解決するための初期の試みでした。 それは非常に効果がなかったため、ほとんどのパフォーマンスの専門家は、非アクティブな接続が多すぎるためにサーバーを停止させるため、実際にはそれを思いとどまらせています。 以下のTCPと、この問題がHTTP/2によってどのように修正されたかを詳しく見ていきます。

HTTP/2のHTTPHOLブロッキングソリューション

HTTP / 2では、単一の接続を介した要求と応答の多重化が導入されました。 ブラウザはいつでも新しいリクエストを開始できるだけでなく、応答を任意の順序で受信できます。アプリケーションレベルでのブロックは完全に排除されます。

直接的な結果として、これはHTTP/2に精通したWebサーバーが効率を最大化できることを意味します。これについては後で詳しく説明します。

要求と応答の多重化はHTTP/2のヘッドライン機能ですが、他にもいくつかの重要な機能が含まれています。 読者は、それらがすべていくらか関連していることに気付くかもしれません。

HTTP/2バイナリフレーミング

HTTP / 2は、HTTPプロトコル標準を非効率的な人間が読めるASCII要求/応答モデルから効率的なバイナリフレーミングに切り替えます。 それはもはや単なる要求と応答ではありません。

HTTP / 2を使用すると、ブラウザは、それぞれが複数のフレームで構成される複数のメッセージを含む双方向ストリームを介してサーバーと通信します。

HTTP / 2 HPACK（ヘッダー圧縮）

HPACK形式を使用したHTTP/2の新しいヘッダー圧縮により、ほとんどのサイトで大量の帯域幅が節約されます。 これは、接続内で送信されるリクエストのヘッダーの大部分が同じであるためです。

Cloudflareは、HPACKのみのおかげで、大幅な帯域幅の節約を報告しています。

• 入力ヘッダーの76％圧縮
• 総入力トラフィックが53％削減
• 出力ヘッダーの69％圧縮
• 総出力トラフィックが1.4％から15％減少

もちろん、使用する帯域幅が少ないということは、一般的にWebサイトが高速であることを意味します。

HTTP/2ストリームの優先順位付けとサーバープッシュ

ここで、HTTP / 2の多重化により、サーバーは実際に効率を最大化できます。 多重化は、低速のリソース（たとえば、大きな画像、データベースで生成されたJSONなど）よりも高速なリソース（たとえば、メモリキャッシュされたJavaScript）を提供するのに役立ちます。 ただし、HTTP/2のストリーム優先順位付けを介してパフォーマンスをさらに向上させることもできます。

ストリームの優先順位付けは、他のリソースを大量に消費する要求が完了するのを待たずに、ページのほぼ準備が整った側面を完全に完了するのに役立ちます。 これは、加重依存関係ツリーを介して実現されます。 このツリーは、サーバーがサービスに最も多くのシステムリソースを割り当てる必要がある応答をサーバーに通知するために使用されます。

これは、プログレッシブWebアプリケーション（PWA）にとって特に重要です。 たとえば、ページに4つのJavaScriptファイルがあるとします。 2つはページ機能用で、2つは広告用です。 最悪のシナリオは、機能的なJSの半分とアドバタイズするJSの半分をロードしてから、残りのJSをロードする前に、大きな画像をロードすることです。 その場合、すべてが最も遅いリソースを待機する必要があるため、ページ上の何も最初は機能しません。

ストリームの優先順位付けを使用すると、Webブラウザーは、広告JavaScriptファイルを送信する前に、両方のページ機能JSファイルを送信するようにサーバーに指示できます。 このように、ユーザーはページの機能を使用する前に広告が完全に読み込まれるのを待つ必要はありません。 全体的な読み込み時間は改善されていませんが、知覚されるパフォーマンスは大幅に向上しています。 残念ながら、Webブラウザー内でのこの動作は、Web開発者によって指定されたものではなく、依然としてほとんどの場合アルゴリズムの問​​題です。

同じように、HTTP / 2のサーバープッシュ機能を使用すると、サーバーはまだ行っていないリクエストに対してブラウザに応答を送信できます。 サーバーは、送信のギャップを利用して、サーバーがすぐに要求することをサーバーが認識しているブラウザーリソースにプリロードすることにより、帯域幅を効率的に使用できます。 ここでの希望の一部は、リソースのインライン化の慣行を排除することです。これは、リソースを膨らませ、ロードに時間がかかるだけです。

残念ながら、これらの機能は両方とも、実際に成功するためにWeb開発者による多くの注意深い構成を必要とします。 それらを有効にするだけでは十分ではありません。

HTTP / 2は明らかに多くの潜在的な利点をもたらします—それらのいくつかは他のものよりも活用するのが安価です。 彼らは現実の世界でどのように進んでいますか？

HTTPとHTTP/2の採用

SPDYは2009年に作成されました。HTTP/2は2015年に標準化されました。SPDYはコードの不安定な開発ブランチの名前になり、HTTP/2が最終バージョンになりました。 その結果、SPDYは時代遅れになり、HTTP/2は一般的に誰もが従う標準です。

標準化後、HTTP / 2（または「h2」）の採用は急速に成長し、上位1,000のWebサイトの約40％になりました。 これは主に、顧客に代わってサポートを展開している大規模なホスティングおよびクラウドプロバイダーによって推進されました。 残念ながら、数年後、HTTP / 2の採用は遅くなり、インターネットの大部分はまだHTTP/1を使用しています。

HTTP/2クリアテキストモードのブラウザサポートの欠如

暗号化を標準の必須部分にするために、HTTP/2に対する多くの要求がありました。 代わりに、標準では暗号化（h2）モードとクリアテキスト（h2c）モードの両方が定義されています。 そのため、HTTP/2はHTTP/1を完全に置き換えることができます。

標準にもかかわらず、現在のすべてのWebブラウザーは、暗号化された接続を介したHTTP / 2のみをサポートしており、意図的にクリアテキストモードを実装していません。 代わりに、ブラウザはHTTP/1下位互換モードに依存して安全でないサーバーにアクセスします。 これは、デフォルトでWebを安全にするというイデオロギー的な推進の直接的な結果です。

なぜHTTP/3なのか？ そしてそれはどのように違うのですか？

HTTP / 2によってHTTPヘッドオブラインブロッキングの問題が修正されたため、プロトコル開発者は次に大きなレイテンシドライバーであるTCPヘッドオブラインブロッキングの問題に注意を向けました。

伝送制御プロトコル（TCP）

IP（インターネットプロトコル）ネットワークは、コンピューターが相互にパケットを送信するという考えに基づいています。 パケットは、いくつかのアドレス情報が上部に付加された単なるデータです。

ただし、アプリケーションは通常、データのストリームを処理する必要があります。 この錯覚を実現するために、伝送制御プロトコル（TCP）は、データのストリームが流れることができるパイプをアプリケーションに提供します。 ほとんどのパイプと同様に、データがパイプに入るのと同じ順序でパイプから出ることが保証されています。これは「先入れ先出し」（FIFO）とも呼ばれます。 これらの特性により、TCPは非常に便利になり、非常に広く採用されています。

TCPが提供するデータ配信保証の一部として、TCPはさまざまな状況を処理できる必要があります。 最も複雑な問題の1つは、ネットワークが過負荷になったときに、すべての人の状況を悪化させることなく、すべてのデータを配信する方法です。 このためのアルゴリズムは輻輳制御と呼ばれ、インターネット仕様の絶えず進化している部分です。 十分な輻輳制御がないと、インターネットは停止します。

'86年10月、インターネットは一連の「混雑崩壊」となった最初のものを持っていました。 この期間中に、LBLからカリフォルニア大学バークレー校（400ヤードと3つのIMPホップで分離されたサイト）へのデータスループットは、32Kbpsから40bpsに低下しました。

V.ジェイコブソン（1988）

そこで、TCPのヘッドオブラインブロッキングの問題が発生します。

TCPHOLブロッキングの問題

TCP輻輳制御は、パケット損失が検出されるたびに使用される、パケットのバックオフおよび再送信メカニズムを実装することによって機能します。 バックオフは、ネットワークを落ち着かせるのに役立つことを目的としています。 再送信により、データが最終的に確実に配信されます。

これは、TCPデータが順不同で宛先に到着する可能性があることを意味し、パケットをストリームに再アセンブルする前に、受信側がパケットを再順序付けする責任があります。 残念ながら、これは、単一の失われたパケットにより、サーバーが再送信を待機している間、TCPストリーム全体が一時停止する可能性があることを意味します。 したがって、行の先頭がブロックされます。

Googleの別のプロジェクトは、QUICと呼ばれるプロトコルを導入することでこの問題を解決することを目的としていました。

QUICプロトコルはTCPではなくUDPの上に構築されており、QUICはHTTP/3の基盤を形成しています。

UDPとは何ですか？

ユーザーデータグラムプロトコル（UDP）は、TCPの代替手段です。 ストリームのような錯覚や、TC​​Pが提供するのと同じ保証は提供されません。 代わりに、データをパケットに入れ、別のコンピューターにアドレス指定して送信する簡単な方法を提供するだけです。 信頼性が低く、順序付けられておらず、いかなる形式の輻輳制御も付属していません。

その目的は、軽量であり、通信を可能にするために必要な最小限の機能を提供することです。 このようにして、アプリケーションは独自の保証を実装できます。 これは、リアルタイムアプリケーションで非常に役立つことがよくあります。 たとえば、電話では、ユーザーは通常、データの100％を最終的に受信するのではなく、データの90％をすぐに受信することを好みます。

HTTP/3のTCPHOLソリューション

TCP HOLブロッキングの問題を解決するには、UDPに切り替えるだけでなく、すべてのデータの配信を保証し、ネットワークの輻輳の崩壊を回避する必要があるためです。 QUICプロトコルは、UDPを介した最適化されたHTTPタイプのエクスペリエンスを提供することにより、これらすべてを実行するように設計されています。

QUICがストリーム管理やバイナリフレーミングなどの制御を引き継ぐため、QUIC上で実行するときにHTTP/2が実行することはあまりありません。 これは、HTTP/3として標準化されているQUIC+HTTPのこの新しい組み合わせに向けた推進要因の一部です。

注：プロトコルは開発中であり、実稼働環境で何年にもわたって展開されているため、QUICには多くのバージョンがあります。 GQUICと呼ばれるGoogle固有のバージョンもあります。 そのため、古いQUICプロトコルと新しいHTTP/3標準を区別することが重要です。

常に暗号化

HTTP / 3には、TLSを多用しているが、直接使用していない暗号化が含まれています。 HTTP / 3の主な実装上の課題の1つは、新たに必要な機能を追加するためにTLS/SSLライブラリを変更する必要があることです。

この変更は、HTTP/3が暗号化の点でHTTPSと異なるためです。 古いHTTPSプロトコルでは、データ自体のみがTLSによって保護され、多くのトランスポートメタデータが表示されたままになります。 HTTP / 3では、データとトランスポートプロトコルの両方が保護されます。 これはセキュリティ機能のように聞こえるかもしれませんが、そうです。 ただし、HTTP / 2に存在する多くのオーバーヘッドを回避するために、この方法で実行されます。 したがって、トランスポートプロトコルとデータを暗号化すると、実際にはプロトコルのパフォーマンスが向上します。

ネットワークインフラストラクチャに対するHTTP/3の影響

HTTP/3には論争がないわけではありません。 主な懸念事項は、ネットワークインフラストラクチャに関するものです。

クライアント側のHTTP/3

クライアント側では、UDPトラフィックが大幅にレート制限されたりブロックされたりすることがよくあります。 これらの制限をHTTP/3に適用すると、プロトコルのポイントが無効になります。

第二に、HTTPが監視および/または傍受されることは非常に一般的です。 HTTPSトラフィックがある場合でも、ネットワークはプロトコルのクリアテキストトランスポート要素を定期的に監視して、特定のネットワークまたは特定の地域内から特定のWebサイトへのアクセスを防ぐ目的で接続を切断する必要があるかどうかを判断します。 一部の国では、これは特定のサービスプロバイダーに対して法律で義務付けられています。 HTTP / 3での必須の暗号化により、これは不可能になります。

政府レベルのフィルタリングだけではありません。 多くの大学、公立図書館、学校、および親が心配している家庭は、特定のWebサイトへのアクセスをブロックするか、少なくともどのサイトにアクセスしたかをログに記録することを積極的に選択しています。 HTTP / 3での必須の暗号化により、これは不可能になります。

現在、限定的なフィルタリングが可能であることに注意してください。 これは、サーバー名表示（SNI）フィールド（Webサイトのホスト名を保持しているが、パスやクエリパラメーターなどは保持していない）がまだ暗号化されていないためです。 しかし、これは近い将来、TLS標準に最近追加されたESNI（暗号化されたSNI）の導入によって変更される予定です。

サーバー側のHTTP/3

サーバー側では、トラフィックを予期していないポートとプロトコルをブロックすることをお勧めします。つまり、サーバー管理者は、既存のTCP 443ルールに依存するのではなく、HTTP/3用にUDP443を開く必要があります。

次に、ネットワークインフラストラクチャによってTCPセッションがスティッキーになる可能性があります。つまり、ルーティングの優先順位が変更されても、TCPセッションは常に同じサーバーにルーティングされます。 HTTP / 3はセッションレスのUDPで実行されるため、ネットワークインフラストラクチャを更新してHTTP / 3固有の接続IDを追跡する必要があります。この接続IDは、スティッキールーティングを支援するために特に暗号化されていないままになっています。

第三に、HTTPを検査して不正使用を検出し、一般的なセキュリティ問題を監視し、マルウェアやウイルスの拡散を検出して防止することは非常に一般的です。これは、HTTP/3では暗号化されているため不可能です。 それでも、デバイスがHTTP / 3サポートを実装していると仮定すると、傍受デバイスがセキュリティキーのコピーを持っているオプションは引き続き可能です。

最後に、多くの管理者は、さらに多くのSSL証明書を管理する必要があることに反対していますが、Let'sEncryptなどのサービスが利用できるようになった今ではそれほど問題にはなりません。

これらの懸念に対処するための広く受け入れられているよく知られたソリューションが存在するまでは、多くの大規模なネットワークが単にHTTP/3をブロックする可能性が高いと思います。

Web開発に対するHTTP/3の影響

この面で心配することはあまりありません。 HTTP/2のストリーム優先順位付けとサーバープッシュ機能は引き続きHTTP/3に存在します。 Web開発者がサイトのパフォーマンスを本当に最適化したい場合は、これらの機能に精通することは価値があります。

今すぐHTTP/3を使用する

Google ChromeまたはオープンソースのChromiumブラウザのユーザーは、すでにHTTP/3を使用するように設定されています。 HTTP / 3サーバーの本番品質のリリースはまだ少し離れています。この記事の執筆時点では、仕様は完全には完成していません。 しかし、その間、遊ぶためのツールはたくさんあり、GoogleとCloudflareの両方がすでに本番環境へのサポートをプッシュしています。

それを試す最も簡単な方法は、DockerでCaddyを使用することです。 これにはSSL証明書が必要なので、公的にアクセス可能なIPアドレスを使用すると作業が簡単になります。 手順は次のとおりです。

1. DNSの設定。 インターネット上に存在する有効なホスト名を取得します。たとえば、 yourhostname.example.com IN A 192.0.2.1です。
2. キャディファイルの作成。 次の行が含まれている必要があります。

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Caddyの実行： docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic —またはDockerの外部では、caddy-- caddy --quic 。
2. QUICを有効にしてクロムを実行する： chromium --enable-quic
3. （オプション）プロトコルインジケータ拡張機能をインストールします。
4. ファイルブラウザが表示されているQUIC対応サーバーに移動します。

開発者は、次の便利なツールを使用してサーバーをテストすることもできます。

• KeycdnのHTTP/2テスト
• LiteSpeedのHTTP3Check
• QualysのSSLサーバーテスト

読んでくれてありがとう！