HTTP/2リクエストヘッダ圧縮

Question

私は専門家ではないので、HTTP/2に関する一般的な質問があります。

一般に知られているように、HTTP2はヘッダーを圧縮してメッセージサイズを小さくします。これは応答または要求にのみ適用されますか？小規模な実験を行い、バージョン1.1を使用する小型のHTTPサーバーとバージョン2を使用するもう1つの小型HTTPサーバーを実行する場合は、正確に同じコンテンツを送信し、両方のページをFirefoxでリクエストすると、応答ヘッダーのサイズがHTTP/2バージョン。ただし、要求ヘッダーのサイズはほぼ同じです。サーバーがHTTP/2対応のため、ヘッダーを先に圧縮することができない場合、ブラウザーは事前にわからないので、わかりました。私は正しい？もしそうなら、HTTP/2を使うようにクライアントを強制する方法がありますか？（クライアントでは私はブロッカーではなくプログラム的なものです）またリクエストヘッダーを圧縮しますか？

また、HTTP/1.1とHTTP/2の両方のパフォーマンスを負荷の下でベンチマークしたければ、有用なテスト設定はどのようなものになりますか、どのパラメータが変化するのか、 、TTFB、...？）

Answer 1

接続を開始するときに、プロトコルをネゴシエートします。クライアントは、送信する形式を知る前に、HTTP/1.1、HTTP/2など何かを話しているかどうかを知る必要があります。 HTTPS接続の場合、これはALPNを使用するTLS接続ネゴシエーションによって処理されます。

HTTP/1.1で最初の（またはそれ以上の）要求を開始し、後でHTTP/2にアップグレードすることもできます。これは、応答の中でUpgrade: h2（HTTPSの場合）またはUpgrade: h2c（HTTPの場合）HTTPヘッダーを送信し、クライアントがアップグレードを選択することによって、HTTP/1.1接続を介したサーバー広告h2サポートによって処理されます。これは、最初にTLSネゴシエーションがないため、クライアントがHTTP/1.1と見なす可能性が高いHTTP接続の方が便利です。しかし、すべてのWebブラウザでは、HTTP/2 over HTTP（h2c）はサポートされず、HTTPS（h2）でのみサポートされます。私は正直なところ、なぜHTTPS接続がHTTP/1.1で始まり、次にHTTP/2にアップグレードするのか考えることができません - HTTP/2として開始するのではなく、理論的には可能です。

あなたは、このリンクをクリックしてアップグレードヘッダーの例を見ることができます： https://securityheaders.io/?q=https%3A%2F%2Fwww.tunetheweb.com&followRedirects=on 注私は唯一のHTTPヘッダを表示する簡単な方法として、securityheaders.ioウェブサイトを使用しています。理論的にはブラウザでhttps://www.tunetheweb.comに直接行けば同じことを見ることができ、レスポンスヘッダを見ることができますが、これはHTTP/2を介して行われる可能性が非常に高いのでヘッダを持たないでしょう。これはオプションのヘッダーであり、すべてのHTTP/2サーバーがそれを送信するわけではないことに注意してください（ApacheはNGINXはそうではありません）。

圧縮がHTTP/2でどのように機能するかを理解することが重要です。最初はテキストベースのプロトコルではなくバイナリであるという利点がありますので、そこにはいくつかの節約があります。しかし、主な節約は、ヘッダーの辞書を作成して繰り返しを避けることです。これは、最初の要求がフルサイズになり、実際のヘッダーを辞書への参照に置き換えるため、後続の要求のみが小さくなることを意味します。レスポンスヘッダーの場合も同様です（圧縮は両方に使用されます）。

ブラウザはHTTP/2 HPACK圧縮を考慮せずにフルサイズを表示することは確かですが（ほとんどの場合2つの数字が表示されますがgzipのボディ圧縮ですが、それは異なります）。実際のHTTP/2の詳細とサイズを見るには、ワイヤーシャークやChromeのネット内部ページなどのツールを使用する必要があります。いくつかの推奨ツールについては、このページを参照してください：https://community.akamai.com/community/web-performance/blog/2015/06/05/useful-tools-for-http2-debugging。注目すべき点は、ほとんどの場合、ヘッダーのサイズはしばしば小さくなることです。

スタックオーバーフローの範囲を超えた大規模なトピックであるパフォーマンスベンチマークツールについては、これに影響を与える変数が非常に多いため（たとえば、ネットワークの場所、タイプに影響を与える待ち時間と帯域幅、ブラウザでのHTTP/2のソフトウェア実装、クライアント側...など）。可能な限り一般的な設定を複製し、できるだけ多くのテストを繰り返したり、たとえばRUM（Real User Monitoring）メトリックを分析ソフトウェアで使用することをお勧めします。 HTTP/2はほとんどのウェブサイトをより速くしなければならないが、それは与えられていない。このWebページは、非常に帯域幅が制限されたサイトの良い例です。実際には、調整なしでHTTP/2接続よりも遅くなります。https://99designs.ie/tech-blog/blog/2016/07/14/real-world-http-2-400gb-of-images-per-day/

希望します。