2010年3月29日星期一

网络神兽古鸽迁移记

古鸽是一种目前在中国境内濒临灭绝的鸽属鸟类,是一种搜索隐禽。

此鸟起源于北 美洲,据生物学家考证其祖先生活在相当于今天的美国加州圣克拉拉县的山景城附近。在20世纪末至21世纪初的一段时 间,它曾经遍布世界各地,但在2010年3月23日以后,该鸟类开始大规模往中国南部沿海的一个港口迁徙,从此在中国内地绝迹。

据环保人士 的谨慎假设,怀疑该鸟类的异常行为和最近全球气候极端化,特别是中国近几年来频发的大面积生态、环境、气候和 地质灾害有关。遭遇问题,它没有像草泥马一样顽强地生存下来,而是举族迁徙,这被全球各地的一些动物爱好者所鄙视。

古鸽被认为是目前所有鸽 属鸟类的真正祖先。所以被称为"古鸽"。

外形特征

身披蓝、黄、红、绿四色羽毛,比家鸽体型稍大。鸣叫声和英文单词 "googol"类似,美洲印第安人认为其叫声代表了"难以置 信的数量"的意思,数学家经过严谨的考证计算,认为这个数量大概是10的100次方。

生活环境

古鸽具有超强的环境适应能力,并且总能在短期内进化出本地化的新品种。例如目前数量较多的有美国古鸽、曰本古鸽、英国古 鸽等亚种。由于生物考古学的研究证明古鸽起源于美国,一般我们把美国古鸽简称为古鸽,其他地区的亚种冠以当地国名。

初步研究表明,古鸽的离 去很可能导致另一种长着熊爪,酷似古鸽,却又习性不同的猛禽类——犤毒鸟,这种古书中传说的本土 鸟类数量呈爆炸性增长,最终迫使中国内地居民不得不使用这种带有剧毒、性情凶狠、只以中文作为鸣叫声、以钱币为食的上古神兽 级猛禽,以代替古鸽的部分功能。

生活习性

群居,一个国家的古鸽族群有各种不同的擅长功能。古鸽以各种印有文字的物体为食,并 会自动评估该食物的权重,最终以极复 杂的算法决定下一次进食的优先选择顺序。

已知古鸽的天敌有河蟹、中国蚊祚蟹等蟹类生物。

种群现状

全球约有120,000,000,000只古鸽,但是中国内地目前已经基本绝迹,原中国古鸽大规模往中国香港迁徙。所以,目前全球古 鸽 的种群数量呈下降趋势。

不少动物爱好者已于2010年3月23日晚前往位于北京鸟关村的古鸽园进行悼念活动。


古鸽 (by shou3301)

2010年3月26日星期五

加密方式Google搜索


谷歌搜索宣布退出中国内地 国新办网络局表态

新华网北京3月23日电 国务院新闻办公室网络局负责人今天凌晨就谷歌公司宣布停止按照中国法律规定的对有害信息过滤,将搜索服务由中国内地转至香港发表谈话。
这位负责人指出,外国公司在中国经营必须遵守中国法律。谷歌公司违背进入中国市场时作出的书面承诺,停止对搜索服务进行过滤(Google承诺的过滤和ZF要求的过滤在内容和形式上肯定不一样,或者说双方在签订合同时对"过滤"的含义上有误解),并就黑客攻击影射和指责中国,这是完全错误的。我们坚决反对将商业问题政治化,对谷歌公司的无理指责和做法表示不满和愤慨。

这位负责人说,1月12日谷歌公司在未事先与我政府有关部门通气的情况下(通了气又会怎么样?难道ZF承认了自己是发动黑客攻击方吗),公开发表声明,声称受到了中国政府支持的黑客攻击,不愿在中国运营"受到审查的互联网搜索引擎",并"考虑退出中国市场"。在谷歌公司一再请求下,为当面听取其真实想法,体现中方诚意(最无耻的一句,从字面看明明是Google非常有诚意,ZF非常傲慢),今年1月29日、2月25日中国政府有关部门负责人先后两次与谷歌公司负责人接谈,就其提出的问题作了耐心细致的解释,强调外国公司在中国经营应当遵循中国法律,如谷歌公司愿遵守中国法律,我们依然欢迎谷歌公司在中国经营和发展;如谷歌公司执意将谷歌中国网站的搜索服务撤走,那是谷歌公司自己的事情,但必须按照中国法律和国际惯例,负责任地做好有关善后工作。

