Rails 3.1 将支持 HTTP 流技术

Rails 3.1 将支持 HTTP 流技术 - 开源中国社区

Rails 3.1 将支持 HTTP 流技术





2人收藏此新闻,



我要收藏
| 新闻投递

红薯
发布于： 2011年04月19日 (4评)

Rails 项目称 Rails 3.1 将会支持 HTTP Streaming ，也叫做 chunked 响应。fxn 发布了一个博客详细描述了该特性。

在解释流技术带来的好处时，博客写道：

    Streaming 并不是为了取代现有的技术，它也不会减少页面生成的时间。但通过使用这项技术，可让页面多个元素并行加载，从而提升了页面在浏览器上的加载速度。

更多关于Rails的详细信息，或者下载地址请点这里

Riding Rails: Why HTTP Streaming?

Why HTTP Streaming?

Posted by fxn April 18, 2011 @ 03:23 PM

Rails 3.1 is going to support HTTP streaming, aka chunked responses, this post explains what's all about.

What Is HTTP Streaming?

Ordinary dynamic HTTP responses need a Content-Length header. Their timeline look like this:

HTTP request -> dynamic content generation -> HTTP response

Those are three serial steps because normally you need to generate the content in order to be able to know its size, and thus fill the Content-Length header of the response.

HTTP provides an alternative to this schema to be able to flush data as it is produced, known as chunked transfer encoding. That's what we are referring to as streaming in recent commits.

Streamed responses have no Content-Length header. Rather, they have a Transfer-Encoding header with a value of "chunked", and a body consisting of a series of chunks you write to the socket preceded by their individual sizes. Modulus details.

This is an example taken from 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

Point is, you are able to flush chunks to the socket as soon as you have them, no need to wait for the whole thing to be generated.

When Do Web Browsers Fetch Assets?

Web broswers parse documents as their content is received. When they find an asset referenced, think an image, stylesheet, or script, a request to fetch them is fired. That happens in parallel while the document is being received and processed, no matter whether the content comes chunked or not.

Browsers have limits on the number of concurrent requests they are allowed to do, a global one (typically +30), and another per domain (nowadays typically 4 or 6), but within those limits, requests for getting assets happen as the content is parsed.

Modern clients do not even block on JavaScript files as old ones did, they implement scanners that look ahead for asset nodes and request them. For example, this is the preload scanner of WebKit.

Trivia: While investigating this I discovered by accident that if the MIME type is unclear, for example "text/html" without an explicit charset, then web browsers buffer 1 KB of data firing no asset requests to be able to peek at the content and do an educated guess.

So What's The Benefit Of Streaming?

Streaming doesn't cut latency, neither it cuts the time a dynamic response needs to be generated. But since the application sends content right away instead of waiting for the whole response to be rendered, the client is able to request assets sooner. In particular, if you flush the head of an HTML document CSS and JavaScript files are going to be fetched in parallel, while the server works on generating content. The consequence is that pages load faster.

Followup

Streaming is still being polished for Rails 3.1, expect another post in the future covering its practical aspects in Ruby on Rails applications.

Thanks

Tony Gentilcore provided his insider's guidance into this, thank you very much Tony! Also, thanks a lot to the Browserscope project for their really useful tables.