greensea 的 blog

这回是如何高效地判断出迅雷的FTP指令序列。
这里所说的FTP指令序列是指，一个FTP会话从连接开始，到开始下载文件前，发送给服务器的FTP指令的序列。另外，指令参数是不算入指令序列里面的。
一个典型的FTP指令序列就是：USER->PASS->SIZE->PASV->RETR。

实际上就是一个数据结构而已，虽然偶觉得这个数据结构应该已经有人提出过了的说，但是找不到。偶把这个数据结构叫做哈希树，然后偶以哈希树为关键词查找，没找到多少结果。然后偶又以hash tree作为关键词查找，找到了维基百科，但是看上面的解释不太清楚，不过估计应该就是那样子的没错了。
弄出这个数据结构的初衷是想要保存一些FTP已登陆用户的信息，因为查找频繁，所以希望这个数据结构能提供很快的查找速度。于是想到了哈希表，但问题是，同时登陆的用户数是未知的，这样就不知道需要定义多大的哈希表，而且如果同时登陆的用户较多的话，哈希表也会变得比较大才能满足要求。

话说回家之后就发现这个黑色的羽毛球，第一次见到竟然还有黑色的羽毛球。问来源，答曰是从别人那里くれます的。
然后这个球，据反映，在我家下面的球馆打的话几乎看不到，而在（百色）电力公司的球馆里面打的话却看的很清楚。不过偶灭去过电力公司那边的球馆，可能和照明有点关系。我家下面的球馆照明是从场地边上吊着一排普通日光灯，场地正上方没有照明，所以可能球灰高远的时候就融入天花板去了。
好吧是偶火星了还是这是新品种或者说是恶搞的球偶就不知道了，不过看起来这球打起来应该挺不错的说，按照惯例上图。至于照片名字不连续，是因为中间有三张用长焦然后手抽了成像模糊所以删掉了。
查看图片请谨慎，数码相机原图体积庞大，2M多*3张

自从YT部署了反迅雷策略以后，服务器的流量没这么大了。普他下载主要还是以用户代理字串判断来识别迅雷，YT网站的音乐下载则采用定期改变下载地址的方法。现在YT的服务器流量一直比较正常，没有再被迅雷拖累了。虽然新版的迅雷已经修改了自己的特征，绕过了YTS的反迅雷策略，但是似乎使用迅雷新版的用户不多，YTS的流量也没有受到太大的影响。
不过这样下去显然是不行的，使用新版迅雷的人会越来越多，有朝一日YTS肯定又会变成带宽被迅雷吃尽的状况。说起来迅雷也真是太不厚道了，都已经盗链这么久了还不反省，再这样下去我都忍不住想采用不厚道的手段对付迅雷了。
这个不厚道的手段实际上针对的是迅雷用户，正因为是针对用户的，所以我才说这个手段不厚道。

今年暑假弄到了白菜级机票，于是终于不用忍受那10个小时的破烂不堪的广西铁路系统的折磨了。不过其实坐飞机的话也是比较囧，行程不像坐火车那样先到南宁才到百色这样绕一个大弯，直线距离的话，在谷歌地球上量了一下，桂林到百色才400多千米。于是“预计飞行时间50分钟”，我来回机场的时间，候机的时间分别都比这个时间长啊。好吧其实偶没想到桂林机场中午人很少，于是去得有点早了。另外一个原因是，本来预计桂林市区到机场需要1小时，而实际上40分钟就到了，我到机场的时间才11点，而航班是13：00的……