http笔记整理：传输大文件

数据压缩

gzip 等压缩算法通常只对文本文件有较好的压缩率，而图片、音频视频等多媒体数据本身就已经是高度压缩的，再用 gzip 处理也不会变小（甚至还有可能会增大一点），所以它就失效了

分块传输

“化整为零”的思路在 HTTP 协议里就是“chunked”分块传输编码，在响应报文里用头字段“Transfer-Encoding: chunked”来表示，意思是报文里的 body 部分不是一次性发过来的，而是分成了许多的块（chunk）逐个发送。

分块传输也可以用于“流式数据”，例如由数据库动态生成的表单页面，这种情况下 body 数据的长度是未知的，无法在头字段“Content-Length”里给出确切的长度，所以也只能用 chunked 方式分块发送。

 

Transfer-Encoding: chunked”和“Content-Length”这两个字段是互斥的，

 

分块传输的编码规则

每个分块包含两个部分，长度头和数据块；

长度头是以 CRLF（回车换行，即\r\n）结尾的一行明文，用 16 进制数字表示长度；

数据块紧跟在长度头后，最后也用 CRLF 结尾，但数据不包含 CRLF；

最后用一个长度为 0 的块表示结束，即“0\r\n\r\n”

 

范围请求

 

 

多段数据

每一个分段必须以“- -boundary”开始（前面加两个“-”），之后要用“Content-Type”和“Content-Range”标记这段数据的类型和所在范围，然后就像普通的响应头一样以回车换行结束，再加上分段数据，最后用一个“- -boundary- -”（前后各有两个“-”）表示所有的分段结束。

请求：

GET /16-2 HTTP/1.1 Host: www.chrono.com Range: bytes=0-9, 20-29

响应：

HTTP/1.1 206 Partial Content Content-Type: multipart/byteranges; boundary=00000000001 Content-Length: 189 Connection: keep-alive Accept-Ranges: bytes --00000000001 Content-Type: text/plain Content-Range: bytes 0-9/96 // this is --00000000001 Content-Type: text/plain Content-Range: bytes 20-29/96 ext json d --00000000001--