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

1. 最新Webプロトコル傾向と対策第43回 HTML5とか勉強会こまつけんさく

2. 自己紹介  名前：小松健作     HTML5の研究開発 HTML5の啓蒙・コミュニティ運営 html5jスタッフカンファレンスのNW（ケーブル）頑張ってひきました。  Google Developer Expert (HTML5)  Microsoft Most Valuable Professional(IE)

3. 最新Webプロトコルが続々と  WebSocket  SPDY, HTTP2.0  WebRTC  Raw Socket API  SCTP over DTLS (for WebRTC reliable data channel )  QUIC

4. なぜこんなに？

5. HTTP/1.1 Browser GET /index.html Server index.ht ml GET /style.css style.css 画像素材：http://www.emstudio.jp/free/data1030/

6. HTTP/1.1 Browser GET /index.html Server index.ht ml GET /style.css style.css Round Trip Tiime

7. Concurrent HTTP  複数のTCPを同時に用いることで高速化  車の例で言えば、道路の車線を増やすことに相当

8. Concurrent HTTP Browser Server 超えられないGAP リソースも多く使う

9. Gap を超えるために  複数リソースを一つのセッションにまとめる。 Browser Server まとめたリクエストを送る

10. Gapを超えるpractice  CSS sprite

11. もっと Genericに!

12. SPDYの考え方  複数リソースを一つのTCPにまとめている Browser Server

13. DEMO

14. SPDY使えば何も考えなくてもいい？

15. リソースサイズを変えてみる

16. 更に、ネットワークをエミュレート(MacOS) sudo ipfw add pipe 1 ip from any to any sudo ipfw pipe 1 config delay 50ms

17. エミュレート環境で測ってみる

18. リソースサイズ、latency SPDY HTTPS

19. TCP : Long Fat Pipe Browser ACKが返ってくるまで、データを送信で Server きない

20. 計測データ総データ送信量 ACK time (100ms) データ送信量 about 15KB

21. SPDYとHTTPSの違い  SPDY  複数リソースダウンロードをを一つのTCPで  Long Fat Pipeの制限が顕著となる  HTTPS  Long Fat Pipeは、個々のTCPに対して起こる  TCPの数だけ早くなる

22. 何が言えるか？  Latencyが多い環境  ACKの待ち時間が支配的  リソースサイズが増えるに従い、顕著となる  SPDYより、HTTPSのほうが早いケースも

23. Head of Line Blocking Browser Server

24. HTTPSでは、HoLの影響を受けづらい Browser Server

25. 計測データ

26. ケアしたほうがいいこと  SPDYを使う際は  大容量のファイルが多量に存在する場合  モバイル環境（ロスもlatencyも大きい）でのテストに注意したほうがいいファイルサイズの最小化など、従来からのプラクティス・サイト設計は引き続き重要 ※ WebSocketについても同様のことが言えます。（場合によっては、 WebSocket 複数コネクション使ったほうがいいかも！？）

27. 何が原因？  SPDY, WebSocket … NO  TCPの制限が原因  Webの進化によりTCPの制限にぶつかるようになった HTTP / HTTPS SPDY, WebSocket HTTP2.0 TCP TCP IP IP Layer Dependency

28. TCP alternative  SCTP over DTLS  QUIC

29. TCP alternativeはいつ？ Access NW Browser Load Balancer FireWall Server CGN インターネット上のあらゆる機器に影響が出てくる・・・

30. WebRTC的な話

31. WebRTCの特徴 WebRTC WebSocket Server Server Browser Browser Browser Browser

32. P2Pを実現するには？相手のIPアドレス、ポート番号が必要 Browser Browser

33. NATがある場合実際のアドレス、ポート番号は分からない NAT Browser NAT Browser

34. アドレス、ポート番号を知るために : STUN STUN NAT Browser 実際のアドレス、ポート番号をブラウザに返す NAT Browser

35. フルコーンNAT STUN ポート番号だけを見て変換（UDP Hole Punching) NAT Browser NAT STUNに教えてもらった情報を使い通信 Browser

36. シンメトリックNAT STUN アドレスが違うのでブロック NAT Browser NAT STUNに教えてもらった情報を使い通信 Browser

37. TURN TURN NAT Browser サーバーを中継するため、シンメトリックNATでもOK NAT Browser

38. 同一セグメント内ならICEは STUN, TURNは不要 Broadband Router LAN Browser Browser

39. 同一セグメントでも・・・ Wireless Controller 公衆無線LAN セキュリティの観点からセグメント内 P2Pを禁止 TURNが必要 Browser Browser

40. WebRTCもうちょっと詳しくサーバーサイドコーディングセッション情報の交換 Broker Server Stun server NATのhole punching NAT WebRTC Web app NAT WebRTC Web app データの交換 http://blog.livedoor.jp/kotesaki/archives/1794148.html

41. WebRTCもうちょっと詳しくセッション情報の交換 Broker Server Stun server とにかくめんどくさい NATのhole punching NAT WebRTC Web app NAT WebRTC Web app データの交換

42. ふつーに書くと（browser side） https://github.com/KensakuKOMATSU/rtc_datachannel/blob/master/ public/javascripts/script.js

43. ふつーに書くと（server side） https://github.com/KensakuKOMATSU/rtc_datachannel/blob/mast er/app.js

44. 毎回こんなコード書いてられない・・・

45. wrapper  Peer.js http://peerjs.com/

46. SkyWay (preview release!) Peerjs互換 http://nttcom.github.io/skyway/

47. WebRTCを簡単に使えるBaaS サーバーサイド Broker コーディング Server セッション情報の交換 Stun server NAT WebRTC Web app NATのhole punching NAT WebRTC Web app この部分は、 SkyWayが提供（気にしなくていい）ブラウザ部分の開発に集中データの交換

48. コードの短縮化 220 line => 50 line サンプルレベルならサーバーサイドコーディングは不要！！ https://gist.github.com/KensakuKOMATSU/5377673

49. SkyWay (PeerJS) のコーディングパターン  WebSocketと若干コーディングパターンが変わる WebSocket サーバー SkyWay サーバー（裏側で接続制御）サーバーに接続すれば、お互いが自動的につながる相手先のPeer IDを指定して、明示的に繋がる（呼ばれる側はサーバー的なコーディングが必要）

50. SkyWay (PeerJS)のコーディングパターン SkyWay サーバー最初にSkyWay サーバーに接続 SkyWay サーバー接続先IDを指定して p2p接続 caller （裏側でうまいこと橋渡し） callee

51. DataChannelの相互接続性問題 DataChannelのreliable通信の実装がブラウザ（バージョン）ごとに異なる  当面はsctpをオフにしたほうがベター  util.supports.sctp = false;

52. より詳しくは・・・ http://nttcom.github.io/skyway/docs/

53. Preview releaseにつき無料!! http://nttcom.github.io/skyway/registration.html

54. Pull request, Issueお待ちしています!! https://github.com/nttcom/peerjs

55. Thank You!! @komasshu

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

Esté a ler uma amostra.

Confira estes a seguir

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

Mais Conteúdo rRelacionado

Semelhante a 第43回HTML5とか勉強会最新webプロトコル傾向と対策 (20)

Mais de Kensaku Komatsu (20)

Mais recentes (20)