Transfer-Encoding: chunked 的含义

本文详细解读了HTTP响应头中的'Transfer-Encoding:chunked'标识符的含义及其工作原理,通过使用Java Socket进行HTTP请求,展示了其在实际应用中的表现,并附上相关代码和输出结果。

Transfer-Encoding: chunked 的含义


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

没有多大关系。

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

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



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

Java代码  收藏代码
  1. <%      out.print( "helloworld!" );  
  2.     out.flush();  
  3.     out.print("123" );  
  4.     out.flush();  
  5. %>  


输出结果是:

引用

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



其中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]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值