昨天瑞星发布了一个新产品，卡卡上网安全助手6.0版，这是承载了瑞星所谓云安全理念的新产品，并且承载了瑞星走在行业前列的高调姿态以及宏伟目标。
不过这基本都是等于扯淡。
在描述其工作机理时，是这么说的，该软件在用户启动机器时会自动加载，其“自动在线诊断”模块会自动检测并提取电脑中的可疑***样本，并上传到瑞星“***/恶意软件自动分析系统”(Rs Automated Malware Analyzer，简称RsAMA)，整个过程只需要几秒钟。随后RsAMA将把分析结果反馈给用户，查杀***病毒，并通过“瑞星安全资料库”(Rising Security Database，简称RsSD)，分享给其他所有“瑞星卡卡6.0”用户。（以上部分来自新浪发的厂商新闻稿。）
这就带来一些问题，第一，用户机器里面的所谓“可疑样本”如何确定，显然这无法提取所有的***样本，更多的是对已知的***起作用；其次，可疑样本会不会判断错误，如果出现错误的判断会不会造成大面积的恶劣后果——例如去年瑞星把IE给杀了那样的后果；再其次，所谓的自动分析系统，在瑞星自己的陈述中，也只能“可以自动分析、处理绝大多数新增***病毒”，看来这个系统也并不能处理所有的威胁，自然厂商不会说的是，也不能杜绝错误处理的可能。第四，对于无法随时与云端联系的客户端，这个产品的效果如何很不好说。当然，在商言商，吹捧自己的产品倒也没什么问题。
不过我倒不是对于瑞星有什么兴趣，因为以前不是其用户，以后估计也不大会是，主要是他们的所谓“云安全”的先进理念。只想赞扬一下瑞星还真是与时俱进，紧跟最新时尚。
云是目前比较热门的一个名词了，云计算的拥护者们激动的为它鼓而呼，象GOOGLE更是把自己打扮成布道者与先驱的形象。不过仔细想一下云计算的概念，是不是有点似曾相识呢？似乎以往一个叫网格计算的概念也没有太多的差别？当然云计算把更多一些的资源如存储等也拉了进来并且更加商业化，但是从本质上，两者是没有什么区别的。
就是这么一个旧酒新瓶的概念，却让如今的大小厂商们都趋之若鹜，生怕赶掉了这班车……不过有人说得好：“套用一个大家都熟知的概念来阐述“云计算”吧，“网格计算”、“服务科学”与“云计算”的关系，就是“脑黄金”、“脑白金”和“黄金搭档”的关系。但后者起码还有个可以喝下去的东西呢，而前者连个东西都没有，只有概念。”
 
好吧，我得承认我可能起了个大早，却也有可能连晚集都赶不上。
大概在7、8年前，我也有过一个云计算的点子，当然那时候我甚至连网格计算也都不知道，但是确实就是出现了……
事情是这样的…………
当时正在研究TCP/IP，以及路由器原理和OSPF（开放最短路径优先），某一天受困于上海拥挤的交通的我，突然想起了OSPF似乎可以用来解决交通问题，并且，想起了前两年（当时的前两年是1999年）的一个NASA项目：SETI@HOME——我相信如果我是在北京的话，那大概可以更早的想到这个点子，毕竟上海的交通还没有北京那么糟。
具体一点说是这样的，我们可以把每一辆车看成一个数据包，那么根据路由原理，每个路由器都发送广播询问谁知道到达某个目标点的路径，收到广播的路由器们，如果自己也不知道，那么就转发广播，如果知道则返回路径，这一过程迭代直到找到一条或者多条路径，所有被告知路径的路由器都把路径添加到路由表中并且发送一个广播（这时候是否发送广播我不是非常确定）。不过仅仅如此是不够的，这个最多也就是一丁丁地图。OSPF的作用在于，这是一个状态型的协议，每一个路由器都知道自身的负载或者称状态，到达一个目标点可能有不同的路径，那么把各条路径上的每个跃点（HOOP，也就是路由器）的开销相加，并选择开销最小的一条路径作为最优路径——当然这只是OSPF的基本原理，具体实现要复杂得多，而我也脱离技术线的工作很多年了——那么回到我们的问题上来，要确定车从起点到目的地该走什么路径最快，从原理上来讲基本可以认为是一个OSPF问题，如果我们把每一个路口都看成是一个跃点，那么最了解路口负载的当然是路口本身，通过多个路口的联合计算，应该可以有一条最快的路径（注意未必是最短）。
原理说完了，自然要说说实现。首先这需要大量的计算，绝对大量，这就跟SETI@HOME有关系了，当然我们是需要计算中心的，另一方面，我也希望通过类似的项目来获取更多的运算能力，这显然就是云计算了……如果能够获得联接在网络上的比较多的PC的空余计算能力，那么应该足够应付路由的计算，自然计算能力并不是免费的，不过我们可以用提供指路服务来交换，尤其针对一些大公司，可以将有关的服务提供给其员工作为福利，而最需要计算能力的交通高峰期，恰恰是大家都堵在路上而没有使用PC的时候。这是计算云。另一端是客户端，我设想是类似GPS的一个小设备，一方面它把要去的目的地传输到路由网络，另一方面把网络的指令反馈回车上，第三个作用则是在路口处向跃点设备发送识别信息，便于设备计算本地负载，基本类似于传感器；这是用户端的探测云，很显然这个方式有一个很重要的条件就是需要在尽可能多的车上安装用户端设备，否则效果不会理想，直到前两年才解决这个问题，这得感谢狼总，在06年某次我跟他说起这个问题时，他告诉我有一种新技术通过路口的探头画面自动获得路口拥挤程度，如果把这项技术整合进来，可以为判断路口负载提供一个修正的参数。
通过在一个城市中部署这样的技术，相信可以把整个城市的交通效率提高一个相当可观的水平，我个人估计可以提高10-15%，随着客户端设备的普及，可能会有更好的效果。其他一些实现以及商业上的细节在这里就没必要描述太多了。
 
这个想法在实现上，需要太多的资源，因此这班车我估计是赶不上了。不过至少我得证明在车来以前我也预料到了，这比某些跟风的厂商大概要高明一点，嘿嘿……
 
 
 
 
说明：这篇BLOG不是先发在这里的。大概比另一个BLOG晚上那么3、5分钟。