第43回HTML5とか勉強会 最新webプロトコル傾向と対策

最新 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