罗剑锋透视HTTP协议学习笔记---16 | 把大象装进冰箱：HTTP传输大文件的方法

16 | 把大象装进冰箱：HTTP传输大文件的方法

HTTP中处理大文件的几种方式

1. 压缩

• 对body数据进行压缩，用头字段Accept-Encoding/Content-Encoding，对文本文件效果较好，但对image，video等已经压缩的文件没有意义。
• Accept-Encoding可以罗列若干客户端支持的压缩方式，服务器端可以挑选一个压缩方式，如果不支持客户端的压缩方式，则不回应Content-Encoding。
• 另外，如果服务器负载太高【CPU overload >80%】，或是已压缩的文件，服务器也不会压缩。

2.分块(chunked)

• 分块的典型应用场景是从服务器下载大文件，服务器端用头字段Transfer-Encoding:chunked标记，表示将把文件分块发送给客户端，每一个chunked块对应一个ACK消息。消息格式为

16进制长度\r\n
chunked数据\r\n #\r\n在wireshark解析为chunk boundary
最后以
0\r\n
\r\n
结束

在浏览器中看不到chunked块的传输细节，只能通过抓包或telnet观察。

telnet抓包结果：

GET /16-1 HTTP/1.1
Host: www.chrono.comHTTP/1.1 200 OK
Server: openresty/1.19.3.1
Date: Sat, 28 Aug 2021 12:49:33 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alivef
chunked data 1f
chunked data 2f
chunked data 30

注：实际传输的是chunked data x\n，所以chunked data x和f之间多一个空行。

wireshark抓包结果，缺省wirechark中所有chunked消息在一个报文中显示：

*注：*如果需要显示HTTP消息交互细节，则需要去掉Reassemble HTTP bodies spanning multiple TCP segments选项。【编辑-首选项-协议-HTTP】

wireshark抓到的chunked数据，回应的消息，除第一个有HTTP头部，后继的chunked块没有HTTP头部，wirkshark标识为continuation，TCP会为每一个chunked块回应一个ACK分段。
第二个chunked分块消息

chunked段消息的ACK分段

最后一个chunked段以0+\r\n\r\n结束

3. 范围请求(range)

• 范围请求的典型应用场景是以拖动方式浏览视频，前提条件是服务器必须实现该功能，用Accept-Ranges: bytes标记。客户端用Range: bytes=x-y发起请求: 表示取文件的一部分，x标识读取的起始位置，y表示结束位置，序号从0开始，x-y可以部分省略，类似python中的切片。如Range: bytes=0-9,表示从0开始取，取到序号9，一共10个字节。服务器端用Content-Range: bytes x-y/length回应，状态码为206。

客户端发起请求/16-2的前32个字节，表示为Range: bytes=0-31

GET /16-2 HTTP/1.1
Host: www.chrono.com
Range: bytes=0-31

服务端回应状态码206，Content-Range: bytes 0-31/90

HTTP/1.1 206 Partial Content
Server: openresty/1.19.3.1
Date: Sun, 07 Feb 2021 09:00:57 GMT
Content-Type: text/plain
Content-Length: 32
Last-Modified: Sat, 28 Sep 2019 17:07:38 GMT
Connection: keep-alive
Accept-Ranges: bytes
ETag: "5d8f935a-5a"
Content-Range: bytes 0-31/90// this is a plain text json doc

Range可以包括多个范围，如Range: bytes=0-31, 32-60
此时服务器响应消息会包含一个总的头部Content-Type: multipart/byteranges; boundary=xxxxx，并还会为每一个数据片段，组织一个数据头，格式如下：

--boundary
Content-Type: text/plain
Content-Range: bytes 0-9/96
实体数据
最后以
--boundary--
结束多段

GET /16-2 HTTP/1.1
Host: www.chrono.com
Range: bytes=0-9, 20-29HTTP/1.1 206 Partial Content
Server: openresty/1.19.3.1
Date: Sun, 07 Feb 2021 09:54:19 GMT
Content-Type: multipart/byteranges; boundary=00000000001
Content-Length: 189
Last-Modified: Sat, 28 Sep 2019 17:07:38 GMT
Connection: keep-alive
Accept-Ranges: bytes
ETag: "5d8f935a-5a"--00000000001
Content-Type: text/plain
Content-Range: bytes 0-9/90
// this is
--00000000001
Content-Type: text/plain
Content-Range: bytes 20-29/90
ext json d
--00000000001--

补充：
关于chunk方式的补充：
如果使用chunk方式传输body，则Content-Length头部被忽略，协议并没有明确它们出现的先后对处理是否有影响，推测和实现有关，感觉合理的实现是检查所有收到的头字段，去掉有冲突的头字段，再做进一步处理。
chunk的优点：可以把大的文件以chunk块的形式发送，后继chunk块不阻塞其它HTTP请求。
chunk的完整格式是在lask chunk后还可以发送tailer-part，trailer-part是一些和chunk发送包体相关的头字段，如md5值，只有chunk发送完毕，才能计算出MD5。
关于Trailer: 如果需要在chunk中发送trailer，客户端必须首先通过TE: Trailers 告知服务器，自己支持TE(Transfer Encoding)，服务器在响应消息中，在发送chunk内容之前，要回应Tailer: header的，声明后面chunk中要发送的头字段。

`
#客户端声明支持trailers
TE: trailers

#服务端首先声明Trailer中的头字段，并在chunk尾部添加它
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: Expires

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
Expires: Wed, 21 Oct 2015 07:28:00 GMT\r\n
\r\n
`

