案例分析，Mac与iOS客户端无法播放视频，服务端的问题？ _生活知道

0 – 本案例所涉及的知识点
HTTP协议范围请求允许服务器只返回一部分资源到客户端，范围请求在传送大的媒体文件，或者与文件下载的断点续传功能搭配使用时非常有用。
涉及知识点：nginx http协议
1 – 案例概要
前端用户反馈，在Mac或iOS下Safari浏览器无法播放视频，但Chrome等浏览器又可以，视频由HTML5的Video标签实现，简化示例代码如下：
demo
2 – 故障重现
分别通过Safari与Chrome浏览器打开，并同时开启开发者模式：
safari访问情况，视频无法打开：
chrome访问情况，视频打开正常：
对比之下容易发现发现请求头略有不通之处，主要差别在于Range的值。
safari为：
Range: bytes=0-1
chrome为：
Range: bytes=0-
3 – 初步假设
大概率问题围绕在Range请求头相关。
4 – 理论知识
在HTTP协议请求中，可通过设置请求头：Range ，实现范围数据获取，告知服务器返回资源的哪一部分。请求某范围内的资源可以更有效地对大型对象发出请求（分段对其发出请求），或者更有效地从传输错误中恢复（允许客户端请求没有完成的那部分资源）。
在一个Range请求头中，支持三种请求方式：单一范围查询、多重范围查询、条件范围查询。
单一范围查询：
Range: =-Range: =-
多重范围查询：
Range: =-, -Range: =-, -, -
条件范围查询：
If-Range: entity-tagIf-Range: HTTP-dateRange: =-
条件范围查询需配合If-Range实现，当字段值中的条件得到满足时， Range头字段才会起作用，HTTP-date为资源Last-Modified时间， entity-tag一般设置为资源的md5值（不管Last-Modified或etag ，首先需确保资源存在该响应头）。
并不是所有服务端都接受范围请求，但很多都可以。服务端可以通过在响应中包含Accept-Ranges请求头向客户端说明可以接受范围请求，这个值在HTTP1规范中只定义了bytes，表示范围的单位是以字节计算的。
Accept-Ranges: bytes 范围请求的单位是 bytes （字节）Accept-Ranges: none 不支持范围请求，其等同于没有返回此头部，因此很少使用
5 – 疑点提出缓存在服务器中的资源请求头是否包含Accept-Ranges ，能否支持Range请求？如果主动在缓存服务器设置返回Accept-Ranges请求头呢？如果主动在真实服务器设置返回Accept-Ranges请求头呢？客户端通过范围请求资源，如果缓存服务器没有数据，那缓存服务器的行为是什么？如果缓存服务器不存在资源而客户端又是范围请求，缓存的数据会是部分吗？6 – 实践检验6.1 – 实验前准备
-r, --range RANGE 获取资源数据的范围，从字节哪里到哪里-I, --head 只获取响应头信息，不捕获响应体，也就是Head请求
登陆缓存服务器，查看nginx.conf中的proxy_cache设置
nginx.conf设置示例：
proxy_cache_key $host$uri;proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m;
如上所示，假设$host=example.com，uri=/hello/world.jpg，则缓存在本地磁盘可通过如下算法获得：
echo -n 'example.com/hello/world.jpg' | md5sumd34eacb50650153d77e82aded8de91a0
【案例分析，Mac与iOS客户端无法播放视频，服务端的问题？】即存在路径，路径0与1a根据levels设置得出：
/data/nginx/cache/0/1a/d34eacb50650153d77e82aded8de91a0

文章插图
获取缓存前20行数据（主要是查看后端真实服务器的响应头）
strings /data/nginx/cache/0/1a/d34eacb50650153d77e82aded8de91a0 | head -n 20
手工删除缓存：
rm /data/nginx/cache/0/1a/d34eacb50650153d77e82aded8de91a0 | head -n 20
以上步骤将会在以下实验中不断使用到。
6.1 – 验证疑点1
通过curl命令进行模拟测试：
请求的资源字节范围为：1000-2000 。结果响应状态码为200，通过Content-Length可以看出，实际返回了整个资源，根据理论知识可知，实际是缓存服务器忽略了来自客户端的Range请求头。
可知缓存服务器并不支持Range请求范围查询。
6.2 – 验证疑点2
通过设置nginx的add_header指令对缓存服务器添加请求头
add_header "Accept-Ranges" bytes;
返回了Accept-Ranges请求头，但实际还是不支持Range请求范围查询。
通过缓存服务器，获取缓存文件前20行，如下：
实际缓存在服务器中的数据也不包含Accept-Ranges请求头。
6.3 – 验证疑点3
在真实服务器上主动设置返回Accpet-Ranges请求头请求中时间戳与服务器，同时清除缓存服务器上的缓存数据。
Accept-Ranges: bytes
查看缓存服务器上的数据，来自源服务器的响应头：
缓存在服务器上的数据包含Accept-Ranges，也就是来自源服务端的响应包含此请求头，此时缓存服务器对客户端是支持Ranges的范围请求了。
6.4 – 验证疑点4、5
由实验3可知，当缓存不存在时，即时客户端为范围请求数据，缓存在本地的数据均为整体，而非部分。
通过nginx官方的ngx_http_proxy_module文档，存在如下关键描述：
If caching is enabled, the header fields “If-Modified-Since”, “If-Unmodified-Since”, “If-None-Match”, “If-Match”, “Range”, and “If-Range” from the original request are not passed to the proxied server.
大意如下：如果设置了缓存，则不会对客户端请求中的“If-Modified-Since”, “If-Unmodified-Since”, “If-None-Match”,“If-Match”, “Range”, “If-Range”这几个请求头传递到后端真实服务器。
所以客户端通过范围请求资源，如果缓存服务器没有数据，那缓存服务器将会去源站获取整个数据并缓存请求中时间戳与服务器，而不管客户端是否为范围请求。
7 – 问题定位
此时缓存服务器支持Range范围请求之后，在通过浏览器查看效果：
由于担心涉及版权，播放效果的图片取消了。
此时不在是原先的黑屏，可正常播放视频了。
8 – 解决方案8.1 – 方案1
由源服务器程序实现范围请求功能，返回给缓存服务器时需明确包含Accept-Ranges头，如果值非bytes，为其他自定义类型，则两端均需对该类型的实现。
8.2 – 方案2
如果缓存服务器是基于nginx1.7.7及以上版本，可通过设置proxy_force_ranges参数值为on来实现，默认为off，而不管后端服务是否设置Accept-Ranges请求头。
Syntax: proxy_force_ranges on | off;
Default: proxy_force_ranges off;
本文到此结束，希望对大家有所帮助！

案例分析，Mac与iOS客户端无法播放视频，服务端的问题？

猜你喜欢