SlideShare a Scribd company logo
1 of 34
SPDY の話

  IIJ 大津繁樹 (@jovi0608)
       2012年7月5日

    HTML5とか勉強会番外編
- ブラウザとサーバの間を考えよう-
自己紹介
• 大津 繁樹(@jovi0608, https://github.com/shigeki)
• 所属: インターネットイニシアティブ(IIJ)
  アプリケーション開発部 戦略的開発室
• HTML5/Node.js/Kinect 等流行もの担当
• 最近は Node.js コアの開発やってます。
最近 SPDY が話題です。




   SPDYはGoogle, Incの登録商標です。
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サポート
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%早いだけ
最近のトピック(Chrome Secure
          Proxy)
Chromeを「Amazon Silk もどき」に、




    ChromeとProxyサーバ間をSPDYでつなぐ

                      実際にデモ
引用元 SPDY & Secure Proxy Support in Google Chrome by Ilya Grigorik
http://www.igvita.com/2012/06/25/spdy-and-secure-proxy-support-in-
google-chrome/
HTTP高速化の試み




HTMLのページの読み込み時間の短縮には帯域
増大よりRTT短縮の方が効果が大きい
引用元: More Bandwidth Doesn’t Matter (much) by Mike Belshe
http://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub
3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2
SPDY vs HTTP
SPDYの特徴
          (Google I/O 2012セッション資料より引用)
 • 常にTLSの上で動作
 • ヘッダ圧縮をする
 • バイナリーのフレーム
 • フルデュプレックス、優先ストリームが
   ある
 • サーバプッシュが可能
 • TCP接続が1つだけ
 • 少ないパケットですむ
 • 既存コンテンツを変える必要はない
引用元 Google I/O 2012 SPDY It's Here!: http://r2---
bru02t11.c.bigcache.googleapis.com/io2012/presentations/live%20to%20website/1201.pdf
SPDYに向かないこと
         (Google I/O 2012セッション資料より引用)

 • 3rd partyドメインのリソースを多用してい
   るサイト
      – それぞれのサイトへの接続オーバヘッドが発
        生
 • 極めて少ないリソースで作られているサ
   イト
      – コネクション再利用の機会がなく効果が薄い。
 • パケットロスが多発しているリンク
      – RTTが大きくて、パケットロスが多発している
引用元 Google I/O 2012 SPDY It's Here!: http://r2---
          ところでは HTTPよりも性能が悪くなる。
bru02t11.c.bigcache.googleapis.com/io2012/presentations/live%20to%20website/1201.pdf
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通信制御情報のやり取り
                に使う
単純なSPDYのストリームフロー

               SSLハンドシェイク

         NPN (Next Protocol Negotiation) を
         使って SPDY 利用バージョンを交換
                  SYN_STREAM
           HTTPリクエストヘッダ情報を送信

                   SYN_REPLY

           HTTPレスポンスヘッダ情報を送信

クライアント             DATA Frame                サーバー

           HTTPレスポンスボディを送信

                    GOAWAY

           SPDYストリーム利用停止を通知

 SSLのTCPセッションは1つ
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 1
1                     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
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 1
1            version                                     2
     Flags                                      Length
X                                 Stream-ID
                        Number of Name/Value pairs
                              Length of name
                                  Name
                              Length of value
                                  Value


                                  Flags
                       0x01 FLAG_FIN


                                                             圧縮データ
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 1
0                            Stream-ID
     Flags                               Length
                              Data

                              Flags
                    0x01 FLAG_FIN
                    0x02 FLAG_COMPRESS
Server Push とは、
              HTTPリクエスト                   この間にサーバ
                          SYN_STREAM      が先読みレスポ
UNIDIRECTIONAL
        で                                 ンスとデータを
assosicate-stream         SYN_STREAM      送りまくる
     が必須
           キャッ            DATA Frame
            シュ

                          SYN_STREAM
クライアント
           キャッ                                サーバー
                          DATA Frame
            シュ


                            SYN_REPLY
                                         HTTPレスポンス
                            DATA Frame
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);
 }
});
SPDYの性能を測る
Navigation Timing APIで見るSPDY
                                     DOMComplete
                  DOMContentLoaded
                                       /onLoad     loadEventEnd

       DOMLoading

DNS 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効果が一番現
  れる。
