写在最前面
自从迅雷被华军和天空联合封杀以后，有关迅雷下载方式的争议就没有断过。一方面很大一部分网民支持迅雷，因为对他们来说迅雷就是高速下载的代名词，而且连死链都能下，在技术方面了解得不多的网民自然会支持迅雷。而另一方面对于下载站来说，迅雷未经他们同意就擅自连接他们的资源，给他们的网站造成了很大压力，同时或多或少影响到了页面流量。最后一个方面，对于小网站的站长来说，他们的网站带宽有限，如果网站上的资源被迅雷索引，就会带来大量的外来连接，导致网站的流量被占用殆尽，严重影响了网站的运行。
我自己呢？我为什么要开发反迅雷的插件？
我有一个网站，一般我们把她称为YT。在2007年暑假的时候我把她从虚拟主机上搬回了家里刚刚买的的电脑上，就当作是家庭服务器了。网络用的是百色电信，我们小区里面的人联合起来去电信开通的，相对来说资费较低。在确定安装之前，我先了解了一下情况，得知，虽然是ADSL方式接入，但是上下行是等速的。既然如此，那就一起安装吧，他们都是要1Mbps的带宽，为了有一定的带宽供服务器使用，我家就要了2Mbps的带宽。
在最开始的时候一切都很顺利。速度不慢，论坛上的人都表示感觉和以前没有什么区别（这应该和我开了Gzip有一定的关系）。一直到开学，都没有出现什么大的问题，我在做好远程连接的设置以后，就安心地去学校了。
但是过了半个学期左右，通过Windows的系统监视器我发现，整个服务器的上行带宽经常会达到饱和，而有的时候却仅仅占用了不到四分之一。在上行带宽饱和的时候，访问网站就如同拨号上网一样，而远程桌面连接也是非常缓慢。这个上行占满的现象出现毫无规律，与网站的访问高低峰时间段没有关系。我就很奇怪，会是什么东西把上行带宽都占满了。这个问题一直困扰着我，直到07年12月份的时候我才发现，在上行占满的时候如果停止IIS，流量马上会降低到几乎为零，而一旦启动IIS，流量立刻占满。这时我才发现，原来是IIS占用的流量。但是很奇怪，有时候在访问高峰期流量占有也仅仅是满负荷的二分之一，现在这种低峰时段怎么会占满呢？有人在正常下载是不太可能的，因为这个现象是经常出现，而且如果是正常下载的话，那么这种现象应该在高峰期出现得多一些，而在低峰期出现得少一些才对。但现在的情况是，这种现象的出现和高低峰时段根本没有联系，因此不太应该会是正常用户的下载。
因为IIS上运行着不止一个网站，我只好一个一个网站排查。在抓住了一个流量占满出现的机会以后，通过关闭所有网站然后逐个打开，我把目标锁定到了两个站点。其中一个站点因为是不太重要的，所以我就先关闭了，重点观察另一个站点。在对另一个站点进行继续观察后发现，基本上流量占满的情况就是由这个站点引起的。但是这个站点流量并不大，为什么会把带宽占满？这个站点上的大多数可下载资源的地址都是每3天改一次的，应该不会被盗链。想到这里我也不知道为什么这个站点会产生这么大的流量了，没办法，只好暂时把这件事情放一边去。
突破点是一个游戏
过了一段时间，论坛上的一个筒子，也是我的一个好友，包子研究员（简称包子）告诉我，原来放在论坛上的“樱町小传”（樱町=YT）游戏被迅雷索引了。发现这件事情的起因是，他最初把樱町小传发在了两个地方，现在他出于一些原因，不想继续让人玩这个游戏了，于是就把这个游戏删除了。不过他只删除了在另一个地方发布的游戏下载文件，而在我们这边论坛上的文件则没有删除，但是发布在帖子里面的下载地址已经给檫掉了。本以为这样做以后就不会有人能下载到这个游戏了，可是……
在高兴地向外界宣布，这个游戏已经不能被下载到以后，过了几天，却在另一个论坛上发现有人下载并玩过了这个游戏。后来追问那个人，包子才知道，他是用迅雷下载到的。在YT论坛发布的地址已经檫掉了，但资源没有删除，而在另一个地方是资源删除了，但是没有把地址檫掉。这样，那个人使用迅雷，下载另一个地方的还没有差掉的地址，根绝迅雷返回的资源，也是唯一的资源，从YT上下载到了樱町小传。知道了这一点以后，我们就把还放在YT服务器上的下载文件去掉了，这时我们再尝试使用迅雷下载，嗯，很好，已经不能下载到了。
经过这件事以后，我就想到，会不会是迅雷索引了产生大量网站上的资源，所以出现了流量占满的情况？虽然下载地址是三天一边，但是这三天内不能保证绝对没有人使用迅雷下载，而一旦有人使用迅雷下载之后，这些资源就会被索引，使得很多使用迅雷的人没有访问我们的网站，就直接下载了我们的资源。因为下载请求过多，2Mbps的带宽根本就不够用，所以就出现了流量占满的情况。
当然这只是猜想，不能肯定情况就是这样的。我想起了以前看过的一个通过HTTP头识别迅雷连接的方法，于是我根据这个方法分析IIS日志，果然，在日志里发现了大量迅雷的访问记录，且访问的资源都是mp3和几个压缩包。到这里，我基本上确定，是迅雷通过非正常途径下载我们网站上的资源，而导致网站占用了大量流量。
开始行动，阻止迅雷
既然已经知道是迅雷引起的，那么最好的办法就是限制迅雷下载我们网站上的资源。既然根据HTTP头可以识别出迅雷发起的连接，那么就利用这一点来识别迅雷并封锁它。因为我们网站上的地址都是直接请求而不通过程序处理的，所以如果要限制迅雷的下载，只能在IIS级别进行处理。这样子的话，当然就要使用ISAPI。ISAPI可以在IIS处理请求之前预处理请求，利用这一点，我们就可以抢在IIS前面，识别迅雷的连接，从而屏蔽它。理论基础已经有了，那么接下来的就是实践。最后， GS_ISAPI_Xunlei_Immune 就诞生了。
在HTTP方式上成功地限制了迅雷以后，我又想在FTP方式上也限制迅雷。因为我们在另一个网站上开设了FTP服务，供用户上传交流资源。我们担心，一旦有用户使用迅雷下载FTP上的资源，这些资源就会被索引，而导致过多的不是我们网站上的用户通过迅雷下载我们FTP上的资源，这会消耗多少带宽啊。虽然我们在开设FTP的时候已经提醒不要使用迅雷下载，但是也不能保证每一个用户都不使用迅雷去下载FTP上的资源。所以，如果能在FTP上识别出迅雷的请求并屏蔽掉，这将会是一件很好的事情
但是FTP协议过于简单，没有要求提供太多的客户端信息，这就给识别迅雷的连接带来了很大的困难。虽然有一个CLNT指令可以让客户端发送自己的名字，但是迅雷、快车、IE都没用使用这个指令，所以通过CLNT指令来识别迅雷是不行的。尽管如此，最后在我和白水山言（简称言子）的努力下，我们还是发现了一个方法，可以识别出迅雷的请求。通过实践，我们首先在理论上证明了这种方法的可行性。理论证明之后，我就开始了实践。这个方法实际上不算复杂，在耗费了离散数学考试两天前的大半个白天之后， GS_Serv-U_Xunlei_Immune 被成功地开发了出来。在言子的帮助下，我们使用各种FTP客户端以及下载工具进行了测试，测试结果表明，除了迅雷以外，其他的FTP客户端或下载工具都能正常下载FTP上的资源，只有在使用迅雷进行下载时下载失败。这标志着，在FTP下载方式上识别并屏蔽迅雷的请求的成功。这一天是2008年1月12日。
总结，继续努力 2008.01
现在在IIS上和FTP上都已经初步能阻止迅雷的下载，但这两个插件还处于开发和测试中，还达不到实用的程度。毕竟要用于服务器，绝对不能粗心。虽然还不能发布，但至少已经从理论到实践都证明了这些方法的可行性（其实主要是FTP方面，ISAPI方面好像已经有类似的扩展出现了，不过好像是要收费的？），以后要做的事情就是完善和测试，最后就可以发布了。
其实我还有一个打算，就是开发针对Gene6的插件。无奈找遍了用户手册都没有找到可用的接口可以提供我所需的识别迅雷发起的连接的数据，只好先放一放这个打算了（其实最初在打算进行FTP方面的实践的时候我是想使用G6来进行测试的）。不知道G6的技术支持会不会回复我的邮件，如果没有回复，或者回复了但是给了我否定的答案，那针对G6的插件也没办法开发了。
说过了，这两个插件仍处于开发和测试阶段，如果有谁想要帮助测试的话，我们非常欢迎。但是要提醒你，这两个插件仍处于开发和测试阶段，可能在使用过程中会出现不可预料的错误，产生不可预知的后果，这对服务器来说是很危险的。那么，如果你不怕危险的话，就发邮件给我吧，我的邮箱用户名是“dengyi九一零”（请把用户名中的中文数字替换成阿拉伯数字），用的是163的邮箱。最后，一定要记住，测试是有风险的。