HTTP传输编码Transfer-Encoding

2019独角兽企业重金招聘Python工程师标准>>>

HTTP传输编码Transfer-Encoding

内容编码——是对报文的主体进行的可逆变换，内容编码是和内容的具体格式细节相关的。例如你可能会用gizip压缩文本文件，但不是JPEG文件，

因为JPEG这类东西用gizp压缩的不够好。

传输编码——也是作用在实体主体（报文主体）上的可逆变换 ，但使用它们是由于架构方面的原因，同内容的格式无关。传输编码是为了改变报文中的数据在网络上传输的方式。

经过内容编码的报文，只是对报文的实体部分进行了编码。而对于经过传输编码的报文来说，编码作用在整个报文之上，报文自身的结构发生了改变。

 

Transfer-Encoding首部：

HTTP协议只定义了下面两个首部来描述和控制传输编码。

• Transfer-Encoding首部：

  告知接收方为了可靠地传输报文，已经对其进行了何种编码

• TE首部：

  用在请求首部中，告知服务器可以使用哪些传输编码扩展

传输编码的值都是大小写无关的。最新的HTTP规范只定义了一种传输编码，就是分块编码。

与Accept-Encoding首部类似，TE首部也可以使用Q值来说明传输编码的优先顺序，不过，HTTP/1.1规范中禁止将分块编码关联的Q值设为0.0

 

分块编码——chunked

分块编码把报文分割成若干个大小已知的块。块之间是紧挨着发送的，这样就不需要在发送之前知道整个报文的大小了。

要注意的是，分块编码是一种传输编码，因此是报文的属性，而不是主体的属性。

 

分块与持久连接

若客户端和服务器之间不是持久连接，客户端就不需要知道它正在读取的主体的长度，而只需要读到服务器关闭主体连接为止。

当使用持久连接时，在服务器写主体之前，必须知道它的大小并在Content-Leng首部中发送。如果服务器动态创建内容，就可能在发送之前无法知道主体的长度。

分块编码为这种困难提供了解决方案，允许服务器把主体逐块发送，说明每块的大小就可以了。因为主体是动态创建的，服务器可以缓冲他的一部分，发送其大小和相应的块，然后在主体发送完成之前重复这个过程。服务器可以用大小为0的块作为主体结束的信号，这样就可以继续保持连接，为下一个响应做准备。

 

客户端也可以发送分块的数据给服务器。因为客户端事先不知道服务器是否接受分块编码（这是因为服务器不会再给客户端的响应中发送TE首部），所以客户端必须做好服务器用

411 Length Required（需要Content-Length首部）响应来拒绝分块请求的准备。

 

分块传输——报文的格式

如果一个HTTP消息（请求消息或应答消息）的Transfer-Encoding消息头的值为chunked，那么，消息体由数量未定的块组成，并以最后一个大小为0的块为结束。‍‍每一个非空的块都以该块包含数据的字节数（字节数以十六进制表示）开始，跟随一个CRLF （回车及换行），然后是数据本身，最后块CRLF结束。‍‍在一些实现中，块大小和CRLF之间填充有白空格（0x20）。最后一块是单行，由块大小（0），一些可选的填充白空格，以及CRLF。最后一块不再包含任何数据，但是可以发送可选的尾部，包括消息头字段。消息最后以CRLF结尾。

========END========

转载于:https://my.oschina.net/xinxingegeya/blog/269203