Web服务器 - 何时应该使用分块传输编码？ [英] Web server - when should I use chunked transfer encoding?
问题描述
查看各种Web服务器HTTP头，我注意到Google.com有：
客户端传输编码： chunked
什么是chuncked传输编码，我应该在我的网络服务器上使用？
分块可用于发送多个部分的HTTP请求或响应，并发送一部分，而后续部分不可用。 p>
多个请求 - 响应对可以通过单个HTTP连接传输。 （这是为了避免后续请求的TCP connect（）的开销。）为了实现这一点，客户端需要知道服务器响应结束的位置。如果服务器生成 Content-Length 头，客户端可以倒数字节。当没有可读字节时，客户端可以启动下一个请求。但如果事先不知道完整响应的长度，服务器将如何生成 Content-Length 头文件？解决方案是使用 chunked 而不是 Content-Length 。
Apache（1.3和2），默认只要它有意义（并且HTTP客户端支持），就会发送静态文件为 chunked 。你不必采取任何行动。如果您编写自己的Web应用程序，您可能会考虑手动生成分块响应。
请参阅 http://www.research.att.com/~bala/papers/h0vh1.html 和 http://developers.sun.com/mobility/midp/questions/chunking/ 多一点。
Looking at various web servers HTTP Headers, I notice that Google.com has:
client-transfer-encoding: "chunked"
What is chuncked transfer encoding and should I be using it on my web server?
Chunked can be used to send a HTTP request or response in multiple parts, and send one part while subsequent parts are not available.
Multiple request--response pairs can be transferred over a single HTTP connection. (This is to avoid the overhead of the TCP connect() for subsequent requests.) To implement this, the client needs to know where the server response ends. If the server generates the Content-Length header, the client can count down the bytes. When there are no bytes left to read, the client can initiate the next request. But how would the server generate the Content-Length header if it doesn't know the length of the full response in advance? The solution is to use chunked instead of Content-Length.
Apache (1.3 and 2), by default, sends static files as chunked whenever it makes sense (and the HTTP client supports it). You don't have to take any action. If you write your own web application, you might consider generating a chunked response by hand.
See http://www.research.att.com/~bala/papers/h0vh1.html and http://developers.sun.com/mobility/midp/questions/chunking/ for a little more.
这篇关于Web服务器 - 何时应该使用分块传输编码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
