SlideShare uma empresa Scribd logo
1 de 17
WebSocketについて Spring_MT 2011/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.1 Host: today.is.sky.blue.sky User-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.14 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ja,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Cookie: 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 OK Date: Mon, 20 Jun 2011 18:12:40 GMT Content-Type: text/plain; charset=UTF-8 Connection: close Transfer-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 Poisoning Flash : 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 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をつかったwebsocket CORE   Perl        (5.010000, darwin) Mojolicious (1.45, Smiling Face With Sunglasses) で動かず・・・・

Mais conteúdo relacionado

Mais procurados

JavaプログラマのためのWebSocket概要
JavaプログラマのためのWebSocket概要JavaプログラマのためのWebSocket概要
JavaプログラマのためのWebSocket概要Shumpei Shiraishi
 
AWSとmod_pagespeedで 楽々サクサク高速化!!
AWSとmod_pagespeedで楽々サクサク高速化!!AWSとmod_pagespeedで楽々サクサク高速化!!
AWSとmod_pagespeedで 楽々サクサク高速化!!aasakawa
 
サーバPUSHざっくりまとめ
サーバPUSHざっくりまとめサーバPUSHざっくりまとめ
サーバPUSHざっくりまとめYasuhiro Mawarimichi
 
モダンブラウザストレージ
モダンブラウザストレージモダンブラウザストレージ
モダンブラウザストレージKazuyuki Mori
 
第1回Webサーバ勉強会 - 212-223 ブラウザマッチ処理
第1回Webサーバ勉強会 - 212-223 ブラウザマッチ処理第1回Webサーバ勉強会 - 212-223 ブラウザマッチ処理
第1回Webサーバ勉強会 - 212-223 ブラウザマッチ処理Seiichiro Ishida
 
再入門、サーバープッシュ技術
再入門、サーバープッシュ技術再入門、サーバープッシュ技術
再入門、サーバープッシュ技術Shin Sekaryo
 
これから利用拡大?WebSocket
これから利用拡大?WebSocketこれから利用拡大?WebSocket
これから利用拡大?WebSocketAdvancedTechNight
 
第1回鹿児島node.jsの会資料_内村
第1回鹿児島node.jsの会資料_内村第1回鹿児島node.jsの会資料_内村
第1回鹿児島node.jsの会資料_内村Koichi Uchimura
 
Mongo db勉強会
Mongo db勉強会Mongo db勉強会
Mongo db勉強会otmb
 
非エンジニアでもわかる
非エンジニアでもわかる非エンジニアでもわかる
非エンジニアでもわかるssuser33820e
 
私たちは何を Web っぽいと感じているのか
私たちは何を Web っぽいと感じているのか 私たちは何を Web っぽいと感じているのか
私たちは何を Web っぽいと感じているのか Kenta Yamamoto
 
BestGems.org -RubyGemsランキングサイトのご紹介-
BestGems.org -RubyGemsランキングサイトのご紹介-BestGems.org -RubyGemsランキングサイトのご紹介-
BestGems.org -RubyGemsランキングサイトのご紹介-Misao X
 
Frontend optimization dena_creativeseminar
Frontend optimization dena_creativeseminarFrontend optimization dena_creativeseminar
Frontend optimization dena_creativeseminarDeNA_open_events
 

Mais procurados (17)

JavaプログラマのためのWebSocket概要
JavaプログラマのためのWebSocket概要JavaプログラマのためのWebSocket概要
JavaプログラマのためのWebSocket概要
 
AWSとmod_pagespeedで 楽々サクサク高速化!!
AWSとmod_pagespeedで楽々サクサク高速化!!AWSとmod_pagespeedで楽々サクサク高速化!!
AWSとmod_pagespeedで 楽々サクサク高速化!!
 
サーバPUSHざっくりまとめ
サーバPUSHざっくりまとめサーバPUSHざっくりまとめ
サーバPUSHざっくりまとめ
 
モダンブラウザストレージ
モダンブラウザストレージモダンブラウザストレージ
モダンブラウザストレージ
 
第1回Webサーバ勉強会 - 212-223 ブラウザマッチ処理
第1回Webサーバ勉強会 - 212-223 ブラウザマッチ処理第1回Webサーバ勉強会 - 212-223 ブラウザマッチ処理
第1回Webサーバ勉強会 - 212-223 ブラウザマッチ処理
 