単純なベンチ結果(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
実際に測る(その1)




spdy/3 はnode-spdy の spdy-v3 ブランチを使用。Flow Control (WINDOW_UPDATE
Stream) の受信で頻繁にエラーが発生しているので値は正確ではないかもしれな
いです。
実際に測る(その2)




SPDYの方が遅いこともしばしば
実際に測る

• 実際にデモ
まとめ
• SPDYはHTTPを高速化を目指すプロトコル
• 1つのTCPセッション内で任意の key/value
  のデータ組をサーバ・クライアント間で
  双方向で多重化通信を行える。
• TLSと組み合わせることによって既存の通
  信との互換性が高い
• 多重化・優先度・フロー制御・サーバ
  プッシュなど新しい機能も実現。
• SPDYによってどこまで高速になるかどう
  か
 – うーん、まだまだ検証や運用ノウハウが必要
(時間があれば、) SPDYプロト
コルの中身を見る(SPDY/3)
     SPDLAY にお世話になってます。
        https://github.com/tatsuhiro-t/spdylay
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 ストリームの初期ウィンドウサイズ(バイト)
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
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
     (以下略)
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
spdylayを使ってSPDYの中身を見る
              Chrome ブラウザ編 (その1)
      ./examples/spdyd --htdocs=. -v 3000 ./foo-key.pem ./foo-cert.pem

  NPNでプロトコル情報の決定
[id=1] [ 5.046] closed
The negotiated next protocol: spdy/3

SYN_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
      (以下略)
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
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
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
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)

More Related Content

What's hot

#mailerstudy 02 暗号入門 (2012-02-22更新)
#mailerstudy 02 暗号入門 (2012-02-22更新)#mailerstudy 02 暗号入門 (2012-02-22更新)
#mailerstudy 02 暗号入門 (2012-02-22更新)Takashi Takizawa
 
Android開発者向けempress暗号化資料
Android開発者向けempress暗号化資料Android開発者向けempress暗号化資料
Android開発者向けempress暗号化資料ITDORAKU
 
TAM 新人ディレクター システムスキルアップ プログラム第2回「システム案件のヒアリング」
TAM 新人ディレクター システムスキルアップ プログラム第2回「システム案件のヒアリング」TAM 新人ディレクター システムスキルアップ プログラム第2回「システム案件のヒアリング」
TAM 新人ディレクター システムスキルアップ プログラム第2回「システム案件のヒアリング」(株)TAM
 
リーダブルコードが良書だったのでまとめました
リーダブルコードが良書だったのでまとめましたリーダブルコードが良書だったのでまとめました
リーダブルコードが良書だったのでまとめましたTakumi Sato
 
DTraceによるMySQL解析ことはじめ
DTraceによるMySQL解析ことはじめDTraceによるMySQL解析ことはじめ
DTraceによるMySQL解析ことはじめMikiya Okuno
 
NGSIv1 を知っている開発者向けの NGSIv2 の概要 (Orion 3.5.0対応)
NGSIv1 を知っている開発者向けの NGSIv2 の概要 (Orion 3.5.0対応)NGSIv1 を知っている開発者向けの NGSIv2 の概要 (Orion 3.5.0対応)
NGSIv1 を知っている開発者向けの NGSIv2 の概要 (Orion 3.5.0対応)fisuda
 
C10K on Mongo's sharding
C10K on Mongo's shardingC10K on Mongo's sharding
C10K on Mongo's shardingHiroaki Kubota
 
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説Takateru Yamagishi
 
AutoDock_vina_japanese_ver.3.0
AutoDock_vina_japanese_ver.3.0AutoDock_vina_japanese_ver.3.0
AutoDock_vina_japanese_ver.3.0Satoshi Kume
 
AutoDock_vina_japanese_ver.2.0
AutoDock_vina_japanese_ver.2.0AutoDock_vina_japanese_ver.2.0
AutoDock_vina_japanese_ver.2.0Satoshi Kume
 
RLSを用いたマルチテナント実装 for Django
RLSを用いたマルチテナント実装 for DjangoRLSを用いたマルチテナント実装 for Django
RLSを用いたマルチテナント実装 for DjangoTakayuki Shimizukawa
 
Optimisation 2013-07-02
Optimisation 2013-07-02Optimisation 2013-07-02
Optimisation 2013-07-02kmiyako
 
Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介Hiroshi Tokumaru
 

What's hot (14)

#mailerstudy 02 暗号入門 (2012-02-22更新)
#mailerstudy 02 暗号入門 (2012-02-22更新)#mailerstudy 02 暗号入門 (2012-02-22更新)
#mailerstudy 02 暗号入門 (2012-02-22更新)
 
