2

http://dev.chromium.org/spdy/spdy-whitepaperでSPDYホワイトペーパーを読むと、それをサポートすることでHTTPレイテンシーが改善されるようです。しかし、私はいくつかの主張についてはっきりしていません。

1）「HTTPは一度に1つのリソースしかフェッチできないため（HTTPパイプラインは役立ちますが、FIFOキューのみを強制します）、500ミリ秒のサーバー遅延により、追加の要求にTCPチャネルを再利用できません。」-この500msの数値はどこから来たのですか？

2）「SPDYの遅延の節約は、パケット損失率の増加に比例して増加し、2％で最大48％のスピードアップになることを発見しました。」-しかし、すべての要求を単一のTCP接続に配置することは、輻輳制御がすべての要求を遅くすることを意味しませんが、複数の接続がある場合、1つのTCPストリームは遅くなりますが、他の人は遅くなりませんか？

3）「[パイプライン処理を使用]ストリーム内の何かの処理の遅延（行頭での長い要求またはパケット損失のいずれか）は、ストリーム全体を遅延させます。」-これは、パケット損失がSPDYを使用してストリーム全体を遅延させないことを意味します。なぜだめですか？

4

2 に答える 2

2

500msの参照は単なる例であり、数は50msまたは5sですが、ポイントは同じです。HTTPはFIFO処理を強制するため、基盤となるTCP接続の使用が非効率になります。論文が指摘しているように、パイプラインは理論的には役立つ可能性がありますが、実際には、パイプラインをオンにすると壊れてしまう多くの中間体があるため、パイプラインは使用されません。したがって、最悪のシナリオ、つまり完全なRTT +サーバー処理時間、およびFIFOの順序付けにとらわれています。

再、パケット損失。うん、あなたは正確に正しい。単一の接続を使用することの欠点の1つは、パケット損失の場合、飛行中のN個の接続の1つの1/2とは対照的に、接続全体のスループットが半分に削減されることです。そうは言っても、いくつかの利点もあります！たとえば、単一の接続を飽和させると、トリプルACKと潜在的にはるかに広い輻輳ウィンドウにより、回復がはるかに高速になります。ほとんどのHTTP転送は比較的小さい（数十KB）ため、そうではありません。多くの接続がスロースタートフェーズを終了する前に終了するのは珍しいことです。

再、パイプライン。パケットが失われると、ストリームが遅延します。これがTCPです。利点は、ヘッドオブラインブロッキングを排除することです。これにより、ブラウザーによるより多くのよりスマートな最適化が可能になり、その後に、上記で説明したいくつかの利点が続きます。

于 2013-03-19T03:43:14.187 に答える
1

@GroovyDotCom：HTTP2（SPDY）のパフォーマンス上の利点の実践的な証拠を次に示します。

http：//www.httpvshttps.com/

于 2014-12-01T14:16:14.733 に答える