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

背景

一个安静的晚上，突然接到小伙伴电话线上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也没有进行过类似配置。

似是301黑手的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 。
探索到这里的时候已经下意识的认为就是nginx的这个merge_slashes功能导致的返回301响应了，本来以这个为结论已经把blog都发布出来了，结果两天后看到博友@唐大侠灵魂拷问：“既然nginx默认开启合并/，为啥不起作用呢？”
陷入深思，回想之前尝试了好一会儿阅读nginx源码找寻merge_slashes具体触发301的代码逻辑，但是并没有在纷繁复杂的源码中捋清这个逻辑，于是在简单验证了直接通过HTTP调用后端server时并不会触发301后即直接将301的锅甩到了nginx头上，所以其实属于一个间接确认，并不能100%肯定。看似有必要重整旗鼓再探查一番301产生的迷雾，结果还真发现了迷雾背后另有真相。
先重新澄清一下merge_slashes的功能，merge_slashes在开启的情况下确实会合并path中的多余/，但是合并这块的逻辑仅发生在location match这一步，假设有以下配置

    location / {
        return 404;
    }
    location /scripts/  {
        proxy_pass http://127.0.0.1:6666;
    }

当merge_slashes开启时: //scripts/one.php 在匹配时会合并多余/视为/scripts/one.php 进行匹配，因此命中location /scripts/ 规则，但是命中后proxy_pass传递到upstream 服务的数据中其path依然会是原本的 //scripts/one.php ，而非合并版本。
而当merge_slashes关闭时: //scripts/one.php 直接和location /scripts/ 比较是不会match的，所以最终只能命中 location / 返回404。
所以merge_slashes只会在match location时合并/，而后将对应请求转入location后的处理流程，真正的301幕后黑手并不是它！！
任重道远，继续探寻，既然nginx上找不到301的真正黑手，又回过来来拷问文件server。

golang DefaultServeMux

源站的文件server是个golang 服务，之前只check了业务代码而没有考虑依赖的底层库，这次重整旗鼓研究一下net/http的相关源码。
在默认的ServerMutex实现中有一个Handler函数：

2322 func (mux *ServeMux) Handler(r *Request) (h Handler, pattern string) {
...
2335
2336     // All other requests have any port stripped and path cleaned
2337     // before passing to mux.handler.
2338     host := stripHostPort(r.Host)
2339     path := cleanPath(r.URL.Path)
2340
2341     // If the given path is /tree and its handler is not registered,
2342     // redirect for /tree/.
2343     if u, ok := mux.redirectToPathSlash(host, path, r.URL); ok {
2344         return RedirectHandler(u.String(), StatusMovedPermanently), u.Path
2345     }
2346
2347     if path != r.URL.Path {
2348         _, pattern = mux.handler(host, path)
2349         url := *r.URL
2350         url.Path = path
2351         return RedirectHandler(url.String(), StatusMovedPermanently), pattern
2352     }
2353
2354     return mux.handler(host, r.URL.Path)
2355 }

在上述代码的2339行会调用cleanPath， CleanPath又最终会调用path.Clean, path.Clean官方文档有介绍：

Clean returns the shortest path name equivalent to path by purely lexical processing. It applies the following rules iteratively until no further processing can be done:

1. Replace multiple slashes with a single slash.
2. Eliminate each . path name element (the current directory).
3. Eliminate each inner .. path name element (the parent directory) along with the non-.. element that precedes it.
4. Eliminate .. elements that begin a rooted path: that is, replace "/.." by "/" at the beginning of a path.

第一点就是明确说明会将多个slashes合并为单个slash，而在Handler代码2347行明确会判断原始的 r.URL.Path若与CleanPath处理过后的path不相等，则会通过 return RedirectHandler(url.String(), StatusMovedPermanently), pattern 直接返回301永久重定向。
文件server的HTTP启动代码是http.ListenAndServe(settings.HttpBind, nil)，即handler=nil，就会使用默认的DefaultServeMux，至此终于真相大白。
至于为什么之前为什么会有“于是在简单验证了直接通过HTTP调用后端server时并不会触发301后即直接将301的锅甩到了nginx头上” 这个情况，因为当时偷懒直接HTTP调用的不是golang的文件server而是golang版的log server，而log server中定义了自己的handler，因此并不会有默认handler的301逻辑--最终导致了错误的结论--偷懒早晚是要付出代价的==

多余的/到底哪来的

没错，这是个低级错误--几天前刚修改了图片文件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的图片占用带宽而已，所以万幸这一步带宽并没有出现问题。

总结

回顾本次事故，手抖真是万恶之源，本来是新增部分代码，结果不小心把之前的测试代码带上导致CDN 301请求飙升，具体对用户的影响：

所有图片类CDN请求均会多一次301跳转，根据用户所属地理位置与源站的距离加载耗时新增几到几百ms不等。
大约有1%左右的图片请求会因为重复拼接的path而被响应404。

行走码湖这么多年，终究还是踩下了这个测试代码提到线上导致事故的程序员经典大坑之一，引以为戒，引以为戒！

转载请注明出处，原文地址：https://www.cnblogs.com/AcAc-t/p/cdn_nginx_301_by_merge_slashes.html

参考

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/301
https://cloud.tencent.com/document/product/228/7183
https://www.cnblogs.com/AcAc-t/p/cdn_nginx_301_by_merge_slashes.html
http://nginx.org/en/docs/http/ngx_http_core_module.html#merge_slashes
https://juejin.cn/post/6844903850625761288
https://pkg.go.dev/path#Clean
https://weakyon.com/2017/04/25/redirect-of-golang-serverMux.html
https://stackoverflow.com/questions/47475802/golang-301-moved-permanently-if-request-path-contains-additional-slash

posted @ 2023-03-28 00:51 及时阅读(2642) 评论(6) 编辑收藏举报

刷新页面返回顶部