Android開発者向けempress暗号化資料
Android開発者向けempress暗号化資料Android開発者向けempress暗号化資料
Android開発者向けempress暗号化資料
 
CPUの同時実行機能
CPUの同時実行機能CPUの同時実行機能
CPUの同時実行機能
 
TAM 新人ディレクター システムスキルアップ プログラム第2回「システム案件のヒアリング」
TAM 新人ディレクター システムスキルアップ プログラム第2回「システム案件のヒアリング」TAM 新人ディレクター システムスキルアップ プログラム第2回「システム案件のヒアリング」
TAM 新人ディレクター システムスキルアップ プログラム第2回「システム案件のヒアリング」
 
リーダブルコードが良書だったのでまとめました
リーダブルコードが良書だったのでまとめましたリーダブルコードが良書だったのでまとめました
リーダブルコードが良書だったのでまとめました
 
DTraceによるMySQL解析ことはじめ
DTraceによるMySQL解析ことはじめDTraceによるMySQL解析ことはじめ
DTraceによるMySQL解析ことはじめ
 
NGSIv1 を知っている開発者向けの NGSIv2 の概要 (Orion 3.5.0対応)
NGSIv1 を知っている開発者向けの NGSIv2 の概要 (Orion 3.5.0対応)NGSIv1 を知っている開発者向けの NGSIv2 の概要 (Orion 3.5.0対応)
NGSIv1 を知っている開発者向けの NGSIv2 の概要 (Orion 3.5.0対応)
 
C10K on Mongo's sharding
C10K on Mongo's shardingC10K on Mongo's sharding
C10K on Mongo's sharding
 
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
 
AutoDock_vina_japanese_ver.3.0
AutoDock_vina_japanese_ver.3.0AutoDock_vina_japanese_ver.3.0
AutoDock_vina_japanese_ver.3.0
 
AutoDock_vina_japanese_ver.2.0
AutoDock_vina_japanese_ver.2.0AutoDock_vina_japanese_ver.2.0
AutoDock_vina_japanese_ver.2.0
 
RLSを用いたマルチテナント実装 for Django
RLSを用いたマルチテナント実装 for DjangoRLSを用いたマルチテナント実装 for Django
RLSを用いたマルチテナント実装 for Django
 
Optimisation 2013-07-02
Optimisation 2013-07-02Optimisation 2013-07-02
Optimisation 2013-07-02
 
Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介
 

Viewers also liked

ISOC-JP/JPNIC IETF95 報告会 ネットワーク計測関連WG報告
ISOC-JP/JPNIC IETF95 報告会 ネットワーク計測関連WG報告ISOC-JP/JPNIC IETF95 報告会 ネットワーク計測関連WG報告
ISOC-JP/JPNIC IETF95 報告会 ネットワーク計測関連WG報告Satoshi KAMEI
 
Hokkaido.cap #osc11do Wiresharkを使いこなそう!
Hokkaido.cap #osc11do Wiresharkを使いこなそう!Hokkaido.cap #osc11do Wiresharkを使いこなそう!
Hokkaido.cap #osc11do Wiresharkを使いこなそう!Panda Yamaki
 
IIJmio meeting 14 みおふぉん教室「格安スマホの選び方2017」
IIJmio meeting 14 みおふぉん教室「格安スマホの選び方2017」IIJmio meeting 14 みおふぉん教室「格安スマホの選び方2017」
IIJmio meeting 14 みおふぉん教室「格安スマホの選び方2017」techlog (Internet Initiative Japan Inc.)
 
Speed matters, So why is your site so slow?
Speed matters, So why is your site so slow?Speed matters, So why is your site so slow?
Speed matters, So why is your site so slow?Andy Davies
 
Cloud Architectures with AWS Direct Connect (ARC304) | AWS re:Invent 2013
Cloud Architectures with AWS Direct Connect (ARC304) | AWS re:Invent 2013Cloud Architectures with AWS Direct Connect (ARC304) | AWS re:Invent 2013
Cloud Architectures with AWS Direct Connect (ARC304) | AWS re:Invent 2013Amazon Web Services
 
