摘要:     前些天发现自己的网站无法访问，询问机房这边，说是机器最近常死机，我就把网站迁移到一个朋友的主机上， 结果没过几天机器又挂了，问朋友的机房那边说是硬件防火墙被攻击了而死掉了，详细情况不知。看来不是硬件问题，多半是被SYN FLOOD或者CC攻击了。恰好原来的机房说最近购买了新的防火墙，我又放了回去。       既然不是硬件问题而可能是攻击，我就开始检查IIS log了，发现 IIS 里面很多Timer_ConnectionIdle和Timer_MinBytesPerSecond的错误，到网络上google了一下，常见说法是说错误是因为IIS的设置不当引起的，是因为连接超时时间设置太小，解决方法是设置连接超时为600秒，把MinFileBytesPerSec的设置从240修改到0（相当于关掉该设置)。觉得这些解决方法都有问题，假如车辆防盗警报经常响，正确的解决方法是看看有谁常来打你车子的主意，或者把车子放在更安全的地方，而绝对不是关掉警报。       因为HTTP服务需要占用TCP连接，而TCP连接时是需要占用系统资源的，而且IIS为每个连接也需要分配相应的资源(至少一个FSM是要给的)。目前的主机能够处理上万的连接就可以说是软硬件设计都很不错了(可以参见C10K )。假如恶意人员通过一台或者多台机器发起大量的连接，而不请求内容(这样不需要消耗多少攻击机器的带宽)，就可以大量消耗服务器资源而达到拒绝服务的目的。      所以 IIS 需要关闭长时间非活动的连接，这个就是Timer_ConnectionIdle 的错误由来。      既然盾牌改进了，当然矛也要发展一下，攻击者可以给服务器故意缓慢的发送和接收内容而消耗服务器的资源，这样可以避免服务器对于Timer_ConnectionIdle 的保护，相应的IIS的防范就是 MinFileBytesPerSec 设置，MinFileBytesPerSec 属性通过以最小的数据量保持连接，来禁止恶意的或软件工作不正常的客户端消耗资源。如果吞吐量低于 MinFileBytesPerSec 设置的值，则终止连接。LOG里面就会显示Timer_MinBytesPerSecond错误（一些Timer_MinBytesPerSecond错误是因为 windows 2003 的http.sys错误引起的，解决方式是打上最新 ServicePack ： http://support.microsoft.com/kb/919797   http://support.microsoft.com/kb/919797/en-us ）       所以说这些设置都是用来保护IIS服务器的，可以一定程度上抵御一些恶意的行为消耗服务器的资源，所以我反而将IIS连接超时从原来的600秒改到了30秒，就让攻击来得更加猛烈些吧！！不过我还是很纳闷: 网站不大，所以我不可能去财消灾。无怨无仇的，谁这么无聊啊？！   最后发现结果挺搞笑的，欢迎看后继文章。（最近挺忙, 续集暂时不会出来。希望解决这种错误的同志：假如不是攻击的话，打上微软的补丁包就好了)...[阅读全文]