cache.iijgio.com の中
cache.iijgio.com の中cache.iijgio.com の中
cache.iijgio.com の中
 
再入門、サーバープッシュ技術
再入門、サーバープッシュ技術再入門、サーバープッシュ技術
再入門、サーバープッシュ技術
 
Nodejs
NodejsNodejs
Nodejs
 
Varnish
VarnishVarnish
Varnish
 
これから利用拡大?WebSocket
これから利用拡大?WebSocketこれから利用拡大?WebSocket
これから利用拡大?WebSocket
 
Groovyでjson
GroovyでjsonGroovyでjson
Groovyでjson
 
第1回鹿児島node.jsの会資料_内村
第1回鹿児島node.jsの会資料_内村第1回鹿児島node.jsの会資料_内村
第1回鹿児島node.jsの会資料_内村
 
Mongo db勉強会
Mongo db勉強会Mongo db勉強会
Mongo db勉強会
 
非エンジニアでもわかる
非エンジニアでもわかる非エンジニアでもわかる
非エンジニアでもわかる
 
私たちは何を Web っぽいと感じているのか
私たちは何を Web っぽいと感じているのか 私たちは何を Web っぽいと感じているのか
私たちは何を Web っぽいと感じているのか
 
BestGems.org -RubyGemsランキングサイトのご紹介-
BestGems.org -RubyGemsランキングサイトのご紹介-BestGems.org -RubyGemsランキングサイトのご紹介-
BestGems.org -RubyGemsランキングサイトのご紹介-
 
Frontend optimization dena_creativeseminar
Frontend optimization dena_creativeseminarFrontend optimization dena_creativeseminar
Frontend optimization dena_creativeseminar
 

Semelhante a 20110622 haruyama webso]cket

Chromebook 「だけ」で WebRTCを動かそう
Chromebook 「だけ」で WebRTCを動かそうChromebook 「だけ」で WebRTCを動かそう
Chromebook 「だけ」で WebRTCを動かそうmganeko
 
CometPub20070223
CometPub20070223CometPub20070223
CometPub20070223Hiroshi Ono
 
第43回HTML5とか勉強会 最新webプロトコル傾向と対策
第43回HTML5とか勉強会 最新webプロトコル傾向と対策第43回HTML5とか勉強会 最新webプロトコル傾向と対策
第43回HTML5とか勉強会 最新webプロトコル傾向と対策Kensaku Komatsu
 
CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~
CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~ CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~
CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~ SEGADevTech
 
【17-A-5】ウェブアーキテクチャの歴史と未来
【17-A-5】ウェブアーキテクチャの歴史と未来【17-A-5】ウェブアーキテクチャの歴史と未来
【17-A-5】ウェブアーキテクチャの歴史と未来Developers Summit
 
最新Webプロトコル傾向と対策
最新Webプロトコル傾向と対策最新Webプロトコル傾向と対策
最新Webプロトコル傾向と対策Kensaku Komatsu
 
SPDY/3 の HTTP 重畳効果を測定する
SPDY/3 の HTTP 重畳効果を測定するSPDY/3 の HTTP 重畳効果を測定する
SPDY/3 の HTTP 重畳効果を測定する彰 村地
 
Webページが表示されるまで
Webページが表示されるまでWebページが表示されるまで
Webページが表示されるまでMasataka Suzuki
 
いよいよ始められる Java EEでのWebSocket #jjug #jjug_ccc #ccc_r21
いよいよ始められる Java EEでのWebSocket #jjug #jjug_ccc #ccc_r21いよいよ始められる Java EEでのWebSocket #jjug #jjug_ccc #ccc_r21
いよいよ始められる Java EEでのWebSocket #jjug #jjug_ccc #ccc_r21Takakiyo Tanaka
 
HTTP入門
HTTP入門HTTP入門
HTTP入門Sho A
 
Lesson01
Lesson01Lesson01
Lesson01MRI
 
Speed Up Web 2012
Speed Up Web 2012Speed Up Web 2012
Speed Up Web 2012彰 村地
 
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説You_Kinjoh
 
Webrtc最新動向
Webrtc最新動向Webrtc最新動向
Webrtc最新動向Yusuke Naka
 