AWS re:Invent 2016: Deep Dive: AWS Direct Connect and VPNs (NET402)
AWS re:Invent 2016: Deep Dive: AWS Direct Connect and VPNs (NET402)AWS re:Invent 2016: Deep Dive: AWS Direct Connect and VPNs (NET402)
AWS re:Invent 2016: Deep Dive: AWS Direct Connect and VPNs (NET402)Amazon Web Services
 
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先Kazuho Oku
 

Viewers also liked (10)

ISOC-JP/JPNIC IETF95 報告会 ネットワーク計測関連WG報告
ISOC-JP/JPNIC IETF95 報告会 ネットワーク計測関連WG報告ISOC-JP/JPNIC IETF95 報告会 ネットワーク計測関連WG報告
ISOC-JP/JPNIC IETF95 報告会 ネットワーク計測関連WG報告
 
Hokkaido.cap #osc11do Wiresharkを使いこなそう!
Hokkaido.cap #osc11do Wiresharkを使いこなそう!Hokkaido.cap #osc11do Wiresharkを使いこなそう!
Hokkaido.cap #osc11do Wiresharkを使いこなそう!
 
IIJmio meeting 14 SIMロックについて
IIJmio meeting 14 SIMロックについてIIJmio meeting 14 SIMロックについて
IIJmio meeting 14 SIMロックについて
 
IIJmio meeting 14 IIJmio Updates 2016/10~2017/01
IIJmio meeting 14 IIJmio Updates 2016/10~2017/01IIJmio meeting 14 IIJmio Updates 2016/10~2017/01
IIJmio meeting 14 IIJmio Updates 2016/10~2017/01
 
IIJmio meeting 14 みおふぉん教室「格安スマホの選び方2017」
IIJmio meeting 14 みおふぉん教室「格安スマホの選び方2017」IIJmio meeting 14 みおふぉん教室「格安スマホの選び方2017」
IIJmio meeting 14 みおふぉん教室「格安スマホの選び方2017」
 
Speed matters, So why is your site so slow?
Speed matters, So why is your site so slow?Speed matters, So why is your site so slow?
Speed matters, So why is your site so slow?
 
IIJmio meeting 14 IIJmioタイプAとSIMフリー端末について
IIJmio meeting 14 IIJmioタイプAとSIMフリー端末についてIIJmio meeting 14 IIJmioタイプAとSIMフリー端末について
IIJmio meeting 14 IIJmioタイプAとSIMフリー端末について
 
Cloud Architectures with AWS Direct Connect (ARC304) | AWS re:Invent 2013
Cloud Architectures with AWS Direct Connect (ARC304) | AWS re:Invent 2013Cloud Architectures with AWS Direct Connect (ARC304) | AWS re:Invent 2013
Cloud Architectures with AWS Direct Connect (ARC304) | AWS re:Invent 2013
 
AWS re:Invent 2016: Deep Dive: AWS Direct Connect and VPNs (NET402)
AWS re:Invent 2016: Deep Dive: AWS Direct Connect and VPNs (NET402)AWS re:Invent 2016: Deep Dive: AWS Direct Connect and VPNs (NET402)
AWS re:Invent 2016: Deep Dive: AWS Direct Connect and VPNs (NET402)
 
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先
 

Similar to SPDYの話

Node.js で SPDYのベンチマーク体験サイトを作りました
Node.js で SPDYのベンチマーク体験サイトを作りましたNode.js で SPDYのベンチマーク体験サイトを作りました
Node.js で SPDYのベンチマーク体験サイトを作りましたshigeki_ohtsu
 
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014Nov Matake
 
mod_auth_ticket - Bringing Single-Sign-On to lighttpd
mod_auth_ticket - Bringing Single-Sign-On to lighttpdmod_auth_ticket - Bringing Single-Sign-On to lighttpd
mod_auth_ticket - Bringing Single-Sign-On to lighttpdTaisuke Yamada
 
CDNの仕組み(JANOG36)
CDNの仕組み(JANOG36)CDNの仕組み(JANOG36)
CDNの仕組み(JANOG36)J-Stream Inc.
 
The overview of Server-ide Bulk Loader
 The overview of Server-ide Bulk Loader The overview of Server-ide Bulk Loader
The overview of Server-ide Bulk LoaderTreasure Data, Inc.
 
CommunityOpenDay2012名古屋セッション資料
CommunityOpenDay2012名古屋セッション資料CommunityOpenDay2012名古屋セッション資料
CommunityOpenDay2012名古屋セッション資料Shinichiro Isago
 
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみようHokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみようPanda Yamaki
 
