Lejayの日記

2009-11-13

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プロトタイプ公開

 ・Chromehttp://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"で,これからさらなる性能査定や評価が必要.

2008-12-10

EZWebのCookieはサーバに保存される(但しSSL以外)

今日,携帯電話リファラCookieについて調べてて,たまたま知った.

EZweb対応端末においてCookieは、EZサーバに保管されます。

※ ただし、WAP2.0ブラウザ搭載端末ではEnd to EndのSSL通信時は端末に保管されます。

なお、EZサーバに保管されたCookieKDDI設備のメンテナンスなどによりリセットされる場合があります。

via KDDI au:そのほかの技術情報 > Cookie

なるほどな.

こんなことしてるのか.