摘要: 看了蝈蝈俊.net的《理解缓存》，觉得真的是一个对于web applcation 缓存应用的好文，难得的是覆盖了冰山海面下的部分。我现在做的应用可以说和缓存打的交道也不少(不过不是web应用)，也写些东西来分享给大家。 1.缓存是什么？ 在我看来，缓存是通过存储中间结果，缩短访问路径来减少开销，提高性能的方法。这个概括未必最科学全面，也不够具体。我们来看看一个http 动态页面访问的例子： 访问路径是 ： 数据库->应用数据集->内存对象->动态页面->HTTP服务器->用户浏览器 一个简单的访问，中间经过了多个环节，我们称这些环节为访问路径，我们来看看哪些地方可以采用缓存： HTTP服务器->用户浏览器，大家都知道浏览器都有本地缓存，浏览过的页面图片脚本等都会根据http header还有html的相关指令临时保存在本地硬盘里面，假如再次访问，访问路径就变成了"本地硬盘缓存->用户浏览器"， 浏览的环节大幅度减少，性能也提高了。在这个环节，经常还使用带缓存的代理服务器来提高性能。 动态页面->HTTP服务器，这里有多种方式, 比如动态页面静态化，目前大量的大型网站使用这种方式。还有WEB服务器根据一定规则缓存整个动态页面，比如asp.net的Page Cache。这里的访问路径变成了"缓存页面->HTTP服务器->用户浏览器" 本地数据集->内存对象->动态页面。常见的就是缓存数据集还有对象，这个是ASP.NET cache里面相对浓墨重彩的部分，也是Memcached发力的侧重点, 也就不多说了。 数据库->应用数据集，不少数据库实现都有查询缓存 这里缓存都在访问路径中的环节存储了中间结果，用来减少相应的开销 2.缓存本身的开销 缓存本身也是有性能开销的，一种是将内存存储到缓存中开销，一种是将内容取出来的开销。另外，缓存往往还要付出空间上的开销。另外还要付出系统复杂度的开销，这增加了开发和维护成本。 大家也听说过IE缓存太大了或者是文件系统碎片太多以后，可能相反会拖累浏览速度，测试我倒是没有做过，但是的确是完全可能的。也就是说，缓存的开销可能会不缓存而是直接访问还要大，这就是大家不想看到的了。 3. 缓存的目的 其实前面已经说过缓存是为了减少开销，提高性能，这不就是缓存的目的吗？这倒是没错，但是也不尽然。 因为开销是一个很笼统的词，具体点有CPU开销，磁盘IO开销，网络开销，数据库访问开销等，缓存对于性能的优化，除了一些大众化的优化措施以外，还得有的放矢。 以前学习写程序，大家一定都听说过什么时间换空间，空间换时间，到底什么时候要拿空间换时间，什么时候要拿时间换空间，只能看具体应用了。前面说过缓存也有开销，其实缓存就是拿某些开销换取其他开销的下降而已。比如说动态页面静态化是一些大型网站常见的优化方法，他付出了磁盘的空间和读写开销，来换取更低的CPU消耗(不用解析动态页面)和数据库访问。有些网站每天访问量没有多少，却频繁生成和更新静态页面，同时还在服务器上做下载，本来磁盘就不堪重负，这下更加是雪上加霜，可以说是缓存优化的反面例子。或者是本来内存不大，磁盘swap很多影响性能，但是却使用大量内存做页面和对象缓存，也是反面的例子。 所以说不能盲目的进行缓存优化，一个系统，性能出现了问题，或者将来可能出现问题，性能总会有一个或者若干个瓶颈，我们要做的就是平衡或者削弱这个瓶颈，缓存是重要的手段。 所以缓存的目的是针对几个主要指标，兼顾若干个其他指标，来尽量实现低开销。 比如，数据库的CPU较高，那么一般是复杂的查询或者是存储过程导致的，在前面的各个环节进行缓存优化，比如缓存数据集和内存对象，都是好的解决方法，缓存整个页面也是个好方法，但是缓存页面要付出更多的空间开销，在某些情况下，缓存数据集或者内存对象已经够了。 假如WEB服务器的CPU较高，往往是因为动态页面处理造成的，找出开销大的处理，将处理的结果对象缓存，或者是页面静态化是不错的方法，而缓存数据库结果集往往收效不大。 4. 啥样的缓存才是好缓存？ 蝈蝈俊认为是命中率最高的缓存最好。我做的领域是streaming server的磁盘IO缓存和CDN的网络边缘缓存，瓶颈就是磁盘或者网络IO，这种时候，命中率就是硬道理。 但是对于web服务器来讲，影响性能的因素很多，不同的内容访问开销相差很大，什么是好缓存，虽然命中率是极为重要的指标，但是还得要综合缓存的开销，原始的访问路径/开销和性能瓶颈来综合评价。也就是说不同的应用侧重不同，跑的硬件条件和瓶颈也不一样，很难有一个简单的指标。 ......[阅读全文]

