HTTP传输大文件

关注

原创最新推荐文章于 2026-04-09 07:15:00 发布 4.7k 阅读 AI 写同款· GEO 优化 ›

http上传文件 http协议是建立在tcp、ip协议的应用层规范。 http协议规范把http请求分为3个部分：状态行，请求头，请求体。所有的方法、实现都是围绕 “如何运用和组织这三部分” 来完成的。了解http请求的组成部分后，就可以应变任何实际工作中所遇到的需求和问题了。 http里没有专门用于文件上传的请求方式，文件上传请求是在post请求基础之上定义出来的一种方式。 Content-Type在发送到服务器时候内容编码方式，它有如下的三个值。 ①application/x-www-form-urlen... 阅读详情

一概述

早期网络传输的文件非常小，只是一些几K大小的文本和图片，随着网络技术的发展，传输的不仅有几M的图片，还有可以达到几G和几十G的视频。

在这些大文件传输的情况下，100M的光纤或者4G移动网络都会因为网络压力导致在上传或者下载的情况下导致网络传输链路挤的“满满当当”。

二网络中大文件传输之数据压缩

通常浏览器在发送请求时都会带上"Accept-Encoding"头字段，该字段用来声明浏览器支持的压缩格式列表，例如gzip，deflate，br等，这样服务器就可以从中选择一种压缩算法，并将其放进"Content-Encoding"响应头中，最后将元数据压缩后发给浏览器。

这种情况下下，如果压缩率是50%，也就是100K数据可以变成50K大小的文件进行传输，从网络的角度考虑，就类似于网络提升了一倍。

这种方法的缺点是，gzip等压缩算法通常只是对文本文件有较好的压缩率，而图片，音频，视频的多媒体文件由于本身已经是高度压缩的，此时再使用gzip处理不会变小（甚至还有可能会增大一点），所以这种方法就不适用了。

由于这种方法对文本类型的数据压缩效果比较好，所以大部分网站会使用该技术作为"保底"。例如，Nginx里就会使用"gzip on"指令，启用对"text/html"的压缩。

三网络中大文件传输之数据分块传输

相对于数据压缩那种将大文件整体变小来说，数据分块传输可以保证在大文件无法因压缩处理变小的时候，可以将其拆解，分成多个小块，然后将这些小块批发给浏览器，浏览器收到后会对拆解后的文件再进行组装复原。

这样的好处是，在浏览器的和服务器的内存中都不会再内存中保存文件的全部，每次只是发送一小部分，从而网络不会被大文件占用，内存，宽带等资源就会被节省。

这种"化整为零"的思路在HTTP协议里就是通过"chunked"分块传输编码，在响应报文里用头字段"Tranfer-Encoding:chunked"来表示，意思就是报文中的body部分不是一次性发送过来，而是分成许多块的"chunk"并进行逐个发送。

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

"Tranfer-Encodeing:chunked"和"Content-Length"这两个字段是互斥的，也就是说响应报文中的两个字段是不可以同时出现的，一个响应报文的传输长度要么已经知道了，要么是未知的（chunked）。

四分块传输的编码规则

分块传输的编码规则类似于响应头，同样采用了明文的方式。

每个分块包含两部分，长度头和数据块。
长度头是以CRLF(回车换行，即\r\n)结尾的一行明文，用16进制数字表示长度。
数据块紧跟其后，最后同样使用CRLF结尾，但数据不包含CRLF。
最后用一个长度为0的块（即最后的空行）来表示结束，即"0\r\n\r\n"。

图示：

注意：浏览器在收到分块传输的数据之后会自动按照规则去掉分块编码，重新组装出内容。

五大文件传输之范围请求

有了分块传输编码，服务器就可以轻松地收发大文件了，但对于上 G 的超大文件，还有一些问题需要考虑。

比如，你在看当下正热播的某穿越剧，想跳过片头，直接看正片，或者有段剧情很无聊，想拖动进度条快进几分钟，这实际上是想获取一个大文件其中的片段数据，而分块传输并没有这个能力。

HTTP 协议为了满足这样的需求，提出了“范围请求”（range requests）的概念，允许客户端在请求头里使用专用字段来表示只获取文件的一部分，相当于是客户端的“化整为零”。

范围请求不是 Web 服务器必备的功能，可以实现也可以不实现，所以服务器必须在响应头里使用字段“Accept-Ranges: bytes”明确告知客户端：“我是支持范围请求的”。

如果不支持的话该怎么办呢？服务器可以发送“Accept-Ranges: none”，或者干脆不发送“Accept-Ranges”字段，这样客户端就认为服务器没有实现范围请求功能，只能老老实实地收发整块文件了。

请求头 Range 是 HTTP 范围请求的专用字段，格式是“bytes=x-y”，其中的 x 和 y 是以字节为单位的数据范围。

要注意 x、y 表示的是“偏移量”，范围必须从 0 计数，例如前 10 个字节表示为“0-9”，第二个 10 字节表示为“10-19”，而“0-10”实际上是前 11 个字节。

Range 的格式也很灵活，起点 x 和终点 y 可以省略，能够很方便地表示正数或者倒数的范围。假设文件是 100 个字节，那么：

“0-”表示从文档起点到文档终点，相当于“0-99”，即整个文件；
“10-”是从第 10 个字节开始到文档末尾，相当于“10-99”；
“-1”是文档的最后一个字节，相当于“99-99”；
“-10”是从文档末尾倒数 10 个字节，相当于“90-99”。

六服务器收到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 发给客户端，一个范围请求就算是处理完了。

有了范围请求之后，HTTP 处理大文件就更加轻松了，看视频时可以根据时间点计算出文件的 Range，不用下载整个文件，直接精确获取片段所在的数据内容。不仅看视频的拖拽进度需要范围请求，常用的下载工具里的多段下载、断点续传也是基于它实现的，要点是：

先发个 HEAD，看服务器是否支持范围请求，同时获取文件的大小；
开 N 个线程，每个线程使用 Range 字段划分出各自负责下载的片段，发请求传输数据；
下载意外中断也不怕，不必重头再来一遍，只要根据上次的下载记录，用 Range 请求剩下的那一部分就可以了。

七多段数据

刚才说的范围请求一次只获取一个片段，其实它还支持在 Range 头里使用多个“x-y”，一次性获取多个片段数据。这种情况需要使用一种特殊的 MIME 类型：“multipart/byteranges”，表示报文的 body 是由多段字节序列组成的，并且还要用一个参数“boundary=xxx”给出段之间的分隔标记。

多段数据的格式与分块传输也比较类似，但它需要用分隔标记 boundary 来区分不同的片段，可以通过图来对比一下。

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

参考：把大象装进冰箱：HTTP传输大文件的方法 (geekbang.org)

收录于