HTTP编码机制

内容编码

在http协议中，可以对内容（也就是body部分）进行编码，可以采用gzip这样的编码，从而达到压缩的目的。也可以使用其他的编码把内容搅乱或加密，以此来防止未授权的第三方看到文档的内容。所以我们说HTTP压缩，其实就是HTTP内容编码的一种。

Content-Encoding

Accept-Encoding

内容编码的类型

HTTP定义了一些标准的内容编码类型，并允许用扩展的形式添加更多的编码
Content-Encoding值:
gzip 表明实体采用GNU zip编码
compress 表明实体采用Unix的文件压缩程序
deflate　表明实体是用zlib的格式压缩的
identity　表明没有对实体进行编码。当没有Content-Encoding header时，就默认为这种情况
gzip,compress, 以及deflate编码都是无损压缩算法，用于减少传输报文的大小，不会导致信息损失。其中gzip通常效率最高，使用最为广泛。

内容压缩的过程

浏览器发送Http request 给Web服务器, request 中有Accept-Encoding: gzip, deflate。 (告诉服务器，浏览器支持gzip压缩)
Web服务器接到request后，生成原始的Response, 其中有原始的Content-Type和Content-Length。
Web服务器通过Gzip，来对Response进行编码，编码后header中有Content-Type和Content-Length(压缩后的大小)，并且增加了Content-Encoding:gzip. 然后把Response发送给浏览器。
浏览器接到Response后，根据Content-Encoding:gzip来对Response 进行解码。获取到原始response后，然后显示出网页。

传输编码

描述实体对象(entity)的传输形式(分块策略);

Transfer-Encoding

可选值有：chunked,identity

分块传输编码

分块传输编码是超文本传输协议（HTTP）中的一种数据传输机制，允许HTTP由网页服务器发送给客户端应用的数据可以分成多个部分。分块传输编码只在HTTP协议1.1版本（HTTP/1.1）中提供
通常，HTTP应答消息中发送的数据是整个发送的，Content-Length消息头字段表示数据的长度。数据的长度很重要，因为客户端需要知道哪里是应答消息的结束，以及后续应答消息的开始。然而，使用分块传输编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小

分块传输编码的优点

HTTP分块传输编码允许服务器为动态生成的内容维持HTTP持久链接。通常，持久链接需要服务器在开始发送消息体前发送Content-Length消息头字段，但是对于动态生成的内容来说，在内容创建完之前是不可知的。
分块传输编码允许服务器在最后发送消息头字段。对于那些头字段值在内容被生成之前无法知道的情形非常重要，例如消息的内容要使用散列进行签名，散列的结果通过HTTP消息头字段进行传输。没有分块传输编码时，服务器必须缓冲内容直到完成后计算头字段的值并在发送内容前发送这些头字段的值。
HTTP服务器有时使用压缩（gzip或deflate）以缩短传输花费的时间。分块传输编码可以用来分隔压缩对象的多个部分。在这种情况下，块不是分别压缩的，而是整个负载进行压缩，压缩的输出使用本文描述的方案进行分块传输。在压缩的情形中，分块编码有利于一边进行压缩一边发送数据，而不是先完成压缩过程以得知压缩后数据的大小。

分块传输编码格式

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

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

25
This is the data in the first chunk
1C
and this is the second one
3
con
8
sequence
0

protocol