【HTTP】持久连接与分块chunked传输

1、已知报文的长度Content-Length时

　　HTTP1.1支持持久连接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟（也就是一次TCP的连接不马上释放，允许许多的请求跟响应在一个TCP的连接上发送），所以客户机与服务器需要某种方式来标示一个报文在哪里结束和下一个报文从哪里开始。简单的方法是使用Content-Length，但这只有当报文长度可以预先判断的时候才起作用。

2、未知报文的长度Content-Length时

　　有的时候，服务器无法确定HTTP回应的消息的大小，比如非常大的文件的下载，或者处理的逻辑比较复杂，需要一边处理一边实时生成消息，这个时候服务器一般都使用分块chunked编码。此时，服务器不会带上Content-Length这个响应头，带上了两外一个头：Transfer-encoding:chunked。

　　chunked编码使用若干个Chunk组成，由一个标明长度为0的chunk结束，每个Chunk有两部分组成，每个部分用回车换行隔开。

　　因此，接收数据的时候，需要首先获取每一个chunk数据的字节长度，然后，跳过2个字节(/r/n)，取出数据，然后，再跳过2个字节(/r/n)，获取下一个chunk的长度，直到最后一个chunk，最后一个chunk一定是0，并且字节的长度都是十六进制形式传输，需要进行相应的转化成十进制，如果是gzip格式的数据，那么，在最后完成所有数据组合之后，需要再解压。

HTTP 1.1引入分块传输编码提供了以下几点好处：

1. HTTP分块传输编码允许服务器为动态生成的内容维持HTTP持久连接。通常，持久链接需要服务器在开始发送消息体前发送Content-Length消息头字段，但是对于动态生成的内容来说，在内容创建完之前是不可知的。[动态内容，content-length无法预知]
2. 分块传输编码允许服务器在最后发送消息头字段。对于那些头字段值在内容被生成之前无法知道的情形非常重要，例如消息的内容要使用散列