Jettyはバージョン7.6.2のリリースで、SPDY™プロトコルをサポートした。当初はバージョン8.2向けに実装されていたが、7.6.2と8.1.2に後方移植された。また、JettyとHightideアプリケーションサーバの今後のバージョンでもサポートされる予定だ。
SPDY™は次世代のHTTP接続向けトランスポートレイヤであり、デフォルトではGoogle Chromeで利用できる。また、Firefox 11ではコンフィグを設定すると有効になる。まだ標準化されていないが、IETFへhttpbisワーキンググループのドラフトとして提案されている。多くのGoogleのサービスはSPDY経由で利用できる。また、一般的なウェブサイトにもSPDYをサポートしているサイト(such as WebtideやTwitterなど)がある。
SPDY™はTLSの仕様の強化案であるNext Protocol Negotiation経由で提供されるTLS上で動作する。従って、SPDY™暗黙にセキュアなプロトコルになる。また、中間者による調査を受け付けない443ポートを使うHTTPプロキシは透過的にSPDY™をサポートする。SPDY™の利点を確かめるため、InfoQはJettyプロジェクトのGreg Wilkins氏とSimone Bordet氏に話を聞いた。
Greg Wikins: SPDYはいくつかの特徴によって性能を改善します。ます、多重送信コネクションを使うので、コネクション作成による遅延が低減します。また、HTTPヘッダを圧縮するので各リクエスト/レスポンスで数百バイト削減できます。多くのページは描画するのに10や20のリクエストが必要ですので、この圧縮だけでも大幅にオーバヘッドを削減できます。さらに、必要なコネクションの数を減らすことで、ひとつのクライアント当たりに必要なサーバのリソースが減り、必要なメモリやCPUも少なくなります。
しかし、良い面ばかりではないことは指摘しておく必要があります。SPDYを使う場合、サーバはTLSと圧縮を使わなければなりません。従ってこの2つの処理のためにCPU/メモリが使われます。しかし、この余計なCPU利用が問題になるなら、SPDY専用のリソースに簡単にオフロードできます。
Simone Bordet: 多重送信にはリソース負荷の点でもメリットがあります。典型的なウェブページは10から30の二次的なリソースを含んでいます。これらのリソースはサーバから取り出す必要があります。現在、ブラウザが並列で実行できるリクエストは6つです。しかし、SPDYにはこの制限はありません。ブラウザは必要に応じて多重化された"ストリーム"を開けます。それによって、ページの読み込みが高速になり、HTTPパイプラインも必要なくなります。加えて、多重化された"ストリーム"には優先順位が付き、例えばファビコンのような重要でないリソースよりもCSSのような重要なリソースが優先されます。これによって、TCPコネクションの使用が改善されるので、TCPの性能が向上します。
6という制限なしに多重化された"ストリーム"を発行できる機能は、実装の細部とは独立した方式でリアルタイムウェブアプリケーション(Cometを利用した)を実現できます。現在のCometを利用したウェブアプリケーションは、ブラウザが4から6のコネクションを使い切らないように制御しなければなりませんが、SPDYでは必要ありません。
InfoQ:SPDYとHTTPのベンチマークを取り、比較しましたか。
Greg Wilkins: Jettyでは実施していません。Googleによれば、ページの読み込みは60%以上改善されたそうです。しかし、彼らはCPU/メモリの使用についてのベンチマークの結果は開示していません。
Jettyの場合、初期の実装は多重化されたHTTP通信を意識して設計してはいないソフトウエアアークテクチャに対処しなければならないため、非効率になる部分もあるだろうと考えています。しかし、私たちは、既にSPDYを意識して再設計したjetty-9の実装を始めています。近々に性能値を計測したいと思っていますし、計測結果を元にjetty-9の改善を続けたいです。
InfoQ: SPDYを使うことでHTTPプロキシのキャッシュにはどのような影響が起きますか。SPDYサーバをキャッシュする計画はありますか。
Greg Wilkins: 大きな影響がありますよ。既存のHTTPプロキシはSPDYのストリームを見ることができません。暗号化されているからです。しかし、SPDYのキャッシュのサポートはとても優れています。プッシュの仕組みやクライアントが必要とするコンテンツを予測する仕組みもあります。プロキシキャッシュはSPDYの挙動を理解し、SSLセッションの一部として動作しなければならないでしょう。
InfoQ: 既存のウェブアプリケーションでJettyのSPDYサポートを利用するにはコードや構成を変更しなければなりませんか。特別な構成が必要なのでしょうか。それともデフォルトの設定で利用できますか。
Greg Wilkins: SPDYはHTTPリクエストを運びます。なので、アプリケーションには変更の必要はありません。リクエストとレスポンスのセマンティクスも変わりません。最終的にはSPDYレイヤ上の直接動作するアプリケーションを作成する必要があるかもしれませんが、アプリケーションにとっては透過的な変更になるはずです。
Simone Bordet: 変更の必要はありません。Javaのウェブアプリケーションは以前と同様にJettyに直接配置でき、ヘッダーの圧縮や多重化された通信などSPDYの恩恵を受けることができます。サーバの構成だけは更新する必要がありますが、この変更も小さなものです。SSLコネクタをSPDYコネクタ(
org.eclipse.jetty.spdy.http.HTTPSPDYServerConnector)に置き換えるだけですから。
InfoQ: クライアント側はどのようにしてSPDYを使えばいいのでしょうか。Jettyの既存のHTTPクライアントクラスで透過的に使えるようになるのでしょうか。
Greg Wilkins: SPDYコネクションはNext Prototocol(NPN)拡張を使って、TLSコネクションを443ポートに接続することで確立されます。サーバがNPN拡張を解釈できるのなら、クライアント側からSPDYコネクションの利用を提案されていることを検知して、それを受け入れることができます。そうでない場合は普通のHTTPコネクションを確立します。
NPN拡張はまだ標準化されていません。また、JVMでもサポートされていません。SimoneがOpen JDKのクラスを拡張してNPNをサポートするようにしてくれました。すぐに標準化されてすべてのJVMでサポートされるようになるといいのですが。
Simone Bordet: まだ、JettyのHttpClientにSPDYを統合していません。しかし、SPDYが利用できるサーバに対してSPDY呼び出しができる専用のSPDYクライアントを提供しています。
また、リクエストを受け取る前にクライアントにリソースをプッシュできるのもSPDYの興味深い特徴です。例えば、静的なHTMLページをダウンロードする場合、サーバがそのページにJSスクリプトやCSSや画像が含まれていることを意識して動作できるでしょう。サーバがページの最初の数行を送り、そして、CSSをプッシュして、さらに数行送り、JSスクリプトをプッシュして、さらに数行送り、画像をプッシュする、という挙動が実現できます。これによって、無駄なラウンドトリップが削減でき、クライアント側のページの描画が高速になります。
サーバがどのようにしてプッシュすべきリソースを検知するかについては議論が続いています。メタデータファイル(例えば、
index.htmlがリクエストされたときにプッシュするべきリソースを含むindex.html.spdyファイル)を使う方法から、サーバ側でリクエストを分析して、ページがリクエストされた時に常にリクエストされる追加リソースをリソース毎のキャッシュに入れるという方法まで、いろいろな方法があります。サーバがプッシュすべきリソースを検知する機能を実装するかどうかはそのサーバ次第です。重要なのはSPDYでは、HTTPでは実現できない、サーバ側での様々な最適化が実現できるということです。ブラウザについて注意する必要があるのは、アドレスバーにURLを入れてページをリクエストしたときも
XMLHttpRequestを使ってリクエストしたときも、ブラウザのSPDYの扱い方はHTTPの扱い方と完全に統合されるということです。
InfoQ: クライアントとサーバは単なるHTTP以外のリクエストも発行できますか。
Greg Wilkins: できます。現時点ではブラウザからは無理ですが、サーバ側ではSPDYに直接アクセスできます。ブラウザが直接、SPDYのセマンティクスを利用できるようになるか、それともHTTPやWebSocketのようにSPDYもそのセマンティクスがアプリケーションレイヤの下に隠れたままになるのかは現時点ではわかりません。
InfoQ: SPDYが一般的に使えるようになるには、Googleのプロジェクトではなく、IETF標準になる必要があります。このプロトコルの現在の状態を説明するRFCはありますか。ないのであれば、いつ頃できるのでしょうか。GoogleがSPDYの商標を所有していることに懸念はありますか。
Greg Wilkins: Googleのこのプロジェクトの扱い方は賞賛に値すると思います。プロジェクトの扱い方については、Googleがその力を乱用していると見られているかもしれません。彼らは人気のブラウザとウェブサービスを持ち、意図的かどうかに関わらず、ウェブに新しいプロプラエタリなプロトコルを押し付けているように見えるのです。一方で、Googleはこのプロジェクトの意図やこのプロトコルの開発についてオープンにしています。2年に渡ってこのプロトコルはGoogleの開発プロジェクトで開発されてきましたが、開発者たちはコミュニティと共に設計や実装に対するフィードバックや貢献を考えています。
GoogleはこのプロトコルをIETFで標準化するつもりであると表明しています。既にドラフトhttp://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00も提出しています。このドラフトはhttpbisワーキンググループで扱われます。どのような予定で標準化が進むのかは私はわかりません。しかし、今まで取られてきは手法はIETFの標準の好みに適合しやすいと思います。
Googleが市場占有力を乱用しているかどうかについては確かに問題にすべきなのかもしれません。しかし、ある程度時間が経ち、IETFの案件になるのであれば、この点については心配しすぎる必要はないと思います。SPDYと分離できないGoogleの提供する"機能"はありません。SPDYが気に入らないのであれば、ブロックして普通のHTTPでウェブサービスを使えばいいのです。速度は少し遅いかもしれませんが。
InfoQ: Jettyは一般的な通信の仕組みとしてWebSocketsをサポートしています。 WebSocketsはフレームの転送にHTTPを使います。SPDYとWebSocketsの違いを教えていただけますか。この2つの技術は今後、関係を持つのでしょうか。
Greg Wilkins: WebSocketsはHTTPと同じように2つの部分として考えられます。通信のセマンティックとそのセマンティックを転送するためのプロトコルです。 WebSocketはブラウザに双方向データグラムを導入し、そのデータグラムをサーバへ送信したり、サーバから受信するためのプロトコルを提供します。既にSPDY上でのWebSocketのベータ実装の実装案があります。
SPDY™はGoogle, Incの登録商標だ。