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

背景

触发问题的原因很快被发现并修复上线，这里分享一下跟进过程中进一步学习到的CDN回源策略、301触发机制原理等相关概念与知识。

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

大量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

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 。

多余的/到底哪来的

立刻把导致多余/的测试代码注释掉上线，并清理了一波线上相关缓存后，再回过头来观察源站的nginx log请求量肉眼可见的急速下降，后续少量404请求也逐渐消失了。

少量资源404怎么来的

仔细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节点在转发源站的301请求到客户端时响应的Location给拼接错了，考虑到CDN作为一个广泛使用的产品提供给这么多用户使用，CDN节点出错的可能性很低。
nginx在merge /后给出的301响应中的 Location 给错了，考虑到nginx这么千锤百炼的产品这种可能性极低。
不由得回忆起千奇百怪的android机型可能存在千奇百怪的各种情况（踩过的各种坑...），是不是某些小众机型在301跳转时其跳转机制存在问题？可惜源站并直接不能收到客户端的原始请求，因此无法分析此类404请求具体的客户端相关参数，暂时无法进一步分析。

因此目前只能从出现时机上推断404与大量请求的301出

编程笔记 » 一个斜杠引发的CDN资源回源请求量飙升