该负责人指出,中国政府鼓励互联网发展和普及,促进互联网对外开放。中国互联网上的交流和言论十分活跃(确实大部分人都没被喝过咖啡),电子商务等发展迅速。事实证明,中国互联网的投资环境、发展环境是好的。中国将坚定不移地坚持对外开放的方针,欢迎外国企业参与中国互联网发展,并为外商到中国经营发展提供良好服务。中国互联网依然会保持快速发展的势头。

北京时间3月23日凌晨3时零3分,谷歌公司高级副总裁、首席法律官大卫·德拉蒙德公开发表声明,再次借黑客攻击问题指责中国,宣布停止对谷歌中国搜索服务的"过滤审查",并将搜索服务由中国内地转至香港

2010年3月24日星期三

[转] 你永远不应该做的事 -- 关于重写代码

你永远不应该做的事,第一部分

by Joel Spolsky

Thursday, April 06, 2000

原文链接  http://www.joelonsoftware.com/articles/fog0000000069.html

       Netscape6.0终于要进行第一次公测了。第5.0版本从来就没有发布。最后一次主要的发布就是第4.0版本了,几乎是在3年前。3年时间在网络世 界中是非常长的。在这期间,Netscape停步了,绝望了,因为他们的市场份额直线下降。

      我评论他们说在两次发行之间等待这么长的时间有一点虚情假意。他们是故意这样做的,是吗?

      不,不是。他们这样子是犯了一个最严重战略性的错误,这个错误任何软件公司都有可以犯:

      他们决定重写代码

      Netscape不是第一个犯这个错误的公司。Borland在收购了Arago并把它整合进dBase的时候也犯了同样的错误,这个项目花费了如此长的 时间以使Microsoft Access吃了他们的午餐,然后他们又一次犯了这个错误去重写Quattro Pro,它的功能少的令人惊讶。微软差点也犯了同样的错误,在一个叫Pyramid的项目中重写Word,这个项目被关闭,抛弃,被掩盖掉了。幸好,微软 没有停止在旧的代码的基础上做工作,因此他们能有成果,这个仅仅是财政上的灾难而不是战略上的。

      我们是程序员。在程序员心中,他们是建筑师,我们到达一个地方最想要做的事情是填平道路和建造宏伟的建筑。我们不热衷于翻新:修补,改良,种植花床。

      有一个微妙的原因使得程序员总是想抛弃原有的代码重新开始。原因是他们认为原来的代码太混乱。而且有一个很有趣的现象:他们可能错了 。他们认为旧代码混乱的原因是由于编程上的一个基本的,主要的定律:

