HTML5とか勉強会の番外編〜ブラウザとサーバの間を考えよう〜に行ってきました

イベントリンク: http://html5j.komasshu.info/ya31st.html

司会: わかささんより、濃い話はツイート×サイン(特製うちわ)が出るとのこと

今回、会場の節電の都合で空調が止まっている中、
配布されたノベルティーのgooうちわを使ってみんな暑さをしのぎました。
会場担当のみなさんありがとうございました。

以下、[]内は私の感想です。

(19:15)

WebSockets html5j.org 小松さん

slideshare: http://goo.gl/0kJGW
- @komasshu
- http://blog.livedoor.jp/kotesaki

どうやったらWebページが速くなるかを日々追求
- wakochiのデモ http://wakachi.komasshu.info
- サーバーに「分かち書き」で入っているテキストをどんどん取ってくるデモ
  - WebSockets pipelineを使っている

今日のトピック
- Intro to WebSocket and SPDY
- Dive into WebSocket Protocol

Intro to WebSockets

Webの使い方が変わってきた
最初はHTMLひとつ → イメージ、CSS → ユーザー/ユーザー間コンテンツ
- Single resource → multiple resources → multi + bidrectional
使われているプロトコルはHTTPで同じ: リクエスト/レスポンスのプロトコル
- どんな問題が?
- 複数リソースの場合、往復をくり返すので遅い
- リアルタイム性にはポーリングが必要
現在どんな方法が使われているか?
- 複数のTCP接続を使う
  - サーバー負荷、intermediaryへの負荷
- ロングポーリング(COMET)
  - コーディングが複雑、ヘッダトラフィックがムダ
最新テクノロジー: SPDY, WebSocket
- SPDY: リクエスト多重化(リクエストが来ないうちにレスポンス送りつけちゃう)
- WebSocket: リクエスト/レスポンスを使わない
プロトコルスタック
- SPDY: フレーミングレイヤ、HTTPレイヤが明確に定義されている
- WebSocket: TCPの上に何でも通せるものを作成
比較表: slideshare参照
- ゴールは
  - SPDY: レイテンシを縮少
  - WebSockets: 双方向アプリケーションを作る

Dive Into WebSocket Protocol

デモ1: multi device interaction
- WebIntents + ServiceDiscovery(uPnP) + WebSocket
- ビデオクリップを選択するとWebIntentsで視聴サービスを選択できる
  - 近くの視聴デバイスを見つけて(自動ディスカバリ)表示 → 選択
  - スマホでリモコン(ここでWebSocketsを使っている)
デモ2: 双方向通信の比較
- echocompare.html: マウス座標をエコーするだけのデモ
- WebSocketsでも遅延はあるがなめらかに流れる
JSでの書き方の例: slideshare参照
プロトコル定義 RFC6455
- handshake: in context of HTTP/1.1
- data transfer: frame format
- schema: ws(80), wss(443)
- 多くのブラウザでサポートされてきている
ハンドシェイク
- request

 GET /chat HTTP/1.1
 Host: server.example.com
 Upgrade: websocket          ← websocketを使いますよ
 Connection: Upgrade         ← upgradeしたいです
 Origin: http://example.com
 Sec-WebSocket-...

- response

 HTTP/1.1 101 Switching Protocols ← upgradeしますよ
 Upgrade: websocket               ← websocketですよ
 Connection: Upgrade
 Sec-WebSocket-...

データフレーミング
- バイナリプロトコル
  - ヘッダの中にopcode(データタイプ識別子)が入っている
  - masking-keyが指定される
- マスキング
  - ペイロードデータに対してmasking-keyでXORをかけて送る
  - firewall circumvention & cache poisoning
    - [セキュリティー上の問題ならwssを使えばいいのでは?]
- ping/pong (keep-alive)
  - intermediaryがトラフィックがないと判断して切ることを防ぐ
  - CGN in mobile network
    - CGN: Career Grade NAT
    - キャリアレベルでNATを置き、モバイル端末にはプライベートアドレスを払い出す
reachability
- プレーンなデータを送ると、intermediaryが中身の解釈ができないとき打ち切ってしまうことが
subprotocol
- WS上で動くプロトコルを決めよう → IANA登録
extension
- multiplexing
- per-frame compression
socket.io
- fallbackしてくれるJSライブラリ
スケーラビリティーは?
- ロードバランサ(node-proxy, nginx)でWSを解釈してアプリサーバーに振り分ける

