最近のブラウザでパイプラインが無効になっているのはなぜですか？
最新のブラウザの多くは、パイプライン化されたHTTPリクエストを使用していません。理論的には、パイプライン処理は、Webサイトのフェッチに必要なラウンドトリップ時間の数を減らすことにより、要求を高速化するはずです。
HTTP標準によると、すべてのサーバー必須パイプライン化されたリクエストを処理するため、サーバーでのサポートが不足していることが問題になることはありません。
クライアントが受信する可能性のある応答を無視して、サーバーのパフォーマンスを重視するURLにできるだけ多くのパイプライン要求をプッシュした場合のレイヤー7 DoS攻撃など、セキュリティ上の懸念がいくつか見られました。
これがサーバーでパイプラインサポートをオフにする理由です（標準に違反しています）が、クライアントでオフにする理由は見つかりません。
ただし、AndroidブラウザおよびChromeモバイルではデフォルトでオンになっています。
Chrome、Firefox、IE、OperaおよびSafariがデスクトップ（場合によってはモバイル）バージョンでパイプラインされたHTTPリクエストを使用しないのはなぜですか？オフにする理由は何ですか？
パイプラインは次の理由で無効になっています。
- Firefox：
より大きな問題は、率直に言って、行ブロッキングの責任者と、パフォーマンスと堅牢性への影響です。ナイーブパイプラインは単にパフォーマンスを悪化させます。
- クロム：
既知のクラッシュバグと既知のキューの先頭のブロックの問題があるため、パイプラインを有効にするオプションはChromeから削除されました。パイプラインが有効になっていると、動作が悪く一貫性のないサーバーやミドルボックスも多数あります。これらが解決されるまで、パイプラインを使用しないことをお勧めします。現在、これを行うには、Chromiumのカスタムビルドが必要です。
一般に：
バギープロキシは依然として一般的であり、これらはWeb開発者が簡単に予測および診断できない奇妙で不安定な動作につながります。
パイプラインは正しく実装するのが複雑です。転送されるリソースのサイズ、使用される有効なRTT、および有効な帯域幅は、パイプラインによって提供される改善に直接影響します。これらを知らないと、重要なメッセージが重要でないメッセージより遅れる可能性があります。重要な概念は、ページレイアウト中にも進化します！したがって、HTTPパイプラインは、ほとんどの場合にのみわずかな改善をもたらします。
パイプラインは HOL問題 の影響を受けます。
HTTP/2は代替手段を提供します：
HTTP/1.xでは、ブラウザは優先度を超えるデータを活用する機能が制限されています。プロトコルは多重化をサポートしておらず、リクエストの優先度をサーバーに伝達する方法はありません。代わりに、並列接続の使用に依存する必要があります。これにより、オリジンごとに最大6つの要求の制限された並列処理が可能になります。その結果、接続が利用可能になるまで要求がクライアントでキューに入れられ、不要なネットワーク遅延が追加されます。理論的には、HTTPパイプラインはこの問題に部分的に対処しようとしましたが、実際には採用されていません。
HTTP/2は、これらの非効率性を解決します。ブラウザはすべてのリクエストを検出された瞬間にディスパッチでき、ブラウザはストリームの依存関係と重みを介してストリームの優先順位設定を伝達できるため、リクエストのキューイングと行頭ブロッキングが排除されます。応答配信をさらに最適化します。
プロキシも使用できます。
KDE3でKonquerorを高速化するために私が行ったことを試すことができます。 KonquerorにHTTPパイプラインがないことに不満があったので、検索した後、PolipoをローカルHTTP/HTTPS/FTPプロキシとしてインストールし、それを使用するようにKonquerorを設定しました（正しく覚えていれば、ポート8123のlocalhost）。 HTTPパイプラインに加えて、Polipoは改善されたキャッシュも提供しました。これはプロキシであるため、すべてのブラウザーでそれを使用するように設定でき、キャッシュはブラウザー間で共有されます。 （これは、各ブラウザーの独立したキャッシュを無効にすることをお勧めします。）
Salesforceは次のプロセスを使用します。
Salesforceには、TCPレイヤーでHOLBを軽減するための、強力でフィールドテスト済みのアプローチがあります。HTTPリクエストとTCP接続）の関係を切り離します。考えてみてください。複数のTCP接続（ネットワークコンテキストが必要とする数）で構成されるトランスポート）。HTTP要求の任意の部分が任意のTCP接続を経由できます。したがって、1つの接続でHOLBにアクセスすると、影響を受けるリクエストを軽減するだけでなく、正常な接続を使用して他のアプリケーションリクエストへの影響を最小限に抑えることができます。その結果、HTTPレイヤーで多重化とパイプライン化のメリットを享受しながら、最小限に抑えることができます。 HOLBのリスク。
参照
受け入れられた回答はやや古くなっている可能性があります。今日、私はサーバーに対する単一のHTTPS接続でchromeデスクトップパイプライン10リクエストを確認しました。これにより、パイプライン数がわかりました。