📚 课程目录第4章 HTTP/HTTPS协议基础

4. HTTP/HTTPS 协议基础：Range 请求头、Content-Range 响应头、断点续传的 HTTP 语义

做 OTA 的人，要是搞不懂 HTTP 的 Range 机制，那断点续传基本就是空中楼阁。我见过不少团队，上来就自己造轮子，搞什么分片标记、本地偏移量记录，折腾一圈发现——其实 HTTP 协议早就把这事定义得明明白白了。

说白了，断点续传在 HTTP 世界里就两个核心：客户端告诉服务器我要哪一段，服务器告诉我这一段是什么。就这么简单。

客户端发起续传时，会在请求里带上 Range 头。格式长这样：

Range: bytes=5000-9999

意思是：我要第 5000 到第 9999 字节的数据。注意，HTTP 里的字节范围是从 0 开始计数的，而且两端都是闭区间。

我遇到过有人把范围写成 bytes=5000-10000，结果多要了一个字节，校验和死活对不上。排查了半天才发现是边界问题。

Range 头还有几种变体：

车载场景下，最常用的是 start- 这种格式。比如下载到 5000 字节时断了，重连后直接发 Range: bytes=5000-，服务器就从断点往后发。

我的习惯：在车载 OTA 客户端里，我会把已接收的字节数持久化到 /data/ota/download_progress 文件里。每次断连后读取这个值，构造 Range 头。别放内存里，车机一断电就丢了。

服务器收到 Range 请求后，如果支持断点续传，会返回 206 Partial Content 状态码，并在响应头里带上 Content-Range。

格式是这样的：

Content-Range: bytes 5000-9999/10000

斜杠前面是实际返回的字节范围，斜杠后面是整个文件的总大小。这个总大小很关键——客户端拿到它，就知道整个升级包有多大，可以提前分配存储空间。

我建议你在客户端做这么一件事：

  核心要点：Content-Range 里的总大小是「整个资源的大小」，不是「剩余大小」。很多新手会搞混，以为斜杠后面是还没下载的部分。

把上面两个头组合起来，就是一次完整的断点续传流程。我画了张图，你看一眼就明白了：

流程其实就四步：

我曾经踩过的坑：有些老旧的车载 HTTP 服务器（比如某些供应商的嵌入式 HTTPD）不支持 Range 头，遇到 Range 请求直接返回 200 完整文件。客户端必须做兼容——收到 200 时，丢弃已下载的部分，重新下载整个文件。别问我怎么知道的，问就是被坑过。

HTTP 1.1 还支持多段 Range，即一次请求多个不连续的范围。响应会使用 multipart/byteranges 格式返回。

但在车载 OTA 里，我不推荐用多段 Range。原因有三：

我的做法是：一次只请求一段，串行下载。虽然慢一点，但稳定可靠。车载系统最怕的就是不稳定。

断点续传还有一个隐藏问题：服务器上的文件变了怎么办？

比如你下载到一半，服务器端换了一个新版本的升级包。这时候你拿着旧的 Range 去续传，拼出来的文件就是「前半段旧版本 + 后半段新版本」，校验和肯定过不了。

解决方案是用 ETag 或 Last-Modified 做条件请求：

GET /update.bin HTTP/1.1
Range: bytes=5242880-
If-Match: "abc123def456"

服务器发现 ETag 不匹配，会返回 412 Precondition Failed，客户端就知道文件变了，需要重新下载。

我的建议：在车载 OTA 客户端里，把 ETag 和已下载字节数一起持久化。每次续传前先比对 ETag，变了就清空进度重新下载。别省这一步，省了就是给自己挖坑。

HTTPS 本质上不影响 Range 语义——Range 和 Content-Range 是 HTTP 层面的东西，TLS 只负责传输加密。

但有一个实际问题：TLS 握手开销。每次断线重连都要重新握手，在信号不好的车载环境里，这个开销可能比传输数据本身还大。

我一般会做这么几个优化：

嗯，这些优化在 4G/5G 信号稳定的地方效果不明显，但在隧道、地库这些场景里，差别就大了去了。