BT

Ready for InfoQ 3.0? Try the new design and let us know what you think!

SPDY対WebSockets?

| 作者: Mark Little フォローする 15 人のフォロワー , 翻訳者 徳武 聡 フォローする 1 人のフォロワー 投稿日 2012年6月27日. 推定読書時間: 5 分 |

原文(投稿日:2012/06/24)へのリンク

InfoQではHTML5のWebSocketsプロトコルについて多くの記事で取り上げてきた。動作原理を取り上げた記事にしろ、RESTfulなサービスのサポートの可否を取り上げた記事にしろ、すでに定着した技術であるかのように紹介している。しかし、ほとんどの新しい技術と同様、問題点もある。潜在的な脆弱性がそうだ。WebSocketsの普及を推し進めているのはウェブの性能改善の必要性だ。そして、この必要性を満たすにはWebSocketsの以外の選択肢もある。InfoQが今年の始め取り上げたGoogleのSPDYプロトコルはHTTPbisワーキンググループでHTTP/2.0のコンテナになりうるものとして検討されている。

これまで、WebSocketsとSPDYが競合するかどうか、もし競合するとしたらどちらが優れた選択肢なのかについてはあまり注意が向けられていなかった。けれども、2つを共存させ組み合わせることについては言及されている。Brit Gardner氏が言うように

このふたつのプロトコルは相補的です。WebSocketsはサーバとの最初のハンドシェイクをHTTPで行い、ws://プロトコルがサポートされているかどうかを調べます。一方、SPDYはHTTPリクエストのヘッダを圧縮しキャッシュすることで最適化を図ります。[...]したがって、SPDYを使い、リアルタイムの通信にはWebSocketsを使うのが、RESTfulなリクエストをベースにしたウェブの理想的なかたちです。このふたつのプロトコルは似ています。

Googleは今年の3月、'WebSocket Layering over SPDY/3'という文書を公開している。これはGoogle自体ががこのふたつのプロトコルの関係について関心を示している証拠だ。

しかし、2009年、HTTPbisの議長のMark Nottingham氏はWebSocketsとSPDYが別々の未来を見ていることをほのめかしている

[...]今週の前半に広島で開催されたIETFでは、[WebSocketsの]標準化のためのワーキンググループを立ち上げるべきだという雰囲気が強かったです。もし、SPDYが最終的にWAKAと同じ道を辿るなら、WebSocketsを使って実現しようとしていたHTTPライクな通信処理にはSPDYを使って実現するという選択肢も生まれます。

InfoQが以前報じたWebSocketsの潜在的な脆弱性は元々Lori MacVittie氏が指摘したものだ。氏はSPDY対WebSocketsの詳しい議論についてのツイートに反応した。氏はMark氏と同様に、2つのプロトコルのHTTPの使い方の違いに答えがあると考えている。/p>

“なぜWebSocketsをここで使ってはだめなのか”という疑問には簡単に答えられます。つまりHTTPヘッダーです。また、インフラへの影響という答えでもいいでしょう。[...]単純な実装の違いのため、WebSocketsはSPDYよりもウェブに対する影響が小さいでしょう(データセンターには大きな影響をあたえそうですが)。

Lori氏は2つのプロトコルは同じような特徴を持っているにも関わらず、SPDYのようなプロトコルの方がWebSocketsよりも次世代のウェブの支配権を握ると考えている。

2つのプロトコルは両方ともHTTPの“外”で動き、プロトコルを起動するための昇格の仕組みを持っています。WebSocketsは昇格を要求するためHTTPコネクションのヘッダーを使います。一方、SPDYはNext Protocol Negotiation(TLSの拡張)を利用します。Next Protocol Negotiationを使った昇格は後方互換性を持ち、サイトは次世代ウェブアプリケーションと従来のHTTPの両方をサポートできるようになります。[...]WebSocketsはHTTPヘッダーを使いません。SPDYは使います。この単純そうな違いがインフラのサポートに大きな影響を与えます。

Lori氏はWebSocketsとHTTPの弱い結びつきは、少なくともファイアウォールの前では"価値よりもトラブル"を生んでしまうと考えている。

仕様では、2つのプロトコルは完全に受け入れられるまでゲートウェイ転送サービスを要求しますが、SPDYよりもWebSocketsの方がインフラに悪影響を与えます。というのは、WebSocketsはインフラから見えないのです。IDS、IPS、ADC、ファイアウォール、アンチウイルスソフトのスキャナなど、コンテンツタイプや要求されたオブジェクトのURIの特定にHTTPヘッダーを使っているサービスはWebSocketsのリクエストを調査したり検証したりできません。HTTPヘッダーがないからです。現時点ではSPDYのHTTPヘッダーを利用するのも簡単ではありません。圧縮されているからです。しかし、gzipが簡単に扱われており、通信の中間にあるインフラで比較的簡単に(しかもSSL/TLSとは違って特別なデータなしで)圧縮や再圧縮ができるので、それほど大きなハードルではありません。

さらに、SPDYはHTTPを除去しないので、WebSocketsよりも安全性が高いと考えている。そして、SPDYは既存のインフラにも馴染みやすい。

SPDYはSPDYゲートウェイがひとつあればデータセンター全体で使えます。WebSocketsには多くのインフラサービスの更新または置き換えが必要で、さらに多くの組織にとって受け入れられないリスクを呼び込む可能性があります。

Lori氏はWebSocketsとSPDYのHTTPヘッダの使い方の違いがあるためにSPDYによる性能改善の方が広く受け入れられそうだと結論付けている。彼女の考えではWebSocketsはエンタープライズで使われる。しかし、多くの企業のインフラがHTTPで構成されていることを考えれば、それほど簡単ではないだろう。

 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション
BT