CA LDAP Server for z/OSのご紹介
CA LDAP Server for z/OSのご紹介 CA LDAP Server for z/OSのご紹介
CA LDAP Server for z/OSのご紹介 幸純 浦山
 
20190516_DLC10_PGStrom
20190516_DLC10_PGStrom20190516_DLC10_PGStrom
20190516_DLC10_PGStromKohei KaiGai
 
Inside mobage platform
Inside mobage platformInside mobage platform
Inside mobage platformToru Yamaguchi
 
2010 04クラウド技術講座
2010 04クラウド技術講座2010 04クラウド技術講座
2010 04クラウド技術講座sisawa
 
知っておくべきCephのIOアクセラレーション技術とその活用方法 - OpenStack最新情報セミナー 2015年9月
知っておくべきCephのIOアクセラレーション技術とその活用方法 - OpenStack最新情報セミナー 2015年9月知っておくべきCephのIOアクセラレーション技術とその活用方法 - OpenStack最新情報セミナー 2015年9月
知っておくべきCephのIOアクセラレーション技術とその活用方法 - OpenStack最新情報セミナー 2015年9月VirtualTech Japan Inc.
 
ソシャゲにおけるサーバとクライアントの決めごと
ソシャゲにおけるサーバとクライアントの決めごとソシャゲにおけるサーバとクライアントの決めごと
ソシャゲにおけるサーバとクライアントの決めごとpeto_tn
 
ceph acceleration and storage architecture
ceph acceleration and storage architectureceph acceleration and storage architecture
ceph acceleration and storage architectureYuki Kitajima
 
WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)
WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)
WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)Shinichiro Isago
 
Man-in-the-Middle Attack for SSH with Scala and JSch
Man-in-the-Middle Attack for SSH with Scala and JSchMan-in-the-Middle Attack for SSH with Scala and JSch
Man-in-the-Middle Attack for SSH with Scala and JSchAtsuhiko Yamanaka
 
WebSocket Protocol と Plack::Middleware::WebSocket
WebSocket Protocol と Plack::Middleware::WebSocketWebSocket Protocol と Plack::Middleware::WebSocket
WebSocket Protocol と Plack::Middleware::WebSocketYu Nobuoka
 
DRBD 8.3の開発終了に伴う今後の対応について
DRBD 8.3の開発終了に伴う今後の対応についてDRBD 8.3の開発終了に伴う今後の対応について
DRBD 8.3の開発終了に伴う今後の対応について株式会社サードウェア
 

Similar to SPDYの話 (20)

Node.js で SPDYのベンチマーク体験サイトを作りました
Node.js で SPDYのベンチマーク体験サイトを作りましたNode.js で SPDYのベンチマーク体験サイトを作りました
Node.js で SPDYのベンチマーク体験サイトを作りました
 
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
 
mod_auth_ticket - Bringing Single-Sign-On to lighttpd
mod_auth_ticket - Bringing Single-Sign-On to lighttpdmod_auth_ticket - Bringing Single-Sign-On to lighttpd
mod_auth_ticket - Bringing Single-Sign-On to lighttpd
 
CDNの仕組み(JANOG36)
CDNの仕組み(JANOG36)CDNの仕組み(JANOG36)
CDNの仕組み(JANOG36)
 
The overview of Server-ide Bulk Loader
 The overview of Server-ide Bulk Loader The overview of Server-ide Bulk Loader
The overview of Server-ide Bulk Loader
 
CommunityOpenDay2012名古屋セッション資料
CommunityOpenDay2012名古屋セッション資料CommunityOpenDay2012名古屋セッション資料
CommunityOpenDay2012名古屋セッション資料
 
Windows Azure Community Open Day 2012
Windows Azure   Community Open Day 2012Windows Azure   Community Open Day 2012
Windows Azure Community Open Day 2012
 
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみようHokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
 
CA LDAP Server for z/OSのご紹介
CA LDAP Server for z/OSのご紹介 CA LDAP Server for z/OSのご紹介
CA LDAP Server for z/OSのご紹介
 
20190516_DLC10_PGStrom
20190516_DLC10_PGStrom20190516_DLC10_PGStrom
20190516_DLC10_PGStrom
 
Inside mobage platform
Inside mobage platformInside mobage platform
Inside mobage platform
 
2010 04クラウド技術講座
2010 04クラウド技術講座2010 04クラウド技術講座
2010 04クラウド技術講座
 
