一个斜杠引发的CDN资源回源请求量飙升

技术分享 1年前 (2023-03-28) 0 999+

背景

一个安静的晚上，突然接到小伙伴电话线上CDN回源异常，具体表现为请求量飙升，且伴有少量请求404，其中回源请求量飙升已经持续两天但一直未被发现，直到最近404请求触发了告警后分析log才同时发现回源量飙升这一问题。
触发问题的原因很快被发现并修复上线，这里分享一下跟进过程中进一步学习到的CDN回源策略、301触发机制原理等相关概念与知识。

多余斜杠(/)引发的流量飙升

大量301

通过查看源站nginx log，发现回源请求量比上周同一天飙升近1000倍，甚至开始怀疑是不是CDN厂商那边出问题了，进一步分析log后发现源站对于CDN的回源请求基本上都是301(Move Permanently)响应，此类响应占了95%以上，301表示永久重定向，这说明绝大部分回源请求都会被源站重定向到另一个地址。
咨询CDN厂商后确认，CDN节点对于源站的301请求默认是不跟随的，即CDN节点不会代为跳转到最终地址并缓存在本地后返回，而是直接返回给客户端301，最终由客户端自行进行301跳转。
那突然飙升的301请求是怎么来的？查看nginx 301请求的path后很快发现所有的CDN图片资源地址的path开头多了一个/，比如http://cdn.demo.com/image/test.jpg 会变成 http://cdn.demo.com//image/test.jpg ，此类请求源站会直接返回301 Location: http://cdn.demo.com/image/test.jpg ，即要求用户301跳转至去除多余/的版本。
这就产生了一个疑问，印象中源站的文件server是没有这种类似301的处理机制，那这个合并/的操作难道是发生在nginx？然而印象中nginx也没有进行过类似配置。

nginx的merge_slashes

再次check文件server代码确认没有合并/的301处理逻辑，并经过实测后确认其实是nginx做了这一步301的处理，nginx配置中有一个merge_slashes配置，官方文档说明如下：

Syntax:	merge_slashes on | off; Default: merge_slashes on; Context: http, server Enables or disables compression of two or more adjacent slashes in a URI into a single slash. Note that compression is essential for the correct matching of prefix string and regular expression locations. Without it, the “//scripts/one.php” request would not match location /scripts/ {     ... } and might be processed as a static file. So it gets converted to “/scripts/one.php”. Turning the compression off can become necessary if a URI contains base64-encoded names, since base64 uses the “/” character internally. However, for security considerations, it is better to avoid turning the compression off.

如上所示merge_slashes默认是开启的，其作用是将URI中多于2个的连续/合并为一个单一的/，也就是说无论是cdn.demo.com//a.jpg 还是cdn.demo.com///a.jpg , 都会被合并为cdn.demo.com/a.jpg 。

多余的/到底哪来的

没错，这是个低级错误--几天前刚修改了图片文件CDN URL组装的模块代码，赶紧回去diff一看发现图片资源model生成代码中有一行本地测试代码给手抖提交了(尴尬==!)，其最终效果就是导致所有CDN图片资源的URL path开头都会多出一个/，这多出的一个/只会导致图片加载变慢一些而非加载失败，所以大家使用app的时候也没有发现什么问题。
立刻把导致多余/的测试代码注释掉上线，并清理了一波线上相关缓存后，再回过头来观察源站的nginx log请求量肉眼可见的急速下降，后续少量404请求也逐渐消失了。

少量资源404怎么来的

虽然404请求也消失了，但是404出现的原因却依然没有定位到，整体来说404请求数量只有301请求的1%左右，而通过分析log发现404请求开始出现与消失的时机基本上与大量301请求的出现与消失是保持一致的，看上去两者直接是有相关性的。
仔细check 404请求的log，发现其path也很有规律，如：

GET /demo/image/icon.png,/demo/image/icon.png GET /demo/image/profile.png,/demo/image/profile.png GET /demo/image/head.png,/demo/image/head.jpg

拿这些path拼装完整URL如http://cdn.demo.com/demo/image/icon.png 其实是能成功获取到资源的，也就是说这些资源肯定是存在的，只是莫名原因客户端请求时其path部分重复拼接了一次，对应请求http://cdn.demo.com/demo/image/icon.png,/demo/image/icon.png 自然就是404了。
从整个CDN文件请求的流程上来说，存在四种可能：

首先怀疑的是服务端在拼接CDN URL时出错导致path重复拼接了，但是代码上确实没有找到值得怀疑的地方。
CDN节点在转发源站的301请求到客户端时响应的Location给拼接错了，考虑到CDN作为一个广泛使用的产品提供给这么多用户使用，CDN节点出错的可能性很低。
nginx在merge /后给出的301响应中的 Location 给错了，考虑到nginx这么千锤百炼的产品这种可能性极低。
不由得回忆起千奇百怪的android机型可能存在千奇百怪的各种情况（踩过的各种坑...），是不是某些小众机型在301跳转时其跳转机制存在问题？可惜源站并直接不能收到客户端的原始请求，因此无法分析此类404请求具体的客户端相关参数，暂时无法进一步分析。

因此目前只能从出现时机上推断404与大量请求的301出现有关联性，但是具体是哪一步有问题还没有办法定位--欢迎大家不吝赐教给出新的可能思路--在301问题修复后404请求已消失，暂且只可遗留至未来有缘再见了。

请求飙升而流量未飙升之谜

问题修复后突然疑惑为什么请求量飙升*1000+的数天，源站带宽没有被打爆呢？源站购买的带宽可是扛不住这*1000的流量呀!
仔细一思考后了然：因为这新增的的请求都是nginx直接返回的301而非实际目标文件，后续客户端301跳转到正确的URL请求后就进入正常的CDN回源->缓存->返回流程了,并不会给源站带来额外消耗。一个完整的301响应也就几百字节，所以实际对于带宽的消耗很小，1000个301响应所占的带宽也就相当于一张几百KB的图片占用带宽而已，所以万幸这一步带宽并没有出现问题。