plokmju

题图:by Charles Loyer

一、序

Hi,大家好,我是承香墨影!

HTTP 协议在网络知识中占据了重要的地位,HTTP 协议最基础的就是请求和响应的报文,而报文又是由报文头(Header)和实体组成。大多数 HTTP 协议的使用方式,都是依赖设置不同的 HTTP 请求/响应 的 Header 来实现的。

本系列《实用 HTTP》就抛开常规的 Header 讲解式的表述方式,从实际问题出发,来分析这些 HTTP 协议的使用方式,到底是为了解决什么问题?同时讲解它是如何设计的和它实现原理。

HTTP 协议是一种无状态的“松散协议”,它不会记录不同请求的状态,并且因为它本身包含了两端(客户端和服务端),根据请求和响应来区分,它大部分的内容都只是一个建议,其实双边是可以不遵守此建议的。

“这里写了建议零售价 2 元...”

“哦,不接受建议!”

文本是本系列的第五篇,前四篇传送门:

今天再来介绍一下 HTTP 的范围请求。范围请求主要是针对较大的文件的请求或者上传,可以仅操作它的某一段。

一个比较常见的场景,就是断点续传/下载,在网络情况不好的时候,可以在断开连接以后,仅继续获取部分内容。例如在网上下载软件,已经下载了 95% 了,此时网络断了,如果不支持范围请求,那就只有*重头开始下载。但是如果有范围请求的加持,就只需要下载最后 5% 的资源,避免重新下载。

另一个场景就是多线程下载,对大型文件,开启多个线程,每个线程下载其中的某一段,最后下载完成之后,在本地拼接成一个完整的文件,可以更有效的利用资源。

这算是两个比较常见的场景,接下来我们来看看范围请求的 HTTP 协议支持的技术细节。

二、HTTP 的范围请求

2.1 是否支持范围请求

HTTP 本身是一种无状态的“松散”协议,而在经历了很多版本的迭代之后,只在 HTTP/1.1(RFC2616) 之上,才支持范围请求。所以如果客户端或者服务端两端的某一端低于 HTTP/1.1,我们就不应该使用范围请求的功能。

而在 HTTP/1.1 中,很明确的声明了一个响应头部 Access-Ranges 来标记是否支持范围请求,它只有一个可选参数 bytes

例如这里给了一个 MP4 的响应头,可以看到它是有 Accept-Ranges:bytes 来标记的,有此标记标识当前资源支持范围请求。

2.2 使用范围请求

如果已经确定双端都支持范围请求,我们就可以在请求资源的时候使用它。

所有的文件最终都是存储在磁盘或者内存中的字节,对于待操作的文件可以将其以字节为单位分割。这样只需要 HTTP 支持请求该文件从 n 到 n+x 这个范围内的资源,就可以实现范围请求了。

HTTP/1.1 中定义了一个 Ranges 的请求头,来指定请求实体的范围。它的范围取值是在 0 - Content-Length 之间,使用 - 分割。。

例如已经下载了 1000 bytes 的资源内容,想接着继续下载之后的资源内容,只要在 HTTP 请求头部,增加 Ranges:bytes=1000- 就可以了。

Range 还有几种不同的方式来限定范围,可以根据需要灵活定制:

1. 500-1000:指定开始和结束的范围,一般用于多线程下载。

2. 500- :指定开始区间,一直传递到结束。这个就比较适用于断点续传、或者在线播放等等。

3. -500:无开始区间,只意思是需要最后 500 bytes 的内容实体。

4. 100-300,1000-3000:指定多个范围,这种方式使用的场景很少,了解一下就好了。

HTTP 协议是一种双边协商的协议,既然请求头部已经确定是使用 Ranges 了,还有响应头部中,也需要使用 Content-Ragne 这个响应头来标记响应的实体内容范围。

Content-Range 的格式也很清晰,首先标记它的单位是 bytes 然后标记当前传递的内容实体范围和总长度。

Content-Range: bytes 100-999/1000

在这个例子中,会传递 100 ~ 999 范围的内容实体,而该资源文件的总大小是 1000 bytes。并且此时的 HTTP 响应状态码为 206 Partial Content

HTTP 206 Partial Content 成功状态响应代码表示请求已成功,并且主体包含所请求的数据区间,该数据区间是在请求的 Range 首部指定的。

有关 206 状态码的解释可以参考:https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/206

所以一个正常的流程应该如下图所示:

注意这里的每个 HTTP 事务中的响应头里,都是会包含 Content-Length 的,只是它包含的是当前范围请求响应的内容实体长度,而非此资源完整的长度。

到这里基本上算是讲清楚 HTTP 范围请求的正确流程了,接下来看看一些特殊的情况。

2.3 资源变化

