http chunked

左手的ㄟ右手 2023-03-02 07:51 18阅读 0赞

# 问题 #

这几天在对接协议的时候发现对接服务器所给的回复有些奇怪，http头中没有`Content-Length`字段，仔细看了下返回的数据，其中多了`Transfer-Encoding: chunked`字段，用Python测试解析接口正常，于是明白是没有http的一种传输数据的方式。

# 结果 #

查了下关于`Transfer-Encoding`的介绍：

**Transfer-Encoding** 消息首部指明了将 `entity` 安全传递给用户所采用的编码形式。

`Transfer-Encoding`是一个逐跳传输消息首部，即仅应用于两个节点之间的消息传递，而不是所请求的资源本身。一个多节点连接中的每一段都可以应用不同的Transfer-Encoding 值。如果你想要将压缩后的数据应用于整个连接，那么请使用端到端传输消息首部 Content-Encoding 。

当这个消息首部出现在 HEAD 请求的响应中，而这样的响应没有消息体，那么它其实指的是应用在相应的 GET 请求的应答的值。也就是：

<table> 
 <thead> 
  <tr> 
   <th>Header type</th> 
   <th><a href="https://developer.mozilla.org/zh-CN/docs/Glossary/%E7%A6%81%E6%AD%A2%E4%BF%AE%E6%94%B9%E7%9A%84%E6%B6%88%E6%81%AF%E9%A6%96%E9%83%A8" rel="nofollow">Forbidden header name</a></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Response header（出现在响应头中）</td> 
   <td>yes（禁止用户修改的头）</td> 
  </tr> 
 </tbody> 
</table>

## 语法： ##

Transfer-Encoding: chunked
    Transfer-Encoding: compress
    Transfer-Encoding: deflate
    Transfer-Encoding: gzip
    Transfer-Encoding: identity
    
    // Several values can be listed, separated by a comma
    Transfer-Encoding: gzip, chunked

**各个值得含义**：

### compress ###

采用 Lempel-Ziv-Welch (LZW) 压缩算法。这个名称来自UNIX系统的 compress 程序，该程序实现了前述算法。  
与其同名程序已经在大部分UNIX发行版中消失一样，这种内容编码方式已经被大部分浏览器弃用，部分因为专利问题（这项专利在2003年到期）。

### deflate ###

采用 zlib 结构 (在 RFC 1950 中规定)，和 deflate 压缩算法(在 RFC 1951 中规定)。

### gzip ###

表示采用 Lempel-Ziv coding (LZ77) 压缩算法，以及32位CRC校验的编码方式。这个编码方式最初由 UNIX 平台上的 gzip 程序采用。处于兼容性的考虑， HTTP/1.1 标准提议支持这种编码方式的服务器应该识别作为别名的 x-gzip 指令。

### identity ###

用于指代自身（例如：未经过压缩和修改）。除非特别指明，这个标记始终可以被接受。

### chunked（分块编码） ###

数据以一系列分块的形式进行发送。 `Content-Length` 首部在这种情况下不被发送。。在每一个分块的开头需要添加当前分块的长度，以十六进制的形式表示，后面紧跟着 ‘\\r\\n’ ，之后是分块本身，后面也是’\\r\\n’ 。终止块是一个常规的分块，不同之处在于其长度为0。终止块后面是一个挂载（trailer），由一系列（或者为空）的实体消息首部构成。

分块传输编码将有效负载主体包装起来，以便将其作为一系列块传输，每个块都有自己的尺寸指示符，后面跟着一个可选的包含在头字段中的尾部。Chunked允许将未知大小的内容流作为长度分隔的缓冲区序列传输，这使发送方能够保持连接持久性，而接收方能够知道何时收到了整个消息。

`chunk-size`字段是一个十六进制数字字符串，表示块数据的八进制大小。当接收到一个块大小为零的块(可能后面跟着一个结尾符)并最终以空行结束时，分块传输编码即完成。

chunked-body   = *chunk
                          last-chunk
                          trailer-part
                          CRLF
    
         chunk          = chunk-size [ chunk-ext ] CRLF
                          chunk-data CRLF
         chunk-size     = 1*HEXDIG
         last-chunk     = 1*("0") [ chunk-ext ] CRLF
    
         chunk-data     = 1*OCTET ; a sequence of chunk-size octets
         
         chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
    
         chunk-ext-name = token
         chunk-ext-val  = token / quoted-string

分块编码主要应用于如下场景，即要传输大量的数据，但是在请求在没有被处理完之前响应的长度是无法获得的。例如，当需要用从数据库中查询获得的数据生成一个大的HTML表格的时候，或者需要传输大量的图片的时候。一个分块响应形式如下：

HTTP/1.1 200 OK 
    Content-Type: text/plain 
    Transfer-Encoding: chunked
    
    7\r\n
    Mozilla\r\n 
    9\r\n
    Developer\r\n
    7\r\n
    Network\r\n
    0\r\n 
    \r\n

## 参考文章 ##

1.  [MDN Transfer-Encoding][]
2.  [Http Trunked协议使用][Http Trunked]
3.  [rfc7231 3.3 Payload Semantics][] 介绍一下关于描述载荷的http头类型
4.  [rfc2616 4.4 Message Length][] http消息长度的表示方式以及各种情况下长度的值；
5.  [rfc7230 3.3.2 Transfer-Encoding][] `Transfer-Encoding`的介绍
6.  [rfc7230 4.1Chunked Transfer Coding][] `chunked transfer encoding`的介绍

[MDN Transfer-Encoding]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Transfer-Encodingc
[Http Trunked]: https://www.cnblogs.com/cstar/archive/2012/06/28/2567370.html
[rfc7231 3.3 Payload Semantics]: https://tools.ietf.org/html/rfc7231#section-3.3
[rfc2616 4.4 Message Length]: https://tools.ietf.org/html/rfc2616#section-4.4
[rfc7230 3.3.2 Transfer-Encoding]: https://tools.ietf.org/html/rfc7230#section-3.3.1
[rfc7230 4.1Chunked Transfer Coding]: https://tools.ietf.org/html/rfc7230#section-4.1