用「超装逼」排查CDN流量剧增问题
Background Information
我是江户川乱步，目前在侦探社担任调查员。
我拥有侦探社首屈一指的头脑，是侦探中的侦探。虽然具备超群的观察能力和推理能力，不过个性比较难以捉摸，说话不会看气氛，喜欢更符合客观逻辑的做事。不讨好媚俗，第一次见面一般会称对方为 「傻逼」 。
作为侦探社核心，我的能力是 「超装逼」。
老子是真正的天才，所以总是孤独的。正所谓天下地上，唯吾独尊。清华北大应该给我顺丰快递一张本科毕业证书，普林斯顿大学欠我一个博士学位，中科院应该聘请我去当个院士，诺贝尔更欠我一个经济学奖。
好了，不吹牛逼了。让我们回到原来问题，用 5W1H 来重新分析这个问题。
When,Where,What,Who
最近一个月（2020-04至今），我发现阿里云CDN费用剧增。
按照二八法则分析，主要矛盾在于图片域名的流量非常高。
图片域名用的是多线路 cname 解析，国内按流量计费的阿里云CDN，国外用按带宽计费的网宿CDN。综合考虑之后，我发现混合策略才是最优解，具体见
《
多公有云CDN最佳实践
》。
Why
直接说结论，那也太无聊了。我决定发动我的「超装逼」技能来解决这个问题。
网站的解析用的是cname，主要面向国内用户
--> 正常用户的特征是国内的固定IP，且访问次数有限
--> 一部分异常用户用国外IP
--> 一部分异常用户的特征是国内变动IP，且每个IP访问流量巨大
对于国外IP，我用了以带宽计费的网宿。
对于国内的IP，我一开始觉得是爬虫的问题。刚好阿里云在公测CDN频次控制功能。就顺便加入了他们的群公（吐）测（槽）一把。
外部原因
在不改任何代码的情况下，治疗爬虫的办法就是封IP。于是我从网宿和阿里云那边找了那些比较贱的IP，然后加以封禁。
但这里面有个蛋疼的地方在于，即便开通了CDN频次控制以及封禁IPV4，这种做法也是治标不治本。
全国多地ping被攻击域名，得到一个阿里云CDN节点的IP列表，然后循环依次请求。 假设循环50次，那么一个IPV4就能放大成50倍的请求次数。
阿里云CDN对每个域名，最多只能屏蔽100个IP。目前CDN频次控制单节点检测也不管用。如果用IP池，kubernetes僵尸网络，QPS可以控制到更低。
腾讯云是增加了一个全国范围的流量限制，超过了返回404。但是这个不是封ip，会让所有人都访问不了。
如果更倒霉，遇到 challenge collapsar，那就准备给阿里云送钱吧。
内部原因
在排查问题过程中，我发现了一个本不该出现的IP。
那个IP是阿里云VPC下的一个SNAT网关IP。这个IP的出现，只会说明一个问题： kubernetes 内部容器通过公网访问OSS
2018年09月04日 03时02分24秒 ，我在公司内部文档是这么写的：
So,怪我文档写的不仔细咯？
How
在不改代码的前提下，解决方案有：
- 建一个中转的
Nginx源站，回源OSS。对外返回 Brotli 编码的图片。 - 使用内网域名读写OSS。
有条件改代码的话使用 URL鉴权 。
其他费用
CDN是边缘计算。如果某个CDN节点上没有资源的副本，那么该节点就会回源，从而产生回源流量。
也就是说，如果在阿里云内部用公网回源OSS,一次请求有可能产生三种费用。
- CDN流量费用
- OSS下行流量费用
- CDN HTTPS请求数计费
网宿，请你争气一点
好好的一家公司，不推进项目，不投入研发，大股东整天想着减持，管理层变着名目和花样想把几个亿理财资金弄到自己腰包里，不思进取，气死沉沉，让股价一跌再跌，就问网宿，你怎么对得起，一直支持你的股民！！！
引用网友的评论，结合自身的实际用户体验，我希望网宿别那么快倒闭。
结论
中国商用带宽的流量费用过高。