Lori MacVittie「SPDYとHTML5 WebSocketsの比較」
f5 DevCentral 2012.6.13のエントリ
SPDY versus HTML5 WebSockets
- websocketsとspdyを比較
- spdyの方が普及の見込みが遥かに高い、と予測
- 予測の理由も説明
- webの高速化とか共通点が多い２つの技術の細かい違い
- websockectsにはヘッダが無い
- この細かい違いが意外と影響範囲が大きいことを説明してる
- 色々勉強になった比較
以下斜め読んだ内容
- #HTML5 #fasterapp #webperf #SPDY
- 似てる部分多い
- だがデータセンターへのインパクトはかなり違う
- http2.0をめぐる議論が少し盛り上がり中
- The HTTP 2.0 War has Just Begun
- このエントリへ「「なぜwebsocketsがスルー？」というコメントが付いた
- 答えは簡単「HTTPヘッダ」
- コメント主は詳しい説明欲しいと思うから、少し突っ込んだ説明してみる
ソリューションが違えばインパクトも違う
- spdyとwebsocketsにはシンプルだが根本的な違いがある
- この相違点ゆえに、websocketsはwebへのインパクトは極めて小さくなる
- データセンターに話を限れば影響力はある、かも。あるいは「またの機会に」扱い
- spdyとwebsocketの特徴の重要な部分はほとんど同じ
- これはコメント主の言う通り
- 非同期通信
- long polling等々既存テクニックのマイナス点を克服し、リアルタイム風な味付けをwebアプリに付けてくれる
- TCPコネクション１つだけを使う
- サーバーのオーバヘッド減らし、エンドユーザの体感パフォーマンス向上
- データ圧縮し通信コスト減らす
- websocketsはデフォルトではない。要拡張機能
- draft-ietf-hybi-thewebsocketprotocol-15 - The WebSocket Protocol
- モバイル環境などで活きてくると期待受けてる
- httpの外で通信する所も同じ
- 仕様も運用も同じような問題を解決しようとしてる
- httpヘッダが、spdy/websocketsの違い
- websocketsにhttpヘッダがない
- ここはSOA World Magazineの「HTML5 Web Sockets: A Quantum Leap in Scalability for the Web」という記事が詳しい。曰く
- websockets接続開始したら、クライアント／サーバー通信は完全に双方の通信に変わる
- websocketデータフレーム双方からいつでも投げれる
- データフレームはテキストだろうとバイナリーだといける
- 両側から同時にデータフレームを投げ合うことだってできる
- 最小データフレームサイズは2バイト
- 「0x00」〜「0xFF」の「〜」に投げたいデータがUTF-8で入ってる
- テキストデータではterminator（RFC2616準拠）使える
- バイナリデータではlength prefixつかえる
- httpヘッダを使うインフラに対して、websocketsのインパクトがとても大きい
インフラへのインパクト
- websocketsのもたらすインフラへのインパクトは「良い事」よりも「悪い事」が上回る可能性あり
- 少なくとも、オープンに使われるwebアプリではその可能性あり
- websockets/spdyともに普及しきるまでは、ゲートウェイサービスが必要になる点では共通してる
- websocketsは既存のインフラにどう導入していくか、というところで色々キツイ場面がある
- 仕組み上websockets通信はインフラ側からは全く分からない
- httpヘッダを使ってリクエストされてるオブジェクトのcontent-type、uriを判定していくタイプのサービスからはwebsocketsでリクエストされるオブジェクトは中身が全く分からなくなる
- IDS, IPS, ADC、ファイアーウォールなどがこのタイプのインフラに該当する
- spdy通信ではオブジェクトの中身が分からないということにはならない
- 過去の自分のエントリから関連部分再掲
- Oops! HTML5 Does It Again
- パフォーマンス改善のためにwebsocketsが使ってるテクニックの１つがhttpヘッダ削除
- 「content-type？」「煩雑！」というノリで
- httpヘッダは通信のエンドポイントに転送してるデータについて伝える（text/html、video/aviなど）
- アンチウィルスソフトやマルウェア検出ソフトが得意とするテクニック
- あるcontent typeにおかしい部分がないかを検出するテクニック
- MIME type情報が使えなくなったら、アンチウィルスソフトの診断は一気に難しくなる
- データからフォーマットを推論してくことは不可能じゃないが
- httpヘッダがないのに「このデータはウィルス」といった正確な知識をどうやったら獲得できるのか
- 「httpヘッダは偽装されるし」
- 確かに。だが一般的に言ってアプリが虚偽のデータタイプを伝えることはないし、あっても悪用されることがまずない脆弱性
- 「httpヘッダなくてもURIはどうか」
- websocketの場合オブジェクトとuriの間に関連性ゼロ
- httpヘッダ削るとデータタイプもわからないし、データサイズもわからなくなる
- httpヘッダの活用がとても重要なインフラ・サービスがインフラの世界にはある
- spdyは削除しないで圧縮する
- このことが、spdyの方がwebsocketsよりも遥かに有望な選択肢の位置に高めてる
- データセンターでspdyを使いたい？
- spdyゲートウェイを導入して、通信されるデータに対してspdy有効にしたら、完了
- データセンターでwebsockets導入したい？
- 既存のスタックを色々置き換えたり、機能追加することが必須になる
- つまりリスク付きの導入
- 実績あるスタックを置き換えて、実績ゼロ・未知数のスタックをたくさん投入しないとwebsockets化できない
- もう一度「なぜwebsocketsスルー？」に戻ると。。
- 高速化・パフォーマンス向上という点ではwebsocketsもspdyも同じ効果
- 既存インフラにかける負担（置き換え、アップグレード、運用コスト増）がwebsocketsは大きすぎて、インフラの世界ではそれほど普及しないはず
- パブリックな場面、オープンな場面ではwebsocketsがあんまり普及しない
- エンタープライズについてはまだダメだと結論でてない
- 結論出てない＝有望、ということじゃないが。。。
