SPDYはキープアライブ接続上のHTTP多重化とは異なります

Question

HTTP 1.1はキープアライブ接続をサポートし、接続は「接続：クローズ」が送信されるまで閉じられません。

ブラウザの場合、この場合firefoxはnetwork.http.pipelineを有効にし、network.http.pipelining.maxrequestsを増やしても最後に同じ効果はありませんか？

いくつかのWebサイトでは負荷が増加する可能性があるため、これらの設定は無効になっていますが、単純なhttpヘッダーフラグはブラウザにokを使用してマルチプレキシングを行うことができると考えています。

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

Answer 1

SPDYはSPDY whitepaperに記述されているHTTPパイプラインが提供できるものを超えて多くの利点、持っている：パイプラインで

1. を、サーバはまだ順番に一度応答のいずれかを返すことがあります彼らは要求された。これは、クライアントが静的なリソースの前に動的に生成されたリソースを要求した場合に問題になる可能性があります。動的に生成されて送信されるまで、サーバは「簡単な」静的応答を送信できません。 SPDYを使用すると、応答が生成されたときに応答が順不同で並行して返されるため、すべてのリソースを受信する合計時間が短くなります。
2. 質問にお答えしましたとおり、すべてのサーバーがパイプライニングを処理できるわけではありません。単に負荷ではなく、クライアントがパイプラインを要求したときに実際に正しく動作しないサーバーもあります。ヘッダーを使用してパイプライニングを行うことが適切であることを示すことは、最大の利益を得るには遅すぎます。既にその時点で最初の応答を受信して​​いるため、将来の接続で使用することはできますが、
3. SPDYは、そのタスクに固有のアルゴリズムを使用してヘッダーを圧縮します（ステートフルであり、通常はHTTPヘッダーにあるものの知識があります）。はい、SSLにはすでに圧縮が含まれていますが、単に圧縮するだけでは効率的ではありません。ほとんどのHTTPリクエストにはボディがなく、短いGETラインしかないので、ヘッダーはほとんどすべてのリクエストを構成します。多くの回答はヘッダーに比べて小さい。
4. SPDYを使用すると、サーバーはクライアントからの応答を要求せずに、追加の応答を返すことができます。たとえば、クライアントがHTMLを受信して​​解析してスタイルシートのURLを判断する前に、サーバーが元のHTMLとともにページのCSSの返送を開始する可能性があります。これにより、ページのレンダリングに必要な他のリソースを要求する前に、クライアントが実際にHTMLを解析する必要がなくなるため、ページの読み込み速度がさらに向上します。また、どのリソースが必要かを「ヒント」し、クライアントが決定できるようにする、この機能の帯域幅の少ないバージョンをサポートしています。これにより、たとえば、画像を気にしないクライアントが気にしないようにすることができますイメージを表示したいクライアントは、HTMLを待つことなく、指定されたURLを使用してイメージを要求できます。
5. 他のものもあります：ウィリアム・チャンの答えはさらに詳しく見てください。 SPDYのみでブロッキングラインのヘッドを有しているのに対し、

Answer 2

• HTTPパイプラインは、HTTPトランザクション・レベルでラインブロッキング（http://en.wikipedia.org/wiki/Head-of-line_blocking）の頭部に対して感受性でありますその多重化の使用のために、トランスポートレベル。
• HTTPパイプライニングにはデプロイ性の問題があります。これを軽減するためのさまざまな回避策とヒューリスティックを説明しているhttp://tools.ietf.org/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でチェックしてください。

Answer 3

Difference between HTTP pipeling and HTTP multiplexing with SPDY