Guy Podjarny「SPDYはみんな思ってるものと違う」
Guy's POD 2012.6.12のエントリ
Guy's Pod » Blog Archive » Not as SPDY as You Thought
- AkamaiでChief Product Architectという肩書きを持つエンジニアによるspdy検証エントリ
- コメント欄も盛り上がってる
- Steve SoudersやSPDYテストしてるgoogleの人（Matt Welsh）とか
- Guyがspdy rantじゃないことがよくわかる
- 「spdyいいよね」「高速化tipsの賞味期限」「spdyはここ変えたら凄くなる」等々議論してて楽しい
- Guyのポイントはまとめると
- spdyに手を出す前にサイト高速化のベストプラクティスを実践しろ
- お前らの糞重いサイトのボトルネックはhttpじゃない
- 広く使われてる高速化のテクニックの中にはSPDYの現在の仕様と相性悪いものがある
- spdyはリクエスト／レスポンスの多重化を「ホストを問わない」形に変えるともっと良くなる
以下斜め読んだ内容
- spdy良い技術
- httpの過去１０数年で初の実用レベルのアップデート
- spdyが取り組んでる問題
- モバイル環境での高いレイテンシ・低パフォーマンス
- webのセキュリティ
- spdyとhttpの違いは色々
- tcpコネクション1つ（もしくは少数のtcpコネクション）上でリクエスト／レスポンスの多重化の実現が大きい
- 巷にはspdyのベンチマークをみかける
- 曰く「ページ読込を倍速に」やら「モバイル環境でspdy/httpsがhttpよりも23%高速」とか
- Chromium Blog: A 2x Faster Web
- SPDY performance on mobile networks - Google Developers Blog
- 自分も実際のサイトで試した。でも宣伝されてる通りにならなかった
- 自分のテストが示す限りspdyは「httpsより僅かに速い」が「httpより遅い」
- 巷のベンチマークと自分のテスト結果が食い違う理由は簡単
- spdyはhttpより良い。これは本当
- たいていのウェブサイトにおいてhttpがボトルネックではない
長すぎて読みたくない人向けに。最初にまとめ
●alexaのデータで上位500サイトピックアップ
●各サイトでページ読込時間をテスト
●各サイトにhttps+spdy、httpsのみ、httpの3パターンをテスト
●spdy対応クライアントにchrome
●spdy対応サーバとしてContendoをchromeと各サイトの間に置いた
●同じ条件で各サイトをテストするため
●Contendo側でhttp/http/https+spdyをスイッチ
●テスト結果
●httpsよりもspdyは4.5%速い
●httpよりもspdyは3.4%遅い
●ぱっとわかるような違いは出なかった
●httpからhttpsへ切り替えるときに味わう速度低下
●これを帳消しにしてくれるほど速くならなかった
●自分でテストする気になったきっかけ
●出回ってるベンチマークが現実離れした環境でテストしてたから
●︵補足︶
●guyが説明のために使ってる言い回し
●1stパーティコンテンツ、サードパーティコンテンツ
●サイト運営側がコントロールできるコンテンツなのか、どうか
●別サーバー、別ドメインから読み込み、改変等できないコンテンツ、リソース
●ソーシャルプラグイン、とか
●サードバーティコンテンツの典型例
●自分のテストは過去のテストと比べて条件がいくつか違う
●1stパーティコンテンツにのみspdyを有効化
●3rdパーティコンテンツはサイト運営者がspdy化／オフ、とかコントロールできないから
●便宜的に1stパーティコンテンツが複数のドメイン／サブドメインに分散してるのを1ホストにまとめてる
●サードパーティコンテンツは除外
●過去のベンチマークだとサードパーティコンテンツも静的なコピーを作って1ホストにリソースがまとまっているような状態でテストしてた
●こういうのは自分のテストではやってない
●これは実態と異なる人工的環境でのテスト
●spdyが実戦投入される環境からかけ離れてる
●リバースプロキシを使いクライアントサイドプロキシは使わない
●クライアントサイドプロキシを使うとダメな理由
●クライアント／プロキシ間に余分にリクエスト／レスポンス発生
●リクエスト／レスポンスを多重化できるspdyが活躍できる状況だがよくある状況でない
●架空サイトじゃなく実運用されてるサイトをテスト
●パフォーマンスの最適化ができてる部分、全然な部分とか本当それぞれ
●そのままテスト
●ページ読込の最適化が全然であっても、そのままに
●バックエンドが不効率であっも、そのままに
●巷でみかけるspdyベンチマークの対象サイトは2パターンに収まる
●google傘下のサイト
●高速化のチューニングをきっちり
●動的／静的なコンテンツが複合的に使われてるサイトを、完全静的に作り替えたバージョン
●実運用されてるサイトの数々のボトルネックがテスト前から刈り取られてる
●自分のテストの良し悪しを判断できないという形にはなってないと思う
●巷でみかけるテスト結果と自分のテスト結果は結構違う
●でも、これだけ違う理由を十分に理解してもらえるはず
●多くのウェブサイトにとってspdyが救世主にならない理由は色々
●大きな理由は2つ
●理由1。webページのリソースが複数ドメインに分散
●リクエストの多重化は﹁原則﹂ドメインごとにしかできない
●﹁コネクション数激減﹂というspdyの最大の長所が削がれる
●﹁ドメインごとに多重化﹂には例外あり
●SPDY and IP pooling
●︵補足︶
●サブドメインだけ違う複数ドメインでIP同じとき
●ex. a.foo.com、b.foo.com、c.foo.com、etc.
●同じTCPコネクション内で処理
●SSL証明書も共有する
●実験的仕組みとしてchromeのdev channelのみ投入してる、らしい
●理由2。spdyでは解決できないwebページのボトルネックが複数ある
●jsが他のリソースの読み込みをブロックしてしまう場面。spdyにできること無い
●cssがページレンダリングをブロックしてしまう場面。spdyに出来る事は無い
●spdyはhttpよりも良い技術。
●たいていの遅いページのボトルネックはhttpじゃない
テスト詳細
●spdy対応ブラウザ、spdy対応リバースプロキシが自分のテストには必要
●アメリカのトップ500サイトをAlexaから抽出
●トップ500にはアダルトサイトもあるが﹁これが現実の姿﹂ってことでこのままテスト
●Contendo CDNをリバースプロキシとして使った
●最近Akamaiが買収
●spdy対応した商用サーバとしては古株
●http、httpsのみ、https+spdy。この3パターンでテスト
●クライアント側のchromeはWebPagetest上で動かした
●WebPagetest - Website Performance and Optimization Test
●Patrick Meenanに助けてもらった
●WebPagetestを使うとchromeでのテストを自動化できる
●テスト時点ではchrome18
●実はchromeは実行時間の5%はランダムにspdyを無効化してる
●WebPagetestはテスト結果から無効中のデータを自動的に除外してくれる
●WebPagetestではテストするネットワークの速度選べる
●Cable/DSL/遅いモバイル／速めのモバイルの4環境でそれぞれ5回テストした
●テストしたwebサイトの1stパーティのリソースが1ドメインだけにある場合と複数ドメインに分散する場合があった
●別ドメインのリソースを同一ドメインにあるかのように配信できる機能がある。これを活用
●ネットワークの一時的な変化がテスト結果にバイアスを与える可能性を考慮
●テストを昼間2回、夜中1回の計3回実施
●累計9万ページロードした
●http/https/http+spdyそれぞれ3万ページロード
●統計的な正確さに必要な回数よりも多くテストした
テスト結果
- spdyはwebページを速くしてくれなかった
- テスト結果のデータは同じ結論を示した
- 数値は多少変わるかも。そこは重要じゃない
- 速い／遅いが数%レベルに留まってるのがポイント
| ネットワーク速度 | SPDY vs HTTPS | SPDY vs HTTP |
| Cable | SPDY 6.7% faster | SPDY 4.3% slower |
| DSL | SPDY 4.4% faster | SPDY 0.7% slower |
| モバイル（低レイテンシ） | SPDY 3% faster | SPDY 3.4% slower |
| モバイル（高レイテンシ） | SPDY 3.7% faster | SPDY 4.8% slower |
●Cable
●down5,000Kbps、up1,000Kbps, レイテンシ28ms
●DSL
●down1,500Kbps、up384Kbps, レイテンシ50ms
●モバイル︵低レイテンシ︶
●down780Kbps、up330Kbps, レイテンシ50ms
●モバイル︵高レイテンシ︶
●down780Kbps、up330Kbps, レイテンシ200ms
spdyは良い技術なのに、なんで速くならない？
●一言で言えば、実際のボトルネックを解決しないから。
●使ってるドメイン多過ぎ
●spdyによる高速化はドメイン単位に分割される
●仮にページが読み込むリソースがそれぞれ別ドメインにあったら、spdy化は益無し
●ページのリソースが多くのドメインに分散してるwebサイトは最近増えた
●サードパーティドメインのリソースである場合が多い
●spdyが力を発揮できない
●ページが使ってるドメインの数
●自分のテストしたデータだと、平均18ドメイン／page
●そのうち半分以上のリソースが、htmlファイルがあるドメインとは別のドメインにある
●9ドメインで1度リクエスト出すだけのために専用のコネクション作ってる
●4ドメインで2回リソースを転送するだけのために専用コネクション作ってる
●この13ドメインではspdy使うメリットが当然見えない
●18ドメインでspdy有効化されても結果変わらなない
●spdyは接続ドメインの数を減らせない
●平均コネクション数をページ単位で比較
●httpsで、平均6.2コネクション
●spdy︵+https)で、平均2.6コネクション
●効果ありといえる数字出た、かにみえる
●各ドメイン単位でのコネクション平均を比較
●httpsで、平均34.9コネクション
●spdy︵+https)で、平均30.5コネクション
●︵補足︶算出方法よくわからない
●リソース読込のブロック頻発してる
●ページ読込時に起こること
●js/cssがロードされ処理されてる間は画像の読み込みはブロックされる
●ページ読込時に発生する処理のブロックはspdy化しても変わらない
自分がやったテストから活かせそうなこと
●webサイト運営者
●﹁spdyの御利益﹂の理解を訂正すべき
●spdy化から得られるメリットをMaxにしたい？
●ならば、ページが読み込むリソース群が使ってるドメイン数を最小化しろ
●フロントエンド側でのボトルネックを潰しておく
●実施して無駄になることはない
●ブラウザベンダー、spdyコミュニティの住人
●複数ドメインにリソース分散してるとspdyの効力が骨抜きになる現状を解決するべき
●chromeでは実験的取組み
●IPと証明書が同じだったら複数ホスト間でtcpコネクションを共通にする仕組み入れてる
●ブラウザにおけるリソース読込みを洗練化させる
●リソースの先読みテクニックの洗練化、とか
●トラフィックの混雑を回避しながらリソースに優先順位をつけて読込する、とか
●spdy導入の相性の悪さを改善してく
●アイディアとしては既に知られてるものばかりだが、積極的に取り組みされてない
●spdyは自分も注目してる技術だし、あるべき発展の途上にある技術
●spdy使うは時間の無駄といいたいわけじゃない
●spdyには改良の余地、高速化の余地がある
コメント欄
●Q‥spdy+tlsのテストになってて、spdy単体のテストになってないのはダメでは？
●A‥
●実質的にはspdyにはhttpsが必要
●spdyはtlsの高速化に貢献するという見方が成り立つ
●spdyのプロトコル自体はsslを要求しない。これは正しい
●現実の環境ではtls抜きだとspdyリクエストを通すゲートウェイもミドルウェアは1つもない
●テスト環境では、Cotendo(CDN︶とウェブサイト間はhttp接続
●ウェブサイトへのアクセスにhttsは要求されてないから
●googleがspdyについて出してる数字を疑ってるわけじゃない
●現実世界ではgoogleの出してる数字通りにいかないことをテストして示した
●サードパーティのリソース使うのを止めるのはspdyの有無に関係なく高速化にとって重要
●サイトが現状のネットワーク環境に最適化していくとは考えてない
●spdyやhttp2.0が実運用されてるウェブサイトに最適化していくと考えてる
●Q‥by Steve Souders
●テスト結果について異論無し。指摘しておきたいこと数点
●トップ100のサイトはページ速度の最適化についても下位サイトよりも徹底してる
●比較のためにHTTP Archiveを参照する
●上位100サイトのPage Speedスコア平均は90ポイント
●これが上位1000サイトだと、83ポイントにダウン
●さらに上位20万サイトだと、74ポイントまでダウン
●傾向として、高速化のための実装をあまりやってないサイトの方が、SPDYの恩恵を受けやすい
●500以下のサイトで同じテストやった方がSPDYの効果は大きくなるはず
●Guyのテスト対象は上位500サイトだけだったから、テスト対象を色々変えてテストしたらより有意義な結果でるはず
●複数のドメインにリソース分散してるサイトはSPDYと相性悪いのは確か
●domain shardingを使うことを高速化のためのtipsとしてここ3年間提唱してきた
●SPDYが使われてない環境ではdomain shardingは結構普及した。特に上位サイトでその傾向高い
●上位50位サイトのうち25サイトでdomain sharding使ってる
●domain shardingが登場する前からspdyがあれば、このテクニックは普及しなかったと思う
●ちなみに上位サイトピックアップには、HTTP Archive使ってる
●A‥
●上位サイトでもサイトが遅くなるような設計してる
●レンダリングなど他の処理をブロックするスクリプト読み込み
●重くなるのが目に見えるjavascriptの書き方
●キャッシュを活用するとか考えてられない
●サイトが遅いことに何ら手を打ってないサイトにおいてhttpはボトルネックになってない
●domain shardingとSPDYの相性の悪さは解決可能
●今のspdyのスペックではホスト別になってる
●リクエスト／レスポンスの多重化があくまでホスト別になってる。ここにテコ入れ
●1つのコネクションで複数ホストのリクエスト／レスポンスを捌けるようにする
●Q‥by Matt Welsh @google
●モバイルネットワークの検証で実機使ってなくない？
●googleのモバイルウェブパフォーマンスチームがspdy化すると23%高速化できたと前にリポートした
●ここでは実機使ってテストしてる
●ただし、ページのリソースが複数ドメイン／ホストにまたがってるサイトはテストしてない
●今後テストしたい
●プロキシーもforward proxyでテストした
●A‥
●実機使ってない、EC2上のデスクトップ版chromeでテスト
●手軽にモバイル環境をエミューレートできると思ったから
●モバイル環境は高速化に関してデスクトップ環境とは異なる条件がたくさんある
●実機使って同じテストを今後やりたい
●AkamaiファミリーのMobitestをパワーアップしたらできるかも
●forward proxy使った環境でspdyのテストをすること自体には価値がある
●プロトコルとしての評価には有益
●サードパーティーのドメインのリソースをページに使うこと自体はどんどん悪い方へ向かってる
●現状をspdyやブラウザがどう振る舞って行くのかを注視したほうがいい
●現時点の環境のもとでspdyを使うときのベストプラクティスを広めてく活動が必要
●Q‥追試したいけどCotendo CDNは無料？
●A‥Cotendoのサポートに連絡してくれ。
●Q‥
●テストを実施したタイムゾーンは？
●Cotendo CDNサーバーから離れた場所との通信は試した？
●A‥
●EC2サーバは東海岸のリージョン
●Cotendoの CDNサーバはNew York
●これ以外のパターンは試してない
●Q‥Cotendo〜オリジナルサーバ間のレイテンシをどうやって割引いてベンチマーク結果だしてる？
●A‥
●http,https,spdyの3つとも全てのテストはCotendoを経由
●テスト結果に影響出てる
●通常介在しないプロキシがある分、余分な通信時間発生してるという意味では
●ただし全てのテストで同じように影響出るので、比較には困らない
●Q‥Cotendo〜オリジナルサーバ間
●この区間でどうやってspdy接続をエミュレートしてる？
●Cotendoサーバに全てキャッシュして、Cotendo〜オリジナルサーバ間の通信は省いたテストの方が正確では？
●A‥
●クライアントからのspdyリクエストが出るとCotendo CDNはたくさんコネクションを開いてオリジナルサーバへリクエスト投げる
●通常のhttp通信で発生するリクエストの処理待ちが出ないようにエミュレートしてる
●Cotendoのコネクションのやり方は、webの屋台骨で使われてるやり方と同じ。だからとても早い
●キャッシュするやり方は別の検証方法として面白いかも。ただ別のバイアスが生まれるかも
●︵補足︶
●リクエスト／レスポンスの多重化のエミュレートはわかったが、ヘッダ圧縮をどうエミュレートしてるのかわからん
●Q‥
●テスト結果が遅いのは当たり前では
●cdnからウェブサイトへの接続がhttpになってたら意味ないんでは？
●cdn経由のレイテンシを差っ引いたとしても、多くのhttp接続を確立・破棄するコストがあるし
●A‥
●ブラウザがhttp通信で困る部分は、CDNのhttp通信には当てはまらないことが多い
●CDNはブラウザよりも遥かに多くのコネクションを張れるし、貼りっ放しにもできる
●CDNはウェブサイトへのリクエストの多重化を多くのコネクションを確立することで実現してる
●CDNを経由することことに由来するレイテンシはもちろん発生する
●spdyはブラウザ〜サーバ間通信の﹁ゴール直前﹂部分︵ブラウザとCDNの間︶で起こる問題を解決するために設計されてる
●多くのウェブサイトにおいて、spdyはそのウェブサイトが使ってるCDNで実装されるのが王道
●ここではCDNはウェブサイトのフロントエンドサーバだから
●自分が行ったテスト︵ブラウザ〜ウェブサイトの間にspdy対応したCDNを置いてテスト︶は現実的な環境を想定してる
●ウェブサイトのオーナーが実際にspdyを導入するときに使うシナリオ︵フロントエンドサーバでspdy実装︶に忠実
●パフォーマンスのテストは難物
●spdyが実戦投入される一番リアルなシナリオにそったテストだと思う
●一覧リアルなシナリオでのテストを今回実施して、分かったことをシェアしておこうと思った
●Q‥byCatchpointの共同創業者
●あとでかく
●A‥
●あとでかく
●一言で言えば、実際のボトルネックを解決しないから。
●使ってるドメイン多過ぎ
●spdyによる高速化はドメイン単位に分割される
●仮にページが読み込むリソースがそれぞれ別ドメインにあったら、spdy化は益無し
●ページのリソースが多くのドメインに分散してるwebサイトは最近増えた
●サードパーティドメインのリソースである場合が多い
●spdyが力を発揮できない
●ページが使ってるドメインの数
●自分のテストしたデータだと、平均18ドメイン／page
●そのうち半分以上のリソースが、htmlファイルがあるドメインとは別のドメインにある
●9ドメインで1度リクエスト出すだけのために専用のコネクション作ってる
●4ドメインで2回リソースを転送するだけのために専用コネクション作ってる
●この13ドメインではspdy使うメリットが当然見えない
●18ドメインでspdy有効化されても結果変わらなない
●spdyは接続ドメインの数を減らせない
●平均コネクション数をページ単位で比較
●httpsで、平均6.2コネクション
●spdy︵+https)で、平均2.6コネクション
●効果ありといえる数字出た、かにみえる
●各ドメイン単位でのコネクション平均を比較
●httpsで、平均34.9コネクション
●spdy︵+https)で、平均30.5コネクション
●︵補足︶算出方法よくわからない
●リソース読込のブロック頻発してる
●ページ読込時に起こること
●js/cssがロードされ処理されてる間は画像の読み込みはブロックされる
●ページ読込時に発生する処理のブロックはspdy化しても変わらない
自分がやったテストから活かせそうなこと
●webサイト運営者
●﹁spdyの御利益﹂の理解を訂正すべき
●spdy化から得られるメリットをMaxにしたい？
●ならば、ページが読み込むリソース群が使ってるドメイン数を最小化しろ
●フロントエンド側でのボトルネックを潰しておく
●実施して無駄になることはない
●ブラウザベンダー、spdyコミュニティの住人
●複数ドメインにリソース分散してるとspdyの効力が骨抜きになる現状を解決するべき
●chromeでは実験的取組み
●IPと証明書が同じだったら複数ホスト間でtcpコネクションを共通にする仕組み入れてる
●ブラウザにおけるリソース読込みを洗練化させる
●リソースの先読みテクニックの洗練化、とか
●トラフィックの混雑を回避しながらリソースに優先順位をつけて読込する、とか
●spdy導入の相性の悪さを改善してく
●アイディアとしては既に知られてるものばかりだが、積極的に取り組みされてない
●spdyは自分も注目してる技術だし、あるべき発展の途上にある技術
●spdy使うは時間の無駄といいたいわけじゃない
●spdyには改良の余地、高速化の余地がある
コメント欄
●Q‥spdy+tlsのテストになってて、spdy単体のテストになってないのはダメでは？
●A‥
●実質的にはspdyにはhttpsが必要
●spdyはtlsの高速化に貢献するという見方が成り立つ
●spdyのプロトコル自体はsslを要求しない。これは正しい
●現実の環境ではtls抜きだとspdyリクエストを通すゲートウェイもミドルウェアは1つもない
●テスト環境では、Cotendo(CDN︶とウェブサイト間はhttp接続
●ウェブサイトへのアクセスにhttsは要求されてないから
●googleがspdyについて出してる数字を疑ってるわけじゃない
●現実世界ではgoogleの出してる数字通りにいかないことをテストして示した
●サードパーティのリソース使うのを止めるのはspdyの有無に関係なく高速化にとって重要
●サイトが現状のネットワーク環境に最適化していくとは考えてない
●spdyやhttp2.0が実運用されてるウェブサイトに最適化していくと考えてる
●Q‥by Steve Souders
●テスト結果について異論無し。指摘しておきたいこと数点
●トップ100のサイトはページ速度の最適化についても下位サイトよりも徹底してる
●比較のためにHTTP Archiveを参照する
●上位100サイトのPage Speedスコア平均は90ポイント
●これが上位1000サイトだと、83ポイントにダウン
●さらに上位20万サイトだと、74ポイントまでダウン
●傾向として、高速化のための実装をあまりやってないサイトの方が、SPDYの恩恵を受けやすい
●500以下のサイトで同じテストやった方がSPDYの効果は大きくなるはず
●Guyのテスト対象は上位500サイトだけだったから、テスト対象を色々変えてテストしたらより有意義な結果でるはず
●複数のドメインにリソース分散してるサイトはSPDYと相性悪いのは確か
●domain shardingを使うことを高速化のためのtipsとしてここ3年間提唱してきた
●SPDYが使われてない環境ではdomain shardingは結構普及した。特に上位サイトでその傾向高い
●上位50位サイトのうち25サイトでdomain sharding使ってる
●domain shardingが登場する前からspdyがあれば、このテクニックは普及しなかったと思う
●ちなみに上位サイトピックアップには、HTTP Archive使ってる
●A‥
●上位サイトでもサイトが遅くなるような設計してる
●レンダリングなど他の処理をブロックするスクリプト読み込み
●重くなるのが目に見えるjavascriptの書き方
●キャッシュを活用するとか考えてられない
●サイトが遅いことに何ら手を打ってないサイトにおいてhttpはボトルネックになってない
●domain shardingとSPDYの相性の悪さは解決可能
●今のspdyのスペックではホスト別になってる
●リクエスト／レスポンスの多重化があくまでホスト別になってる。ここにテコ入れ
●1つのコネクションで複数ホストのリクエスト／レスポンスを捌けるようにする
●Q‥by Matt Welsh @google
●モバイルネットワークの検証で実機使ってなくない？
●googleのモバイルウェブパフォーマンスチームがspdy化すると23%高速化できたと前にリポートした
●ここでは実機使ってテストしてる
●ただし、ページのリソースが複数ドメイン／ホストにまたがってるサイトはテストしてない
●今後テストしたい
●プロキシーもforward proxyでテストした
●A‥
●実機使ってない、EC2上のデスクトップ版chromeでテスト
●手軽にモバイル環境をエミューレートできると思ったから
●モバイル環境は高速化に関してデスクトップ環境とは異なる条件がたくさんある
●実機使って同じテストを今後やりたい
●AkamaiファミリーのMobitestをパワーアップしたらできるかも
●forward proxy使った環境でspdyのテストをすること自体には価値がある
●プロトコルとしての評価には有益
●サードパーティーのドメインのリソースをページに使うこと自体はどんどん悪い方へ向かってる
●現状をspdyやブラウザがどう振る舞って行くのかを注視したほうがいい
●現時点の環境のもとでspdyを使うときのベストプラクティスを広めてく活動が必要
●Q‥追試したいけどCotendo CDNは無料？
●A‥Cotendoのサポートに連絡してくれ。
●Q‥
●テストを実施したタイムゾーンは？
●Cotendo CDNサーバーから離れた場所との通信は試した？
●A‥
●EC2サーバは東海岸のリージョン
●Cotendoの CDNサーバはNew York
●これ以外のパターンは試してない
●Q‥Cotendo〜オリジナルサーバ間のレイテンシをどうやって割引いてベンチマーク結果だしてる？
●A‥
●http,https,spdyの3つとも全てのテストはCotendoを経由
●テスト結果に影響出てる
●通常介在しないプロキシがある分、余分な通信時間発生してるという意味では
●ただし全てのテストで同じように影響出るので、比較には困らない
●Q‥Cotendo〜オリジナルサーバ間
●この区間でどうやってspdy接続をエミュレートしてる？
●Cotendoサーバに全てキャッシュして、Cotendo〜オリジナルサーバ間の通信は省いたテストの方が正確では？
●A‥
●クライアントからのspdyリクエストが出るとCotendo CDNはたくさんコネクションを開いてオリジナルサーバへリクエスト投げる
●通常のhttp通信で発生するリクエストの処理待ちが出ないようにエミュレートしてる
●Cotendoのコネクションのやり方は、webの屋台骨で使われてるやり方と同じ。だからとても早い
●キャッシュするやり方は別の検証方法として面白いかも。ただ別のバイアスが生まれるかも
●︵補足︶
●リクエスト／レスポンスの多重化のエミュレートはわかったが、ヘッダ圧縮をどうエミュレートしてるのかわからん
●Q‥
●テスト結果が遅いのは当たり前では
●cdnからウェブサイトへの接続がhttpになってたら意味ないんでは？
●cdn経由のレイテンシを差っ引いたとしても、多くのhttp接続を確立・破棄するコストがあるし
●A‥
●ブラウザがhttp通信で困る部分は、CDNのhttp通信には当てはまらないことが多い
●CDNはブラウザよりも遥かに多くのコネクションを張れるし、貼りっ放しにもできる
●CDNはウェブサイトへのリクエストの多重化を多くのコネクションを確立することで実現してる
●CDNを経由することことに由来するレイテンシはもちろん発生する
●spdyはブラウザ〜サーバ間通信の﹁ゴール直前﹂部分︵ブラウザとCDNの間︶で起こる問題を解決するために設計されてる
●多くのウェブサイトにおいて、spdyはそのウェブサイトが使ってるCDNで実装されるのが王道
●ここではCDNはウェブサイトのフロントエンドサーバだから
●自分が行ったテスト︵ブラウザ〜ウェブサイトの間にspdy対応したCDNを置いてテスト︶は現実的な環境を想定してる
●ウェブサイトのオーナーが実際にspdyを導入するときに使うシナリオ︵フロントエンドサーバでspdy実装︶に忠実
●パフォーマンスのテストは難物
●spdyが実戦投入される一番リアルなシナリオにそったテストだと思う
●一覧リアルなシナリオでのテストを今回実施して、分かったことをシェアしておこうと思った
●Q‥byCatchpointの共同創業者
●あとでかく
●A‥
●あとでかく