知っておくべきCephのIOアクセラレーション技術とその活用方法 - OpenStack最新情報セミナー 2015年9月
知っておくべきCephのIOアクセラレーション技術とその活用方法 - OpenStack最新情報セミナー 2015年9月知っておくべきCephのIOアクセラレーション技術とその活用方法 - OpenStack最新情報セミナー 2015年9月
知っておくべきCephのIOアクセラレーション技術とその活用方法 - OpenStack最新情報セミナー 2015年9月
 
Xml Security
Xml SecurityXml Security
Xml Security
 
ソシャゲにおけるサーバとクライアントの決めごと
ソシャゲにおけるサーバとクライアントの決めごとソシャゲにおけるサーバとクライアントの決めごと
ソシャゲにおけるサーバとクライアントの決めごと
 
ceph acceleration and storage architecture
ceph acceleration and storage architectureceph acceleration and storage architecture
ceph acceleration and storage architecture
 
WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)
WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)
WindowsAzureの長所を活かすクラウド アプリ開発(PDF版)
 
Man-in-the-Middle Attack for SSH with Scala and JSch
Man-in-the-Middle Attack for SSH with Scala and JSchMan-in-the-Middle Attack for SSH with Scala and JSch
Man-in-the-Middle Attack for SSH with Scala and JSch
 
WebSocket Protocol と Plack::Middleware::WebSocket
WebSocket Protocol と Plack::Middleware::WebSocketWebSocket Protocol と Plack::Middleware::WebSocket
WebSocket Protocol と Plack::Middleware::WebSocket
 
DRBD 8.3の開発終了に伴う今後の対応について
DRBD 8.3の開発終了に伴う今後の対応についてDRBD 8.3の開発終了に伴う今後の対応について
DRBD 8.3の開発終了に伴う今後の対応について
 

More from shigeki_ohtsu

Node最新トピックス
Node最新トピックスNode最新トピックス
Node最新トピックスshigeki_ohtsu
 
SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向shigeki_ohtsu
 
HTTP/2の現状とこれから
HTTP/2の現状とこれからHTTP/2の現状とこれから
HTTP/2の現状とこれからshigeki_ohtsu
 
Node-v0.12のTLSを256倍使いこなす方法
Node-v0.12のTLSを256倍使いこなす方法Node-v0.12のTLSを256倍使いこなす方法
Node-v0.12のTLSを256倍使いこなす方法shigeki_ohtsu
 
Technical Overview of QUIC
Technical  Overview of QUICTechnical  Overview of QUIC
Technical Overview of QUICshigeki_ohtsu
 
Node-v0.12の新機能について
Node-v0.12の新機能についてNode-v0.12の新機能について
Node-v0.12の新機能についてshigeki_ohtsu
 
httpbis interim@チューリッヒ レポート
httpbis interim@チューリッヒ レポートhttpbis interim@チューリッヒ レポート
httpbis interim@チューリッヒ レポートshigeki_ohtsu
 
第43回HTML5とか勉強会 SPDY/QUICデモ
第43回HTML5とか勉強会 SPDY/QUICデモ第43回HTML5とか勉強会 SPDY/QUICデモ
第43回HTML5とか勉強会 SPDY/QUICデモshigeki_ohtsu
 
HTTP/2.0がもたらす Webサービスの進化(後半)
HTTP/2.0がもたらすWebサービスの進化(後半)HTTP/2.0がもたらすWebサービスの進化(後半)
HTTP/2.0がもたらす Webサービスの進化(後半)shigeki_ohtsu
 
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_t
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_tHTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_t
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_tshigeki_ohtsu
 
httpbis interim@シアトル レポート (第2回HTTP/2.0接続試験)
httpbis interim@シアトル レポート(第2回HTTP/2.0接続試験)httpbis interim@シアトル レポート(第2回HTTP/2.0接続試験)
httpbis interim@シアトル レポート (第2回HTTP/2.0接続試験)shigeki_ohtsu
 
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話Node の HTTP/2.0 モジュール iij-http2 の実装苦労話
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話shigeki_ohtsu
 
httpbis interim とhttp2.0相互接続試験の話
httpbis interim とhttp2.0相互接続試験の話httpbis interim とhttp2.0相互接続試験の話
httpbis interim とhttp2.0相互接続試験の話shigeki_ohtsu
 
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解する
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解するそうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解する
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解するshigeki_ohtsu
 