摘要:     发现很多情况下，msn传输文件比qq要慢，倒不是说msn没有快的时候，但是大部分的时候是真的比QQ慢，连我这种神经比较大条的人都注意到了，google了一下，早就有人做了解答，基本上就是说msn传输文件是使用TCP，而QQ使用UDP，剩下的事情就是论证TCP传输文件没有UDP快。大概的就是下面的几个观点： 1. TCP是可靠的，需要验证数据是否到达和是否正确，而UDP是不可靠的，少做了很多事情，所以MSN的文件传输比QQ慢。 我看了当时就想笑，UDP传输不可靠，但是应用层肯定会写代码作些和TCP的可靠传输差不多的事情。也用了QQ不少时日了，从来也没有发现传输文件有问题的，用UDP作协议也很久了，不做应用层验证重传的代码，我还真不敢写。这个理由，失败。 2. TCP建立连接需要3次握手，而UDP不需要，所以TCP慢。 3次握手这个事实倒是千真万确，还好我没有那么容易被忽悠，两个人谈话之前要握握手的确要稍微费上几秒钟，但是这个关谈话的语速啥事情？假如网络的ping值达到300ms，各位看官喜欢网络游戏的，估计都不会玩了，否则垂死的boss会高兴的发现你忽然变成了木偶可以随便殴打不还手，最后你只能骂骂电信网通然后复活几分钟后又是一条好汉。但是对于TCP，这样的ping值，3次握手一般都不需要1秒钟，把这个定为文件慢慢传的罪魁祸首，似乎太不靠谱了，这个理由还是失败。 3. TCP一旦建立链接,路由就确定了,而UDP是不确定的路由方式,谁速度快走谁的线路。 这样说就说明没有作者好好理解TCP/IP协议了，TCP的链路只是一个逻辑的，又没有建立物理链路，下面跑的还是IP包，这个包走这条路，那个包完全可能走另外的路，这点TCP和UDP没有两样。理由继续失败。 4. msn服务器在国外？ 有些道理，但是我听一个美国的朋友说他也喜欢用QQ传文件的。        那到底是怎么回事呢？是因为微软没有做好？（题外话，个人的确觉得MSN相比QQ的飞速进步而显得动作迟缓）QQ的Fans开始摩拳擦掌，一些不那么喜欢M$的估计就要开始丢板砖了。不管立场如何，事实还是要探寻一下，本着不求甚解，薄积薄发，浅入浅出的精神，我认为有几个可能原因： 1. 两个传文件客户端都在NAT后面的时候 (你不知道NAT啥意思？比如多个人通过路由器共享一个猫上网，那么你们一般就是在NAT后面了)，从技术实现上讲，TCP在这种情况下穿越NAT比UDP麻烦得多。UDP只要开始几个穿越NAT的协商包需要服务器转一下，后面的文件数据可以两个客户端之间直接传输搞定，但是一般TCP就只能全程由服务器中转了，你说哪一个会比较快？ 为什么TCP需要服务器中转？先看看NAT吧，听说有高人可以用raw sock搞定，反正我没有中间服务器搞不定。   2. 但是即使上面的条件不成立，msn还是一般比QQ慢的。问题还是在出在前面提到的验证数据可靠性上面，TCP是可靠的，UDP是不可靠的，但是用UDP做传输文件这档子事情，肯定要在应用层写一个验证的协议，否则传过来的文件缺胳膊少腿，会被用户骂死的。说是协议，其实也不难，打个比方吧：     long long ago，贾宝玉在北京，林黛玉在长沙，怎么互诉衷肠呢，派家丁送信！路途遥远，怎么知道信收到没有？打电话问？那时候发明了这个就不用送信了，只能看家丁是否带了回信来了。假如发现一个家丁一个月还没有回，那就多半迷路堵车遭遇山贼或者开小差到扬州花差快活去了，再派一个人送吧！ TCP就是这么做的，UDP在应用层协议一般也需要这么做，但是实现上有时候往往有区别。     北京到长沙之间的路，并不是只有一个人跑的，常常会发生拥堵，假如发现家丁好久没有回了，TCP版的贾宝玉再派人送信是要的，但是他会比较识大体，他会少写信，降低发送速度，原来一天一封，现在可能一周一封了。他想，大家假如都这样，路就不会那么拥挤了。这做法很有道理，假如塞车了大家都想见缝插针，只能越来越塞，最后大家都动不了，还不如彼此容让慢慢排队。而UDP版本的贾宝玉假如也这么集体主义，那么他就叫做TCP友好流，就假如它只管自己拼命挤，就是非TCP友好的。     所有的TCP协议实现假如发现拥塞，都会马上降低自己的发送速度。假如基于UDP的协议不这么做的话，原来拥塞的IP包加上重发的包，网路只会越来越拥塞，最后所有的坚持集体主义的TCP流都会做出牺牲，把带宽让给一些非TCP友好的UDP流。所以除非网络状况非常好，否则TCP是拼不过非TCP友好的协议的。     我怀疑（仅仅是怀疑而已，我也没有条件和时间验证），QQ的文件传输机制是不那么TCP友好的，它抢带宽更加"我能"，这样虽然对于整个网络负荷不是什么好事，但是对于单个用户，就见仁见智了，就好像大家看待多线程下载或者p2p一样。...[阅读全文]

