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

ふむ

[M-FalconSky (8868)]

レイヤの順序がいまいち掴みきれてませんが、HTTPの下を支えるコネクション用の専用かつ協調(サーバ/クライアントで)する必要のあるプロトコル、でいいのかな。

Proxyが時としてキャッシュを提供できるように、この上にのったHTTPコネクションはヘッダごと圧縮できたり、プッシュできたり、リクエストのQoSができたり?

それはそれで良いですね。

-- オフトピ
# ただ、なんでもかんでもHTTPなのはGoogleががんばってやってることなので、「ちゃんとかつやっとこ自分のことは自分でやってる」という感じも
# いや効率自体はさほど差はないのかもですが、Google Waveみたくall on httpなのもどうかなぁ、とか思うので。
## 前出のコメントでは「XMPPとかあるしircサポートうんぬん」言ってましたが、だからって全部はどうだろう、みたいな

--
M-FalconSky (暑いか寒い)

Re:ふむ

[Anonymous Coward]

SPDYの仕様のまとめは
SPDYについて: 適当なメモ [hatena.ne.jp]
がわかりやすいです。
プロトコルの詳細はSPDY Protocol [chromium.org]

Re:ふむ

[Anonymous Coward]

暗号化無しで圧縮オプションを有効にしたSSHトンネルを掘るってイメージに近いのかな？
そこにQoSを加える、と。

サーバやNAT管理者から見れば、何よりも嬉しいのは1ユーザからのコネクションが1本だけで済むってことだろうか。
QoSの精度をある程度犠牲にすれば、HTTP→SPDYなプロキシとかも実現可能かな。
ポートが足りなくてNATが悲鳴を上げているようなネットワークにはいい感じになりそうだ。

Re:ふむ

[M-FalconSky (8868)]

そういう意味だとIPv4上のサービスの延命(たとえIPv6が本格化しても当座はかなり残るから)の意味でも有効ですねー。

--
M-FalconSky (暑いか寒い)

Re:

[Anonymous Coward]

HTTPはあくまで運用目的のほうで、実態はFTPやIMAPの方が近いと思う。ただ、ファイルを転送するわけじゃないし、IMAPほど腐った仕様でもない、ってだけで。

Re:

[Anonymous Coward]

Accept-Encoding: gzip
というものが既にあるんだが

Re:ふむ

[haratake (365)]

そのヘッダを送るのは、プレーンテキストなんですけど。。。
それに、それで圧縮可能なのは、HTTPのコンテンツの方で、HTTPヘッダは圧縮の対象外です。
返答のHTTPヘッダに、何のプロトコルで圧縮してあるか書いてあったりするので(gzipとは限らない)、
圧縮ファイルの解凍方法が、その圧縮ファイルの中に書いてある状態になってしまいます。

なので、今まで圧縮できていなかったHTTPヘッダを圧縮可能にしたってことが胆なのでは。

Re:ふむ

[Anonymous Coward]

ヘッダ圧縮は解析・デバッグが面倒だな

Re:

[Anonymous Coward]

圧縮ストリームを非圧縮ストリームのように扱えるクラスを挟めばよいのでは？暗号化と違うのだから、のぞき見は別に制約は少ないかと。