「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)]

> また、リクエストのパイプライン化を行うことで応答の完了を待たずに次のリクエストを送り、応答結果を流している間に次の要求を処理できるようになっています。

それは知りませんでした。
それができるのであれば、挙げた例は該当しないです。