HTTP2はヘッドオブラインブロッキング（HOL）の問題をどのように解決しますか
HTTP2はヘッドオブラインブロッキング（HOL）の問題をどのように解決しますか？
この問題はhttp1.1では頻繁に発生しますが、HTTP2でこの問題が修正されたと聞きました。 HTTP2が問題をどのように修正したかを誰かが説明できますか？
HTTPヘッドオブラインブロッキング
HTTP用語での行頭ブロッキングは、各ブラウザー/クライアントがサーバーへの接続数に制限があり、それらの接続の1つを介して新しいリクエストを実行する前に、接続が完了するまで待機する必要があるという事実を指していることがよくあります。それをオフにします。
行頭リクエストは後続のリクエストをブロックします。
HTTP/2は、多重化を導入することでこれを解決し、以前の要求が完了するのを待たずに、同じ接続を介して新しい要求を発行できるようにします。
理論的には、HTTP/1.1のパイプライン処理はHOLを回避する方法も提供しましたが、実際に実装するのはトリッキーであり、エラーが発生しやすいものでした。そのため、今日に至るまで、Web上で広く使用できるようになりませんでした。
TCPヘッドオブラインブロッキング
ただし、HTTP/2は、別の種類のHOL、つまりTCPレベルで問題を抱えています。TCPストリームで1つのパケットが失われると、allストリームは、そのパッケージが再送信および受信されるまで待機します。このHOLはQUICプロトコルで対処されています...
QUICはUDPを介して実装される「TCPに似た」プロトコルで、各ストリームは独立しているため、失われたパケットは、失われたパケットが属する特定のストリームのみを停止し、他のストリームは続行できます。
HTTP/1は基本的には要求と応答のプロトコルです。ブラウザはリソース（HTMLページ、CSSファイル、画像など）を要求し、応答を待ちます。この間、その接続は他に何もできません-この応答を待つのはブロックされます。
HTTP/1はパイプラインの概念を導入していたので、待機中にリクエストを送信できます。リクエストの送信に遅延がなくなり、サーバーがリクエストの処理をより早く開始できるようになるため、状況が改善されます。応答は要求された順序で返される必要があるため、真のマルチ要求プロトコルではありませんが、改善されています（機能した場合-下記を参照）。これにより、接続でヘッドオブラインブロッキング（HOLB）の問題が発生しました。最初のリクエストに時間がかかる場合（たとえば、データベースルックアップを行い、ページを作成するために他の集中的な処理を行う必要がある場合）、その他のすべてのリクエスト彼らは行く準備ができていても、その後ろに並んでいます。実際、実際には、接続が解放されるまでブラウザがリクエストをキューに入れなければならなかったため、パイプラインを使用しなくてもHOLBはすでに問題でした-パイプラインを使用すると、接続レベルで問題がより明確になりました。
この上、HTTP/1のパイプライン処理はサポートされていなかったため、実装が複雑で、セキュリティの問題を引き起こす可能性がありました。したがって、HOLBの問題がなくても、それほど有用ではありませんでした。
このすべてを回避するために、HTTP/1はサーバーへの複数の接続（通常6〜8）を使用して、要求を並列に送信できるようにします。これには、セットアップと管理にクライアント側とサーバー側の両方で労力とリソースが必要です。また、TCP接続はさまざまな理由でかなり非効率的であり、ピーク効率に到達するまでに時間がかかります。その時点で、多くの労力を費やして、複数の接続を必要としなくなったと思われます。
一方、HTTP/2には、双方向のマルチプレックスストリームの概念が最初から組み込まれています。私はそれらがここにあるものの詳細な説明をしました： HTTP/2での多重化の意味 。これにより、HTTP/1要求のブロックの性質が取り除かれ、はるかに優れた、完全に機能し、完全にサポートされたバージョンのパイプラインが導入され、応答の一部を他の応答と混合して送り返すこともできます。これらすべてが一緒になってHOLBを解決します。より正確には、HOLBを問題とさえしません。
注意すべき1つの点は、これはHTTP HOLBを解決しますが、それでもTCPに基づいて構築されており、独自のTCP HOLBの問題があるためです。単一の接続！単一のTCPパケットが失われた場合、TCP接続は再送信を要求し、その後のTCPを処理する前にそのパケットが正常に再送信されるのを待つ必要がありますパッケージ-これらのパケットが、理論的にはその間に処理される可能性がある他のHTTP/2ストリーム用である場合でも（HTTP/1での実際の個別の接続で発生するように）。 Googleは、この問題を解決するために、QUICと呼ばれるプロトコルでTCPを保証するのではなく、非保証UDP上でHTTP/2を使用する実験を行っており、これも（SPDYと同様に）Web標準として設定中です-最初はGoogleの実装-HTTP/2に標準化されました。