sailei1
commented
4 years ago 大文件处理
数据压缩 通常浏览器在发送请求时都会带着“Accept-Encoding”头字段，里面是浏览器支持的压缩格式列表，例如 gzip、deflate、br等，这样服务器就可以从中选择一种压缩算法，放进“Content-Encoding”响应头里，再 把原数据压缩后发给浏览器。
gzip 文本压缩率超过60% br算法是专为html设计的，压缩效率和性能比gzip还要好 nginx gzip on 指令 只压缩文本数据 不压缩图片 音频 视频等大文件
分块传输
压缩是把大文件整体变小，我们可以反过来思考，如果大文件整体不能变小，那就把它“拆开”，分解成多个小块，把这些小块分批发给浏览器，浏览器收到后再组装复原。
Transfer-Encoding: chunked 表示报文里的body部分不是一次性发过来的，而是分成了许 多的块(chunk)逐个发送。
分块传输的编码规则 (明文传输)
- 每个分块包含两个部分，长度头和数据块;
- 长度头是以CRLF(回车换行，即\r\n)结尾的一行明文，用16进制数字表示长度; 3. 数据块紧跟在长度头后，最后也用CRLF结尾，但数据不包含CRLF;
- 最后用一个长度为0的块表示结束，即“0\r\n\r\n”。
“Transfer-Encoding:chunked”和“Content-Length”这两个字段是互斥的，也就是说响应报文里这两个 字段不能同时出现，一个响应报文的传输要么是长度已知，要么是长度未知(chunked)，这一点你一定要 记住。
chunked编码用在“流式”收发数据的时候，通常数据是即时生成的，也就是动态数据。
Transfer-Encoding 常见的值 chunked, 也可以用gzip deflate br 表示传输时使用了压缩编码。 注意这与Content-Encoding不同，Transfer-Encoding 在传输后会被自动解码还原出原始数据，而content-Encoding 则必须由应用自行解码
范围请求
范围请求不是Web服务器必备的功能，可以实现也可以不实现，所以服务器必须在响应头里使用字 段“Accept-Ranges: bytes”明确告知客户端:“我是支持范围请求的”。如果不支持的话，服务器可以发送“Accept-Ranges: none”，或者干脆不发送“Accept-Ranges”字段
请求头Range是HTTP范围请求的专用字段，格式是“bytes=x-y”，其中的x和y是以字节为单位的数据范围。
服务器收到Range字段后，需要做四件事。
第一，它必须检查范围是否合法，比如文件只有100个字节，但请求“200-300”，这就是范围越界了。服务器就会返回状态码416，意思是“你的范围请求有误，我无法处理，请再检查一下”。 第二，如果范围正确，服务器就可以根据Range头计算偏移量，读取文件的片段了，返回状态码“206 Partial Content”，和200的意思差不多，但表示body只是原数据的一部分。 第三，服务器要添加一个响应头字段Content-Range，告诉片段的实际偏移量和资源的总大小，格式 是“bytes x-y/length”，与Range头区别在没有“=”，范围后多了总长度。例如，对于“0-10”的范围请 求，值就是“bytes 0-10/100”。 最后剩下的就是发送数据了，直接把片段用TCP发给客户端，一个范围请求就算是处理完了。
多段数据
Range: bytes=0-31 // 获取文件的前32个字节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--报文里的“--00000000001”就是多段的分隔符，使用它客户端就可以很容易地区分出多段Range 数据。
要注意这四种方法不是互斥的，而是可以混合起来使用，例如压缩后再分块传输，或者分段后再分块
如果对一个被gzip的文件执行范围请求，比如“Range:bytes=10-19”，那么这个范围是应用于原文件大小
HTTP协议规定了非常多的头部字段，实现各种各样的功能，但基本上可以分为四大类:
Accept 跟 Content MIME type 形式是“type/subtype”的字符串 比如 1 文本 text/html text/plain 2 图片 image/png 3 音视频 audio/mpeg、video/mp4 4 数据格式不固定由上层应用程序来解释 application/json application/javascript
Encoding type 1 gzip压缩 2 deflate 3 br
有了MIME type和Encoding type，无论是浏览器还是服务器就都可以轻松识别出body的类型，也就能够正 确处理数据了。
客户端用Accept头告诉服务器希望接收什么样的数据，而服务器用Content头告诉客户端 实际发送了什么样的数据。
Accept字段标记的是客户端可理解的MIME type，可以用“,”做分隔符列出多个类型，让服务器有更多的选择余地
Accept-Language字段标记了客户端可理解的自然语言，也允许用“,”做分隔符列出多个类型
请求头 Accept: application/json, text/plain, / Accept-Encoding: gzip, deflate Accept-Language:zh-CN,zh;q=0.9,en;q=0.8,es;q=0.7,fr;q=0.6,ru;q=0.5,tr;q=0.4,vi;q=0.3,zh-TW;q=0.2,de;q=0.1,da;q=0.1,ja;q=0.1,pt;q=0.1
服务器会在响应报文里用头字段Content-Type告诉实体数据的真实类型
响应头 Content-Type: application/json; charset=utf-8 Content-Encoding: gzip
注意 content-type是实体字段，所以请求和响应里都可以用，作用是指明body数据的类型。
字符集在HTTP里使用的请求头字段是Accept-Charset，但响应头里却没有对应的Content-Charset，而是 在Content-Type字段的数据类型后面用“charset=xxx”来表示，这点需要特别注意。
q 代表权重值 最大是1 最小是0.01 默认1。 0表示拒绝 在数据类型或语言代 码后面加一个“;” “;”的意义是小于“,”的。
表示浏览器最希望使用的是HTML文件，权重是1，其次是XML文件，权重是0.9，最后是任意数据类型，权重是0.8。服务器收到请求头后，就会计算权重，再根据自己的实际情况优先输出HTML或者XML。
有的时候，服务器会在响应头里多加 一个Vary字段，记录服务器在内容协商时参考的请求头字段，给出一点信息 Vary: Accept-Encoding,User-Agent,Accept
Vary字段可以认为是响应报文的一个特殊的“版本标记”。每当Accept等请求头变化时，Vary也会随着响应 报文一起变化