问题描述
CDN控制台显示05-24日CDN回源带宽突增，同时访问有异常，有很多5xx错误。
排查过程
1. 监控查询
控制台查看监控信息，发现一周内同比对比，访问带宽并没有突增，跟周围几天的业务量保持一致，说明业务侧并没有明显的上量，但是回源带宽在异常时间确实有一个突增，而且命中率突降。
2. 日志查询
下载对应时间段CDN的日志，发现有大量的httpcode为206的range日志，请求的是zip后缀的大文件。分析日志查询前10的clientip，例如top1的clientIP在1小时日志里有上万条请求，都是range请求zip。
cat log_file | awk '{print $3}' |sort|uniq -c|sort -nr |head -10
3. 查询配置
查询range配置，发现CDN上并没有开启range回源。同时直接range请求源站，发现源站并不支持range请求。由此问题基本明确是range原因产生。
问题原因
在5.24日上午的时候，07:00～11:00期间，有一些客户端在请求一些大文件，比如类似日志里分析的zip。由于文件比较大，客户端发的是range请求，range的形式分片去请求。而这个文件由于在CDN上没有缓存，因此CDN需要去回源。另外由于CDN上没有配置开启range回源，因此虽然客户端请求的时候带了range，但是CDN回源请求源站的时候是不带range的，CDN是向源站请求完整的数据然后返回给客户端。但是由于客户端拿完他该拿的数据部分（range的部分）就断开了，客户端的断开导致CDN跟源站的连接也断开了，这种情况下这个文件并没有缓存到CDN上。然后客户端继续发range请求，CDN继续做同样的动作，因为一直缓存不住，而客户端又一直在range请求，CDN就会一直回源，造成回源带宽增加，源站的压力增大，产生了一些504。
解决方案
这种情况建议CDN上开启range回源，这样CDN也会range的形式请求源站，并且把range到的部分缓存到CDN上，不过前提是需要源站支持range请求。不过现在直接测试源站，发range请求，源站返回的是完整部分，因此源站不支持range请求，这样即使CDN range回源也达不到效果，因此需要源站开启range功能，然后CDN开启range回源来优化这个场景。
适用产品
- CDN
- 全站加速
