Total Pageviews

Wednesday 13 February 2013

反迅雷

HTTP请求识别(用户代理方法)
        每一个HTTP请求都应该带有一个用户代理字串(User-Agent),不同的浏览器或下载工具所发送的用户代理是一般是不同的,迅雷也不例外。而很巧的是,迅雷发送的用户代理几乎是唯一的,通过这一点,我们就可以识别出迅雷的请求。
        迅雷所发送的用户代理有以下几种:
       
            Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
            Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
            Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; )
       
        第一个是旧版迅雷所发送的,后两者者是较新版(至少为V5.7.7.441版本或更早)迅雷发送的,第三个发现是从V5.7.7.446版本开始使用的;Web迅雷所发送的用户代理是:Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.0)。
        通过分析某两个网站超过6G的IIS日志,我们发现用户代理和以上两个迅雷的用户代理相同的连接绝大部分都是对资源型文件的请求。其中发现的极少一部分对普通页面的请求其行为记录不像是普通用户的浏览操作,因为这部分请求的页面请求间隔极短,最高达时请求频率超过每秒3个,由此我们猜测这一小部分是页面抓取程序所发起的请求。最后还有更少一部分的请求看样子是普通用户产生的,不过量极小,我们猜测可能是同一个用户发起的请求。
        知道了迅雷的用户代理以后,我们通过比对每一个请求所发来的用户代理,就可以识别出哪些请求是迅雷的,而哪些普通用户的请求。这就是通过HTTP限制迅雷的核心所在。
        由于也有可能有极小一部分用户使用和迅雷相同的用户代理,为了避免这些用户无法正常浏览网站,我们可以采取以下策略:
       
            限制或仅限制迅雷(或使用与迅雷相同户代理的用户)对资源型文件的请求
            限制或仅限制迅雷(或使用与迅雷相同户代理的用户)对大型文件的请求
            限制或仅限制带有Range请求头的迅雷(或使用与迅雷相同户代理的用户)的请求
       
        通过应用以上策略,我们就可以保证迅雷不会对网站造成太大影响,同时也保证了极小部分用户的正常浏览不会受到太大影响。
        虽然不同的迅雷版本有不用的用户代理(如迅雷国际版的用户代理可能就与迅雷不同),但迅雷和Web迅雷被使用得最为广泛,因此只要限制掉迅雷和Web迅雷的请求基本上就可以消除迅雷对网站造成的影响了。
        现在应用于小樱之町网站上的策略是,若请求带有Range请求头(即续传请求),或者是对资源型文件的请求,则禁止访问。这个策略在限制迅雷上会收到较好的效果,不过缺点是极少部分的用户不能下载网站上的资源型文件。

        FTP请求识别(指令序列方法)
        FTP中,服务器与客户端的交互是以纯文本的指令来完成的。如果我们要下载FTP上的资源,一般的过程就是登陆、列目录、请求文件,最后接收数据。基于FTP的通信方式,每一种FTP下载工具进行下载时必须发送一系列指令才能下载文件,迅雷也不例外。我们就利用从登陆到开始下载前迅雷发送的FTP指令来识别迅雷的连接。
        首先在这里临时定义一个名词:指令序列。指令序列,指一个FTP连接自连接时到接受数据前,发送的所有指令的前半部分(空格之前的部分),所组成的队列。根据这个定义,我们截取了迅雷进行FTP下载时发送的指令序列如下(迅雷与Web迅雷的指令序列相同):
        直接下载(无REST指令,即非续传)
       
            USER
            PASS
            CWD
            TYPE
            SIZE
            PASV
            RETR
       
       
        续传下载(有REST指令)
       
            USER
            PASS
            CWD
            TYPE
            SIZE
            PASV
            REST
            RETR
       
        特别地,当请求的文件在FTP根目录下时,迅雷会省略掉CWD指令。
        如果迅雷的指令序列是唯一的,我们就可以通过指令序列来识别迅雷的请求。为了验证这一点,我们也截取了以下软件的指令序列,将其与迅雷的指令序列进行对比:
       
            SmartFTP
            FlashFXP
            CuteFTP
            LeechFTP
            LeepFTP
            Firefox
            Internet Explorer
       
        比对结果证实了我们的想法,没有一个软件的指令序列与迅雷的指令序列相同。由此我们可以得出结论,至少在大部分常用工具的范围内,迅雷的指令序列是唯一的,这样我们就可以利用指令序列来识别迅雷的连接。
        对于每一个FTP连接,从连接建立之时,我们就记录这个连接发送的指令,当这个连接第一次发出下载请求的时候,我们就比对这个连接的指令序列与迅雷的指令序列进行对比,如果相同,就可以判定这个连接是迅雷发起的。接着,我们可以直接断开这个连接,或者给这个连接打上记号,拒绝这个连接以后发送的任何下载请求。
        现在应用于测试FTP上的方法是,一旦识别出某个连接是迅雷的,就给这个连接打上标记,之后对这个连接所发起的下载请求都予以拒绝。

        HTTP请求识别的另一个方法
        这个方法还只是推测,没有详细考察是否可行。这个方法类似于FTP请求识别的方法,也是通过HTTP头的发送顺寻来识别迅雷的请求。如果迅雷发送的HTTP头的序列与其他浏览器或下载工具都不同的话,那个这个方法将是一种比上面介绍的用户代理方法更能准确识别出迅雷请求的方法.