昨天托管商通知我，由于连续四天带宽超高，被限制带宽到10M。看了一下流量日志，平均带宽30M左右，最高带宽52M，是从3月14日开始的。
于是挨个站排查，看看谁的流量高，用了很笨的办法，就是挨个站停，看流量有没有变化，没想到20多个站停下来，流量还是没有降下来。于是停掉IIS，流量马上归零，看来流量还是从IIS这里来的，跟FTP和SQL SERVER没有什么关系。
无奈之下，打开IIS日志5分钟，查看日志的时候才发现，有两个RMVB文件出现频率相当高，5分钟之内被上千个IP下载。找到这两个RMVB文件，发现其上传时间就是3月14日晚上7时左右，跟流量飙升时间吻合。这两个文件是一个朋友上传到自己的博客的，想传上去让别的朋友下载，但是他只告诉了一个人。这时候我才意识到，恐怕这两个文件被迅雷索引了，就让博客主人向他的朋友求证，得来的消息是，他的朋友用迅雷下载的这两个文件，当时下载速度很快，达到2M。看来这就是事情的根源。
说到这里不得不提到迅雷，这个让人又爱又恨的工具。作为一个单纯的用户或者下载者来说，多数人是喜欢它的，下载速度快。但对于网站主或者服务器的主人来说，它就没有那么可爱了。迅雷为什么有那么高的速度？我的理解是它靠了有限的点对点，以及无限制的点对SERVER。通俗一点说，当我通过迅雷下载S1服务器的A文件的时候，迅雷记住了此次下载的S1的地址，同时当文件下载完成后，将此文件的HASH值存入了迅雷自己的数据库。当另一个人要从S2服务器下载A文件时，迅雷先从数据库查找是否有此文件的其他可用源，那么它至少查找到两个结果，一个是我的这个点，另一个就是S1，那么它会从 S1 S2同时下载文件，或许也会试图从我的电脑上点对点传输有限的一部分。利用这个原来，当它的数据库积累越来越庞大时，它的理论下载速度就是下载者网络带宽的极限。苦就苦了我们这些小网站主，我们的巨大流量甚至换不来一个PAGE VIEW。
据我所知，现在很多站都在封杀迅雷，当然，也有站与迅雷合作赚点蝇头小利的。站在下载者和网站主办者的双重身份的角度，我觉得，迅雷必须采取某些措施，至少不要对这些小网站资源过度使用，否则，等到所有网站封杀迅雷的时候，恐怕也就是迅雷走到头的日子。