[详解《图解HTTP》+ 拓展] 六：HTTP传输大文件的相关字段这个篇章决定不按照《图解HTTP》那样罗列全部字段，因

该系列博客是记录自己的学习笔记，若有错误请大佬们指出

狗头声明，本文适用于：新手学习进步，老鸟回顾消遣
该系列以《图解HTTP》为基本路线，该书有11章节，所以本系列也决定编写11篇水文技术博客进行适当的拓展和补充，希望可以帮助大家。

这个篇章决定不按照《图解HTTP》那样罗列全部字段，因为单纯的只要字段以及其属性值是没啥用的，必须结合使用的场景讲解，所以在我该系列的文章中，许多拓展的地方就把常用的需要的字段都学习了。

这章就学习HTTP传输大文件相关字段

HTTP是传输超文本的协议，而超文本包括了文字、图片、视频等等，所以有时候可能传输的文件会很大。

即使5G已经普及，但是一个高清电影打底1GB起步，上传和下载的时候都是大文件的传输，高效快捷地传输这些大文件是个提高用户体验感的关键。

相关字段：请求头字段的Accept-Encoding与响应头字段的Content-Encoding

通常浏览器在发送请求时都会带着“Accept-Encoding”头字段，里面是浏览器支持的压缩格式列表，例如 gzip、deflate、br 等，这样服务器就可以从中选择一种压缩算法，放进“Content-Encoding”响应头里，再把原数据压缩后发给浏览器。

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

相关字段：响应头字段Transfer-Encoding: chunked

即先把大文件拆成很多个小文件，这样网络就不会被大文件长时间占用；等小文件都传过去了，再组装回大文件。

注意：
分块传输这种情况下 body（实体）数据的长度是未知的，所以无法在头字段Content-Length里给出确切的长度。
也就是说Transfer-Encoding: chunked和Content-Length这两个字段是互斥的，不能同时出现。

所以，压缩无法解决的视频文件，就可以使用分块传输来优化

相关字段：请求头字段Range，响应头字段Accept-Ranges、Content-Range

分块确实解决了大文件传输的问题，但是还有不足：
例如在视频快进的时候，跳过的那一段是不需要获取的资源，能省则省啊，所以HTTP 协议允许客户端在请求头里使用专用字段来表示只获取文件的一部分。

Accept-Ranges: bytes告知客户端：“本服务器是支持范围请求的”。
Accept-Ranges: none，或者响应头里直接没有“Accept-Ranges”字段，则不能范围请求，只能收发整块文件（分块传输是大文件拆为小文件，而范围传输是获取单个文件中的一部分资源。）
Range范围必须从 0 计数，单位是字节，eg：获取前 10 个字节表示为“Range: bytes=0-9”（0-10是前11个字节）

服务器收到 Range 字段后，需要做四件事：

1、检查范围是否合法，比如文件只有 100 个字节，但请求“200-300”，这就是范围越界了。服务器就会返回 416状态码，即范围请求有误。
2、范围正确，服务器就可以根据 Range 头计算偏移量，读取文件的片段，会返回206状态码，和 200 的意思差不多，但表示 body（实体）只是原数据的一部分。
3、服务器要添加一个响应头字段 Content-Range，例如Content-Range: bytes 0-9/100
最后，将这范围内的数据发送，一个范围请求即处理完成。