1. 最新Webプロトコル
傾向と対策
HTML5 conference 2013
NTT communications
こまつけんさく

2. 自己紹介
 名前：小松健作
 所属：NTT communications
 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 UDP (for WebRTC reliable data channel )
 QUIC

4. なぜ
こんなに？

5. HTTP/1.1
Browser
Server
request
response

6. HTTP/1.1
Browser
Server
Round Trip Tiime

7. Concurrent HTTP
Browser
Server

9. Concurrent HTTP
Browser
Server
超えられないGAP

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

11. Gapを超えるpractice
 CSS sprite

12. もっと
Genericに!

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

14. DEMO

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

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

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

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

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

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

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

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

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

24. Head of Line Blocking
Browser
Server

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

26. 計測データ

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

28. TCP alternative
 SCTP over UDP
 QUIC

29. TCP alternativeはいつ？
Access
NW
Browser
Load
Balancer
FireWall
Server
CGN
インターネット上のあらゆる機器に影響が出てくる・・・
ルーム５C：17:15〜のキャリアパネルでこの辺の話が聞けるかも

30. 速度って何？
 SPDYの特徴は、スピードだけではない
 絶対的なスピード競争に目を奪われてはいけない
 ユーザーの体感スピードをあげることが重要
 User Experience

31. 体感速度を早くする
 1st view のレンダリングを高速化する
 1st viewに関係ない画像やスクリプトなどは、後でダ
ウンロードすればいい。

32. Resource Priorities

33. 例 Attribute = lazyload
<img class='Backgrounds' id='BackgroundLevel1' src='Background1.png' />
<img class='Backgrounds' id='BackgroundLevel2' src='Background2.png'
lazyload />

34. WebRTC的な話

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

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

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

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

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

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

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

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

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

44. IPv6になったらSTUNは不要？
STUN
FWに穴を開けるために
必要
FW
Browser
FW
Browser

45. 宣伝
SkyWay
WebRTC BaaS
日本で、もっとWebRTCを！
近日 preview release 予定

47. Thank You!!
@komasshu