WebSocket について

Spring_MT2011/06/18 社内勉強会

WebSocket とは？・公式 draft http://dev.w3.org/html5/websockets/

・何ができるの？一言でいうと・・・・Client 側と Server 側のリアルタイム通信がよりシンプルにかつ、付加が少なく実現できるClient( ブラウザ ) 、 Server(web server)

今までの技術でも実現可能 ex). Comet　　　　　　　　　　　　　　　　　　　　何が問題なの？

従来の方法一体何が問題なの？

・従来の手法だと、 HTTP 通信に頼るしかない　→同時接続数が多いと　　メモリなどのリソースを大量に消費する。　　 1 リクエスト／レスポンスヘッダー自体は数 KB

・ HTTP だとステートレスな通信しかできない　→セッション管理等が面倒ex.) クッキーに情報を保存する リクエストの URI パラメータにすべての値を指定する（例： http://example.com/?val=[a,b,c] ）　

HTTP のヘッダー・ リクエストヘッダーGET / HTTP/1.1Host: today.is.sky.blue.skyUser-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; ja-JP-mac; rv:1.9.2.14) Gecko/20110218 Firefox/3.6.14Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: ja,en-us;q=0.7,en;q=0.3Accept-Encoding: gzip,deflateAccept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7Keep-Alive: 115Connection: keep-aliveCookie: wp-settings-1=editor%3Dhtml%26m1%3Do%26m3%3Dc; wp-settings-time-1=1304502829; __utma=56171822.1273043786.1307855232.1307855232.1307855232.1; __utmz=56171822.1307855232.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

・ レスポンスヘッダーHTTP/1.1 200 OKDate: Mon, 20 Jun 2011 18:12:40 GMTContent-Type: text/plain; charset=UTF-8Connection: closeTransfer-Encoding: chunked

従来の方法一体何が問題なの？

・従来の手法だと、 HTTP 通信に頼るしかない　→同時接続数が多いと　　メモリなどのリソースを大量に消費する。　　 1 リクエスト／レスポンスヘッダー自体は数 KB

・ HTTP だとステートレスな通信しかできない　→セッション管理等が面倒ex.) クッキーに情報を保存する リクエストの URI パラメータにすべての値を指定する（例： http://example.com/?val=[a,b,c] ）　

ポーリング例

WebSocket• 通信に HTTP ではなく、別のプロトコル WS を

使う　（ただし、接続の確立には HTTP を使用）

・一回接続を確立すれば、ステートフルに通信可能　 TCP の接続を張り続けておく・一回あたりのデータ転送のオーバーヘッドが小さいデータの前後に 1 バイトずつ付けた「データフレーミング」という形式「数キロバイトのデータ転送量を（最低） 2 バイトへ、 150ms の遅延を 50msにできるとしたら、それはわずかな向上といったような生やさしいものではない。実際この 2 つの事実だけをもっても、 WebSocket を Google にとって本気にさせるには十分なものだ」

WebSocket• 通信に HTTP ではなく、別のプロトコル WS を

使う　（ただし、接続の確立には HTTP を使用）

・一回接続を確立すれば、ステートフルに通信可能　 TCP の接続を張り続けておく・一回あたりのデータ転送のオーバーヘッドが小さいデータの前後に 1 バイトずつ付けた「データフレーミング」という形式「数キロバイトのデータ転送量を（最低） 2 バイトへ、 150ms の遅延を 50msにできるとしたら、それはわずかな向上といったような生やさしいものではない。実際この 2 つの事実だけをもっても、 WebSocket を Google にとって本気にさせるには十分なものだ」

WS のヘッダー・リクエスト GET /demo HTTP/1.1 Host: example.com Connection: Upgrade Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 Sec-WebSocket-Protocol: sample Upgrade: WebSocket Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 Origin: http://example.com ^n:ds[4U

・レスポンス HTTP/1.1 101 WebSocket Protocol Handshake Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Origin: http://example.com Sec-WebSocket-Location: ws://example.com/demo Sec-WebSocket-Protocol: sample 8jKS'y:G*Co,Wxa-

この後は・・・・0x00[Data]0xFF 　という形式でやり取りを行う

対応ブラウザ対応しているブラウザは下記の二つ• Safari 5• Chrome 10

FireFox は？Firefox 4 の Beta 8 以降から WebSocket のサポートを無効化すると決定したのは、プロトコルレベルのセキュリティ問題によるものです。 Beta 7 では Chrome や Safari 同様に -76 バージョンのプロトコルをサポートしています。Beta 8 からはサポートされません。https://dev.mozilla.jp/hacksmozillaorg/websockets-disabled-in-firefox-4/実際は、 Flash や Java applet にもいえる問題です。http://blog.livedoor.jp/kotesaki/archives/1600864.html

実際におこる確率

Cache PoisoningFlash : 0.12%

Java Applet : 0.15%WebSocket : 0.01%

原文http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pdf

WebSocket の中身・ブラウザ側の API　旧 WebSockets API・サーバと通信するための通信プロトコル　旧 WebSocket protocolこの二つが WebSocket の中身

WebSocket は W3C によって規定される API とIETF によって規定されている通信プロトコルによってなりたちます。以前は API の方を「 The Web Sockets API 」（複数形）、プロトコルの方を「 The Web Socket protocol 」 ( 単数形 ) としていましたが、現在では両者とも「 The WebSocket 」に統一されたようです。

WebSocket 　 APIメソッド 説明

WebSocket(url, protocol) コンストラクタ。 ws:// もしくは wss:// で始まるurl をしてする。

onopen サーバーとの接続が確率したとき呼び出されるイベントハンドラ。

onmessage サーバーからデータを受信したときに呼び出されるイベントハンドラ。

send(msg) サーバーにデータを送る。

close() サーバーとの接続を切断する。

WebSocket 　 protocol・クライアントからサーバに TCP 接続して handshake する・ handshake のリクエスト / レスポンスのやりとりは HTTP そのもの・クライアントはリクエストボディで 8 バイトのランダム文字列(challenge) を送る・サーバは 16 バイトの response 文字列を返す・ handshake 後、 TCP 接続は張りっぱなしにする・ handshake 後の TCP 接続上、双方向にデータを送信可能・テキストデータは 0x00 で始まり 0xff で終了するフレーム単位・テキストデータの文字コードは UTF8・バイナリデータも送れる ( タイプと長さを最初に送る )・ URL は ws:// or wss://・紳士的な切断は 0xff 0x00 を送って、 0xff 0x00 を受信してからTCP レベルで切断

WebSocket 　 protocol・クライアントからサーバに TCP 接続して handshake する・ handshake のリクエスト / レスポンスのやりとりは HTTP そのもの・クライアントはリクエストボディで 8 バイトのランダム文字列(challenge) を送る・サーバは 16 バイトの response 文字列を返す・ handshake 後、 TCP 接続は張りっぱなしにする・ handshake 後の TCP 接続上、双方向にデータを送信可能・テキストデータは 0x00 で始まり 0xff で終了するフレーム単位・テキストデータの文字コードは UTF8・バイナリデータも送れる ( タイプと長さを最初に送る )・ URL は ws:// or wss://・紳士的な切断は 0xff 0x00 を送って、 0xff 0x00 を受信してからTCP レベルで切断

ラッパーされていることがほとん

どなので、何やっているかはライブ

ラリの中身をみないと・・・

でも時間がなかったで

す。。。。。。。

くううううう• Mojo をつかった websocketCORE Perl (5.010000, darwin) Mojolicious (1.45, Smiling Face With Sunglasses)で動かず・・・・