当我们在一些下载工具中,下载大尺寸资源的时候,偶尔中间暂停过再重新下载,可能会遇见它又重头开始下载的情况。

这看似是 HTTP 的范围请求失效了,但是实际上并不一定如此,很可能是因为请求的资源,在请求的这个过程中,发生了改变。

假如你下载的过程中,下载的源资源文件发生了变化,但是 URL 没有改变,此时文件长度可能已经变化了(这是非常容易发现的),极端情况下就算没有长度没有变化,你再继续下载,很可能最终下载完成之后,无法将下载的内容拼接成我们需要的文件。

如果我们需要从服务器上下载某个资源,一定要预防此资源可能发生的变动。在之前讲 HTTP 缓存的时候讲到,在 HTTP 协议中,可以通过 ETag 或者 Last-Modified 来标识当前资源是否变化。

  • ETag:当前文件的一个验证令牌指纹,用于标识文件的唯一性。
  • Last-Modified:标记当前文件最后被修改的时间。

在 HTTP 的范围请求中,也可以使用这两个字段来区分分段请求的资源,是否有修改过,只需要在请求头中,将它放在 If-Range 这个请求报文头中即可。If-Range 使用 ETag 或者 Last-Modified 两个参数任意一个,原样填入即可。

此时,如果两次操作的都是同一个资源文件,就会继续返回 206 状态码,开始后续的操作,反之则会返回 200 状态码,表示文件发生改变,要从头下载。

需要注意的是 If-Range 需要和 Range 配合起来使用,否则会被服务端忽略。

再额外提一点,如果客户端请求报文头中,对 Range 填入的范围错误,会返回 416 状态码。

HTTP 416 Range Not Satisfiable 错误状态码意味着服务器无法处理所请求的数据区间。最常见的情况是所请求的数据区间不在文件范围之内,也就是说,Range 首部的值,虽然从语法上来说是没问题的,但是从语义上来说却没有意义。

有关 416 状态码,可以参考:https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/416

三、范围请求的例子

3.1 用 Chrome 播放一个适配

前面介绍的概念,很多技术点其实描述的都是某一个请求片段,接下来我们以一个实际的例子来说明范围请求的具体细节。

在这个例子中,我找了一个视频的播放地址,直接在 Chrome 中进行播放。正常播放之后,再随手拖动视频进度,之后无操作让其自动播放一段时间,来看看 HTTP 的事务报文。

简单描述一下情况,自然播放的时候,会首先想资源的 URL 发送请求,返回 200 的响应码,可以判断出当前资源支持 Accept-Ranges,接下来会去使用 Range 发送范围请求,得到的响应码就是 206,并返回对应范围的实体内容。而在每次拖动进度的时候,都会去重新发送一个范围请求,依照拖动的进度来计算请求范围。此处不存在资源被修改的情况,所以不会出现重新请求下载的情况。

就不一个一个对 HTTP 事务截图了,大概抽象了一下流程,如下图所示:

可以看到,一次资源下载其实包含了很多次的请求过程,我们需要站在全局的角度来看到它。

四、范围请求小结

到这里我们就已经把 HTTP 范围请求的整个流程都说明清楚了。

再重新整理一下关键点:

1. HTTP 范围请求,需要 HTTP/1.1 及之上支持,如果双端某一段低于此版本,则认为不支持。

2. 通过响应头中的 Accept-Ranges 来确定是否支持范围请求。

3. 通过在请求头中添加 Range 这个请求头,来指定请求的内容实体的字节范围。

4. 在响应头中,通过 Content-Range 来标识当前返回的内容实体范围,并使用 Content-Length 来标识当前返回的内容实体范围长度。

5. 在请求过程中,可以通过 If-Range 来区分资源文件是否变动,它的值来自 ETag 或者 Last-Modifled。如果资源文件有改动,会重新走下载流程。

再配一张流程图,就更清晰了。

到此 HTTP 范围请求的所有关键技术点,就已经讲解清楚。范围请求被用在诸如:断点续传、多线程下载等场景下,大部分 CDN 上的资源都是支持范围请求的,具体你能在什么场景下应用,就看你的想象力了。

还有什么更多的想法,欢迎留言讨论。


公众号后台回复成长『成长』,将会得到我准备的学习资料,也能回复『加群』,一起学习进步;你还能回复『提问』,向我发起提问。

推荐阅读:

Android P 适配经验 | 技术创业选择清单 | HTTP传输编码 | 什么正在消耗你? | HTTP 内容编码 | 图解 HTTP 缓存 | 聊聊 HTTP 的 Cookie | 辅助模式实战 | Accessibility 辅助模式 | 小程序 Flex 布局 | 好的 PR 让你更靠谱 | 密码管理之道

相关文章: