私たちは、ファイルホスティングソリューションを提供しています。私たちのクライアントは、HTTP 1.1プロトコル&ダウンロードファイルを使用して私たちのサーバーにヒットしたエンドユーザーです。これらのクライアントは基本的にはソフトウェアシステムまたはCDNであり、ソフトウェアライブラリを使用してファイルをダウンロードします。人間のユーザは私たちのシステムにアクセスしません。また、HTTP/1.1レンジヘッダーなどを使用した部分ファイルダウンロードのオプションも提供します。クライアントシステムは、複数のスレッドを使用してチャンク間で分割して大きなファイルをダウンロードします。Http2＆Fileダウンロード
私たちのサーバーにHTTP/2プロトコルを公開すると、本当のメリットがあるかどうかチェックしたいですか？私たちのクライアントシステムは既に複数のスレッドを使ってファイルをダウンロードすることができるので、Http/2多重化は本当に有益でしょうか？
おかげ
HTTP/2ファイルのダウンロードには2つの主な理由のためにHTTP/1.1よりも少し遅い：フレームのオーバーヘッドとflow control。
HTTP/1.1では、Content-Lengthの区切りのダウンロードを使用すると、ダウンロードされる唯一のバイトはコンテンツバイトです。 しかし、HTTP/2では、各フレームのDATAは、フレームヘッダーに対して9つの余分なバイトを持ちます。小さいオーバヘッドである16384バイトの通常の最大フレームサイズにおいて、それは存在する。
スローダウンに大きく寄与するのは、HTTP/2フロー制御です。 クライアントは、デフォルトセッションとストリームフロー制御ウィンドウを必ず大きくしなければなりません。デフォルトでは両方とも65535バイトです。
HTTP/2の仕組みは、サーバーが各HTTP/2セッション（接続）とそのセッションの各ストリームに対してのの送信ウィンドウを保持していることです。 ダウンロードが開始されると、サーバーは、送信ウィンドウで許可されたバイト数だけ、そのストリームまたはそのセッションのいずれかが最初に使い果たされるまで送信できます。次に、クライアントがWINDOW_UPDATEフレームを送信するのを待たなければなりません。これは、ストリームとセッションの両方のフロー制御ウィンドウを補充し、クライアントがより多くのデータを受け取る準備ができていることをサーバーに伝えます。
デフォルトのものなどの小さなウィンドウでは、特に、単純に実装されている場合、クライアントとサーバー間のネットワーク待ち時間のためにこのメカニズムがダウンロードパフォーマンスを低下させる可能性があります。 サーバーは、クライアントがWINDOW_UPDATEを送信するのを待っている間、ほとんどの時間が停止し、サーバーがより多くのデータを送信できるようになります。
多重化は二重の役割を果たします。同時に多数のファイルのダウンロードを開始することができますが（HTTP/1.1よりも多くのファイルがありますが、これは接続の数を減らすことによって制限される可能性があります）、ストリームごとにダウンロードされたデータセッション送信ウィンドウの削減に貢献します。各ストリームはまだ送信されていない送信ウィンドウを持っている可能性があります（したがって、より多くのデータを送信できます）が、セッションウィンドウが使い果たされているため、サーバーが停止する必要があります。ストリームは、セッション送信ウィンドウを消費するために互いに競合しています。サーバ実装は、複数のストリームからフレームを正しくインタリーブする必要があるため、重要です。
HTTP/2ではHTTP/1.1とのパリティを達成することができますが、クライアントとサーバーのかなり高度な実装があり、重要なパラメータ。
理想的には、クライアント上：最初のフロー制御ウィンドウをセッションを制御し、ストリーミングする
WINDOW_UPDATEフレームを送信良い実装サーバーは決して行き詰まりません。これは、サーバー上で、理想的には（同様にTCPが何に）bandwidth-delay productに応じて、セルフチューニング機能が必要な場合があります正しく、同じセッションの複数のストリームからのフレームをインターリーブする
[免責事項、私HTTP/2の管理者がJettyの場合
Jetty 9.4.xは、HTTP/2のダウンロードができるだけ高速であることを確認するためにコミュニティとお客様と協力しているため、上記のすべての機能をサポートしています。
サーバー上で適切なインターリーブを実装し、JettyのHttpClientとHTTP2Clientは、それぞれHTTPとHTTP/2要求を処理するための高レベルと低レベルのAPIを提供します。フロー制御はBufferingFlowControlStrategyに実装されており、WINDOW_UPDATEフレームが送信されたときに調整できます（まだ動的ではありません）。 クライアントには、初期フロー制御ウィンドウを設定するオプションもあります。 Jettyのすべてがプラグイン可能なので、より高度なフロー制御戦略を書くことができます。
JavaまたはJettyを使用しない場合でも、クライアントとサーバーの両方で使用しているライブラリを解読（または書き込み）して、上記の機能を提供できるようにしてください。
最後に、試して測定する必要があります。適切なHTTP/2の実装と構成では多重化の効果が出てくるため、クライアントとサーバーの両方で並列性が高まり、リソースの使用率が低下するため、HTTP/1.1よりも利点があります。