SPDYについて: 適当なメモ

・Googleの提案するアプリケーション層プロトコル
・HTTPのオーバーライド

[ 目的 ]
・Web上の通信の最適化
　・Webコンテンツの読み込みを高速化(レイテンシの短縮)
[ 目標 ]
・読み込み時間50%削減
・低い導入コスト
　・TCPを利用するため，既存ネットワークを変更する必要がない
・Webサイト管理者に対して負担をかけない
　・SPDYは，Webサーバとブラウザの実装だけなので，CGIなどには影響を与えない
・オープンソースで開発

[ 技術的目標 ]
・TCPの1セッションで，複数のHTTPリクエストを同時に受け付ける
・HTTPの利用帯域を削減
・実装の容易なプロトコルを提案
・SSLを利用
・サーバからクライアントへのプッシュ機能

・1つのTCPコネクション上で複数の同時SSL接続
・HTTPのGETやPOSTに代わるデータ転送方法
・双方向通信

[ 特徴 ]
・多重化ストリーム(Multiplexed streams)
　・無制限の同時ストリーム
・リクエスト・プライオリタイゼーション(優先順位付け)(Request prioritization)
　・混線時に対応
・HTTPヘッダ圧縮(HTTP header compression)
・サーバプッシュ
　・クライアントからのリクエストを利用せずに，サーバからクライアントへデータを配信
　・X-Associated-Content header
・サーバヒント
　・クライアントがロードするであろうデータをサーバからクライアントに提案
　・但し，サーバからクライアントへのデータ送信は，クライアントからの要求を待機
　・X-Subresources header

・セッションレイヤーをSSL上に追加
・単一のTCP接続で複数の相互データストリームを並列処理
・GETとPOST意外に，新たなデータエンコード及び送信フォーマットを提案

[ HTTPとの差違 ]
・SPDYは，HTTPのアプリケーションレイヤとTCPトランスポートにまたがる感じ
・http://がspdy://になるわけではない

[ HTTPの欠点 ]
・1コネクション x 1リクエスト
　・HTTP pipeliningを使えば大丈夫だが，それでもFIFOしか扱えない
　・殆どのブラウザのドメイン毎の同時接続数が，2から6へと変更された(2008年)
・サーバ側でクライアントの状況を確認する手段がない
・リクエストやレスポンスヘッダーが圧縮されていない
・ヘッダーが冗長すぎる
　・1回のセッションにも関わらず，同一のヘッダーを複数回要求する可能性がある
　・User-Agent,Hostなどは，リクエスト毎に変更されることはない
・圧縮データは，HTTPのエンコードを利用しないといけない

[ 関連研究 ]
トランスポート層やセッション層で，HTTPを高速化する研究
・Stream Control Transmission Protocol (SCTP)
・HTTP over SCTP
・Structured Stream Transport (SST)
・MUX and SMUX

[ 現状 ]
・SPDYに対応したChrome,Webサーバのプロトタイプを開発
・上記のChromeのプロトタイプ公開
　・Chrome：http://src.chromium.org/viewvc/chrome/trunk/src/net/flip/
・一般の家庭用回線を用いた実験では，人気の上位25サイトからのダウンロードが最大55%高速化
　・SSLを利用しないTCPでは，27-60%短縮
　・SSLを利用したTCPでは，39-55%短縮
　・headerの圧縮による成果
　　・headerは，最大88%削減
　　・response headerは，最大85%
　　・headerの圧縮だけで，375Kbpsの環境でupload時間が45 - 1142ms短縮

・研究所内のテストでは，ページロード時間を64%短縮
・SPDYは，Web高速化プロジェクト(http://code.google.com/speed/)の一環

[ 今後 ]
・SPDYに対応したWebサーバやテストツールを近日公開
・コミュニティに公開してフィードバックを取得
・研究所ではなく，一般の状況(回線)で実験が必要
・"an early-stage research project"で，これからさらなる性能査定や評価が必要．