摘要:领导者/追随者（Leader/Followers）模型和半同步/半异步（half-sync/half-async）模型都是常用的客户-服务器编程模型. 这几天翻了些文章，发现对领导者/追随者模型说的比较少，下面就这个模型打个比方： 话说一个地方有一群有组织无纪律的人从事山贼这个很有前途的职业。 一般就是有一个山贼在山路口察看，其他人在林子里面睡觉。 假如发现有落单的过往客商，望风的山贼就会弄醒一个睡觉的山贼，然后自己去打劫。 醒来的山贼接替作望风的事情。 打劫的山贼搞定以后，就会去睡觉，直到被其他望风的山贼叫醒来望风为止。 有时候过往客商太多，而山贼数量不够，有些客商就能侥幸平安通过山岭(所有山贼都去打劫其他客商了)。   下面是这个模式的计算机版本：   有若干个线程(一般组成线程池)用来处理大量的事件 有一个线程作为领导者，等待事件的发生；其他的线程作为追随者，仅仅是睡眠。 假如有事件需要处理，领导者会从追随者中指定一个新的领导者，自己去处理事件。 唤醒的追随者作为新的领导者等待事件的发生。 处理事件的线程处理完毕以后，就会成为追随者的一员，直到被唤醒成为领导者。 假如需要处理的事件太多，而线程数量不够(能够动态创建线程处理另当别论)，则有的事件可能会得不到处理。 这个模型其实并不难于理解，但是我想假如是中国人给起的名字的话，也许会叫作 "皇帝轮流做，今年到我家" 模型更加贴切，因为领导者追随者之间是一种平等的关系。这不符合大部分人对于"领导者-追随者"的通常意义的理解。说句实话，个人认为半同步/半异步模型叫做"领导者-追随者'更加适合，不相信可以看看例子: 话说一个地方有一群有组织无纪律的人从事山贼这个很有前途的职业。 他们有一个山贼头头，他专门负责望风，其他的喽罗待命。 假如发现有落单的过往客商，山贼头头会到路口拦路，让客商双手抱头蹲在地上，然后让一个小喽罗为这个倒霉鬼"服务"。 假如客商很多，山贼头头会让客商在地上蹲成一排(严肃点，排队啦，打劫啦)。 一群小喽罗挨个为大家"服务"。 头头的工作很重要，对于每个客商他都不会花费太多时间，拦路以后，他会让客商排队等待打劫。 过往客商太多而山贼数量不够，客商的排队可能需要等待较长的时间。 这个就是半同步/半异步模型的比喻，可以参考一下 http://www.javaeye.com/article/60414 大家可以看到这两个模式之间的区别，最显著的，就是半同步/半异步模型拥有一个显式的待处理事件队列，而领导者-追随者模型没有一个显式的队列(很多IO机制操作系统一般会有一个隐式的队列)。因为这个事件队列，半同步/半异步模型可以获得处理上的灵活性，但是因为上下文的切换，效率上却比领导者-追随者模型稍有不及。 BTW,昨晚试验live writer，结果这个软件自动post了一篇blog，而我一时半会没有发现，望大家海涵阿。说句实话，觉得这个软件虽然不错，但是不是太适应中国国情阿，国内大部分blog都没法支持，csdn的支持也不是很好，居然上传不了图片，本来想以后可以写文章同时发到多个blog，看来是不现实了。 原文地址: http://blog.joycode.com/peon/archive/2007/05/13/102457.aspx...[阅读全文]

