自从YT部署了反迅雷策略以后,服务器的流量没这么大了。普他下载主要还是以用户代理字串判断来识别迅雷,YT网站的音乐下载则采用定期改变下载地址的方法。现在YT的服务器流量一直比较正常,没有再被迅雷拖累了。虽然新版的迅雷已经修改了自己的特征,绕过了YTS的反迅雷策略,但是似乎使用迅雷新版的用户不多,YTS的流量也没有受到太大的影响。
不过这样下去显然是不行的,使用新版迅雷的人会越来越多,有朝一日YTS肯定又会变成带宽被迅雷吃尽的状况。说起来迅雷也真是太不厚道了,都已经盗链这么久了还不反省,再这样下去我都忍不住想采用不厚道的手段对付迅雷了。
这个不厚道的手段实际上针对的是迅雷用户,正因为是针对用户的,所以我才说这个手段不厚道。
这个不厚道的手段是,如果发现客户端是迅雷,就给客户端返回脏数据。所谓的脏数据就是指不是用户想要得到的数据,比如说一串随机二进制流。假设一个用户正在下载一个比较大的名为A.zip压缩包,服务器发现客户端是迅雷,那么首先返回A.zip的实际大小,然后就发送随机二进制流给客户端,而不发送A.zip的内容。这样用户看起来下载情况很正常,但是下载完成后得到的文件实际上并不是完整的A.zip,用户基本上也没法打开下载到的A.zip。
所以说这是非常不厚道的方法,主要针对使用迅雷的用户。你要用迅雷是吧,我就让你下载不到完整的东西。不仅下载不到,而且还要浪费你下载的时间,让你重新去下载。而就算重新去下载,迅雷还是有可能从我的服务器上下载到脏数据,用户还是没能下载到完整正确的A.zip。如果迅雷不把我的服务器连接从迅雷的索引服务器上移除的话,就等着用户抱怨吧。
好吧这方法是非常不厚道的,至少现在迅雷还没有对我的服务器造成太大影响,暂时不管。以后如果造成影响的话,先在反迅雷策略上更新迅雷的特征。如果以后(我想基本上是必然的了)迅雷还修改特征的话,那对不起用户了,我将部署返回脏数据的策略。
另外再吐两句,迅雷的多源盗链下载的方式必然和普通的下载方式有不同之处,既然有不同之处,就一定可以找到方法识别出迅雷。方法总会有的,只是能不能想到的问题。
另外服务器反迅雷策略还有几个,下面说一个:
一用户一地址:给每个用户生成不同的下载地址,且该下载地址有流量配额,从该地址下载的流量达到文件流量后,该地址自动失效(好吧当然你也可以返回脏数据 = = ……%)。之前JShare就是使用这个方法的,现在好像应该还是用着这个方法。
说起来我还想到了个东西:迅雷钩子。迅雷总是改特征,这样迅雷只要一更新我就要下载一个回来测试,那还真是麻烦的说。于是想到这样一个办法,在服务器上放一个热门资源,比如说新番动画啊最新电影啊之类的,只要把文件放在服务器上,下载地址不公开。然后,自己使用迅雷下载一次这个文件,这样这个未公开的文件下载地址就会传回迅雷的索引服务器。接着只要定期该文件的下载日志就可以知道来盗链的都是哪些家伙了,在服务器已经部署了反迅雷策略的情况下,只要发现有某个请求成功下载到了这个文件,那就可以对这个请求传给服务器的数据进行分析了,基本上就可以肯定这家伙就是迅雷了。
再说服务器反迅雷,一个很不厚道的方法
6 thoughts on “再说服务器反迅雷,一个很不厚道的方法”
F-22's Trace
greensea 的个人主页
sky-city
极夜奁
小樱之町
呃,真的正解么
感觉QOS这种东西的设计很bug。。。
楼下正解
只有一个人在下就75%
也就是说不是用迅雷下也75%
那只能说你的程序有问题了。。
我很喜欢这个脏数据的办法啊
我在内网架的nas,被X雷弄到cpu 75%
只有1个人在下就75%啊
呃,想知道返回脏数据之后迅雷会有啥反应
呃,我是指如何处理索引。。
估计是认为下载错误然后提示下载失败
至于会发送什么消息给索引服务器嘛……有时间试验看看……