17

HTTP 1.1 はキープアライブ接続をサポートしており、接続は「Connection: close」が送信されるまで閉じられません。

したがって、ブラウザ (この場合は firefox) で network.http.pipelining が有効になっており、network.http.pipelining.maxrequests が増加した場合、最終的に同じ効果が得られるのではないでしょうか?

一部のWebサイトでは負荷が増加する可能性があるため、これらの設定が無効になっていることはわかっていますが、単純なhttpヘッダーフラグで、多重化を使用しても問題ないことをブラウザーに伝えることができ、この問題をより簡単に解決できると思います.

特にhttpサーバーで複雑さを増す新しいプロトコルを発明するよりも、ブラウザのデフォルト設定を変更する方が簡単ではないでしょうか?

4

3 に答える 3

22

SPDY には、HTTP パイプラインが提供できる以上の多くの利点があります。これらについては、SPDY ホワイトペーパーで説明されています。

  1. パイプライン処理では、サーバーは要求された順序で一度に 1 つずつ応答を返す必要があります。これは、クライアントが動的に生成されたリソースを静的なリソースよりも先に要求した場合に問題になる可能性があります。動的に生成されたリソースが生成されて送信されるまで、サーバーは「簡単な」静的応答を送信できません。SPDY を使用すると、応答を生成時に順不同または並行して返すことができるため、すべてのリソースを受信するための合計時間が短縮されます。
  2. 質問で指摘したように、すべてのサーバーがパイプライン処理を処理できるわけではありません。負荷だけでなく、クライアントがパイプライン処理を要求したときに実際に正しく動作しないサーバーもあります。ヘッダーを使用してパイプライン処理を行ってもよいことを示すのは遅すぎて、最大限の利益を得ることができません。その時点ですでに最初の応答を受け取っているため、将来の接続で使用することはできますが、この接続には既に遅すぎます。
  3. SPDY は、そのタスクに固有のアルゴリズムを使用してヘッダーを圧縮します (ステートフルで、通常 HTTP ヘッダーにあるものを認識しています)。はい、SSLにはすでに圧縮が含まれていますが、deflateで圧縮するだけでは効率的ではありません. ほとんどの HTTP リクエストには本文がなく、短い GET 行しかないため、ヘッダーが事実上リクエスト全体を構成します。取得できる圧縮は改善されます。多くの応答もヘッダーに比べて小さいです。
  4. SPDY を使用すると、クライアントが要求しなくても、サーバーは追加の応答を返すことができます。たとえば、クライアントが HTML を受信して​​解析し、スタイルシートの URL を特定する前に、サーバーがページの CSS を元の HTML と一緒に送り返し始めることがあります。これにより、クライアントがページのレンダリングに必要な他のリソースを要求する前に実際に HTML を解析する必要がなくなるため、ページの読み込みをさらに高速化できます。また、この機能の帯域幅をあまり使わないバージョンもサポートしており、どのリソースが必要になるかについて「ヒント」を与えることができ、クライアントが決定できるようになります。これにより、たとえば、画像を気にしないクライアントは画像を気にしなくても済みます。ただし、画像を表示したいクライアントは、HTML を待つ必要なく、指定された URL を使用して画像を要求できます。
  5. その他のことも: William Chan の回答を参照してください。
于 2012-04-28T09:57:03.163 に答える
13
  • HTTPパイプラインは、HTTPトランザクションレベルでの行頭ブロッキング（ http://en.wikipedia.org/wiki/Head-of-line_blocking ）の影響を受けやすいのに対し、SPDYは、その使用により、トランスポートレベルでの行頭ブロッキングしかありません。多重化の。
  • HTTPパイプラインにはデプロイ可能性の問題があります。これを軽減するためのさまざまな回避策とヒューリスティックについて説明しているhttps://datatracker.ietf.org/doc/html/draft-nottingham-http-pipeline-01を参照してください。SPDYサポートをネゴシエートするためにNPN（ http://technotes.googlecode.com/git/nextprotoneg.html ）を使用してSSL（ポート443）を介して一般的にデプロイされるため、実際にデプロイされたSPDYにはこの問題はありません。SSLは、仲介者が干渉するのを防ぐため、重要です。
  • SPDYにはヘッダー圧縮があります。ヘッダー圧縮の利点のベンチマーク結果について説明しているhttp://dev.chromium.org/spdy/spdy-whitepaperを参照してください。ここで、帯域幅の問題はますます少なくなっていることに注意してください（http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/を参照）が、帯域幅は依然としてモバイルにとって重要であることを忘れないでください。https://developers.google.com/speed/articles/spdy-for-mobileをチェックしてください。これは、SPDYがモバイルにとってどれほど有益であるかを示しています。
  • SPDYはサーバープッシュなどの機能をサポートしています。サーバープッシュを使用してコンテンツのキャッシュ可能性を向上させ、ラウンドトリップを削減する方法については、 http：//dev.chromium.org/spdy/spdy-best-practicesを参照してください。
  • HTTPパイプラインには、明確に定義されていない失敗のセマンティクスがあります。サーバーが接続を閉じるとき、どの要求が正常に処理されたかをどのようにして知ることができますか？これが、POSTおよびその他のべき等でない要求がパイプライン接続を介して許可されない主な理由です。SPDYは、同じ接続上の個々のストリームをキャンセルするためのセマンティクスを提供し、正常に処理される最後のストリームを示すGOAWAYフレームも備えています。
  • HTTPパイプラインは、多くの場合、仲介者が原因で、深いパイプラインを許可するのが困難です。これは（HoLブロッキングなどの他の多くの理由に加えて）、最大の並列化を実現するために複数のTCP接続を利用する必要があることを意味します。複数のTCP接続を使用するということは、輻輳制御情報を共有できないこと、圧縮コンテキストを共有できないこと（SPDYがヘッダーで行うように）がインターネットにとってより悪いことを意味します（仲介者とサーバーにとってよりコストがかかります）。

HTTPパイプラインとSPDYについて何度も続けることができました。しかし、私はSPDYを読むことをお勧めします。http://dev.chromium.org/spdyとSPDYに関するテクニカルトーク（http://www.youtube.com/watch?v=TNBkxA313kk&list=PLE0E03DF19D90B5F4&index=2&feature=plpp_video ）をご覧ください。

于 2012-05-02T06:04:41.367 に答える
3

SPDY を使用した HTTP パイプリングと HTTP 多重化の違いを参照してください。

于 2012-05-08T08:33:36.973 に答える