1 个用户,1 天,对同一文件的数百万个请求

1 个用户,1 天,对同一文件的数百万个请求

帮助!

场景如下:

我正在托管和投放展示广告。这些广告包括一些媒体创意和一些用于组装和展示广告的 JavaScript 文件。这些文件托管在 CDN 上。

我们在周末对 1 条广告进行了小规模测试。它消耗了大约 10,000 次展示。在查看我的 CDN 日志时,我注意到一个 IP 请求单个媒体文件,平均每秒约 2-3 次,文件点击次数超过 160 万次。所有这些都发生在 24 小时内!

现在这是一个大问题,因为我需要支付带宽费用,而且目前我们已经无缘无故地传输了超过 1 TB 的数据。

为什么会发生这种情况?我该怎么做才能防止任何东西像这样直接访问文件?只有当 javascript 将它们调用到广告位置时,才应该访问它们。

CDN 日志中的以下几行:

#字段:时间戳、所用时间、c-ip、文件大小、s-ip、s-port、sc-status、sc-bytes、cs-method、cs-uri-stem、rs-duration、rs-bytes、c-referrer、c-user-agent、客户 ID、x-ec_custom-1
1305405902 116 XX.XX.XX.XX 1281559 XX.XX.XX.XX 80 TCP_HIT/200 327990 GET http://XXXXXXXXXX.ogg - 0 557 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 ( .NET CLR 3.5.30729)" 10629 "-"
1305405902 89 XX.XX.XX.XX 1281559 XX.XX.XX.XX 80 TCP_HIT/200 655670 GET http://XXXXXXXXXX.ogg - 0 557 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 ( .NET CLR 3.5.30729)" 10629 "-"
1305405902 86 XX.XX.XX.XX 1281559 XX.XX.XX.XX 80 TCP_HIT/200 453386 GET http://XXXXXXXXXX.ogg - 0 557 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 ( .NET CLR 3.5.30729)" 10629 "-"
1305405902 7 XX.XX.XX.XX 1281559 XX.XX.XX.XX 80 TCP_HIT/200 1281869 GET http://XXXXXXXXXX.ogg - 0 557 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 ( .NET CLR 3.5.30729)" 10629 "-"
1305405903 86 XX.XX.XX.XX 1281559 XX.XX.XX.XX 80 TCP_HIT/200 786742 GET http://XXXXXXXXXX.ogg - 0 557 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 ( .NET CLR 3.5.30729)" 10629 "-"

答案1

你可以...

设置过期标头在 http 响应上......

由于你没有提到 CDN,我不知道他们会如何让你影响这一点。他们可能会通过不允许这样做而从可怜的客户身上赚大钱 :) 在这种情况下,快跑,不要走,去一个允许这样做的 CDN

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21

编辑单个 IP?您已经运行 whois 了……也许您可以从那里联系滥用联系人

答案2

我以前见过这种情况(讽刺的是,我曾经签约过一家广告网络)——他们的 Javascript 中有一个错误,在某些罕见但并非未知的情况下,会导致客户端陷入无限循环并不断尝试检索广告。他们的运行已经非常接近其托管基础设施的极限,并且每天的展示次数超过 8000 万次,因此只需要一小部分行为不当的客户端就会对他们的正常运行时间造成严重损害——这实际上是一次自我强加的 DDoS。开发人员修复了这个错误真实的很快,但最后一个行为不端的客户端花了几天的时间才消失(人们打开浏览器的时间比我预期的要长得多)。

相关内容