2

RFC 2616セクション 8.1.2.2 には次のように記載されています。

永続的な接続をサポートするクライアントは、その要求を「パイプライン化」することができます (つまり、各応答を待たずに複数の要求を送信します)。サーバーは、要求が受信されたのと同じ順序で、それらの要求に応答を送信する必要があります。

シリアル応答は、実際にはサーバーがより多くの処理を行う必要があり、パイプライン処理によって得られるパフォーマンスの利点を無効にするため、多くの場合、良いよりも害が大きくなります。

たとえば、HTTP クライアントがファイル 1.jpg、2.jpg、3.jpg、4.jpg、および 5.jpg を要求する場合、3.jpg が 1.jpg の前に返されるか、4 が返されるかは問題ではありません。 .jpg は 3.jpg の前に返されます。クライアントは、応答が利用可能になり次第、任意の順序で応答を求めます。

HTTP クライアントがパイプライン処理の利点を享受しながら、同時に応答キューイングの欠点を補うにはどうすればよいでしょうか?

4

3 に答える 3

2

クライアントは、RFC 2616 の一部であるため、HOL キューイングを回避できません。(私の意見では) パイプライン化の唯一の利点は、非常に具体的で狭い場合です。検討：

R 1コスト=Request A処理コスト。
R 2コスト=Request B処理コスト。
TCPコスト= 新しい TCP 接続のネゴシエーションのコスト。

したがって、パイプラインの使用は、次のような特定の場合に有効です。

R 1コスト≥ R 2コスト≤ TCPコスト

リクエストが以前のリクエストよりも高価で、新しい TCP 接続のネゴシエーションよりも安価である頻度はどれくらいですか? しばしばあるわけではない。Websocket は (はるかに) より興味深く適切なソリューションであると付け加えておきます (並列バックエンド処理に関する限り)。

于 2012-07-17T18:53:01.183 に答える
1

できません (HTTP/1.1 では)。HTTP の将来のバージョンに含まれる可能性があります。

于 2012-07-17T19:10:19.840 に答える
1

HTTP ヘッダーには、どの応答がどの要求に一致するかを識別するデフォルトのメカニズムはありません。応答は、受信された順序により、特定の要求に対するものであることがわかっています。1.jpg、2.jpg、3.jpg、4.jpg、および 5.jpg を要求し、任意の順序で応答を送信した場合、どれがどれであるかはわかりません。

(クライアントとサーバーのヘッダーに独自のマーカーを実装することもできますが、プロトコルに準拠していないことは確かであり、ほとんどの実装はそれを処理する方法を知りません。マップするために何らかの処理を行う必要があり、これにより、この並列実装の利点も予想されます。)

既存の HTTP パイプライン メカニズムから得られる主な利点は次のとおりです。

  • 通信遅延が減少する可能性があります。これは、接続によっては問題になる場合があります。
  • より長いサーバー側の計算を必要とする要求の場合、サーバーは、要求の受信時に、前の応答を送信している間にバックグラウンドでこの計算を開始して、2 番目の結果の送信をより早く開始できるようにすることができます。(これもレイテンシーの一種ですが、応答準備の観点からです。)

これらの利点の一部は、複数の要求を個別に送信し、ページの一部を (AJAX を介して) 段階的に更新できる、より最新の Web ブラウザー技術によっても得られます。

于 2012-07-17T19:23:08.390 に答える