Google、「Webの高速化」をうたう高速データ送受信技術「SPDY」を発表 75
ストーリー by soara
狙えるか、デファクト。 部門より
狙えるか、デファクト。 部門より
あるAnonymous Coward 曰く、
Googleが「SPDY」(SPeeDY)という、新たなデータ送受信技術を発表した(GoogleのChromium Blog、ITmediaの記事、 マイコミジャーナルの記事)。SPDYはWebのコンテンツを高速に送受信するためのアプリケーションレイヤのプロトコルで、複数のストリームを同時に利用したり、リクエストの優先度付けやHTTPヘッダ圧縮といった機能を備えているという。
Chromium Blogでは、現在Webで利用されているHTTPはシンプルでエレガントであり、現在でも非常に有用であると前置きした上で、「我々はウェブサイトやブラウザの進化に対応していく必要がある」とし、そのためにSPDY技術や、それをサポートするWebサーバーおよびクライアントを開発したと述べている。
SPDYはまだ開発中の段階であるが、実験ではWebページの読み込みを55%高速化できたとしている。
HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:3, 興味深い)
昨今のネットワークの性能からすると、HTTPやPOP3はとても性能が悪いです。
メール容量にしたら、たった2MBほどなんでftpで/var/mail/${USER} を持ってきたら
(帯域次第ではあるが)一瞬で転送が終るのだが、POP3を通すと、
1. メールを取得, 2. メールのフラッシュ, 3. ローカルの処理待ち
を届いたメールの数だけ繰り返す、なおかつ、その度にprocmailをforkするんで
遅くて仕方がないです。
ネットワークの遅延を100ms, サーバのレスポンスを50ms, procmailのforkと処理の
時間を100msとすると、1つのメールあたり250msかかることになり、2000通メールが
たまっていると、どれだけ帯域が広くても50秒以上の時間がかかることになる。
以上は簡単に計算した結果だが、TCPの初期転送速度は非常に遅いので、メールの
サイズが1500バイトに収まらない場合、実際には、もっと遅くなってしまう。
例えば、30KBのメールが届いたとすると、サーバの負荷がどれだけ低くても、
最短でも5RTT(100ms*5RTT=500ms)がかかってしまうことになる。
1RTT: 1500
2RTT: 1500+3000=4500
3RTT: 4500+6000=10500
4RTT: 10,500+12,000=22,500
5RTT: 22,500+24,000>30,000
同時にメールを取得して同時にメールをフラッシュできるようなプロトコルが
あればPOPメールのフラッシュを待たなくてもよいと思うのだけど、最近のメール転送
プロトコルには、このようなPOP3の欠点を隠せるような設計が盛り込まれている
のでしょうか?
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:2)
なので、POP を使うならメールを溜め込まないようにしましょう。
procmail 使ってなくても、概略同上。
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:1)
POP3 の欠陥じゃなく、POP3 を利用して procmail でローカルにデータを持ってくる場合の実装上の欠陥じゃないんですか? それ。
そこらの POP3 に対応した MUA で同じ POP3 サーバーからメールを拾ってきた場合にも同様の時間がかかってますか?
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:2)
はい。
挙げた例は、fetchmail+procmail+POP3を使っていて、10年くらい前に
海外の小国に旅行した際の話です。ネットワークが遅いということもあり、
3時間くらい端末の前にずっと座ってました。
/var/mail/${USER} を移動してftpで取ってきて一見落着しました。
あとは、5年くらい前にfetchmail+procmail+POP3で、地方都市の
POP3サーバに対してメールを取りにいったときも(メールの数が
多いので)やはりそんな感じでした。3時間というわけではないですが、
取得毎に数分くらいは待ってしました。
最近は、(個人では)東京住まいで東京にあるデータセンタにメールを取り
にいくのでRTTは低いですし、購読しているMLの数もずいぶん減りました。
そして何より、常時接続されていますので、遅さを体感する機会は少なく
なっていますが、それでも、遅さを感じることはあります。
例えば、今の会社のメールサーバは、某国にありIMAPでアクセスして
いますが、長期休暇で1週間メーラを起動しないで初出社したときには、
全てのメールが受信されるまでにコーヒが飲める程度には時間がかかりますね。
ftpで転送したらどうってことのない転送量なんでしょうけれども。
最近のPOP3/IMAPクライアントは複数のメールの取得を同時にリクエストするのでしょうか?
そもそもプロトコルデザイン上、同時にリクエストはできるのでしょうか?
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:1)
サーバー側の実装の話とか、ファイルシステムとかの話もありまして……。
Solaris のような sync mount 大前提のシステムでそのまま Maildir を利用し、大量に新着メールをため込んでいる場合 Maildir/new → Maildir/cur (だったかな?) の移動のために長時間待たされる場合があります。こういうパターンでは、プロトコルどうこうという話にはなりません。
# テストで 4 万通流し込もうとして、うっかり 40 万通流し込んだら 4、5 時間 MUA が応答しませんでした……。
メールの場合はバックエンドがどのようになっているかは不定です。必ずしも各ユーザーのメールがファイルに落ちているとは限りません。
また、IMAP では共有フォルダも参照できます。これを利用する場合、それこそ 1 ファイルに確定できませんし、ローカルにコピーするのは不適切ですね。
また、IMAP では要求と応答は非同期で行うことが可能です。HTTP のパイプライニングと同様に、応答が戻ってくる前に要求を出せます。
それらとは別にサーバーへ ssh 接続ができるのであれば、-C を付けてポートフォワードを行うことで圧縮をかける事も可能ですね。
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:1)
ほかの人も書いているけど、それは、
POP3 の話じゃなくて 特定の POP3 サーバーかクライアントの実装の話ですよね。
POP3 サーバーを Dovecot にでもして、メールボックス形式を maildir か何か
(mbox 以外) にでもしたらどうですか。
(Qpopper あたりを利用して遅いとか言っているんじゃないかと邪推 :-p)
> 同時にメールを取得して同時にメールをフラッシュできるようなプロトコルが
「メールのフラッシュ」って、具体的にどこのどんな動作のことを指していますか?
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:1)
POP3ですと、USER, PASS, STAT, LIST, RETR, DELEの順番にリクエストしていくわけですが、
RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく
動作するものなのでしょうか?
また、最近は実際にそのようなリクエストの出し方をしているメーラが多いのでしょうか?
もし、このようなリクエストの出し方ができるのであれば、プロトコルの限界ではなく、
指摘の通り、特定のメーラの実装の話です。
「メールのフラッシュ」とは、RETRを実行した後に実行するDELEおよびその完了動作を指して
使っています。
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:2, すばらしい洞察)
> POP3ですと、USER, PASS, STAT, LIST, RETR, DELEの順番にリクエストしていくわけですが、
> RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく
> 動作するものなのでしょうか?
諸々の事情でたぶん動作するでしょうが、意味はないでしょう。
それよりも、どうしてこれ↑とこれ↓から、
> また、最近は実際にそのようなリクエストの出し方をしているメーラが多いのでしょうか?
これ↓が導き出されるんですか?
> もし、このようなリクエストの出し方ができるのであれば、プロトコルの限界ではなく、
> 指摘の通り、特定のメーラの実装の話です。
あなたの書いた /var/mail/${USER} とか、procmail は POP3 仕様ではないので、
mbox 形式のメールボックスのフラッシュが遅いだとか、procmail の fork が
遅いだのってのは、POP3 とは関係ありません。
POP3 のプロトコル仕様を勉強してくださいな。
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:2)
thorin氏が#1672793 [srad.jp]で書いたように、POP3はpipeline capabilityが無いと遅くなりますし、POP3のデータをftpで転送すりゃ速度は出るでしょう。POP3にpipeline capabilityがあったとしてもfetchmailでprocmailのフィルタを通すなど、(車1台1台がハイウエイの料金を支払うときのように)1通1通のメールに対しシーケンシャルに処理行なえば、メール毎にTCPは1セグメントから転送を開始しますので、(車が料金所で混雑するように)POP3のプロトコルの性能上処理は遅くなるでしょう。これは、POP3(というか、HTTPしかり、複数のオブジェクトを取ってくる必要のあるプロトコルをTCP上で動作させた場合に発生する)固有の問題です。(メールを/var/mail/${USER}のように)単一のオブジェクトとみなしてftpで転送する場合には、この現象は発生しません。
昨今のネットワークのシステム設計では、このようなみかけのネットワークレイテンシィをいかに抑制するかが課題となっていると思います。
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:2, 参考になる)
> RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく
> 動作するものなのでしょうか?
昔 POP3 server の実装やりました。
これは POP3 server と client の実装によります。
規格的に言うと POP3 server と POP3 client の両方が PIPELINING capability を実装している場合には上記動作が可能になります。(cf. RFC2449)
ということで規格の方はずっと昔に既に拡張済み。
# それよりも(世の中にあふれている?)行バッファリングでパケットを送る駄目 POP3 server の方が本当の問題だと思う
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:1)
そーじゃなきゃRSETでキャンセルできない。
名前が… (スコア:2, おもしろおかしい)
バグってループしそうな…
プロトコルやGoogleのドキュメントを見たわけではありませんが (スコア:2)
推測ですが、以下のようなことを狙っているのではないでしょうか。
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秒となります。
実際には、画像ファイルにリンクするhtmlファイルの読み込みなども
必要となりますから、もっと時間がかかるでしょう。
これらの複数のコネクションを1つにまとめて、SSL上にのっけた場合、
単一のコネクションで済むのであれば、わずか9RTT(450ms)で済んでしまいます。
(1RTT毎のトータル転送量: 1500, 4500, 10500, 22500,46500,94500,382500,766500,1534K)
昔のサーバはそれほど性能がよくなかったので、リクエストに応じて
コンテンツを再構成するのは結構大変な仕事でしたが、マルチコアが安価
になった昨今、サーバの負荷を多少高くしてでも、通信のオーバーヘッド
を減らすのは重要なことといえるのではないでしょうか。
# プロトコルをちゃんと見てないので、すべて推測ですが…。
Re:プロトコルやGoogleのドキュメントを見たわけではありませんが (スコア:2, 参考になる)
普通 HTTP/1.1 で keep-alive して新規セッションを張るコストを避ける + deflate なりでテキストコンテンツの自動圧縮を行う形を取るため、自動圧縮の処理負荷を避けたいくらい処理性能限界に近付くような状況でもなければ転送時間はもっと少なくなりますよ。
また、リクエストのパイプライン化を行うことで応答の完了を待たずに次のリクエストを送り、応答結果を流している間に次の要求を処理できるようになっています。
SSI/CGI 等を利用していても自動的にコンテンツ圧縮をかける事ができるサーバが大半 + HTTP/1.1 非対応のサーバーを探す方が大変という現状なので、今時そんなことを言うのは色々とアレです。
Re:プロトコルやGoogleのドキュメントを見たわけではありませんが (スコア:1)
> また、リクエストのパイプライン化を行うことで応答の完了を待たずに次のリクエストを送り、応答結果を流している間に次の要求を処理できるようになっています。
それは知りませんでした。
それができるのであれば、挙げた例は該当しないです。
Re:プロトコルやGoogleのドキュメントを見たわけではありませんが (スコア:1)
確かに。
HTTP/1.1 の以下ですね。
http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616 [studyinghttp.net]
まあ、データを1つにまとめることができれば、html取得 -> パース -> データ再取得 のタイムラグは短かくできそうですよね。
ふむ (スコア: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 (暑いか寒い)
Re: (スコア:0)
HTTPはあくまで運用目的のほうで、実態はFTPやIMAPの方が近いと思う。ただ、ファイルを転送するわけじゃないし、IMAPほど腐った仕様でもない、ってだけで。
Re: (スコア:0)
Accept-Encoding: gzip
というものが既にあるんだが
Re:ふむ (スコア:3, 参考になる)
そのヘッダを送るのは、プレーンテキストなんですけど。。。
それに、それで圧縮可能なのは、HTTPのコンテンツの方で、HTTPヘッダは圧縮の対象外です。
返答のHTTPヘッダに、何のプロトコルで圧縮してあるか書いてあったりするので(gzipとは限らない)、
圧縮ファイルの解凍方法が、その圧縮ファイルの中に書いてある状態になってしまいます。
なので、今まで圧縮できていなかったHTTPヘッダを圧縮可能にしたってことが胆なのでは。
Re:ふむ (スコア:1, 興味深い)
ヘッダ圧縮は解析・デバッグが面倒だな
おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:1, 興味深い)
最近のGoogleはなんか神がかってて畏敬すら覚える。
うまく言えないけど、世界最高の知識と知恵と良心をもった人々が、
10代後半の万能感と学園祭前の実行力で、
老人のように当たり前のことを当たり前にやってる感じ。
HTTPを改良できることはみな気付くけど、誰も何もしない。標準だから。
でもGoogleは高速化する手段があるなら標準のプロトコルを変更してでも実現しようとするし、
それができるのはいまはGoogleくらいしかいないと思う・
昔我々のヒーローだった Firefox は IE より良いブラウザを作ることで満足してしまい、
技術者のつまらない理想でUIはスクリプトで動き、メモリは1GB喰う。
きっと速さよりコードのエレガンスさを気にしてる。
Firefox はもう絶対に Chrome を追い抜けないな。
Firefox 4.0 は Netscape 4.0 と似たものになると思う。
チラシの裏になってしまった。のでAC
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:3, 興味深い)
Firefox の最大の長所は、 Windows と Mac と X のどれでも動作すること (クロスプラットフォーム) と、拡張機能とテーマによってカスタマイズできること (カスタマイズ性) です。特にクロスプラットフォームであることと拡張機能によるカスタマイズ性は、主に C++ で書かれたコンポーネントを JavaScript のコードでつなぐという Firefox の設計によって可能になっている面が大きいです。これらの長所を諦めればずっと高速なブラウザーができるでしょうけれど、それで良いならべつに Google Chrome を使えば済むわけで、 Firefox に Google Chrome 並みの速度を求めるのは間違いだと思います。
(Google Chrome も Mac や X で動くバージョンがあるみたいですが、よく知りません。少なくとも正式版はまだのはずです。)
ちなみに、 Mozilla Corporation の人たちは Firefox の速度を気にしまくっているように思います。彼らがいつ「これからは拡張機能によるカスタマイズなんか諦めて速度を追求する!」と言い出さないか、僕はちょっと心配しています。
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:1)
それが理由で Mozilla Suite を捨てて (Galeon や Phoenix →) Firefox にしたはずなのに、原点を忘れて拡張しまくった結果 "Mozilla Suite のブラウザだけ" になってしまったのが問題なんじゃないでしょうか。
今の Firefox って、使えるアドオンがちょっと違う Netscape Communicator と Netscape Navigator くらいの差になってませんか?
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:2)
Firefox は最初から拡張機能によるカスタマイズを諦めて速度を追求する方針だった、とおっしゃるのでしょうか。だとすれば認識が誤っていると思います。僕の記憶では、 Firefox は出てきた当初から、拡張機能でカスタマイズできるブラウザーとして設計されていたし、それを売りにしてきたはずです。
むしろ、 Mozilla Suite と違って Firefox は「本体は軽めに作って、付加機能がほしい人は拡張機能を入れることで対応する」という方針だったように思います。その意味で、 Firefox での拡張機能の重要性は Mozilla Suite よりずっと高いものでした。その方針が今も続いているかどうかは、多少疑わしいです。
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:1)
Firefox 前の Phoenix 時代における方針ですね。
Firefox となった頃からはおっしゃる通りだと思いますが、その時点で「あれ?」という感じでした。
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:2)
知りませんでした。ありがとうございます。それだと、僕の #1672551 [srad.jp] で書いたことはだいぶ不正確ですね。
歴史を知らないのであまり言えませんが、原点を忘れたのではなく方針を転換したのではないのでしょうか。
#1672203 [srad.jp] に書いた通り、僕は Firefox の拡張性とクロスプラットフォームであることを評価します。 #1672203 に書いた「拡張性を諦めるなら Google Chrome でいいじゃん」という表向きの理由のほかに、僕が Firefox の拡張機能を作って遊んでいるから、拡張機能というおもちゃを取り上げないでほしいと思っているのも事実ですが。
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:2, おもしろおかしい)
えーと・・・
http://images.google.co.jp/images?hl=ja&q=%E3%81%9D%E3%82%8C%E3%81... [google.co.jp]
Re: (スコア:0)
よくわかりませんがナチュラルにGoogle画像検索へリンクを張ってるあたりがGoogleの恐ろしさなわけですね、
Re: (スコア:0)
> それができるのはいまはGoogleくらいしかいないと思う
それはあれですよね。スポーツで自分たちの国が不利になってくると「決められたルールで強くなるようにするのではなく、ルール自体を自分たちが有利になるように改正する」ようなものですよね。
スキージャンプとかモーグルみたいに...
Re: (スコア:0)
そう、必要なのはそういうしたたかな行動だよ
で、それが何か?
Re: (スコア:0)
つまり、これは凄いことなのか?と言うと、
感覚的に凄くないんだわ。
5Vの単三電池を作りました。従来品の3倍以上の電圧です。みたいな。
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:1)
ちなみに、単三の単は積層してない、1セルの電池という意味です。
起電力の理論的な最大値は電極に用いられる金属のイオン化傾向の差で決まってしまいます。
Wikipediaによると、積層電池であれば、単三サイズで15Vというものがあるそうです。
http://ja.wikipedia.org/wiki/%E7%A9%8D%E5%B1%A4%E9%9B%BB%E6%B1%A0 [wikipedia.org]
Re: (スコア:0)
Re: (スコア:0)
既存の(すでに標準化されている)規格を無視して、勝手に拡張してでも求める結果を実現する、ってのは、過去マイクロソフトあたりがやってきたことと同じなわけで、本当にGoogleってマイクロソフト化してるなぁ、という印象。
その意味では、マイクロソフトに好意的な人にはこういう手法は受け入れやすいのかもね
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:1, 興味深い)
Re: (スコア:0)
ありものをはやくしてやったぜって成果なのは認めてもいいけど
Re: (スコア:0)
Re: (スコア:0)
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:1)
5Vの単3で100mAhでも欲しいのかと。
いろいろなファクターの中の一部のスペックだけを見て
「絶対欲しい」
なんて言い切るのは危険です。
# 5Vってのが半端だって揚げ足取りたかったんでしょうけど。
Re: (スコア:0)
MSが変更しようとすると、帝国の陰謀だとファビよる癖に、googleさまのやることはすべて正しいですか。
どこの北朝鮮人だ?
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:2)
OSを握っている立場でそれをやられるのとはわけが違うと思いますよ。
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:1)
全然違う。
MSはクローズドソース。独占主義。(最近そうは言ってられなくなってオープンよりにはなってきたが、それも数々のオープンソースのおかげ)
Googleはオープンソース。
Re:おれたちにできない事を平然とやってのけるッ そこにシビれる!あこがれるゥ! (スコア:1)
それは受け取る人の立場によるわけで、
自分には利益が感じられず、MS(に限らず主唱者)だけが利益を得るようなことを、その強い立場の利用して主張されると、帝国の陰謀と言いたくなる。
最近ではOSのアップデートすら、そう感じられなくもない。
大して変わらないんでしょ、なんでまた高い金払わないといけないの、、、ユーザー
革新は? (スコア:1)
あんまり詳しくないから何とも言えんけど、HTTPに対するパラダイムシフトになるような話は無いのかね?
サーバからクライアントへのプッシュ機能というのはなかなか便利そうだけど、実際はどうなのかしらん?
HTTP-NG (スコア:3, 興味深い)
W3CのHTTP-NG [w3.org]でTCP上での複数セッションを含めて構想は昔からあるんですが、全然進んでません。
SPDYを契機に盛り返したりするかなー。
Re:つか、HTTP/2.0でも作れば? (スコア:1)