node-gypを使ったネイティブモジュールの作成
node-gypを使ったネイティブモジュールの作成node-gypを使ったネイティブモジュールの作成
node-gypを使ったネイティブモジュールの作成shigeki_ohtsu
 

More from shigeki_ohtsu (18)

Node最新トピックス
Node最新トピックスNode最新トピックス
Node最新トピックス
 
TLS, HTTP/2演習
TLS, HTTP/2演習TLS, HTTP/2演習
TLS, HTTP/2演習
 
HTTP/2, QUIC入門
HTTP/2, QUIC入門HTTP/2, QUIC入門
HTTP/2, QUIC入門
 
SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向
 
HTTP/2の現状とこれから
HTTP/2の現状とこれからHTTP/2の現状とこれから
HTTP/2の現状とこれから
 
Node-v0.12のTLSを256倍使いこなす方法
Node-v0.12のTLSを256倍使いこなす方法Node-v0.12のTLSを256倍使いこなす方法
Node-v0.12のTLSを256倍使いこなす方法
 
Technical Overview of QUIC
Technical  Overview of QUICTechnical  Overview of QUIC
Technical Overview of QUIC
 
Node-v0.12の新機能について
Node-v0.12の新機能についてNode-v0.12の新機能について
Node-v0.12の新機能について
 
httpbis interim@チューリッヒ レポート
httpbis interim@チューリッヒ レポートhttpbis interim@チューリッヒ レポート
httpbis interim@チューリッヒ レポート
 
第43回HTML5とか勉強会 SPDY/QUICデモ
第43回HTML5とか勉強会 SPDY/QUICデモ第43回HTML5とか勉強会 SPDY/QUICデモ
第43回HTML5とか勉強会 SPDY/QUICデモ
 
HTTP/2.0がもたらす Webサービスの進化(後半)
HTTP/2.0がもたらすWebサービスの進化(後半)HTTP/2.0がもたらすWebサービスの進化(後半)
HTTP/2.0がもたらす Webサービスの進化(後半)
 
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_t
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_tHTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_t
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_t
 
httpbis interim@シアトル レポート (第2回HTTP/2.0接続試験)
httpbis interim@シアトル レポート(第2回HTTP/2.0接続試験)httpbis interim@シアトル レポート(第2回HTTP/2.0接続試験)
httpbis interim@シアトル レポート (第2回HTTP/2.0接続試験)
 
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話Node の HTTP/2.0 モジュール iij-http2 の実装苦労話
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話
 
httpbis interim とhttp2.0相互接続試験の話
httpbis interim とhttp2.0相互接続試験の話httpbis interim とhttp2.0相互接続試験の話
httpbis interim とhttp2.0相互接続試験の話
 
Stream2の基本
Stream2の基本Stream2の基本
Stream2の基本
 
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解する
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解するそうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解する
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解する
 
node-gypを使ったネイティブモジュールの作成
node-gypを使ったネイティブモジュールの作成node-gypを使ったネイティブモジュールの作成
node-gypを使ったネイティブモジュールの作成
 

Recently uploaded

20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directoryosamut
 
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptxIoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptxAtomu Hidaka
 
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000Shota Ito
 
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By DanielPostman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Danieldanielhu54
 
UPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdfUPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdffurutsuka
 
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ       2024/04/12の勉強会で発表されたものです。新人研修のまとめ       2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。iPride Co., Ltd.
 
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。iPride Co., Ltd.
 
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略Ryo Sasaki
 
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムスマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムsugiuralab
 

Recently uploaded (9)

20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory
 
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptxIoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
 
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
 
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By DanielPostman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Daniel
 
UPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdfUPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdf
 
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ       2024/04/12の勉強会で発表されたものです。新人研修のまとめ       2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
 
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
 
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
 
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムスマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
 

