从断点续传故障排查，分析浏览器是怎么实现断点续传的

自研实现文件上传下载的中间件在测试阶段发现断点续传有问题。具体表现是：使用wget下载mp4文件可以正常播放，用google浏览器打开链接，google浏览器无法正常播放mp4视频。

排查思路首先是打开浏览器的开发者工具视图，查看网络请求。发现浏览器一共发起两个请求，一个是不带Range的下载整个文件的请求，一个是带Range: bytes=0-的http range请求，这两个请求都是响应2xx状态码。

请求状态码正常，那么只能抓包分析了。

通过tcpdump命令抓取这两个请求的数据包，然后用Wireshark工具分析。

不带Range的下载整个文件的请求，抓包结果如下：

其中36780端口是中间件服务的端口。从截图可以看出，是浏览器主动向服务端发起的断开连接，TCP报头标志位为[RST]。然后也能看出基本每个TCP数据包都重传了两次，客户端也重复ACK了两次，说明也没有丢包。

那为什么数据还没有传完，也没有什么异常，浏览器为什么要主动断开连接呢？

接着我们看带Range: bytes=0-的http range请求，抓包结果如下：

基本跟前一个请求的表现一致，也是浏览器主动断开了连接，数据也没有传完。

我打算换个浏览器看看，然后我换成使用Safari浏览器。同样的，视频也无法在Safari浏览器上播放。

查看Safari浏览器的网络请求，同样也是发起了两次请求，一次是下载完整文件的请求，一次是http range请求。下载完整的文件请求，响应状态码是200，但为什么显示红色异常？而google浏览器是显示正常。

通过抓包分析后，其实与google浏览器的表现是一样的，也是浏览器主动断开的连接。

浏览器为什么会发起两个请求？感谢这篇文章：https://www.hustyx.com/misc/358/

我觉得这篇文章有些地方说的不对，因为从表现看对不上，下面是我个人理解的浏览器播放mp4视频的流程：

Google浏览器：

浏览器不知道服务端是否支持range请求，所以它会发送一个普通的http请求以获取整个视频文件。
浏览器发送一个range探测请求Range: bytes=0-，服务端接收后会补齐终点位置，返回的是： Content-Range: bytes 0-end/total，这样浏览器就拿到了总文件大小。浏览器不会等到接收完数据，不管响应的数据有没有接收完，他会立马断开连接，前一步下载整个文件请求的连接也会断开。
如果探测请求探测到服务端支持range协议，那么浏览器就开始走Range协议。Google浏览器总是发送 Range: bytes=start- (不指定end)，start为上次接收到的位置，服务端每次都补齐end和total，返回状态码206，表示Partial Content，浏览器开始同步播放视频。循环反复直到文件下载完。

Safari浏览器：

浏览器不知道服务端是否支持range请求，所以它会发送一个普通的http请求以获取整个视频文件。
浏览器发送一个range探测请求Range: bytes=0-1，服务端接收后会补齐终点位置，返回的是： Content-Range: bytes 0-end/total，这样浏览器就拿到了总文件大小。如果探测请求探测到服务端支持range协议，前一步下载整个文件请求的连接也会立即断开。
如果探测请求探测到服务端支持range协议，那么浏览器就开始走Range协议。接着浏览器发送Range: bytes=0-end，浏览器不会等到接收完数据，接收一部分数据后他会立马断开连接。
Safari浏览器总是发送Range: bytes=start-end，start接着前一次接收到的end位置开始（每一次取多少字节看不出规律）。循环反复直到文件下载完。

到这就真相了，由于浏览器的探测请求不会等待所有数据响应完成，如果探测到服务端支持range协议，那么就会断开下个整个文件的请求的连接。

现在再来分析异常，我们从Safari浏览器的第二个请求发现了问题所在。

从截图可以看出，浏览器请求的range是0-1，而服务端响应的是0-13250517/13250517，而且end还错了，应该是文件大小减1。所以服务端处理分片下载的逻辑，响应头Content-Range是有问题的。

修复后视频就能正常播放了。

文章推荐