按流量付费的图片 CDN 如果想坑你是不是毫无办法？

[nikoo]

个人有一个练手作品，一个采集二手信息的网站，里面有一些物品的图片，之前就存在 VPS 上

后来由于某图片 CDN 大力宣传加发送代金券，就把新采集的图片上传至该图片 CDN

网站从未推广，放了几年，最后统计访问量每天几百，没挣过一毛钱

代金券消耗完后，邮件告诉我欠费了，一看账单近百，
我就很奇怪，网站明明没有那么大访问量，仅图片为什么能跑这么多流量？

开始怀疑是搜索引擎爬历史图片，或图被盗用了，所以做了如下操作：
1、每天通过 API 删除两个月以前图片的定时任务，也就是存在该 CDN 上只有近两个月的图片
2、最严格的防盗链，referrer 限制为仅唯一本域名可打开图片，none 都无法打开，也就是直接帖图片 URL 在浏览器是打不开的

本来以为有用，结果网站访问量不见升，CDN 账单破百了。

我就很奇怪，然后脑抽做了这么一个东西：
开启 nginx 针对所有图片的 access log，然后写了一个脚本统计每天具体访问图片的 request
然后针对这个 request 的 response size 统计出一个总流量来
这样我就知道每天到底图片流量跑了多少了

结果弄完才意识到，真是脑抽了，我在用高大上的图片 CDN 啊！！！
它只有一次的请求后就把图片缓冲在它一万个节点里去了，然后再也不会访问我的 nginx 了，它一万个节点不知道哪个节点跑的流量都会跟我算钱，并且我也根本没法统计流量被什么客户端跑走了。

想了想，非常绝望，图片被它的节点缓冲了，那么是不是它说跑了多少流量就是多少？
有没有任何方法可以验证真伪？玩的就是一个诚信？

[mason961125]

看下 CDN 的日志？

[0ZXYDDu796nVCFxq]

CDN 可以配置防盗链……

[nikoo]

@gstqc 配置了，"直接帖图片 URL 在浏览器是打不开的"

[iConnect]

cdn 都有消费控制的，自己设定下限制。

[0ZXYDDu796nVCFxq]

你可以下载访问日志

[coosir]

服务商是不是可以随便编一些流量出来 - -，反正你没法验证

[0ZXYDDu796nVCFxq]

@coosir 你可以下载访问日志
访问日志和你主站的访问做对比即可

[kslr]

你那个算什么防盗链

另外 CDN 去走你流量，明明不管是成本还是法律以及道德是得不偿失的事情，为什么这么多人会相信呢？

[kslr]

这里明明是技术社区，而大多数人都不知道先看看官方给的资料

[nikoo]

@mason961125 @gstqc 谢谢，搜了一下的确是可以通过开启空间的访问日志来获得日志文件

这个日志似乎默认是关闭的？

登录了一下发现：对不起，您的账户已被冻结

[nikoo]

@kslr 请问 CDN 的防盗链不是在 CDN 后台配置限制请求来路来做吗？

应该用什么正确的办法进行防盗链？

[kslr]

@nikoo #11 把空间改成私有的，每次下载生成授权。

https://developer.qiniu.com/kodo/manual/1644/security
https://developer.qiniu.com/kodo/manual/3796/set-the-log

[kslr]

@nikoo #11 但是我看你的网站是公开 cdn 加速，不太适合。我觉得还是从日志下手，分析流量来源到底在哪里

[nikoo]

@kslr 谢谢老铁，我之前真不知道这种防盗链安全机制

有没有这种安全机制下的站点或者 demo 可以观摩一下？谢谢！

[kslr]

@nikoo 流量稍微大点，基本都有，毕竟国内流量这么贵。不同的只是算法不一样，你可以根据 SDK 简单调用接口。
https://developer.qiniu.com/kodo/manual/1202/download-token

[nikoo]

@kslr 谢谢

我并不是想对 CDN 平台做有罪推断

出现的问题大多可能是由于我本人不认真研究、技术欠佳导致

综上回复学习到几点来解决该问题：
1、开启 CDN 访问日志
2、应用更为严格的 安全机制 - 下载凭证（ DownloadToken ）来验证每一个图片的访问请求

第二点实现起来难度大，需要为每次请求页面里的每一张图片生成其独立唯一的 Access Token，运算量有些大

[kslr]

@nikoo 关于第二点七牛不是太清楚，但是边缘计算肯定是趋势，也许会有相映的业务(比如 CloudFlare 的 workers，国内最近也频繁提到)。
我有一个大概每天 400 万请求的 CDN，每一份资源都依靠 edge 计算，这个算法只需要>5ms，实际上也不过是编辑转发请求。
Access Token 由后台维护，落地并没有多少请求

[kslr]

如果真的需要，我觉得可以单独维护 AccessToken，对每个链接签名，有效期 1 ～ 6 个小时等，压力就被分散了。
其实一台破机器也可以轻松解决，毕竟只是很简单的计算签名

[nikoo]

@kslr AccessToken 有效期 1 ～ 6 个小时？为什么不是 request 的生命周期的时间？我理解有效期 30 秒就够了（ 30 秒没返回一般就返回 time out 了）

难道是要针对客户端+图片对其 AccessToken 做一个缓冲？该用户访问某一图片一段时间内重复使用一个 AccessToken ？

[kslr]

根据文档 https://developer.*.com/kodo/manual/1202/download-token
定义
AccessToken 对应 MY_SECRET_KEY
token 是 url sign
那么也不需要维护“ AccessToken ”了

有效期是指如果链接在同一个时间点失效，会把压力集中到一个时刻。