[感想: WebSocketsはintermediaryがどれくらい対応してくれるのかに期待でしょうか。いったんつながってしまえばTCPみたいなものですが、逆に言うとそこでどんな情報を交換するのか、プロトコルをまた考えないといけないですね]

(19:53)

SPDY IIJ 大津さん

@jovi0608, https://github.com/shigeki
slideshare: http://ow.ly/c1NzK
SPDYのベンチマークができるサイトを公開したい
- 作ってみたら安定しない。過激なことをやろうとすると止まってしまう
会場でSPDYのサイトを立ち上げた人 → 2人くらい
- 安いSSL証明書があれば。オレオレでもOK
- Node.js, Jettyなどの実装もある
最近SPDYが話題です
- Firefox13でデフォルト有効になってから知名度上昇(2012/6)
- SPDYはGoogle Inc.の登録商標w
SPDYの歴史
- 2009/11: spdy/1ドラフト公開
- 2010/01: TLS NPN拡張 Internet Draft リリース
- 2011/01: Google サービスの90%がSPDY化完了
- 2012/01: HTTP/2.0の議論開始
- 2011/04 node-spdy, 12 Firefox11, 2012/03 Jetty, twitter, 04 mod_spdy, 05 F5 Big-IP, 06 nginx
SPDYの状況
- 仕様
  - spdy/2: 現在使われている; spdy/3リリース, spdy/4議論開始(DNSプッシュ、証明書プッシュ、proxy設定など)
  - HTTP/2.0議論開始(MSも類似仕様を提出)
- 実装
  - Chrome: spdy/2、spdy/3実験中、Android3.0以降も
  - Firefox: 13から
  - MSIE? Safari? Opera?
- 効果
  - 2倍はなかなか出ない
  - そんなに速くないじゃんと言われるようになってきた
最近のトピック: Chrome Secure Proxy
- ChromeとHTTP Proxy間をSPDYでつなぐ
- その先がSPDYかHTTPかで分けてくれる
- 速いネットにProxyを置くとよい
- SSLのman-in-the-middle的なpeekingもできる [うっそー?]
HTML読込の高速化
- 帯域を増やしてもページ読込時間はサチってくる
- 一方、レイテンシを短くしてやれば読込時間が大きく改善される
- HTTPだとTCP同時接続数の上限が効いてきて、同時にリクエストできない
SPDYの特徴 (Google I/O 2012の資料より)
- 常にTLS上で動作
- ヘッダ圧縮
- バイナリフレーム
- full-duplex
- server push
- TCP接続が1本だけ
- 少ないパケット
- 既存コンテンツを変える必要はない(サーバーだけ変えればいい)
SPDYに向かないこと (Google I/O 2012の資料より)
- 3rd partyドメインのリソースを多用している場合
- 極めて少ないリソースでできている
- パケットロスが多発する環境 → TCPより悪くなる
SPDYフレームの詳細
- データフレーム、コントロールフレーム
- spdy/3からフローコントロール機能追加 WINDOW_UPDATE
ハンドシェイク
- NPNを使ってSPDYを使うか決めるためにTLSを使う
- SPDY専用ポートで合意できればTLSなしでSPDYを使うことも可能
SYN_STREAM
- ヘッダ圧縮の仕組はkey-valueペアをzlib圧縮してるだけなので、HTTPに特化しているわけではない
サーバープッシュ
- SYN_REPLYを送る前に先読みデータを一方向streamをサーバー側からどんどん送っちゃう
- レスポンスが届いたときにはもうデータがキャッシュにある
Navigation Timing APIでSPDY動作を調べるサイトを作った
- window.performance
- 測ってみた → pushはそんなに稼げない
実際にデモ
- localhost上のサーバーとssl, spdy/2, 2 + push, spdy/3, 3+pushなどで比べてみる
- server pushでは画像数が多くなると、push分の転送時間がhttp待ち時間にくり入れられる

[感想: SPDYはNPN拡張でハンドシェークするのが難しいところです。ロードバランサがSPDYネイティブにしゃべれない場合はport forwardingでがんばるのでしょうか]

(20:30)

SSBP Skeed 柳澤さん