Logs are better with elastic apm 20210623
Logs are better with elastic apm 20210623Logs are better with elastic apm 20210623
Logs are better with elastic apm 20210623Shotaro Suzuki
 
ウェブアーキテクチャの歴史と未来
ウェブアーキテクチャの歴史と未来ウェブアーキテクチャの歴史と未来
ウェブアーキテクチャの歴史と未来Kazuho Oku
 

Semelhante a 20110622 haruyama webso]cket (20)

20120525 mt websocket
20120525 mt websocket20120525 mt websocket
20120525 mt websocket
 
Chromebook 「だけ」で WebRTCを動かそう
Chromebook 「だけ」で WebRTCを動かそうChromebook 「だけ」で WebRTCを動かそう
Chromebook 「だけ」で WebRTCを動かそう
 
CometPub20070223
CometPub20070223CometPub20070223
CometPub20070223
 
第43回HTML5とか勉強会 最新webプロトコル傾向と対策
第43回HTML5とか勉強会 最新webプロトコル傾向と対策第43回HTML5とか勉強会 最新webプロトコル傾向と対策
第43回HTML5とか勉強会 最新webプロトコル傾向と対策
 
CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~
CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~ CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~
CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~
 
【17-A-5】ウェブアーキテクチャの歴史と未来
【17-A-5】ウェブアーキテクチャの歴史と未来【17-A-5】ウェブアーキテクチャの歴史と未来
【17-A-5】ウェブアーキテクチャの歴史と未来
 
最新Webプロトコル傾向と対策
最新Webプロトコル傾向と対策最新Webプロトコル傾向と対策
最新Webプロトコル傾向と対策
 
SPDY/3 の HTTP 重畳効果を測定する
SPDY/3 の HTTP 重畳効果を測定するSPDY/3 の HTTP 重畳効果を測定する
SPDY/3 の HTTP 重畳効果を測定する
 
Webページが表示されるまで
Webページが表示されるまでWebページが表示されるまで
Webページが表示されるまで
 
いよいよ始められる Java EEでのWebSocket #jjug #jjug_ccc #ccc_r21
いよいよ始められる Java EEでのWebSocket #jjug #jjug_ccc #ccc_r21いよいよ始められる Java EEでのWebSocket #jjug #jjug_ccc #ccc_r21
いよいよ始められる Java EEでのWebSocket #jjug #jjug_ccc #ccc_r21
 
HTTP入門
HTTP入門HTTP入門
HTTP入門
 
Lesson01
Lesson01Lesson01
Lesson01
 
Speed Up Web 2012
Speed Up Web 2012Speed Up Web 2012
Speed Up Web 2012
 
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説
 
Web基礎
Web基礎Web基礎
Web基礎
 
Webrtc最新動向
Webrtc最新動向Webrtc最新動向
Webrtc最新動向
 
Ajn24
Ajn24Ajn24
Ajn24
 
BP Study #16
BP Study #16BP Study #16
BP Study #16
 
Logs are better with elastic apm 20210623
Logs are better with elastic apm 20210623Logs are better with elastic apm 20210623
Logs are better with elastic apm 20210623
 
ウェブアーキテクチャの歴史と未来
ウェブアーキテクチャの歴史と未来ウェブアーキテクチャの歴史と未来
ウェブアーキテクチャの歴史と未来
 

Mais de Makoto Haruyama

Rails on GKEで運用するWebアプリケーションの紹介
Rails on GKEで運用するWebアプリケーションの紹介Rails on GKEで運用するWebアプリケーションの紹介
Rails on GKEで運用するWebアプリケーションの紹介Makoto Haruyama
 
マイクロサービスっぽい感じの話
マイクロサービスっぽい感じの話マイクロサービスっぽい感じの話
マイクロサービスっぽい感じの話Makoto Haruyama
 
DeNAオリジナル ゲーム専用プラットフォーム Sakashoについて
DeNAオリジナル ゲーム専用プラットフォーム SakashoについてDeNAオリジナル ゲーム専用プラットフォーム Sakashoについて
DeNAオリジナル ゲーム専用プラットフォーム SakashoについてMakoto Haruyama
 