摘要:http://blog.joycode.com/sam1111/archive/2004/11/04/38040.aspx 提到google的高级搜索的site关键字只能把搜索范围限制在blog.joycode.com这个域名内，不能搜索 http://blog.joycode.com/sam1111这样的范围，得确是一个不方便的地方。 其实有一个替代的方法：使用 InUrl 关键字，表示搜索的页面URL必须包含某个关键词 比如 搜索 site:blog.joycode.com inurl:joy 兼职 就可以把开心发布的兼职信息都找出来:) 假如你想进一步缩小范围，只在随笔而不是文章中找，可以搜索 site:blog.joycode.com inurl:(joy archive) 兼职 可惜，这个关键字常常不能如你所愿，好像可以搜索到的东西不是很完全，可能一般的站点google作inurl索引不完全。就好像以前google搜索反向链接(使用link: ... )只能给出rank>=4的，现在能都给出来了，google也在不断的完善中 :-D 但是对于像 www.microsoft.com 的站点，inurl是非常有效的，特别是你已经知晓一个站点URL的一些规律的情况下。比如从经验我们知道微软howto文章的url里面总是包含howto的单词，我们可以这样使用google搜索关于安全的howto: site:www.microsoft.com inurl:howto security 另外，开心大哥提到我们写生活随想之类Post的问题，要求我们不要选中显示在首页的复选，但是发现仍然会显示在 http://blog.joycode.com 的首页，只是不显示在自己blog的首页罢了，合适的选项应该是Include in Aggregated Site 相关文章:Google搜索技巧－入门篇 十大高明的Google搜索技巧 Google黑客搜索技术< Google搜索技巧2005 Google桌面搜索使用心得 Google talk技巧十则 十四个方法提高博客的页面访问量 关于一个google搜索技巧-InUrl 百度搜索技巧 广告: HelixApp流媒体防盗链(WMS IIS HELIX) ...[阅读全文]

摘要:大家都知道Linux是Linus Torvalds不满Minix不够实用，没办法，Andy Taonenbaum 写这个就是为了教学和研究，就写了Linux. 那么大家可以看看 http://www.minix3.org ，这个项目除了保持Minix的特点，比如微内核(内核4000行都不到,驱动都是用户态的)，Minix3更加朝着实用性的方向发展，期望在一些嵌入式设备里面能有一席之地。 运行：大家在http://www.minix3.org/download/ 下载光盘映像，刻盘或者直接放在VMWARE里面开虚拟机运行就可以从光盘启动。 或者也可以从Bochs启动: http://www.osnews.com/story.php?news_id=7303  ...[阅读全文]