阅读代码比写代码要困难

      这就是为什么代码重用这个困难。这就是为什么你团队里的每个人都喜欢用的不同的字符串分割成字符数组的函数。他们都自己写自己的函数是因为这个比弄明白旧 代码更简单更有意思。

      作为这个公理的推论,你可以问任何一个程序员关于他今天工作的代码。"这里糟糕得一塌糊涂"他们会这样告诉你。"没有比扔掉这些重新写更好了。"

      为什么代码混乱?

      他们说"看这个函数。这个有两页长!这些东西都不应该在这里出现!我不知道这里面有一半API调用是为了什么"

      在Borland新的Windows版本的电子表格发布前,Phlippe Kahn,这位具有传奇色彩的创始人说了发表自夸的言论,说Quattro pro相比于Microsoft Excel要优秀很多了,因为它重写了所有的源代码!好像源代码也会生锈一样。

      新代码要比旧代码好的观点是荒谬的。旧代码已经在使用了。已经被测试过了。大量的Bug已经被发现了,而且被修复了。这样并没有什么不好的。把程序放在硬 盘中并不能使你发现BUG。难道软件像老Dogde Dart车一样,有生锈菌会在车库里等着?难道软件像玩具熊那样如果不用新材料就不会有那么多毛?

      让我们回到那个2页长的函数。是的,我知道,这只是简单的显示窗口的函数,只是长出了一些其他东西而且人知道为什么。好的,我告诉你为什么:这是为了修复 BUG。有一个是Nancy修改的,修复了当在一个没有浏览器的电脑上安装的时候出现的BUG。另外一个是为了修复在低内存情况下产生的BUG。还有一个 是修复当文件在软盘的时候用户拔出软盘产生的BUG。这个丑陋的LoadLibrary是为了使代码在低版本的Windows95中运行。

      这些BUG都需要使用好几个星期后才能被发现。程序员也许也在实验室花费了好几天再现BUG和修复BUG。和很多BUG一样,修复BUG只需要一行代码, 甚至几个字符,但是为了这2个字符需要做大量的工作和花费大量的时间。

      当你抛弃这些代码重写的时候,你也抛弃了所有的知识,所有的已经被修复的BUG,多年的编程成果。

      你也抛弃了你的市场领导权。你给了你的竞争者2年或者三年的时间,相信我,这个时间对于软件来说太长了。

      当你几年间只发布一个旧版本的代码产品,完全不能做改变且不能适应市场需求增加新功能,那你就处在一个非常危险的境地,因为你没有可以发行的代码。你也许 会在这期间关闭业务。

      但是再写一遍已经存在的代码是在毫无意义的浪费大量的资金。

      是否还有其他选择?大家一致认为旧版本的Netscape代码非常糟糕。也许确实很糟糕,但是,你知道吗?它在现实世界这些乱七八糟的计算机系统中运行的 非常好。

      当程序员说他们的代码乱七八糟的时候(他们经常这样),是因为代码中有三种错误。

      第一,结构上的问题。代码没有安排在正确的地方。核心代码中有一处是在任何地方的中间弹出自己的对话框;它应该被安排在UI代码里。这个是可以解决掉的, 在一个时间,小心的移动代码,重构,改变接口。可以让一个程序员认真修改和检测改动的地方一次,就没有人再被这个问题干扰了。即使一次重大的结构调整也可 以在不抛弃原来代码的基础上完成。在Juno的一个项目中,我们花了几个月做只在一处做结构调整:只是移动代码,清理代码,创建基类,各个模块之间创建明 晰的接口。我们在原来的代码基础上做的很认真,而且我们没有产生新的BUG,也没有抛弃原来的代码。

      第二个程序员认为他们的代码混乱的原因是代码效率低。Netscape的渲染代码据说效率很低。但是这只是整个项目的一小部分,你可以优化甚至重写这一个 部分。不需要重写全部的代码。当优化效率,1%的工作可以得到99%的回报。

      第三,代码可能非常丑陋。我工作过的一个项目有一个数据类型叫FuckedString。另外一个项目中的成员变量名一开始以下划线开头,后来使用m_开 头。因此一半的函数以"_"开头,一个以"m_"开头,看上去非常丑陋。老实说,这种事情你可以用Emacs中的宏5分钟就解决了,而不需要重写代码。

      一个很重要的事情你要记住,当你重写代码并没有绝对的理由相信你会比旧代码更好。首先,你甚至没有和写第一个版本一样的开发团队,因此你并不是"更有经 验"。我会再一次犯大多数以前犯过的错误,而且会比原始的版本增加更多的新问题。

      当实施一个大型的商业应用的时候,像以前的生成一个扔掉一个是非常危险的。如果你对写代码有经验,你可能会在想出一个更好的算法后取消掉你上星期写的函 数。这行。我也许想重构一个类是它更容易使用。这也行。但是抛弃全部的程序是危险且愚蠢的,如果Netscape拥有一些成熟的有软件工业经验的管理者, 他们也许就不会把自己的脚射伤得这么严重。

2010年3月22日星期一

西厢计划原理的进一步思考[转]

Source: http://obmem.com/?p=615

西厢计划原理的进一步思考

`
我看了西 厢计划项目的wiki还是云里雾里的,好在youxu大大的西 厢计划原理小解解释的非常清楚,在这里我也简单归纳一下,西厢计划就是在TCP建立连接之初通过插入发送完全符合协议的TCP包欺骗GFW连接已 经终结,来达到穿墙的目的。原理据说如下图。

xixiang
`
根据“原理”的说法,张生同学实际上是利用了GFW本身的特性。(事实上,墙可以视作一种网 络入侵检测系统,有着所有NIDS 系统的弱点。)因为性能原因,墙作为一个旁观者,它无法做到对每一条TCP包都进行检查来过滤敏感词汇。tek4 小组的大牛们,据说也就是西厢计划的探索者,经过长时间对墙的研究,发现墙很聪明地只会在连接发起的时候进行检测。
`
这样做是可以说的通的。中国的出 国带宽应该早 已破T,如果墙需要检查所有的TCP包,会是很大的负担。所以墙才会检查TCP会话的状态,当发现是死老虎状态时,直接放跑所有后继TCP会话。
`
然而我有一个百思不得其解的问题让我怀疑墙是否只在连接发起时进行过滤。我做了两个测试:
我建立了一个网页http://test.app-base.com/link.html,这个网页中含有falun词汇,并且有一个链接访问” /?falun”
测试1. 访问link.html。结论正常。
测试2. 访问link.html,再点击falun链接,结果被重置。
`
测试一结束后,我和服务器已经完成了三次握手,并且有来有回地发送了GET和获取了网页,这个时候我还有keep-alive属性,根据我对http 1.1的理解,这时候并没有终止TCP连接,而是立即回应了另一个请求,但是这个请求却被墙重置了,所以墙只在TCP连接发起时进行过滤这个说法我觉得有 问题。当然我对网络协议还是很一知半解的,有说错的话请及时更正我,谢谢。
`
按照我的上述实验来看,墙并非只在TCP连接发起时进行过滤,而是对每一个TCP包都做检查,发现是GET请求就进行过滤,发现是回应则PASS(至少测 试1没有被过滤,如果它扫描的话那就说明基于不同规则。)
`
然而西厢计划的成功实施,说明墙是保存连接信息的,所以它在记录两个主机的连接“终止”以后,放跑了所有这两个主机间的流量。那么关键的问题是,如果墙取 消这么一个设定,不“放跑”已经“终止”的两个主机之间的流量,会对墙造成很大负担吗?

`

