HTTP/2ヘッダー圧縮からパフォーマンスの向上を測定するには

Question

ヘッダー圧縮からHTTP/1.1と比較してHTTP/2のパフォーマンスが向上するのを確認しようとしています。私は、300msのレイテンシと50KB/sの帯域幅のネットワークをシミュレートしました（他にもいくつかの組み合わせを試しました）。

私は、各テストでは1から100

に変え切断する要求の異なる番号を送信テストの複数の試みをした、私は私のページが複数回ロードして、送信された要求し、受信したレスポンスの最初のバイトまでの時間を計測します（私はNavigation Timing APIを使っています）。最初の要求とその後の要求の間にはこの時間が短縮されます。 HTTP/1.1でも同様の減少が見られます。 したがって、HTTP/1.1と比較して目に見える利得はありません。総ページ読み込み時間は大幅に改善されていますが、ヘッダ圧縮や多重化によるものとは言えません。だから私は、送信されたリクエストと最初に受け取ったレスポンスのバイトとの間の時間を測定することが正確な尺度を与えるべきだと思いますしかし、私はそれを体験することができません。

は私のサンプルテスト結果

検索どのようなヘッダ圧縮からパフォーマンスの向上を測定するための正しい方法でなければなりませんか？

ありがとうございました。

Answer 1

ヘッダー圧縮だけでパフォーマンスが向上することを知りたい場合は、ヘッダー圧縮のみが異なる2つのシナリオが必要です。 HTTP/1.1はヘッダー圧縮をサポートしていないので、HTTP/2を使用して実験を行う必要があります。 1つには、HPACKエンコーダに圧縮の種類を使用しないように（ハフマンエンコーディングを使用せず、テーブルをまったく使用しないように）要求します。

私はそれを見る方法は、本格的なウェブサイトでこれを測定するためには、非常に精巧なサーバーサポートが必要です。そしてあなたはおそらくあなたのヘッダーが十分に面白いように本格的なウェブサイトを望んでいるでしょう。私の最善の提案は、あなたがNginXのソースコードをチェックアウトし、基本的にHPACKのスラックを可能な限り持っているコードを編集することです。

このような包括的な解決策が見つからない場合、ヘッダー専用のHTTP/2フレームで使用されているバイト数と、サイトのHTTP/1.1フェッチでヘッダーに使用されているバイト数を単純に測定できます。今すぐWiresharkといくつかの構文解析があなたを助けることができます。私たちはShimmerCatにそのようなカウンターを追加するつもりですが、残念ながらまだありません（異なるプロトコルをテストするのにquick command line switchesがあります）。

Answer 2

ヘッダーサイズを2 KBに増やし、低帯域幅と高レイテンシの条件をエミュレートした後、第1の要求と第2の要求の間のTTFB削減を確認できました。