http代理会把响应 transfer吧-encoding chunked 的效果抵消掉吗

来源：蜘蛛抓取(WebSpider) 时间：2017-06-14 05:55 标签： transfer

通常HTTP协议中使用Content-Length这个头来告知數据的长度。然后在数据下行的过程中，Content-Length的方式要预先在服务器中缓存所有数据然后所有数据再一股脑儿地发给客户端。

当使用transfer吧-Encoding: chunked时传送的实际长度将放到实际内容的首行，如以上截图36就是实际的长度，不过这个数是16进制的

最后的数字0  应该就是结束吧，如果没有0\r\n\r\n來结束chunked会导致解析失败。

？不知道我的理解是不是正确？

Chunked编码使用若干个Chunk串连而成由一個标明长度为0的chunk标示结束。每个Chunk分为头部和正文两部分头部内容指定下一段正文的字符总数（十六进制的数字）和数量单位（一般不写），正文部分就是指定长度的实际内容两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容是一些附加的Header信息（通常可以直接忽略）。具体的Chunk编码格式如下：

最后提供一段PHP版本的chunked解码代码：

如果结合transfer吧-Encoding: chunked使用就不必申请一个很大的字节数组了，可以┅块一块的输出更科学，占用资源更少

这在http协议中也是个常见的字段，用于http传送过程的分块技术原因是http服务器响应的报文长度经常昰不可预测的，使用Content-length的实体搜捕并不是总是管用

分块技术的意思是说，实体被分成许多的块也就是应用层的数据，TCP在传送的过程中鈈对它们做任何的解释，而是把应用层产生数据全部理解成二进制流然后按照MSS的长度切成一分一分的，一股脑塞到tcp协议栈里面去而具體这些二进制的数据如何做解释，需要应用层来完成所以在这之前，一快整体应用层的数据需要等它分成的所有TCP  segment到达对方重新组装后，应用程序才使用自己的解码方法还原它们 HTTP1.1采用了持久的连接，也就是一次TCP的连接不马上释放允许许多的请求跟响应在一个TCP的连接上發送，所以客户机与服务器需要某种方式来标示一个报文在哪里结束和在下一个报文在哪里开始简单的方法是使用呢content-length，但这只有当报文長度可以预先判断的时候才起作用而对于动态的内容或者在发送数据前不能判定长度的情况下，可以使用分块的方法来传送编码

Web服务器有时生成HTTPResponse无法在Header就确定消息大小的，这时一般来说服务器将不会提供Content-Length的头信息而采用Chunked编码动态的提供body内容的长度。

Chunked编码使用若干个Chunk串連而成由一个标明长度为0的chunk标示结束。每个Chunk分为头部和正文两部分头部内容指定下一段正文的字符总数（十六进制的数字）和数量单位（一般不写），正文部分就是指定长度的实际内容两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容是一些附加的Header信息（通常可以直接忽略）。

这里面只有一个有意义的chunke以及一个footer第一个chunk，头部是3134这两个字节表示的是1和4这两个ascii字符，被http协议解釋为十六进制数14也就是十进制的20。后面紧跟0d0a再接着是20个字节的chunk正文（图中的011e~0131）。

后面再接着0d0a然后就是footer了，30表示ascii字符0http解释为长度是0（也说明了这是最后一个chunk），后面紧跟0d0a然后正文部分为空，再接0d 0a表示结束


transfer吧-Encoding 响应头用于告诉客户端服务器發送内容的编码格式

  • compress：使用 算法进行传输的格式，目前没有浏览器在支持
  • deflate：使用 压缩算法 结构。
  • gzip：使用 编码的压缩格式

其中，chunked 就比較有意思了它表示服务器下发到客户端的内容不是一次性完成的，而是分成一小块一小块（trunk）下发过程中客户端与服务器的连接仍然維持不会断开。

在 Web Socket 没出来前可利用这一机制实现长连接的效果。

HTTP/2 中已经不支持 chunked 这一格式了因为其本身提供了更加高级的流机制来实现類似功能。

本文永久更新链接地址：

我要回帖

更多关于 transfer 的文章

 

随机推荐