DeNAのゲーム開発を支える Game Backend as a Service
DeNAのゲーム開発を支える Game Backend as a ServiceDeNAのゲーム開発を支える Game Backend as a Service
DeNAのゲーム開発を支える Game Backend as a ServiceMakoto Haruyama
 
backbone.jsの使用例 その1
backbone.jsの使用例 その1backbone.jsの使用例 その1
backbone.jsの使用例 その1Makoto Haruyama
 
fluent-plugin-resque_stat
fluent-plugin-resque_statfluent-plugin-resque_stat
fluent-plugin-resque_statMakoto Haruyama
 
初心者エンジニアのシステム構築失敗談
初心者エンジニアのシステム構築失敗談初心者エンジニアのシステム構築失敗談
初心者エンジニアのシステム構築失敗談Makoto Haruyama
 
初心者エンジニアの システム構築 失敗談
初心者エンジニアの システム構築 失敗談初心者エンジニアの システム構築 失敗談
初心者エンジニアの システム構築 失敗談Makoto Haruyama
 
Mysql casual fukuoa_vlo_2
Mysql casual fukuoa_vlo_2Mysql casual fukuoa_vlo_2
Mysql casual fukuoa_vlo_2Makoto Haruyama
 
分散ファイルストレージ
分散ファイルストレージ分散ファイルストレージ
分散ファイルストレージMakoto Haruyama
 
Automation tech casual_talks_1_20120717
Automation tech casual_talks_1_20120717Automation tech casual_talks_1_20120717
Automation tech casual_talks_1_20120717Makoto Haruyama
 
My sql casual_in_fukuoka_vol1
My sql casual_in_fukuoka_vol1My sql casual_in_fukuoka_vol1
My sql casual_in_fukuoka_vol1Makoto Haruyama
 

Mais de Makoto Haruyama (14)

Rails on GKEで運用するWebアプリケーションの紹介
Rails on GKEで運用するWebアプリケーションの紹介Rails on GKEで運用するWebアプリケーションの紹介
Rails on GKEで運用するWebアプリケーションの紹介
 
マイクロサービスっぽい感じの話
マイクロサービスっぽい感じの話マイクロサービスっぽい感じの話
マイクロサービスっぽい感じの話
 
DeNAオリジナル ゲーム専用プラットフォーム Sakashoについて
DeNAオリジナル ゲーム専用プラットフォーム SakashoについてDeNAオリジナル ゲーム専用プラットフォーム Sakashoについて
DeNAオリジナル ゲーム専用プラットフォーム Sakashoについて
 
DeNAのゲーム開発を支える Game Backend as a Service
DeNAのゲーム開発を支える Game Backend as a ServiceDeNAのゲーム開発を支える Game Backend as a Service
DeNAのゲーム開発を支える Game Backend as a Service
 
backbone.jsの使用例 その1
backbone.jsの使用例 その1backbone.jsの使用例 その1
backbone.jsの使用例 その1
 
Fluentd in Co-Work
Fluentd in Co-WorkFluentd in Co-Work
Fluentd in Co-Work
 
fluent-plugin-resque_stat
fluent-plugin-resque_statfluent-plugin-resque_stat
fluent-plugin-resque_stat
 
初心者エンジニアのシステム構築失敗談
初心者エンジニアのシステム構築失敗談初心者エンジニアのシステム構築失敗談
初心者エンジニアのシステム構築失敗談
 
初心者エンジニアの システム構築 失敗談
初心者エンジニアの システム構築 失敗談初心者エンジニアの システム構築 失敗談
初心者エンジニアの システム構築 失敗談
 
Mysql casual fukuoa_vlo_2
Mysql casual fukuoa_vlo_2Mysql casual fukuoa_vlo_2
Mysql casual fukuoa_vlo_2
 
Yapc2012 ltthon
Yapc2012 ltthonYapc2012 ltthon
Yapc2012 ltthon
 
分散ファイルストレージ
分散ファイルストレージ分散ファイルストレージ
分散ファイルストレージ
 
Automation tech casual_talks_1_20120717
Automation tech casual_talks_1_20120717Automation tech casual_talks_1_20120717
Automation tech casual_talks_1_20120717
 
My sql casual_in_fukuoka_vol1
My sql casual_in_fukuoka_vol1My sql casual_in_fukuoka_vol1
My sql casual_in_fukuoka_vol1
 

