Riding Rails: Why HTTP Streaming?の意訳です。Rails 3.1 からHTTPストリーミングがサポートされるようになるらしい。
HTTPストリーミングって何？
普通の動的なHTTPレスポンスにはContent-Lengthヘッダが必要。時系列的にはこんな感じ
- HTTPリクエスト
- 動的なコンテンツの生成
- 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を送ると、「サーバがコンテンツを生成するのと並列にcssとjavascriptファイルが取得されるようになる」ということ。結果としてページのロードが早くなる。
