Googleが新プロトコルSPDYを公開

 Webサイトの表示を高速化する新プロトコルSPDYを発表しました。
 SPDYはWEBサーバーと、ブラウザ間のプロトコルHTTPを改良して高速化します。

 Opera Turboはサーバーサイドでのコンテンツを圧縮してブラウザに送ることによる高速化でした。
   Opera Miniでは、Opera Binary Markup Languageにより、コンテンツそのものを小さくして高速化をするアプローチをとっています。
 日本の携帯電話用ブラウザが使う、CHTML、HDMLなどもHTMLもコンテンツをシンプルにしておくアプローチであり、HTTPには手をつけていません。

 SPDYの高速化は、HTTPにも変更を加える以下のような方法をとっているようです。

1つのTCPセッションの上に、複数のストリームを確立し、並列処理する。
ストリーム確立要求を送信後、ACKを待たずデータ送信を開始する。
HTTPセッションを複数利用して並列処理すると、セッション確立待ちが生じる。多数のHTTPセッションを確立すると、PROXYの能力も問題になるので、1つのHTTP上に複数のストリームを作ることにしたそうです。
HTTPヘッダーの圧縮を行う。
一般的にWEBページを1ページ表示させるのに50から100のサブリクエストが必要であり、ヘッダーのデータ圧縮をすれば、高レスポンスとと帯域圧縮が期待できるとの考えに基づいた改良だそうです。
gzipによるデータ圧縮を行う。

クライアント側が優先的に送って欲しいデータをリクエストできる。
重要でないデータの受信完了を待たなくても良くなると、素早くページを表示できると考えているそうです。
 SPDYの説明ページには、 HTTPとSPDYの違いだけではなく、「データはなるべく小さく分けて送ると、レスポンスが良くなる。まとめて送ると回線仕様効率と利用帯域幅がやや改 善するものの、レスポンスが遅くなる。」といったプロトコル上の効率化だけではなく、使う際の諸注意も書かれています。

 とはいえ、SPDYは、依然としてTCPを使っているので、輻輳時のスロースタートによる速度低下はさけられないし、遅延の大きな回線でのACK遅延による実行帯域低下も避けられません。

 LTEになって遅延が片道5msecになるのは無線区間の話であり、大陸間伝送遅延は厳然と存在しますので、数百msecの遅延が存在する現実は変わりません。

  根本的解決には、UDPを使い、上位で効率的な再送制御を行うことによりパケットロスを補完するようなプロトコルを作る必要があると思います。TCPで汎 用再送制御を行うより、上位層でHTTPに特化した再送制御を行うほうが効率的な再送制御ができのではないでしょうか。

 Opera はOpera Turbo, ChromeはSPDYと、ブラウザ毎に異なる高速化手法が提案されています。2つのブラウザのシェアは合計でも10%に届きません。マイナーなブラウザのためにサーバが対応してくれることは望み薄ですね。

最近のブログ記事

SORACOM,HLR持ちeSIM対応
SORACOMが自前のHLRを持ち、自…
準天頂衛星4機体制に
h2{ font-size:12…
Windows 10 mobile終了
Windows 10 mobileの新機…
カスタム検索

月別 アーカイブ