「Google、「Webの高速化」をうたう高速データ送受信技術「SPDY」を発表 」記事へのコメント

プロトコルやGoogleのドキュメントを見たわけではありませんが

[jsi (25633)]

推測ですが、以下のようなことを狙っているのではないでしょうか。

HTTPでWebページを読み込もうとすると、恐しいほどの時間がかかるわけです。
試しに、50msのRTTのネットワークで、20KBのコンテンツ50個(合計:1MB)
に取得に必要な時間を計算してみましょう。

1コンテンツの取得に必要な時間
1RTT: 1500
2RTT: 1500+3000=4500
3RTT: 4500+6000=10500
4RTT: 10,500+12,000=22,500
すなわち、4RTT(50ms*4=200ms)です。

標準的なブラウザでは、5コネクションまでしか張れません。したがって、
50/5=10スロット分の通信を行なう必要があり、ウェブページの読み込み
に必要な時間は、10*200ms=20

Re:

[Stealth (5277)]

普通 HTTP/1.1 で keep-alive して新規セッションを張るコストを避ける + deflate なりでテキストコンテンツの自動圧縮を行う形を取るため、自動圧縮の処理負荷を避けたいくらい処理性能限界に近付くような状況でもなければ転送時間はもっと少なくなりますよ。
また、リクエストのパイプライン化を行うことで応答の完了を待たずに次のリクエストを送り、応答結果を流している間に次の要求を処理できるようになっています。

SSI/CGI 等を利用していても自動的にコンテンツ圧縮をかける事ができるサーバが大半 + HTTP/1.1 非対応のサーバーを探す方が大変という現状なので、今時そんなことを言うのは色々とアレです。

Re:プロトコルやGoogleのドキュメントを見たわけではありませんが

[jsi (25633)]

確かに。

HTTP/1.1 の以下ですね。

http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616 [studyinghttp.net]

8.1.2.2 パイプライン化

持続的接続をサポートするクライアントは、そのリクエストを "パイプライン" する事ができる (例えば、複数のレスポンスを待つ事無く、複数のリクエストを送る)。サーバは、リクエストが受信されたのと同じ順番で、それらのリクエストのレスポンスを返さなければならない。

持続的接続を想定し、接続確立の後にすぐパイプラインを行うクライアントは、もし最初のパイプライン化への試行が失敗した場合は、それらの接続を再試行する準備をすべきである。クライアントがそのような再試行を行う場合は、その接続が持続的であると分かるまではパイプラインを行ってはならない。もし、サーバがすべての通信のレスポンスを返す前に接続を閉じてしまったら、クライアントはそれらのリクエストを再送信する準備をしなければならない。

まあ、データを1つにまとめることができれば、html取得 -> パース -> データ再取得 のタイムラグは短かくできそうですよね。