HTML5カンファレンス2013（http://events.html5j.org/conference/2013/11/）の13:00〜13:45、ルーム6Aの「WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策」のメモです。
NTTコムの小松さんのセッションです。

SPDY周りの話

10年前はたった一つのプロトコル、HTTP。マイナーバージョンは変わったがずっとこれ。

これがHTML5という言葉が出てきて、続々と新しいプロトコルが出てきた。

・WebSocket
・SPDY（→HTTP/2.0）
・WebRTC
・Row Socket API

これらはTCPという通信プロトコルの上にあるプロトコルだが、下位層であるTCPレイヤについてもWebに引きずられて変えた方がいいのではということで「SCTP over UDP」というのもある。

（SCTP＝Stream Control Transmission Protocol。http://ja.wikipedia.org/wiki/Stream_Control_Transmission_Protocol）

新しいWebのプロトコルがなぜこんなに出てきたか。

HTTP/1.1は非常に単純なプロトコルで、リクエストとレスポンスのペア。
例えばhtmlを取って、次にcssが欲しかったらまたリクエストを投げる。
リクエストを投げてレスポンスが返ってきたら次のリクエストを投げる。

このRound Trip Time（RTT）が問題。

Concurrent HTTP。
複数のTCPコネクションを張って、同時にリクエストを投げる。

ChromeのDevToolでネットワークの動きを見ると、データのダウンロードが階段状になっていることが分かる。
これが一番メジャーな使われ方。

Concurrent HTTPで早くはなるが、越えられないギャップがある。
例えばChromeだと、ブラウザから同一のサーバには最大6つまでしか同時にリクエストを送れないので待ち時間が出る。
この数を上げてしまうと、DoSではないがサーバをいじめてしまうことになって問題ではある。

Gapを越えるためにWebの開発者がいろいろとがんばった。
例えば10個の画像をダウンロードしたいなら、10個のダウンロードを1つにする。
具体的にはCSS Sprite。

ツールを使えばある程度できるが、いちいち作らなきゃ行けないのは面倒だし、動的に変化するもの、例えばTwitterのアイコンなどはこのようにまとめるのは難しい。

もっとGenericに。

SPDY。
1つのTCPコネクションの中で複数のHTTPリクエストを投げることができる。

150個の画像のダウンロード速度を比較する。
HTTPSで219msecで、これをSPDYでやると125msecになる。

SPDY使えば何も考えなくてもいい？と単純に考えるのは危険。

先ほどの例では小さいアイコンを150個ダウンロードしたが、リソースのコンテンツサイズを変えるとどうなるか。
大きい画像を150個ダウンロードさせると、HTTPSで1064msec。SPDYでは945msecであまり差が出ない。

さらに、ネットワークをエミュレートしてみる。
Macではipfwコマンドで遅延等をエミュレートできる。
（具体的なコマンドはスライドの19ページ）

例えば200msec遅延がある環境で先ほどの大きい画像のを試す。
HTTPSでは3566msec。SPDYでは14秒。
例えばSPDYをアメリカのサーバにやると遅くなる。

リソースサイズとレイテンシ（遅延）の関係。
理想的な状況だとSPDYの方が早いが、レイテンシを100msぐらいにするとHTTPSの方が早い。

TCPには「Long Fat Pipe」という問題がある。
リクエストをまとめて送った後、ACKが返ってくるまでデータを送信することができない。
だから、レイテンシが大きくなるほどACK待ちの時間が長くなる。

実際に計測してみるとデータ送信量が階段状になるが、これはまとめて送った後にACK待ちになるため。
15KBぐらいの小さいデータだと、ACKを待つ必要がない（のでレイテンシの影響が見えない）。

SPDYとHTTPSの違い。
SPDYは複数リソースのダウンロードを1つのTCPで行えるが、Long Fat Pipeの影響を受ける。
レイテンシの大きい環境ではACKが支配的であり、SPDYよりHTTPSの方が早いことがある。

Head of Line Blocking。
前のデータが送れていないと次のデータが送れない（ので、1つのTCPしか張らないSPDYでは影響が大きい）。
HTTPSでは複数のTCPを張っているので、1つのTCPが再送をかけていても並走する他のTCPでは転送を続けられる。

例えば1GBのデータを送る場合はSPDYのほうが遅い。

このことはSPDYが原因でなく、TCPの制限が原因。
Webの進化によって、TCPの制限に引っかかるようになった。
このんため、SPDYやWebSocketとTCPの間に依存関係が出てくる。

TCP altenative。
TCPをTCP以外に変えた方がよいのではないか、ということで国際標準化の場で出てきている。
具体的には去年のIETFで、SCTP over UDPとか、Googleが提案しているQUICなど。
（QUIC→http://en.wikipedia.org/wiki/QUIC）

TCP altenativeはいつ？
これを変えるとインターネット上のあらゆる機器に影響が出てくるので、簡単にはできない。

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

体感速度を速くするには。

Resource Prioritiesというのができた。
タグの中に「あとで読んでいいよ」というAttributeを仕掛けると後で読み込んでくれる。

WebRTCの話

WebRTCの特徴。
P2Pで、ブラウザ同士がダイレクトにデータ交換することができ、サーバのコストも安くできる。

相手のIPアドレスとポート番号がわかればP2Pを実現できる。
しかし一般的にはBBルータがあって、機器がNATの下にいることが非常に多い。

インターネット上で飛ばさなければならない相手のアドレスとポート番号は、NATの外側のものを知らないと行けないが、機器自身にはわからない。
（なぜなら機器に割り当てられているのはNATで付与された192.168.xx.xxのようなローカルアドレスであって、インターネットで通じるグローバルアドレスではないから）

これをクリアするために、WebRTCではICE、STUNを使っている。
また、STUNはフルコーンNATでは問題ないがシンメトリックNATでは通らないので、シンメトリックNATの場合はTURNを使う。
（STUNとかTURNをよしなにしてくれるのがICE＝Interactive Connectivity Establishment）

同一セグメント内なら基本的にICEはSTUN、TURNは不要。だからWebRTCで企業内ツールなどを作る分にはNAT越えの問題がない。
但し公共無線LANなどは、同一セグメント内でもセキュリティの問題で通らないようになっている。

（通信周りのWeb APIでは）こうしたネットワーク系の知識を知っていないと痛い目に遭う。

IPv6になったらSTUNは不要か、と言えば必要。
IPv6でもファイアウォールは必要で、そしてNATはファイアウォールのようなもの。

（補足：市販されているIPv6対応BBルータは、基本的にデフォルトでは外から中宛の通信を弾く。もし素通しになっていると、IPv6対応のPCや家電を外からつんつんされて危険）

最後に宣伝。
SkyWayというサービスが近日Preview Release予定。WebRTC BaaS。
日本で、もっとWebRTCを。

アメリカはWebRTC系のサービスが多いが、日本は少ない。