Successfully reported this slideshow.

SPDYの話

37,170 views

Published on

Published in: Technology
  • Be the first to comment

SPDYの話

  1. 1. SPDY の話 IIJ 大津繁樹 (@jovi0608) 2012年7月5日 HTML5とか勉強会番外編- ブラウザとサーバの間を考えよう-
  2. 2. 自己紹介• 大津 繁樹(@jovi0608, https://github.com/shigeki)• 所属: インターネットイニシアティブ(IIJ) アプリケーション開発部 戦略的開発室• HTML5/Node.js/Kinect 等流行もの担当• 最近は Node.js コアの開発やってます。
  3. 3. 最近 SPDY が話題です。 SPDYはGoogle, Incの登録商標です。
  4. 4. SPDYを巡る動き2009/11 spdy/1ドラフト公開、 spdy-dev開始2010/01 TLS NPN拡張 I-Dリリース2011/01 Google サービスの90%がSPDY化完了2011/04 node-spdyリリース2011/12 FireFox11 開発版に SPDY実装2012/01 HTTP/2.0の議論開始(現在3案提示中)2012/03 Jetty SPDYサポート, twitter SPDY化開始2012/04 Apache 向け mod_spdy正式リリース2012/05 339 SSL証明書がSPDY化(netcraft調査)2012/05 F5 Big-IPで SPDYサポート2012/06 nginxで SPDYサポート
  5. 5. SPDYの状況• 仕様 – spdy/3リリース, spdy/4議論開始(DNS・証明書プッシュ、 Proxy設定) – HTTP/2.0議論開始 (MSも類似仕様を提出)• 実装 – Chrome: spdy/2実装済(Ver4から) spdy/3試験中 – Android3.0以降の標準ブラウザでもサポート – FireFox: 13から default有効(spdy/2) – MS IE/Apple Safari ? Opera から仕様フィードバックが来 た• 効果測定 – Google のベンチ(2009/11 ラボ環境25サイト約2倍) – Google のベンチ (Chrome for Androidで1.3倍) – Jetty のベンチ 245msec 早くなった。 – Akamai のベンチ 4.5%早いだけ
  6. 6. 最近のトピック(Chrome Secure Proxy)Chromeを「Amazon Silk もどき」に、 ChromeとProxyサーバ間をSPDYでつなぐ 実際にデモ引用元 SPDY & Secure Proxy Support in Google Chrome by Ilya Grigorikhttp://www.igvita.com/2012/06/25/spdy-and-secure-proxy-support-in-google-chrome/
  7. 7. HTTP高速化の試みHTMLのページの読み込み時間の短縮には帯域増大よりRTT短縮の方が効果が大きい引用元: More Bandwidth Doesn’t Matter (much) by Mike Belshehttp://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2
  8. 8. SPDY vs HTTP
  9. 9. SPDYの特徴 (Google I/O 2012セッション資料より引用) • 常にTLSの上で動作 • ヘッダ圧縮をする • バイナリーのフレーム • フルデュプレックス、優先ストリームが ある • サーバプッシュが可能 • TCP接続が1つだけ • 少ないパケットですむ • 既存コンテンツを変える必要はない引用元 Google I/O 2012 SPDY Its Here!: http://r2---bru02t11.c.bigcache.googleapis.com/io2012/presentations/live%20to%20website/1201.pdf
  10. 10. SPDYに向かないこと (Google I/O 2012セッション資料より引用) • 3rd partyドメインのリソースを多用してい るサイト – それぞれのサイトへの接続オーバヘッドが発 生 • 極めて少ないリソースで作られているサ イト – コネクション再利用の機会がなく効果が薄い。 • パケットロスが多発しているリンク – RTTが大きくて、パケットロスが多発している引用元 Google I/O 2012 SPDY Its Here!: http://r2--- ところでは HTTPよりも性能が悪くなる。bru02t11.c.bigcache.googleapis.com/io2012/presentations/live%20to%20website/1201.pdf
  11. 11. SPDY フレームの種類と役割 Data Frames Control Frames 1. SYN_STREAM 2. SYN_REPLY 3. RST_STREAM 4. SETTINGS 5. NOOP( spdy/3で廃止)HTTPリクエスト・レ 6. PING 7. GOAWAYスポンスボディの送 8. HEADERS受信などで使う 9. WINDOW_UPDATE 10. CREDENTIAL HTTPリクエスト・レスポンスヘッダ の送受信に使う その他SPDY通信制御情報のやり取り に使う
  12. 12. 単純なSPDYのストリームフロー SSLハンドシェイク NPN (Next Protocol Negotiation) を 使って SPDY 利用バージョンを交換 SYN_STREAM HTTPリクエストヘッダ情報を送信 SYN_REPLY HTTPレスポンスヘッダ情報を送信クライアント DATA Frame サーバー HTTPレスポンスボディを送信 GOAWAY SPDYストリーム利用停止を通知 SSLのTCPセッションは1つ
  13. 13. SYN_STREAM (spdy/3)0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 11 version 1 type Flags Length ServerPush時 サーバ:偶数 クライアント: のクライアンX Stream-ID ト 奇数X Associated-To-Stream-ID のストリームID Pri Unused Slot Number of Name/Value pairs (32bit) Number of Name/Value pairs 優先度 Length of name (32bit) 0-7 Name (string) Length of value (32bit) Value (string) Flags ServerPush時 0x01 FLAG_FIN 圧縮データ はUNIDIRECTION 0x02 FLAG_UNIDIRECTIONAL
  14. 14. SYN_REPLY (spdy/3)0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 11 version 2 Flags LengthX Stream-ID Number of Name/Value pairs Length of name Name Length of value Value Flags 0x01 FLAG_FIN 圧縮データ
  15. 15. Data frames (spdy/3)0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 Stream-ID Flags Length Data Flags 0x01 FLAG_FIN 0x02 FLAG_COMPRESS
  16. 16. Server Push とは、 HTTPリクエスト この間にサーバ SYN_STREAM が先読みレスポUNIDIRECTIONAL で ンスとデータをassosicate-stream SYN_STREAM 送りまくる が必須 キャッ DATA Frame シュ SYN_STREAMクライアント キャッ サーバー DATA Frame シュ SYN_REPLY HTTPレスポンス DATA Frame
  17. 17. Server Push とは、(コードで見ると)var server = spdy.createServer(options, function(req, res) { if (//push//.test(req.url)) { var header = {content-type : image/png, content-length: image_stat.size}; for(var i = 0; i < maximg; i++) { var imageurl = /images/hoge- + i + .png; res.push(imageurl, header, function(err,stream) { if(err) return; stream.end(image); }); リクエストイベントの後、レスポンス送信の前にストリーム をクライアントに送る必要がある。 } var content = getContent(); res.writeHead(200, {Content-Type: text/html, Content-Length:Buffer.byteLength(content)}); res.end(content); }});
  18. 18. SPDYの性能を測る
  19. 19. Navigation Timing APIで見るSPDY DOMComplete DOMContentLoaded /onLoad loadEventEnd DOMLoadingDNS TCP HTTP DOM DOM onLoad解決 接続 Request/ 処理時間#1 処理時間#2 (通常の 処理 Response (同期) (非同期・並列) JS処理) DNS解決: SPDY/SSL ともに同じだろう TCP: SSL のハンドシェイクは同じだが、再利用前提のSPDYは効果が高 い。 HTTPリクエスト・レスポンス: ヘッダ圧縮の分だけSPDYの効果が高い。 Server Push の影響も現れるだろう。 DOM処理(同期):SPDY/SSLともに同じだが Server Push の影響がここで 現れるだろう。 DOM処理(非同期): イメージのダウンロードなどSPDY効果が一番現 れる。
  20. 20. 単純なベンチ結果(10iter.) 上から、SSL, SPDY/2, SPDY/2+push画像100枚 SPDY/SSL=1.12, SPDY+push/SSL=1.48画像500枚 SPDY/SSL=1.15, SPDY+push/SSL=0.85実際にベンチをデモしてみます。 Chrome 22.0 Canary
  21. 21. 実際に測る(その1)spdy/3 はnode-spdy の spdy-v3 ブランチを使用。Flow Control (WINDOW_UPDATEStream) の受信で頻繁にエラーが発生しているので値は正確ではないかもしれないです。
  22. 22. 実際に測る(その2)SPDYの方が遅いこともしばしば
  23. 23. 実際に測る• 実際にデモ
  24. 24. まとめ• SPDYはHTTPを高速化を目指すプロトコル• 1つのTCPセッション内で任意の key/value のデータ組をサーバ・クライアント間で 双方向で多重化通信を行える。• TLSと組み合わせることによって既存の通 信との互換性が高い• 多重化・優先度・フロー制御・サーバ プッシュなど新しい機能も実現。• SPDYによってどこまで高速になるかどう か – うーん、まだまだ検証や運用ノウハウが必要
  25. 25. (時間があれば、) SPDYプロトコルの中身を見る(SPDY/3) SPDLAY にお世話になってます。 https://github.com/tatsuhiro-t/spdylay
  26. 26. spdylayを使ってSPDYの中身を見る www.google.com サーバ編 (その1) $ ./examples/spdycat -v https://www.google.com NPNでプロトコル情報の交換 [ 0.012] NPN select next protocol: the remote server offers: * spdy/3 * spdy/2 * http/1.1 NPN selected the protocol: spdy/3 google サーバから SDPYの設定情報が送られてくる [ 0.018] recv SETTINGS frame <version=3, flags=0, length=20> (niv=2) [4(1):100] [7(0):12288]4: SETTINGS_MAX_CONCURRENT_STREAMS 最大同時アクティブなストリーム数7: SETTINGS_INITIAL_WINDOW_SIZE ストリームの初期ウィンドウサイズ(バイト)
  27. 27. spdylayを使ってSPDYの中身を見る www.google.com サーバ編 (その2)SYN_STREAMを使ってHTTPリクエストヘッダ情報をサーバに送信[ 0.018] send SYN_STREAM frame <version=3, flags=1, length=106> (stream_id=1, assoc_stream_id=0, pri=3) :host: www.google.com :method: GET :path: / :scheme: https :version: HTTP/1.1 accept: */* user-agent: spdylay/0.2.0
  28. 28. spdylayを使ってSPDYの中身を見る www.google.com サーバ編 (その3)SYN_REPLY でHTTPレスポンスヘッダ情報がサーバから送られてくる[ 0.057] recv SYN_REPLY frame <version=3, flags=0, length=558> (stream_id=1) :status: 302 Found :version: HTTP/1.1 cache-control: private content-length: 222 content-type: text/html; charset=UTF-8 date: Thu, 17 May 2012 01:24:23 GMT location: https://www.google.co.jp/ server: gws (以下略)
  29. 29. spdylayを使ってSPDYの中身を見る www.google.com サーバ編 (その4)Dataフレーム でHTTPレスポンスボディがサーバから送られてくる <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>302 Moved</TITLE></HEAD><BODY> <H1>302 Moved</H1> The document has moved <A HREF="https://www.google.co.jp/">here</A>. </BODY></HTML> [ 0.058] recv DATA frame (stream_id=1, flags=1, length=222)SPDY終了 [ 0.058] send GOAWAY frame <version=3, flags=0, length=8> (last_good_stream_id=0
  30. 30. spdylayを使ってSPDYの中身を見る Chrome ブラウザ編 (その1) ./examples/spdyd --htdocs=. -v 3000 ./foo-key.pem ./foo-cert.pem NPNでプロトコル情報の決定[id=1] [ 5.046] closedThe negotiated next protocol: spdy/3SYN_STREAMを使ってHTTPリクエストヘッダ情報がChromeから送られてくる[id=2] [ 5.051] recv SYN_STREAM frame <version=3, flags=1, length=250> (stream_id=1, assoc_stream_id=0, pri=0) :host: unixjp:3000 :method: GET :path: / :scheme: https :version: HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-charset: Shift_JIS,utf-8;q=0.7,*;q=0.3 (以下略)
  31. 31. spdylayを使ってSPDYの中身を見る Chrome ブラウザ編 (その2) サーバからSETTINGSによって同時ストリーム数の設定 [id=2] [ 5.052] send SETTINGS frame <version=3, flags=0, length=12> (niv=1) [4(0):100]SYN_REPLY でHTTPレスポンスヘッダ情報を Chrome に送る[id=2] [ 5.052] send SYN_REPLY frame <version=3, flags=0, length=109> (stream_id=1) :status: 200 OK :version: HTTP/1.1 cache-control: max-age=3600 content-length: 40 date: Thu, 17 May 2012 02:40:28 GMT last-modified: Mon, 14 May 2012 20:34:32 GMT server: spdyd spdylay/0.2.0
  32. 32. spdylayを使ってSPDYの中身を見る Chrome ブラウザ編 (その3)データフレームでレスポンスボディを送信最後のデータフレームは flag 1 (FLAG_FIN) を使ってストリームを終了させてます。[id=2] [ 5.052] send DATA frame (stream_id=1, flags=0, length=40)[id=2] [ 5.053] send DATA frame (stream_id=1, flags=1, length=0)[id=2] [ 5.053] stream_id=1 closed
  33. 33. spdylayを使ってSPDYの中身を見る Chrome ブラウザ編 (その4)Chrome が favicon.ico を取りに来てるリクエスト[id=2] [ 5.094] recv SYN_STREAM frame <version=3, flags=1, length=39> (stream_id=3, assoc_stream_id=0, pri=1) :host: unixjp:3000 :method: GET :path: /favicon.ico :scheme: https :version: HTTP/1.1 accept: */* accept-charset: Shift_JIS,utf-8;q=0.7,*;q=0.3 accept-encoding: gzip,deflate,sdch accept-language: en-US,en;q=0.8 user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5(KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5
  34. 34. spdylayを使ってSPDYの中身を見る Chrome ブラウザ編 (その5)favicon なんて用意していないので404を返す SYN_REPLY[id=2] [ 5.095] send SYN_REPLY frame <version=3, flags=0, length=33> (stream_id=3) :status: 404 Not Found :version: HTTP/1.1 content-encoding: gzip date: Thu, 17 May 2012 02:40:28 GMT server: spdyd spdylay/0.2.0最後に Chrome から PING で SPDY の生存確認をしています。[id=2] [ 6.048] recv PING frame <version=3, flags=0, length=4> (unique_id=1)[id=2] [ 6.048] send PING frame <version=3, flags=0, length=4> (unique_id=1)

×