20110622 haruyama webso]cket

  • 2. WebSocketとは? ・公式draft http://dev.w3.org/html5/websockets/ ・何ができるの? 一言でいうと・・・・ Client側とServer側のリアルタイム通信が よりシンプルにかつ、 付加が少なく実現できる Client(ブラウザ)、Server(web server) 今までの技術でも実現可能 ex). Comet                     何が問題なの?
  • 3. 従来の方法 一体何が問題なの? ・従来の手法だと、HTTP通信に頼るしかない  ->同時接続数が多いと   メモリなどのリソースを大量に消費する。   1リクエスト/レスポンスヘッダー自体は数KB ・HTTPだとステートレスな通信しかできない  ->セッション管理等が面倒 ex.)クッキーに情報を保存する リクエストのURIパラメータにすべての値を指定する(例:http://example.com/?val=[a,b,c]) 
  • 4. HTTPのヘッダー ・リクエストヘッダー GET / HTTP/1.1 Host: today.is.sky.blue.sky User-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.14 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ja,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Cookie: 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 OK Date: Mon, 20 Jun 2011 18:12:40 GMT Content-Type: text/plain; charset=UTF-8 Connection: close Transfer-Encoding: chunked
  • 5. 従来の方法 一体何が問題なの? ・従来の手法だと、HTTP通信に頼るしかない  ->同時接続数が多いと   メモリなどのリソースを大量に消費する。   1リクエスト/レスポンスヘッダー自体は数KB ・HTTPだとステートレスな通信しかできない  ->セッション管理等が面倒 ex.)クッキーに情報を保存する リクエストのURIパラメータにすべての値を指定する(例:http://example.com/?val=[a,b,c]) 
  • 7. WebSocket 通信にHTTPではなく、別のプロトコルWSを使う  (ただし、接続の確立にはHTTPを使用) ・一回接続を確立すれば、ステートフルに通信可能  TCPの接続を張り続けておく ・一回あたりのデータ転送のオーバーヘッドが小さい データの前後に1バイトずつ付けた「データフレーミング」という形式 「数キロバイトのデータ転送量を(最低)2バイトへ、150msの遅延を50msにできるとしたら、それはわずかな向上といったような生やさしいものではない。実際この2つの事実だけをもっても、WebSocketをGoogleにとって本気にさせるには十分なものだ」
  • 8.
  • 9. WebSocket 通信にHTTPではなく、別のプロトコルWSを使う  (ただし、接続の確立にはHTTPを使用) ・一回接続を確立すれば、ステートフルに通信可能  TCPの接続を張り続けておく ・一回あたりのデータ転送のオーバーヘッドが小さい データの前後に1バイトずつ付けた「データフレーミング」という形式 「数キロバイトのデータ転送量を(最低)2バイトへ、150msの遅延を50msにできるとしたら、それはわずかな向上といったような生やさしいものではない。実際この2つの事実だけをもっても、WebSocketをGoogleにとって本気にさせるには十分なものだ」
  • 10. 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 という形式でやり取りを行う
  • 11. 対応ブラウザ 対応しているブラウザは下記の二つ 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
  • 12. 実際におこる確率 Cache Poisoning Flash : 0.12% Java Applet : 0.15% WebSocket: 0.01% 原文 http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pdf
  • 13. WebSocketの中身 ・ブラウザ側のAPI  旧WebSockets API ・サーバと通信するための通信プロトコル  旧WebSocket protocol この二つがWebSocketの中身 WebSocketはW3Cによって規定されるAPIと IETFによって規定されている通信プロトコルによってなりたちます。 以前はAPIの方を「The Web Sockets API」(複数形)、 プロトコルの方を「The Web Socket protocol」(単数形)としていましたが、 現在では両者とも「The WebSocket」に統一されたようです。
  • 15. 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レベルで切断
  • 16. 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レベルで切断 ラッパーされていることがほとんどなので、何やっているかはライブラリの中身をみないと・・・ でも時間がなかったです。。。。。。。
  • 17. くううううう Mojoをつかったwebsocket CORE Perl (5.010000, darwin) Mojolicious (1.45, Smiling Face With Sunglasses) で動かず・・・・