SPDYの話

  • 1. SPDY の話 IIJ 大津繁樹 (@jovi0608) 2012年7月5日 HTML5とか勉強会番外編 - ブラウザとサーバの間を考えよう-
  • 2. 自己紹介 • 大津 繁樹(@jovi0608, https://github.com/shigeki) • 所属: インターネットイニシアティブ(IIJ) アプリケーション開発部 戦略的開発室 • HTML5/Node.js/Kinect 等流行もの担当 • 最近は Node.js コアの開発やってます。
  • 3. 最近 SPDY が話題です。 SPDYはGoogle, Incの登録商標です。
  • 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. 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. 最近のトピック(Chrome Secure Proxy) Chromeを「Amazon Silk もどき」に、 ChromeとProxyサーバ間をSPDYでつなぐ 実際にデモ 引用元 SPDY & Secure Proxy Support in Google Chrome by Ilya Grigorik http://www.igvita.com/2012/06/25/spdy-and-secure-proxy-support-in- google-chrome/
  • 7. HTTP高速化の試み HTMLのページの読み込み時間の短縮には帯域 増大よりRTT短縮の方が効果が大きい 引用元: More Bandwidth Doesn’t Matter (much) by Mike Belshe http://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub 3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2
  • 9. SPDYの特徴 (Google I/O 2012セッション資料より引用) • 常にTLSの上で動作 • ヘッダ圧縮をする • バイナリーのフレーム • フルデュプレックス、優先ストリームが ある • サーバプッシュが可能 • TCP接続が1つだけ • 少ないパケットですむ • 既存コンテンツを変える必要はない 引用元 Google I/O 2012 SPDY It's Here!: http://r2--- bru02t11.c.bigcache.googleapis.com/io2012/presentations/live%20to%20website/1201.pdf
  • 10. SPDYに向かないこと (Google I/O 2012セッション資料より引用) • 3rd partyドメインのリソースを多用してい るサイト – それぞれのサイトへの接続オーバヘッドが発 生 • 極めて少ないリソースで作られているサ イト – コネクション再利用の機会がなく効果が薄い。 • パケットロスが多発しているリンク – RTTが大きくて、パケットロスが多発している 引用元 Google I/O 2012 SPDY It's Here!: http://r2--- ところでは HTTPよりも性能が悪くなる。 bru02t11.c.bigcache.googleapis.com/io2012/presentations/live%20to%20website/1201.pdf
  • 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. 単純なSPDYのストリームフロー SSLハンドシェイク NPN (Next Protocol Negotiation) を 使って SPDY 利用バージョンを交換 SYN_STREAM HTTPリクエストヘッダ情報を送信 SYN_REPLY HTTPレスポンスヘッダ情報を送信 クライアント DATA Frame サーバー HTTPレスポンスボディを送信 GOAWAY SPDYストリーム利用停止を通知 SSLのTCPセッションは1つ
  • 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 1 1 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. 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 1 1 version 2 Flags Length X Stream-ID Number of Name/Value pairs Length of name Name Length of value Value Flags 0x01 FLAG_FIN 圧縮データ
  • 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 1 0 Stream-ID Flags Length Data Flags 0x01 FLAG_FIN 0x02 FLAG_COMPRESS
  • 16. Server Push とは、 HTTPリクエスト この間にサーバ SYN_STREAM が先読みレスポ UNIDIRECTIONAL で ンスとデータを assosicate-stream SYN_STREAM 送りまくる が必須 キャッ DATA Frame シュ SYN_STREAM クライアント キャッ サーバー DATA Frame シュ SYN_REPLY HTTPレスポンス DATA Frame
  • 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); } });
  • 19. Navigation Timing APIで見るSPDY DOMComplete DOMContentLoaded /onLoad loadEventEnd DOMLoading DNS 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. 単純なベンチ結果(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. 実際に測る(その1) spdy/3 はnode-spdy の spdy-v3 ブランチを使用。Flow Control (WINDOW_UPDATE Stream) の受信で頻繁にエラーが発生しているので値は正確ではないかもしれな いです。
  • 24. まとめ • SPDYはHTTPを高速化を目指すプロトコル • 1つのTCPセッション内で任意の key/value のデータ組をサーバ・クライアント間で 双方向で多重化通信を行える。 • TLSと組み合わせることによって既存の通 信との互換性が高い • 多重化・優先度・フロー制御・サーバ プッシュなど新しい機能も実現。 • SPDYによってどこまで高速になるかどう か – うーん、まだまだ検証や運用ノウハウが必要
  • 25. (時間があれば、) SPDYプロト コルの中身を見る(SPDY/3) SPDLAY にお世話になってます。 https://github.com/tatsuhiro-t/spdylay
  • 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. 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. 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. 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. spdylayを使ってSPDYの中身を見る Chrome ブラウザ編 (その1) ./examples/spdyd --htdocs=. -v 3000 ./foo-key.pem ./foo-cert.pem NPNでプロトコル情報の決定 [id=1] [ 5.046] closed The negotiated next protocol: spdy/3 SYN_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. 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. 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. 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. 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)