如果会,那么墙想要干掉西厢计划还是很困难的;如果不会,那么修正这个破绽简直轻而易举。

`
上述问题等价于:实际应用中,是否有很多正常的应用会在RST终止以后还是罗里罗嗦地发送一堆包?出于网络延时我觉得RST以后确实可能会发送一堆包,但 是这个数量相对于正常应用的TCP包来说应该是小巫见大巫。那么为什么墙要做那么一个古怪的限制呢?为什么墙要记录TCP连接状态,阻断连接以后就直接无视后续的包呢?
`
思索了半天,我所能想到的唯一一个理由就是墙那么做是为了避免DDoS攻击。 如果墙还要继续监控数据包,这可能会造成潜在的攻击点:攻击者不断地发送同样的数据包,墙必须一次又一次地拦截并且发送RST给攻击者,大规模地攻击下, 墙的过滤系统资源将被耗尽,从而无法进行正常的运作。而如果墙能够确认连接已经重置,就算仅仅是出于性能优化考虑,判断主机IP决定是否过滤也要高效得 多。
`

如果我是墙,会怎么应对?

1. 无视reset信号,不记录主机间的连接状态,所有TCP包都加入过滤。
`
这是最容易的一种处理方法,但是也是(据我推测)有安全和性能隐患的一种处理方式,理由见前文。
`
2. 记录三次握手序号,封锁西厢计划。
`
西厢计划骗墙认为receiver已经死老虎是通过发送一个序号不对的RST给sender,sender会无视,墙却会中招以为是死老虎。
`
如果墙想逮住”死老虎”,他必须记录sender给receiver的SYN/ACK握手的序号,并且和receiver再次返回给sender的ACK 序号进行比对才能确定这个是否是西厢计划的一次欺骗。从数据结构上来看,需要多保存一个SEQ号,这是一个32bit的数,相比原来多占1/3的空间;而 且如果墙是硬件实现的话(我觉得是),改变数据结构可不容易;从性能上来看,要多做一次主机的匹配和ACK序号的比对,性能开销也不小;而且墙一旦这么做 了,隐患更大,之前因为不太了解墙的工作模式,想攻击都没法攻击,既然你用这么个办法来堵漏洞,那我就有的放矢直接灌水各种RST信号,那么墙就真的悲剧 了。
`
看起来我觉得这种补救方式更加得不偿失。
`
3. 直接用IP封锁。(黑名单)
`
好像很犀利,不过可以直接通过代理绕过去,以前用代理因为有关键字过滤所以也没什么用,有了西厢计划,再加上代理,封IP就变得非常徒劳了。至于什么代 理?什么都可以,squid、web代理、反向代理等、只要在墙外就行。
`
4. 白名单。
`
真的是大中华局域网了么,@@
这种情况下除非有白名单中包含国外主机,那还能通过代理出去,否则,就一个局域网怎么翻墙?这是最狠的一招,我觉得不太可能发生,但是永远不要低估某些人 的脑残程度,万一……
`

为何不直接对内容过滤?从TCP协议的角度来看

`
根据我自己的测试,GFW似乎没有对内容进行过滤。不考虑处理能力的问题,理论上GFW似乎可以通过随机检查TCP包,然后发送阻断包终止连接。
`
然而他真的能发送阻断包吗?扫了一下TCP/IP协议,我发现它能干的事情有限。这是因为一旦连接建立,慢启动过后,TCP就开始高速运转 了,sender同时会发送n个包给receiver,墙截取了当前的包,发觉有问题,这时候他想干扰传输有两个选择,要么发RST,要么发FIN(RFC1122,4.2.2.13)。 可是这时候墙无法推测下一个序列号,因为他无法知道该死的sender到底同时发了多少个包给receiver,只能靠猜。
`
但是并不是说墙没有办法,根据TCP协议的Flow Control部分,receiver会给sender发一个windows size的参数,规定sender只能发那么多数据,之后要等待receiver的ACK表示收到。发送ACK表示收到的同时,receiver还会告诉 sender它的acknownledge number,表示他预期下一个序列号是什么,这时候墙就能能乘虚而入伪造RST/FIN数据给receiver了。
`
这又是一个复杂的实现+性能和安全隐患,我想这也是为啥墙一般不直接做内容过滤,而是更倾向于url扫描和dns污染的另一个理由吧。
`

