第43回html5とか勉強会 最新webプロトコル傾向と対策
Post on 15-Jan-2015
1.876 Views
Preview:
DESCRIPTION
TRANSCRIPT
最新 Web プロトコル 傾向と対策第 43 回 HTML5 とか勉強会
こまつけんさく
自己紹介名前：小松健作
HTML5 の研究開発 HTML5 の啓蒙・コミュニティ運営 html5j スタッフ カンファレンスの NW （ケーブル）頑張ってひきま
した。
Google Developer Expert (HTML5)
Microsoft Most Valuable Professional(IE)
最新 Web プロトコルが続々とWebSocket
SPDY, HTTP2.0
WebRTC
Raw Socket API
SCTP over DTLS (for WebRTC reliable data channel )
QUIC
なぜこんなに？
HTTP/1.1
Browser ServerGET /index.html
index.html
GET /style.css
style.css
画像素材： http://www.emstudio.jp/free/data1030/
HTTP/1.1
Browser ServerGET /index.html
index.html
GET /style.css
style.css
Round Trip Tiime
Concurrent HTTP複数の TCP を同時に用いることで高速化
車の例で言えば、道路の車線を増やすことに相当
Concurrent HTTP
超えられない GAPリソースも多く使う
Browser Server
Gap を超えるために複数リソースを一つのセッションにまとめる。
まとめたリクエストを送る
Browser Server
Gap を超える practiceCSS sprite
もっとGeneric に !
SPDY の考え方複数リソースを一つの TCP にまとめているBrowser Server
DEMO
SPDY 使えば何も考えなくてもいい？
リソースサイズを変えてみる
更に、ネットワークをエミュレート (MacOS)
sudo ipfw add pipe 1 ip from any to anysudo ipfw pipe 1 config delay 50ms
エミュレート環境で測ってみる
リソースサイズ、 latency
HTTPS
SPDY
TCP : Long Fat PipeACK が返ってくるまで、データを送信で
きないBrowser Server
計測データ
about 15KB
ACK time(100ms)
総データ送信量
データ送信量
SPDY と HTTPS の違いSPDY
複数リソースダウンロードをを一つの TCP で Long Fat Pipe の制限が顕著となる
HTTPS Long Fat Pipe は、個々の TCP に対して起こる TCP の数だけ早くなる
何が言えるか？Latency が多い環境
ACK の待ち時間が支配的 リソースサイズが増えるに従い、顕著となる SPDY より、 HTTPS のほうが早いケースも
Head of Line Blocking
Browser Server
HTTPS では、 HoL の影響を受けづらい
Browser Server
計測データ
ケアしたほうがいいことSPDY を使う際は
大容量のファイルが多量に存在する場合 モバイル環境（ロスも latency も大きい）でのテストに注意したほうがいい
ファイルサイズの最小化など、従来からのプラクティス・サイト設計は引き続き重要
※ WebSocket についても同様のことが言えます。（場合によっては、 WebSocket 複数コネクション使ったほうがいいかも！？）
何が原因？SPDY, WebSocket … NO
TCP の制限が原因
Web の進化により TCP の制限にぶつかるようになった
HTTP / HTTPS
TCP
IP
SPDY, WebSocket
HTTP2.0TCP
IP
LayerDependency
TCP alternativeSCTP over DTLS
QUIC
TCP alternative はいつ？
Browser Server
AccessNW
CGN
FireWall
Load Balancer
インターネット上のあらゆる機器に影響が出てくる・・・
WebRTC 的な話
WebRTC の特徴
Browser Browser
Server
WebSocket
Browser Browser
Server
WebRTC
P2P を実現するには？
Browser Browser
相手の IP アドレス、ポート
番号が必要
NAT がある場合
Browser Browser
NAT NAT
実際のアドレス、ポート番号は分か
らない
アドレス、ポート番号を知るために : STUN
Browser Browser
NAT NAT
STUN実際のアドレス、ポート番号をブラ
ウザに返す
フルコーン NAT
Browser Browser
NAT NAT
STUN
STUN に教えてもらった情報を使い
通信
ポート番号だけを見て変換（ UDP Hole Punching)
シンメトリック NAT
Browser Browser
NAT NAT
STUN
STUN に教えてもらった情報を使い
通信
アドレスが違うのでブロック
TURN
Browser Browser
NAT NAT
TURN
サーバーを中継するため、シンメトリック NAT でも
OK
同一セグメント内なら ICE はSTUN, TURN は不要
Browser Browser
BroadbandRouter
LAN
同一セグメントでも・・・
Browser Browser
Wireless Controller セキュリティの観
点からセグメント内
P2P を禁止公衆無線 LAN
TURN が必要
WebRTC もうちょっと詳しく
WebRTCWebapp
WebRTCWebapp
BrokerServer
Stunserver
NAT NAT
セッション情報の交換
NAT の hole punching
データの交換
http://blog.livedoor.jp/kotesaki/archives/1794148.html
サーバーサイドコーディング
WebRTC もうちょっと詳しく
WebRTCWebapp
WebRTCWebapp
BrokerServer
Stunserver
NAT NAT
セッション情報の交換
NAT の hole punching
データの交換
とにかくめんどくさい
ふつーに書くと（ browser side ）
https://github.com/KensakuKOMATSU/rtc_datachannel/blob/master/public/javascripts/script.js
ふつーに書くと（ server side ）
https://github.com/KensakuKOMATSU/rtc_datachannel/blob/master/app.js
毎回こんなコード書いてられない・・・
wrapperPeer.js
http://peerjs.com/
SkyWay (preview release!)
http://nttcom.github.io/skyway/
Peerjs 互換
WebRTC を簡単に使えるBaaS
WebRTCWebapp
WebRTCWebapp
BrokerServer
Stunserver
NAT NAT
セッション情報の交換
NAT の hole punching
データの交換
サーバーサイドコーディング
この部分は、 SkyWay が提供（気にしなくていい）
ブラウザ部分の開発に集中
コードの短縮化
https://gist.github.com/KensakuKOMATSU/5377673
220 line => 50 line
サンプルレベルならサーバーサイドコーディン
グは不要！！
SkyWay (PeerJS) のコーディングパターンWebSocket と若干コーディングパターンが変わる
WebSocketサーバー
サーバーに接続すれば、お互いが自動的につながる
SkyWayサーバー
相手先の Peer ID を指定して、明示的に繋がる（呼ばれる側はサーバー的なコーディングが必要）
（裏側で接続制御）
SkyWay (PeerJS) のコーディングパターン
SkyWayサーバー
caller callee
最初に SkyWayサーバーに接続
SkyWayサーバー
接続先 ID を指定してp2p接続
（裏側でうまいこと橋渡し）
DataChannel の相互接続性問題DataChannel の reliable 通信の実装がブ
ラウザ（バージョン）ごとに異なる当面は sctp をオフにしたほうがベターutil.supports.sctp = false;
より詳しくは・・・
http://nttcom.github.io/skyway/docs/
Preview release につき無料 !!
http://nttcom.github.io/skyway/registration.html
Pull request, Issueお待ちしています !!
https://github.com/nttcom/peerjs
Thank You!!@komasshu
top related