摘要:上集和相关内容请见：http://blog.joycode.com/peon/articles/16504.aspx 接下来发生了一些事情，张翠山夫妇双双自尽，他们的儿子张无忌又被打伤，张三丰和武当诸侠都忙于给张无忌疗伤，无暇顾及各自弟子的武学，而且为了诸侠和张老道的安全，给他们的问题不再直接交到他们手里，每人选了一个得意的弟子，代替自己解答问题，这些弟子的记忆力和反应都不错，可以解答大部分的问题，假如遇到不会的问题，就先向师父请教，然后回答给提问题的弟子，这样不仅大大减轻了诸侠的负担，而且防止了一些危险，比如在在便条上下毒，保护了诸侠的安全（徒弟的命就不值钱了？）。 在这种关系里，武当诸侠和他们的代理弟子构成了反向代理(Reverse Proxy)的关系，反向代理一般作用有三：减轻源服务器负载，保障源服务器安全，对源服务器进行负载均衡(Load Balance)。 一般反向代理置于源服务器的前端，配备大容量的内存和高速磁盘，缓存客户的请求，所以反向代理又称为服务器加速(Server accelerate)。源服务器一般不再和客户直接通讯，当客户请求没有缓存的内容或者动态内容时，反向代理向源服务器发送请求，然后把回应转发给客户，在这种情况下，反向代理服务器通常要为一个请求同时维护两个会话。和普通的代理不同，反向代理一般只代理一台或者有限的几台服务器，对于客户而言，反向代理服务器对于他们就相当于源服务器，对于源服务器而言，反向代理服务器通常就是唯一的客户，因为一般客户不和源服务器直接通信。典型情况下，源服务器对于客户或者客户对于源服务器，都是不可见的。 过了一段时间，张三丰觉得无法根治张无忌的体内的玄冥寒气，决定带他下山到少林寺去碰碰运气，为了让请教张三丰的弟子不至于得不到解答，宋远桥和俞莲舟暂时代替张三丰答题，凡是有请教张三丰的问题，宋青书就轮流送到宋远桥或者俞莲舟的住所。 张老道不在山上，可是他负责的服务不会中断，这种情况可以称为离线缓存(Offline Caching)，宋青书的所作的相当于把一个域名交替解析到两个或者以上的地址上去，这个就是DNS轮询。 张三丰所学太过渊博，单凭宋或者俞任何一人都难以回答所有的问题，两个人的知识加起来才可以勉强做到，但是宋青书却有时候把宋远桥不会的问题送到宋远桥那里，俞莲舟也常常遇到这种尴尬(说明宋青书到底还是少了根筋)。这两位到底是高人，一合计，决定视情况采取以下三种办法之一:1.假如宋远桥收到自己不会的，就写回复说自己很忙，而且这个问题俞莲舟很有研究，叫弟子另外写纸条问俞莲舟，俞也是如此这般。2.宋远桥把纸条给俞莲舟解答，然后自己把解答给弟子。3.宋远桥把纸条给俞莲舟解答，俞把解答给弟子。 第一种方法称为内容转向(URL Redirection)，就是当服务器发送给客户端一个特殊回应和新的URL，表示客户应该在其他的地方取得内容，然后客户向新的URL提出请求以获取内容，很多的协议都支持，开发过web的人对redirection和302 code应该都很熟悉。 第二种方法中，问问题的弟子，宋远桥，俞莲舟，还有张三丰构成了多重代理关系，宋相当于俞的反向代理，俞又是张三丰的反向代理。这个过程，对客户是完全不可见的。 第三种方法称为三角传输，宋，俞，弟子的请求应答构成了一个三角形，这种方式中，客户向A服务器发起请求，A服务器把请求转发到B服务器，然后根据客户的控制由B服务器向客户发送内容。 这三种方式各有优缺点，内容转向比较灵活，但是需要应用协议的支持(目前HTTP,MMS,RTSP支持)，而且转向次数一般有限制。多重代理构造复杂，而且因为代理需要维持双倍的会话，服务器负担很重。三角传输适合于请求流量小而回应内容流量多（比如流媒体）的情况，但是需要特殊网络设备(radware wsd)的支持，某些情况下，三角传输的前端还易于成为瓶颈。...[阅读全文]

