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

帮帮我!

这是一个场景:

我正在托pipe和投放展示广告。 这些由一些媒体广告素材和一些JavaScript文件组成并显示广告。 这些文件托pipe在CDN上。

我们在周末做了一个小广告,试了一个广告。 它烧了大约10000印象。 在审查我的CDN日志时,我注意到一个IP正在请求一个单一的媒体文件,平均每秒大概2-3次,超过160万次点击文件。 所有在24小时内!

现在这是一个很大的问题,因为我要为带宽收费,而目前我们已经转移了TB,没有明显的原因。

为什么会这样? 我能做些什么来防止任何东西直接访问文件? 只有在JavaScript将其称为广告展示位置时才能访问它们。

来自CDN日志的行:

 #Fields:timestamp耗时的c-ip文件大小s-ip s-port sc-status sc-bytes cs-method cs -uri-stem -rs-持续时间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” - “ 

你可以…

在http响应中设置到期标题 …

既然你不提CDN,我不知道他们怎么会让你影响这个。 他们可能会通过不允许的方式让客户赚大钱。在这种情况下,运行,不要走路,到一个允许它的CDN

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

编辑一个单一的IP? 你确实运行过whois,也许你可以联系那里的滥用联系人

我曾经见过(具有讽刺意味的是,有一个广告networking,我曾经承诺过) – 他们在Javascript中有一个错误(在某些罕见但未知的情况下)导致客户端进入无限循环,并不断尝试检索广告。 他们的托pipe基础​​设施已经非常接近极限了,每天的浏览量高达8千万次,所以只有很less一部分客户对他们的正常运行时间造成了严重的损害 – 这实际上是一种自我实施的行为DDoS攻击。 开发者很快修复了这个bug,但最后一个行为exception的客户却花了几天时间(人们离开浏览器的时间比我预期的要长)。