HTTP/2中并不支持chunk。
Transfer-Encoding: gzip, chunked
indicates that the payload body has been compressed using the gzip coding and then chunked using the chunked coding while forming the message body.
Transfer-Encoding是hop-by-hop的头部，gzip,chunked表示用gzip压缩边chunk分块。而Content-encoding: gzip是全链路压缩。

关于Range的补充：
Range针对3种主要的应用场景：
断点续传，断点续传恢复时需要考虑服务器资源是否发生变化和如何处理？包括如何判断服务器资源发生变化，和续传的策略
用if-match或last-modifed判断，由于使用的是etag和date所以只能判断资源是否整体发生变化，不能针对局部变化，而仅传变化的资源局部片段，如果资源发生改变，则需要全部重传。
if-range可以指定etag或date, 而if-match或last-modified要么指定etag，要么指定date。
多线程
视频拖动播放

Range: bytes=x-y #表示取的数据的范围
几种合法的Range: bytes=x-y取值
x-y #单一闭区间取值
x- #从x开始取到结尾
-y #逆序取y个字节
x-y,a-b #多区间范围取值
注：上述取值方式可以组合使用

和Range相关的状态码：
412 Precondition Failed #条件请求不满足

C:>curl www.chrono.com/letter.txt -H “Range: bytes=0-5” -H “If-Match: “61306161-1a””
abcdef
C:>curl www.chrono.com/letter.txt -H “Range: bytes=0-5” -H “If-Match: “61306161-1b””

<html>
<head><title>412 Precondition Failed</title></head>
<body>
<center><h1>412 Precondition Failed</h1></center>
<hr><center>openresty/1.19.3.1</center>
</body>
</html>

注：对于If-Range:如果条件不满足，则直接返回完整包体，而不报412
C:>curl www.chrono.com/letter.txt -H “Range: bytes=0-5” -H “If-Range: “61306161-1b””
abcdefghijklmnopqrstuvwxyz
C:>curl www.chrono.com/letter.txt -H “Range: bytes=0-5” -H “If-Range: “61306161-1a””
abcdef

416 Requested Range Not Satisfiable #Range取值范围无效

C:>curl www.chrono.com/letter.txt -H “Range: bytes=30” -H “If-Range: “61306161-1a””

<html>
<head><title>416 Requested Range Not Satisfiable</title></head>
<body>
<center><h1>416 Requested Range Not Satisfiable</h1></center>
<hr><center>openresty/1.19.3.1</center>
</body>
</html>

C:>curl www.chrono.com/letter.txt -H “Range: bytes=30” -H “If-Match: “61306161-1a””

<html>
<head><title>416 Requested Range Not Satisfiable</title></head>
<body>
<center><h1>416 Requested Range Not Satisfiable</h1></center>
<hr><center>openresty/1.19.3.1</center>
</body>
</html>

令人疑惑的Range取值中的overlap问题：

case1：区间2包含区间1且起始位置从0开始，则返回所有包体 【#nginx 1.20.0/openresty/1.19.3.1无此问题】
C:>curl www.chrono.com/letter.txt -H “Range: bytes=0-5,0-20”
abcdefghijklmnopqrstuvwxyz

case1.1: 区间2包含区间1,但起始位置从非0开始，则分段返回包体

C:>curl www.chrono.com/letter.txt -H “Range: bytes=1-5,1-20”

–00000000030
Content-Type: text/plain
Content-Range: bytes 1-5/26

bcdef
–00000000030
Content-Type: text/plain
Content-Range: bytes 1-20/26

bcdefghijklmnopqrstu
–00000000030–

case1.2 区间2包含区间1且起始位置从0开始，整体取值较小，则分别返回区间包体
C:>curl www.chrono.com/letter.txt -H “Range: bytes=0-5,0-10”

–00000000048
Content-Type: text/plain
Content-Range: bytes 0-5/26

abcdef
–00000000048
Content-Type: text/plain
Content-Range: bytes 0-10/26

abcdefghijk
–00000000048–

case2：区间2和区间1存在overlap，正常返回各区间
C:>curl www.chrono.com/letter.txt -H “Range: bytes=0-5,1-20”

–00000000020
Content-Type: text/plain
Content-Range: bytes 0-5/26

abcdef
–00000000020
Content-Type: text/plain
Content-Range: bytes 1-20/26

bcdefghijklmnopqrstu
–00000000020–

令人疑惑的x-取值问题：
case3: 区间1-2存在overlap,再包含一个x-,取全包体【nginx 1.20.0/openresty/1.19.3.1仍有此问题】
C:>curl www.chrono.com/letter.txt -H “Range: bytes=0-5,4-10,11-”
abcdefghijklmnopqrstuvwxyz

case3.1 区间1-2无overlap,再包含一个x-,取区间包体
C:>curl www.chrono.com/letter.txt -H “Range: bytes=0-5,6-10,11-”

–00000000057
Content-Type: text/plain
Content-Range: bytes 0-5/26

abcdef
–00000000057
Content-Type: text/plain
Content-Range: bytes 6-10/26

ghijk
–00000000057
Content-Type: text/plain
Content-Range: bytes 11-25/26

lmnopqrstuvwxyz
–00000000057–

nginx/openresty的bug？
上述测试使用的是windows 10+ openrestry 19.3.1

D:\bak\skydrive\http\http_study-1.0.3\openresty>nginx -v
nginx version: openresty/1.19.3.1

课后作业

分块传输数据的时候，如果数据里含有回车换行（\r\n）是否会影响分块的处理呢？

• 不会，chunk根据length控制分块的。

如果对一个被 gzip 的文件执行范围请求，比如“Range: bytes=10-19”，那么这个范围是应用于原文件还是压缩后的文件呢？

• 推测是原文件，如果是压缩后的文件，不同压缩算法压缩效率不一致，结果变得不可控了。