摘要:http://wiki.csdn.net/ 关注codelphi的wiki有一段时间了，现在csdn正式推出了wiki服务，看了一些留言，感觉大家还不了解这个东西，就像从前不了解blog一样（是不是也来个木子美火一把：) ，建议看看这个：http://www.blogchina.com/new/source/180.html 然后用用就知道了 相比BBS纷杂的个体，BLOG的个人化，WIKI的群体概念无疑是另外一个不错的选择。 另外有个想法： 现在在一个公司或者组织内部，除了面对面的交流，一般是通过邮件，一些项目的细节和宝贵的经验和信息都在杂乱无章的邮件里面，这些东西很难整理和共享，而且假如一个员工离开了，关于他的这些就都丢失了:( 觉得一个组织内部可以架设WIKI项目知识库，作为知识和经验的积累手段；架设BLOG作为员工的个人平台；MAILLIST / BBS / BLOG 作为交流的方式。不要说不安全，这些方式都可以附带权限的 呵呵 今天(2004-7-27)发现一个asp.net的wiki引擎http://sourceforge.net/projects/sushiwiki...[阅读全文]

摘要:续集和相关内容请见：http://blog.joycode.com/peon/articles/16504.aspx 话说武当山上，张三丰老道开创武当一派，收了七个弟子，分别是:宋远桥、俞莲舟、俞岱岩、张松溪、张翠山、殷梨亭、莫声谷七人，号称武当七侠。七弟子中，宋远桥是掌门，精研易理，同时对于相面算命很有研究。俞莲舟武功最强，太极拳很厉害，殷梨亭擅长剑术，其他弟子也各有所长。 张三丰常年闭关，钻研武学，而这七个弟子又收了一些弟子，其中宋远桥的儿子宋青书是武当第三代弟子中的佼佼者。 依照武当的规矩，各个弟子(Client)可以向七位师傅(Server)讨教，可以把练功中的疑难写在纸上（Request），送到各位师父的住处，然后由各个师傅解答(Response)。 这种关系，就是最直接的服务器-客户机关系。 但是，这样存在一些问题，武当七侠住在不同的地方，有的地方很艰险，不是所有的弟子都可以到达的，这样，宋远桥就叫宋青书跑腿(Proxy Server)，每个弟子只要知道宋青书的住处(设定代理地址)，把疑难写在纸条上，再写上要请教的师父的姓名，再交给宋青书，就可以了。宋青书将纸条转交给七侠之一，将答复的纸条给各个弟子。 对于宋青书而言，各个弟子向他投递纸条，由他转交各位师父，在这种关系里，宋青书相当于师父(Server)，各位弟子是徒弟(Client),然后宋青书向七侠请教，这种关系里，宋青书是Client,七侠是Server，中间的过程，就叫代理(Proxy),宋青书就相当于代理服务器。 这种代理关系里面，各个弟子需要知道宋青书的地址(设定代理地址)，这种关系叫做显式代理(Explicit Proxy)，IE,MediaPlayer都可以设置代理。 经过一段时间，各个弟子也觉得这种方法虽然避免了很多的麻烦，但是很慢。宋青书也对这种跑腿的事情感到厌烦，他发现大多数人问的问题集中在几个问题上(80%的访问集中在20%的内容上)，于是，宋青书就把这几个问题的答案记在自己的IBM笔记本上(缓存)，以后凡是弟子们问到这几个问题，宋青书不需要再去问七侠，直接找出答案回复给各个弟子，这样各个弟子得到答复的速度快多了，武当七侠也有更多的时间干点其他事情(减轻了Server的负担)。宋青书的脑袋比较灵活，他还写了个程序，统计各个问题被问到的频率，随时记下新的热门问题，淘汰不再热门的问题(缓存替换算法)。 过了一段时间，宋远桥偷偷告诉宋青书，说准备把他作为掌门继承人，让他好好表现。宋青书于是改变工作作风，不再让各个弟子把纸条交给他，而是跑来跑去收集纸条，交给武当七侠。很多新弟子只是知道把纸条写好放在门口，自然会得到武当七侠的指导，大家都忘了宋青书干的这份事情，但是张三丰老道对宋青书可是十分的赞赏，立他为武当掌门继承人。 这种关系，叫做隐式代理(Implicit Proxy)，客户意识不到代理服务器的存在，也不需要设定代理服务器的地址，但是客户请求和服务器回应都会经过代理服务器，对于客户而言，代理服务器是透明的(transparent)。 续集: http://blog.joycode.com/peon/archive/2004/03/21/16756.aspx...[阅读全文]