SkeedSilverBulletProtocol
- 中二病っぽい名前のプロプライエタリプロトコル [自分で言っちゃった!]
- トランスポート層(L4)をとりかえて速くしよう
誰得?
- ブラウザから使えるわけじゃない
- TCPでいいじゃん
- ↓次のような用途に
WAN越しにファイルを送ると異様に遅い。特に外国に送ると遅い
- 話にならないくらい遅い [確かにそういうことあります]
- ビッグデータをクラウドで → 無理ゲー
  - CPUバカ食いする計算をクラウドで → しかしデータ送受信できないと話が始まらない
  - 2Gを米国AWSに送るには14時間かかる → 14時間かかればできるのではない。できない
話の流れ
- この現象の存在自体の認識
- 正確な理解
- TCPの仕様・実装に課題
- さあ直そう
TCPに仕様・実装はどうなっているか
- 詳細TCP/IP Vol.1, 2: 合計16,590円
  - 頭いい人が考えて、長らく使っているのでカンタンに説明するのは難しい
- TCP: 信頼性があって、行儀の良いバイトストリームサービスを実現
  - 送り手から受け手の間に川の流れのような通信路があるかのような幻想をいだかせる
  - そして輻輳回避
- 実装
  - 選択的あるいは否定的な確認応答が返せない、sliding window protocol
  - スロースタートアルゴリズムと輻輳回避
  - 輻輳とパケットロスとを同一視
  - OSカーネル内で動作する
  - 非常に割り切った設計思想でできている
  - ゆっくり上げてガクンと下げる
何が問題なのか
- ウインドウサイズの問題
  - 広帯域&遠距離で通信する場合の適正なwindow sizeはすごく大きい
    - 100Mbps、RTT 150msだと1.875Mバイト
  - OS間通信ではバッファの大きさなどが原因で適正値の範囲がそう変えられない
- フロー制御の問題
  - パケットロス率はある程度から下げられない
  - 輻輳ではないのにパケットロスが発生するとレートを下げてしまう
- → だから代替・改善が必要だ
SSBPの想定
- 帯域副は広いもの
- 距離は遠いもの
- パケットロスは当然ある
- OSカーネル内で動作するのは必ずしも必要でない
SSBPの実装
- TCP: 到達完全性の保証とフロー制御の実現とがACK機構を介して密接に結びついている
  - ACKが2つの役割を持っている
- SSBP: この2つを完全に分離、それぞれに最適な手法を取る
  - 届かなかったパケットを選択的にまとめて報告
- TCP: 輻輳とパケットロスとを同一視
- SSBP: パケットロスは不可避だからそれ以外の方法で
  - 輻輳によるパケットロスの前には機器遅延の増大が発生するはず。つまり「狙うべき遅延」があるはず
    - 例えば…: 電話かけてから出るまでに時間がかかるようになると不良品が出はじめる
    - 電話をかけたら45秒で出れるくらいの忙しさをキープする!
- ユーザー空間で動作するアプリとすることでバッファを大きく取れる
- その結果… 16時間を30分に
とにかく実用性重視
- FTP, scp, rsyncを使ってやる仕事をとことん早くする
- SSBPを使った製品を開発して販売する!
プロプライエタリなプロトコルを作ることについて
- RFC化しろとかよく言われるが……
- 本来、端点どうし、好きに接続を確立して好きなやり方で語り合えるもの
- (SSBPの価値)個別的解決 ←trade-off→ 汎用的解決(TCPの価値)
まとめ
- TCP: 大きくて複雑でよくできたもの
- でも現在のWAN越しのバルクデータ転送には向いていない
- 特に遅延とパケットロスに弱い
- その部分に特化して解決したよ!
- RFCを書いて標準化とかしても、それがみんなの手に届いて世の中よくなるのかなあ?

[感想: すごく面白くて、どんどんのめり込んで聞いてしまうプレゼンでした! 用途を限って最適化するというのはわかりやすい話でした]

(21:00)

第二部: 座談会

NTTコミュ様ご提供のケータリングとビール、ソフトドリンクなどを楽しみつつ
ところどころツイート禁止の濃い話をたくさん聞けました
総論としてはこんな感じでしょうか
- WebレイヤからWSやSPDYが出てくるのだがと、結局低レイヤの話になってくる
- intermediaryのことを考えないとサービスとしては成立しない
- 両レイヤの技術者の間でのコミュニケーション、乗り入れが重要になってくる
@komasshuさんの「俺はweb屋だ、俺はネットワーク屋だ、と閉じていては辛いっちゅうことですよ」という言葉が印象に残りました

非常に楽しく、また勉強になる時間でした。ありがとうございました。