结论

西厢计划很好很强大,让我看到了墙的脆弱性,随着对墙的越来越深入的了解,越来越多牛人加入翻墙的研究,墙终究会变得不堪一击。道高一尺,魔高一 丈。通过这次对墙的原理的学习,我突然觉得墙其实还是很千疮百孔的,并没有我原来想象的那么强大。就那么个破东西,国家花了无数纳税人的钱,只为了阻止纳 税人们了解真实的世界,唉,很是无语啊。
`
最后补充一下,我本人对TCP的了解仅限于学得很是不行的“计算机网络”的知识,而且因为从来不用基本忘光,如果狗屁不通错误连篇也请谅解,如果能指出错 误就更好了。
`

3月22日更新

首先,tek4小组在完成西厢计划后已经解散,解散之后他们发布了对GFW和西厢计划的一个总结,更宏观地解释了GFW的应对方式,证实了西厢计划 并没有那么强大,见参考资料11。
`
其次,由西厢计划得到启发,结合“第八组第三次作业”中提到的忽略RST穿墙法(参考资料12),西厢计划似乎可以简化实现,并且由于实施单方面忽略 RST而不是企图欺骗墙的关系,性能和无解程度会大大增强。如果和参考资料10的判断IDS结合起来,说不定会有很好的效果。
`
最后,第一次感觉不在墙内真是遗憾,那么有趣的技术没有办法实践,sigh…

2010年3月15日星期一

QQLIVE视频下载保存的方法

(来自:http://blog.sina.com.cn/s/blog_538df0630100f0u3.html

    近来一直使用QQLIVE看片,有些片看过之后感觉不错。很自然的就会产生想要保存下来的念头。于是就用两大搜索工具g.cnbaidu.com查找能 够保存或下载QQLIVE视频的方法,找了半天非常让人

失望!要么说根本没法保存、要么说的方法根本行不通,费了半天尽也没找到一个真正有用网页。

    看来还得自已动手,丰衣足食!经过研究和尝试终于成功的把QQLIVE看过的视频保存下来的方法找到了!当然不能独享,方法公布如下:

    1、确定QQLIVE软件使用的\QQVideo.Cache\vodcache在哪个盘哪个目录下;

    2、清空\QQVideo.Cache\vodcache目录下所有内容;

    3、打开QQLIVE,正常观看完想要保存的视频;

    4、这时\QQVideo.Cache\vodcache目录下,QQLIVE会自动建立一个类似于"befe2d933f939bb771035e8b01d28403" 样子的目录,此目录中保存的就是刚刚看完的视频;

    5、把此目录中所有以".tdl"结尾的文件复制到一个新目录下。特别注意:一定要先排好顺序按文件名从小到大(*000.tdl在最前面),选中所 有*.tdl文件,复制时要在*000.tdl文件上点右键复制。(最好是在分区的根目录下建立一个以简单名字命名的目录);

    6、点开始,点运行。输入cmd 回车。打开命令符窗口,进到刚复制存放"*.tdl"文件的目录。(这也就是我前面说的为什么最好在分区的根目录下建立一个简单名字目录的原因);

 

   7、输入命令copy */b aaa.mp4快的话几秒就会在这个目录下生成一个名叫aaa.mp4的文件,此文件也就是刚刚看过的那个视频文件。(copy 是系统的复制命令,"*"是指当前目录下的所有文件,"/b"是使用二进制格式复制,"aaa.mp4"就是你想要生成的那个新文件的名字,当然也可改成 别的)。

2010年3月1日星期一

Firefox插件 - AutoProxy

原来我用FoxyProxy,今天发现了AutoProxy,试用了一下,好像更方便,比较如下:
----- FoxyProxy AutoProxy
-------------------------------------------------------------
支持Tor 是 是
根据Filter自动调用代理 是 是
订阅Filter 否 是 (gfwList)
自定义Filter 是 是
支持多个代理 是 否
内置代理 否 否