アカウント名:
パスワード:
レイヤの順序がいまいち掴みきれてませんが、HTTPの下を支えるコネクション用の専用かつ協調(サーバ/クライアントで)する必要のあるプロトコル、でいいのかな。
Proxyが時としてキャッシュを提供できるように、この上にのったHTTPコネクションはヘッダごと圧縮できたり、プッシュできたり、リクエストのQoSができたり?
それはそれで良いですね。
-- オフトピ# ただ、なんでもかんでもHTTPなのはGoogleががんばってやってることなので、「ちゃんとかつやっとこ自分のことは自分でやってる」という感じも# いや効率自体はさほど差はないのかもですが、Google Waveみたくall on httpなのもどうかなぁ、とか思うので。## 前出のコメントでは「XMPPとかあるしircサポートうんぬん」言ってましたが、だからって全部はどうだろう、みたいな
SPDYの仕様のまとめはSPDYについて: 適当なメモ [hatena.ne.jp]がわかりやすいです。プロトコルの詳細はSPDY Protocol [chromium.org]
そういう意味だとIPv4上のサービスの延命(たとえIPv6が本格化しても当座はかなり残るから)の意味でも有効ですねー。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
ふむ (スコア:1)
レイヤの順序がいまいち掴みきれてませんが、HTTPの下を支えるコネクション用の専用かつ協調(サーバ/クライアントで)する必要のあるプロトコル、でいいのかな。
Proxyが時としてキャッシュを提供できるように、この上にのったHTTPコネクションはヘッダごと圧縮できたり、プッシュできたり、リクエストのQoSができたり?
それはそれで良いですね。
-- オフトピ
# ただ、なんでもかんでもHTTPなのはGoogleががんばってやってることなので、「ちゃんとかつやっとこ自分のことは自分でやってる」という感じも
# いや効率自体はさほど差はないのかもですが、Google Waveみたくall on httpなのもどうかなぁ、とか思うので。
## 前出のコメントでは「XMPPとかあるしircサポートうんぬん」言ってましたが、だからって全部はどうだろう、みたいな
M-FalconSky (暑いか寒い)
Re: (スコア:5, 参考になる)
SPDYの仕様のまとめは
SPDYについて: 適当なメモ [hatena.ne.jp]
がわかりやすいです。
プロトコルの詳細はSPDY Protocol [chromium.org]
Re:ふむ (スコア:2, 興味深い)
そこにQoSを加える、と。
サーバやNAT管理者から見れば、何よりも嬉しいのは1ユーザからのコネクションが1本だけで済むってことだろうか。
QoSの精度をある程度犠牲にすれば、HTTP→SPDYなプロキシとかも実現可能かな。
ポートが足りなくてNATが悲鳴を上げているようなネットワークにはいい感じになりそうだ。
Re:ふむ (スコア:1)
そういう意味だとIPv4上のサービスの延命(たとえIPv6が本格化しても当座はかなり残るから)の意味でも有効ですねー。
M-FalconSky (暑いか寒い)