読者です 読者をやめる 読者になる 読者になる

おもしろwebサービス開発日記

Ruby や Rails を中心に、web技術について書いています

Rails 3.1 でサポートされるHTTPストリーミング機能について

rails

Riding Rails: Why HTTP Streaming?の意訳です。Rails 3.1 からHTTPストリーミングがサポートされるようになるらしい。

HTTPストリーミングって何?

普通の動的なHTTPレスポンスにはContent-Lengthヘッダが必要。時系列的にはこんな感じ

  1. HTTPリクエスト
  2. 動的なコンテンツの生成
  3. HTTPレスポンス

これらは三つの連続したステップとなる。普通はコンテンツを生成するとそのサイズを知ることが可能になり、レスポンスヘッダにContent-Lengthを付け加える。

HTTPは上記のやり方の代わりにchunked transfer encodingと呼ばれるストリーミング的なやりかたも提供している。

ストリーミングなレスポンスにはContnt-Lengthヘッダはない。その代わりにTransfer-Encodingヘッダが"chunked"という値で含まれる。レスポンスボディはそれぞれぶつ切りされたデータのサイズの後にぶつ切られたデータが入る。

Wikipedia の例は下記のような感じ

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

25
This is the data in the first chunk

1C
and this is the second one

3
con
8
sequence
0

ポイントは、コンテンツを生成しつつ送信出来るってこと。生成を完了するのを待つ必要がない。

ブラウザが静的ファイルを取得するときはいつ?

ブラウザはコンテンツを受信しつつパースする。画像ファイルとかスタイルシートとかJSとかの静的ファイルへの参照が見つかったとき、それらの取得が始まる。コンテンツの受信とパースと静的ファイルの取得は並列に行われる。ストリーミングかそうでないかとかは関係ない。

ブラウザは同時リクエストの数が制限されている。グローバルな制限(普通は+30)とドメイン毎の制限(今時は4または6)がある。この制限以内で静的ファイルの取得が行われる。

最近のブラウザは古いブラウザがしていたようにjsファイルを読み込み中にブロックしたりしない。静的ファイルをリクエストするためにドキュメントを先読みするスキャナ機能を実装したりもしてる。例:webkit の preload scanner

ストリーミングの利点は何?

ストリーミングは遅延を減らさないし、動的なレスポンスの生成時間もカットしない。でもレスポンスが生成されるのを待たずにすぐ送ることができるし、クライアントは静的ファイルのリクエストをすぐに送ることが出来る。特に重要なのは、もしストリーミングでHTMLのheadを送ると、「サーバがコンテンツを生成するのと並列にcssjavascriptファイルが取得されるようになる」ということ。結果としてページのロードが早くなる。

補足

ストリーミングは今 Rails 3.1 のために実装されてる途中なので、将来的にRailsアプリでの実践的な内容のエントリを書くと思う。