摘要:大家都知道FTP的用户密码是明码传输，在公网环境下极不安全。因为考虑过书写一个类似的需要安全验证的协议，研究了一下相关的问题。假设一个非法用户可以嗅弹到会话的所有内容，该协议需要达到以下的要求： 1.非法用户无法得到密码 2.非法用户无法利用嗅探到的信息通过验证 我们可以考虑依靠DES等私钥加密方法加密密码，假如我们写的是一个公共的协议，加密方法和加密密钥就都需要公开，加密就形同虚设，黑客可以轻易的得到原来的密码。 我们再考虑MD5等hash算法，当服务器要求密码时，客户端对密码作hash，服务器把客户的密码hash和服务器的密码hash作比较，假如相同就是验证通过，黑客只能得到HASH过的密码，假如原始密码比较复杂的话，黑客是无法在有限时间得到原始密码的，第一点满足了，公钥加密方法也可以达到类似效果。 但是我们发现黑客虽然无法得到原始密码，但是他毕竟得到了hash以后的密码，使用这个密码，也可以正常登录，我们第2点是无法满足的，所以，我们要考虑需要一些客户端的信息，和密码一起做HASH，这个信息必须： 1.服务器和客户端都可以得到这个信息并且内容一致 2.黑客难以伪造这个信息 一个看起来不错的信息是客户的ip地址(我首先想到的也是这个)，但是可惜，因为NAT的存在，这个并不是很好用，我一直把精力放在客户可以提供的信息上，最后在Serv-U Ftp Server中发现它的一种对密码进行MD5的登录会话是这样的： 220 Serv-U FTP Server v5.0 for WinSock ready...USER test331 Response to otp-md5 998 lame113 required for skey.PASS SLAT BEAR QUO TOIL MARS GORE230 User logged in, proceed. 相同的机器，另外一次登录又不一样了： 220 Serv-U FTP Server v5.0 for WinSock ready...USER test331 Response to otp-md5 994 lame113 required for skey.PASS FLED DOOM OVA SAFE LEST HALT230 User logged in, proceed. 总算茅塞顿开：服务器发送给客户一个KEY，然后客户再把密码和这个KEY一起做Hash。因为每次发送的KEY都不一样，即使黑客可以嗅探到登录会话，也无法得到密码或者伪造信息进行登录了。 写出这个，无非是整理我对这个问题的一些思路，希望对大家有作用，也希望大家提一些看法（俺不是搞这个的，大家点拨点拨)。 还看到一篇文章，这是MIT（Massachusetts Institute of Technology）为了帮助人们理解Kerberos的原理而写的一篇对话集。里面有两个虚构的人物：Athena和Euripides，通过Athena不断的构思和Euripides不断的寻找其中的漏洞，使大家明白了Kerberos协议的原理: http://blog.joycode.com/peon/posts/18657.aspx，推荐读读:)...[阅读全文]