「第43回 HTML5とか勉強会」参加レポート

参加してきました。告知されていたページはこちら。
http://atnd.org/events/46252

勉強会は大学で教授が教鞭をとるように硬派に教わる印象を持ちました。プロトコルのお話が中心の回で、日本人はプロトコル大好きといった名言も飛び出しました。個人的には楽しかった回で、内容まとめは以下の通りです。知らなかったことばかりなので勉強になりました。

WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策

長らく使われてきた、HTTP/1.1 であるが、速度面での問題が顕在化してきて、高速化するための各種技術が登場。それぞれ動作原理を解説してくださる。

HTTP/1.1

GET メソッドで、index.html や .css など一つ一つ取りに行く。高速化のための工夫として、「Concurrent HTTP」「CSS Sprite」などがある。

○Concurrent HTTP

複数の TCP コネクションを用いることで高速化する。例えば、Google Chrome だとまとめて 6 個。

○CSS Sprite

複数のリソースを一つのセッションにまとめる。Static なページには特に有効だが、Twitter などのような動的なページでは使いにくいテクニック。

SPDY

1 つの TCP セッション上で、1 つではなく複数のリクエストを送受信する。
ただ、SPDY を使ったほうが遅くなる場合もあり、次のような問題がある。

Long Fat Pipe

次の URL によるとデータセグメント送信後にそれに対する ACK が到着するまでの時間を掛け合わせたものを帯域幅遅延積と呼ぶ。この値が大きくなるに従って、TCP コネクションでデータを送受信する際のスループットが低下していく現象が一般的に見られるとのこと。
http://technet.microsoft.com/ja-jp/library/cc985301.aspx

つまり ACK が来るのが遅い環境だとこの問題が発生する。ちなみに Mac でローカル環境で試験する際にレイテンシを作り出すには ipfw というコマンドを使うとできるとのこと。

Head of Line Blocking

1 車線の道路で 1 台車が止まってしまうと後ろがつかえるのと同じで、SPDY だと 1 車線なのでこの問題の影響を受ける。

これらは、TCP プロトコルの問題でもあるが、Web の進化により TCP の制限が効くようになってきた。こういった背景により、QUIC などのような技術の登場につながっている。

WebRTC

従来は、ブラウザ間の通信はサーバを介してであったが、ブラウザ同士で P2P で通信できるようにするもの。
問題点としては、P2P を張るには相手の IP アドレス、ポート番号が必要だが、NAT が障壁となること。そのため STUN により相手のアドレス、ポート番号を得たり、それでもダメな場合は TURN を使用する。こういった問題への対応を少ないコード量で実装するために PeerJS を使うと楽になるらしい。

HTTP/2.0がもたらすWebサービスの進化

MPTCP

スマートフォンを使っている場合、3G、WiFi が切り替わる時に IP アドレスが変わるので、TCP も張り直しが起こる問題がある。この問題に対しては、IP アドレスが切り替わらない MpbileIP、3 way handshake を簡略化する TCP Fast Open などの解がある。
他には、 MPTCP。TCP が動作する環境であれば必ず動作し、TCP のオプションで通信相手とネゴシエーションする。相手が対応してないければ普通の TCP で通信する。iOS 7 の Siri がMPTCP をサポートしているらしい。

HTTP/2.0 に向けて

モバイルフレンドリーなプロトコルが欲しい → SPDY
Google の独自実装だけでなく Interoperability に → HTTP/2.0

SPDY

サーバからプッシュする機能もある。セッションを張ったらサーバからもコネクションを張れる。LINE の既読機能もこういった方法で実現しているのかもしれない。

QUIC

TCP ではなく UDP 上で、セッション確立、フロー制御、エラー訂正、輻輳制御など独自実装。こうすることで、TCP の限界を乗り越えている。