Transfer-Encoding: chunked 的含义

本文通过使用socket连接HTTP服务器并请求包含Transfer-Encoding: chunked的内容来解释这一响应头的实际意义。具体展示了如何通过Java代码发送请求,并解析服务器返回的分块编码数据。
Transfer-Encoding: chunked 的含义


在用firebug查看服务器的请求时,返回的header都有Transfer-Encoding: chunked,在做实际应用时,好像也

没有多大关系。

试试用socket连接http服务器,看看数据是如何传输的。


Socket s = new Socket("172.16.1.123", 80);
InputStream ins = s.getInputStream();
OutputStream os = s.getOutputStream();
os.write("GET /a.jsp HTTP/1.1\r\n".getBytes());
os.write("Host:172.16.1.123\r\n".getBytes());
//必须加host,否则服务器会返回bad request,无论是tomcat还是resin,还是nginx或者apache httpd
os.write("\r\n\r\n".getBytes());//这个也必不可少,http协议规定的
os.flush();
BufferedReader br = new BufferedReader(new InputStreamReader(ins));
String line = null;
line = br.readLine();
while(line != null){
System.out.println(line);
line = br.readLine();
}
ins.close();


用tomcat做服务器,建立一个a.jsp文件

<% out.print("helloworld!");
out.flush();
out.print("123");
out.flush();
%>

输出结果是:
[quote]
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=8A7461DDA53B4C4DD0E89D73219CB5F8; Path=/
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 10 Nov 2010 07:10:05 GMT

b
helloworld!
3
123
0
[/quote]

其中Transfer-Encoding:chunked表示内容长度在后面介绍,b这个16进制数字就表示长度为11,然后是内容

(helloworld!),然后以\r\n结束,如果有下一段,则一个16进制数字表示长度,直到最后一段没有了,才以0

结束。

不过不用担心,在浏览器里会自动解释分析,不会让你看到b,3,0,就算在firebug里也显示的是helloworld!

123。

如果自己解析,就需要注意了。
<think>嗯,我现在需要分析用户的问题,他问的是Transfer-Encoding: chunked响应头的含义。首先,我得回顾之前的引用资料,确保理解正确。根据引用[2],分块传输编码是HTTP/1.1中的一种机制,允许服务器将数据分成多个块发送,而不需要预先知道总大小。同时,用户提到的引用[1]强调,无论连接长短,只要请求包含chunked头,就会触发分块传输。 接下来,我需要确认分块传输的基本结构。引用[2]中提到,每个分块包含十六进制的长度值,后面跟着数据,长度值独占一行,最后以0长度的块结束。比如,数据"Hello"会被分成5\r\nHello\r\n。这时候要考虑是否需要解释这个例子,但用户可能更关注含义而非具体格式。 另外,用户引用[4]提到重复头部的错误,这可能涉及实际应用中的问题,比如服务器错误地发送了多个Transfer-Encoding头部,导致错误。虽然用户的问题是关于含义,但可能需要稍微提及使用时的注意事项,但根据问题,重点是含义,所以可能不需要深入错误处理部分。 用户引用[3]是关于Go语言的实现,但用户的问题集中在含义上,所以这部分可能不需要涉及,除非用户在后续问题中询问实现细节。因此,当前回答应集中在分块传输的工作原理和优势上。 需要强调分块传输的应用场景,比如动态内容生成,服务器在生成内容前无法确定总大小,这时候分块传输就很有用。引用[2]指出,分块传输允许数据分成多个部分发送,无需预先知道总大小,这点是关键。 还要注意分块传输和持久连接的关系。引用[1]特别提到,分块机制与连接的长短无关,无论是短连接还是长连接,只要设置了chunked头就会生效。这可能纠正一些误解,以为分块只用于长连接,所以需要明确说明这一点。 此外,分块传输的结束标志是0\r\n\r\n,即最后一个块的长度为0,后面跟着空行,这在引用[2]中有说明。需要确保用户理解分块如何终止传输。 最后,总结分块传输的好处:优化性能,特别是在处理大文件或流数据时,避免等待所有数据生成完毕再发送,减少延迟。同时,需要提醒可能的错误,如重复头部的问题,但根据用户问题,可能只需简要提到,或者放在相关问题部分。 </think>`Transfer-Encoding: chunked` 是 HTTP/1.1 协议中用于**分块传输编码**的响应头,其核心含义和工作原理如下: ### 核心含义 1. **动态数据流传输** 当服务器无法预先确定响应体的总大小时(例如动态生成内容或实时流数据),使用此头部将数据拆分为多个“块”(chunk)逐步发送,无需等待完整内容生成完成。 2. **传输机制** - 每个数据块包含两部分: - **长度行**:十六进制数字(如 `A` 表示 10 字节),独占一行 - **数据行**:实际内容,长度须与长度行声明一致 - 示例: ``` 7\r\n <- 长度行(7字节) chunked\r\n <- 数据行 ``` - **结束标志**:以 `0\r\n\r\n`(长度0的空块)标记传输结束。 3. **性能优化** - 允许服务器即时发送已生成的部分数据,减少客户端等待时间 - 避免因内容长度未知而被迫关闭连接(短连接)或长时间占用连接(长连接)[^1][^2] ### 关键特性 | 特性 | 说明 | |------|------| | **HTTP版本** | 仅 HTTP/1.1 支持(HTTP/1.0 不支持)[^2] | | **优先级** | 若同时存在 `Content-Length` 头,`chunked` 优先级更高 | | **压缩兼容** | 可与 `Content-Encoding: gzip` 等压缩算法结合使用 | | **错误场景** | 重复发送此头部会导致 `upstream sent duplicate header line` 错误[^4] | ### 典型应用场景 1. **实时数据推送** 服务器持续生成数据(如日志流、实时监控),通过分块逐步传输[^3]。 2. **大文件下载** 无需预先计算文件总大小即可开始传输。 3. **动态页面渲染** CGI 脚本逐步输出 HTML 内容时使用。 > 例如:Go 语言实现的 chunked 数据推送服务端会持续生成分块数据流,客户端逐块接收解析[^3]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值