Live Spaces是我用过的最烂没有之一的Blog平台，速度慢到掉渣、地址改来改去、RSS链接三天两头的换这些问题都不谈了，因为Windows Live产品经理的脑子进水短路的关系，导致所有的Windows Live用户在打开Live Spaces、Sky Drive等Live相关网站的时候都要忍受一遍又一遍：自动启动MSN→关掉MSN→打开新页面→自动启动MSN→关掉MSN→……这样恶心的循环，而不管你是不是MSN的用户，需不需要这个时候打开MSN。这个经典的SB设计可以排到我接触电脑的13年来所见过的最脑残的产品前十位了。

那么如何帮助Windows Live的产品经理解决这个脑子进水的问题呢？办法有两个，一是购买一根12mm口径的薄皮钢管，把一头削尖，选一个你喜欢的位置插入Windows Live产品经理的头部，使劲摇晃将其中的水全部放出来。当然，如果你嫌这个方法过于麻烦，也可以试试下面这个稍微简单一点的办法：

打开控制面板→Internet选项→程序→管理加载项，选择显示“所有加载项”，然后选中每一个你能看到的名为“Windows Live”的加载项，点击“禁用”。从此便再也不必忍受打开一个Blog文章便要重复十几次关掉MSN的过程了。

• 缘起P2P

自从1999年大名鼎鼎的Napster问世以来，P2P技术在短短几年之内经历了从初生到成熟再到大规模普及的飞速发展，eMule、BT、迅雷等P2P应用为广大互联网网民带来了浩如烟海的丰富资源与风驰电掣的高速体验，最红最火的游戏、最新最全的电影，各种资源琳琅满目，下载一部电影甚至只需要品杯茶的时间……然而在另一方面，对于电信运营商来讲，各种P2P应用迅速耗尽了有限的带宽资源，同时却没有带来任何额外的收益。堵之，则站在了广大用户的对立面，硬生生的将用户朝竞争对手那里推；不理，则眼睁睁的看着各种P2P下载流量占满了接入带宽，令普通用户抱怨不已。不知不觉间，P2P已经成为了各大运营商挥之不去的梦魇。

在大家的注意力还没有从如日中天的P2P技术中移开的时候，一种新兴的P4P技术又悄然进入了人们的视野，给这种僵持不下的局面带来了一丝新的生机。P4P，全称是Proactive network Provider Participation for P2P，意指“运营商主动参与的P2P”。既然运营商和P2P是如此矛盾重重不可调和的两个对立面，P4P技术到底有什么魔力能够把他们凑到一起呢？

• P4P的前世今生

先回过头来看看P2P，P2P技术设计之初的理念就在于“Peer”和“Peer”间的绝对对等，网络中的任意两个节点间都处于相同的地位上，也即是说，一个地处北京的节点，可能会从另一个北京的节点和一个洛杉矶的节点同时下载一个文件的片段，而不管后者跟自己之间隔了整整一个太平洋。对于P2P的用户来讲，两个节点可能只存在速度快慢的差别，但对运营商来讲，数据在本地网间交换与在不同运营商——甚至是跨越好几个运营商的网间交换成本要低得多，如果P2P的用户间都能够优先在本地运营商网络中寻找资源，一则可以大大提升资源下载速度，二则运营商的宝贵出口带宽也得到了释放。但是，虽然象eMule这类的P2P应用引入了评级制度，会对节点的优先级进行排序加以选择，但这种优先级也大多是基于上传/下载率这类实际网络拓扑无关的参考标准；而以KAD为代表的DHT (Distributed Hash Table)网络技术进一步引入了节点间距离的概念，但受限于一个普通网络终端节点的视野，对网络拓扑的了解程度不可能达到足够的程度，KAD当中的距离更多只是体现一个逻辑的距离参数，对数据传输的本地化无法带来太大帮助。

P4P技术的出现改变了这一个局面，根据设计者的思路，在一个成熟的P4P“网络”中，运营商主动提供网络拓扑以及链路带宽信息（毕竟也没有其它人对网络结构信息比运营商了解得更清楚了），P2P的各个节点可以根据拓扑与带宽信息，优先选择本地带宽条件好的节点进行传输。这样，用户的下载速度得到了保证，运营商紧张的网间出口带宽压力也大大减轻，形成了一个用户与运营商双赢的局面，而这又反过来进一步推动运营商积极的参与进P4P网络的建设中来。事实也证明，P4P技术的一经推出，就得到了美国各大运营商的支持，根据P4P技术创始人谢海永博士的报告，P4P在美国最大的有线通信运营商Verizon网络进行了近125万用户参与的实际应用测试，结果表明，P4P可以节约70%-80%的网间流量，数据流的平均跳数从5.6下降到0.9左右，大大优化了运营商的网络资源。

• P4P：管理者的新挑战

有意思的是：在这场P2P引发的博弈当中，人们都把注意力集中到了矛盾最尖锐的用户与运营商两端，却或多或少的忽略了第三个重要角色：园区网管理者。对于最终用户而言，管理者希望能够控制P2P对网络的滥用，提高校园网/企业网用户的学习或者工作效率；而对于运营商而言，管理者也面对着日渐紧张的网络出口与运营商价格高昂的接入费用这一不可调和的矛盾。那么P4P的出现，会给网络管理者带来什么新的挑战呢？

毫无疑问，作为一项有生命力的重大技术革新，P4P虽然诞生时间不长，但迟早会走上普及之路。P4P是P2P在技术上的升级，随着P4P的进一步发展，可能会出现新的大规模普及的P4P应用，或者对现有的P2P应用进行一轮技术上的升级，不过从行为来看，P2P和P4P并没有本质的区别，两者的最终目标都同样是让广大互联网民一起参与到共享资源的平台建设和分享中来。因此，对于园区网管理者来讲，P2P带来的两个麻烦——一是企业员工工作效率/学生学习效率降低；二是占用本来便不充裕的宝贵出口带宽，干扰正常业务开展——并没有任何改善，甚至由于P4P技术在下载速度上的优势而进一步加剧出口带宽的压力。可见，P4P技术虽然为运营商与用户之间找到了一个矛盾的平衡点，但网络管理者仍然夹在最终用户和运营商之间，处于一个尴尬境地。

北京网康科技科技有限公司自成立以来便致力于研究各种互联网应用对用户网络的影响，针对P2P应用给网络管理者带来的困扰，网康科技也力争为用户提供一个全面而有效的解决方案。网康科技的ICG互联网控制网关产品能够对网络中常见的30种不同的P2P应用进行准确识别，针对园区网具体的应用和政策环境，可以对P2P应用灵活的进行彻底封堵、区分时段和用户的部分开放、或是限制其应用的带宽，进行可控的疏导，给予网络管理员切实有效的技术手段来解决P2P应用带来的难题。

而面对新兴的P4P应用，网康ICG互联网控制网关同样能够进行有效的识别并加以控制。虽然P4P发展的时间还不长，目前仅有Pando、Qvod等少数的应用能够支持，但网康科技秉持着对新兴技术的持续关注，以及为用户提供最可靠解决方案的理念，依靠专业的应用协议分析团队及时跟进分析，第一时间在产品中加入了对P4P应用的识别与管控功能，确保管理员手中利剑时刻保持锋刃，不会被各种新兴应用扰乱网络的正常有序运行。同时也确保一旦有新的P4P——以及其它技术更先进的应用产生，能够快速跟进，为用户提供最及时的解决方案。

网康科技通过对技术的不懈追求，密切关注互联网应用的发展，力争实现网络的可视、可管、可控化管理，力争成为每一个网络管理员手中不可或缺的神兵利器！

从Latitude最开始发布的时候就一直用到现在，每一次的版本更新都及时跟进，也切实的感受到了Latidute在一点一点的进步，而这次最新发布的3.2.0（S60V3版）是自第一版到现在更新最大的一个版本，试用了几天下来（所以就不要说我火星了），感觉进步还是相当明显，试总结如下：

优点：

1. 个人认为最大的一个改进是：Google终于把卫星图和矢量地图之间的位移问题解决掉了。之前的版本里面（不管是Latitude还是普通Google map，包括Web版）都存在一个很严重的位移问题。平时用得最多的是矢量地图，位置搜索、公交路线等等都是以矢量图为准，但一旦切换到卫星图，则会发现位置偏移了好几百米，比如搜索天府广场，切换到卫星图一看天府广场就给标到体育馆头上去了。而且这个位移在每个地方都不一样，以我的经验，在北京，卫星图比矢量图要偏西8点钟方向500米左右，在成都则要偏西北11点方向400米的样子。本来卫星图平时用的少，这个问题还不严重，但要命的是Latitude当中自己和好友的位置偏偏又是以卫星图为基准的，这就导致在Latitude的矢量地图中始终可以看到当前自己的实际位置和纵横的位置总是隔着老远挨不到一块去。令人欣慰的是Google终于认识到这个问题，并且在这个版本中出手将其解决了。
2. 第二个改进是增加了图层的概念，虽然这个在Web版的Google地图中已经不是什么新东西了，但应用到移动版上来还是第一次。有了图层概念之后给使用带来了巨大的方便，查询结果可以作为一个图层，公交路线可以作为一个图层，Google纵横可以作为一个图层，等等……各个图层可以任意开启关闭，再也不会象以前那样查看了公交路线就看不到搜索结果，要找好友的位置又搜不了公交路线这种事情了。并且图层还有一个好处是可以把搜索的相关结果全部标注在地图上，比如我搜索了招商银行之后，只需要一直开启这个图层，不管地图显示到哪里，都可以看到地图上相关的搜索结果，非常方便。
3. 把Google账户集成进移动版了，补上了这个其实从Google地图发布的第一天起就应该做的功课。在移动版用自己的Google账户登录之后，Web版中保存的一些图层、收藏都可以在手机上显示了。好处应该不止这些，下一步应该可以继续把GTalk、Gmail这些应用都集成进来，可以直接跟地图上的好友沟通联系，甚至做到更多普通SNS做不到的事情。

当然，还是有一些不足的地方：

1. 速度明显变慢了，在地图上移动感觉比以前的版本要迟滞很多，一点也不流畅，影响体验。
2. 没有使用谷歌地图(http://ditu.google.com)的地图资料。一直没搞明白Google对自己产品线的定位，既然是相同性质相同功能的应用，为什么非要搞两个完全不同的地图版本出来（http://ditu.google.com和http://map.google.com）而ditu.google.com的中国地图不管是从美观还是信息的丰富程度上来说都要比后者好很多。既然现在Google地图移动版的普通版本（2.x.x版）已经开始使用ditu.google.com的地图资料了，为什么不干脆让Latitude也继承过来呢？

OK，平心而论，3.2.0这个版本的进步很明显，本人很满意，Google请继续加油～

下午兴师动众到工体参加MS2008的新品发布会。由于担心去晚了抢不到好座位，我和两位同事中午早早出发一路奔袭赶往工体，到了却发现工体周边正在大兴土木，挖得一塌糊涂，怎么看也不像是世界头号软件公司将要在这里举办新品发布会的样子。绕了两圈没找到北，郁闷之下找人一问，才发现邀请函上写的是“工人体育馆”，当我们三个傻乎乎的在“工人体育场”兜圈子的时候，一街之隔的正牌会场那边已经人潮涌动，开始签到了。MS的会务组织人员实在是高估了我们这些外来务工人员对帝都地理的认知，不能不说是考虑不周啊。

MS这种钱多得没处烧的公司，在这种赚吆喝的场合可真是不惜花血本。诺大一个工人体育场，6千多人的会场竟然坐得满满的，最后一排甚至还有不少人站着看，精神可嘉。整个会场布置得颇为豪华，摄影导播灯光场记等等一应俱全，在发布会开始之前，还首先由一支乐队进行了15分钟左右的热场演出，造足了声势。1点半正式开始的时候，出现在场上的主持人竟然是CCTV-5的刘建宏以及CCTV-9的某海龟女主持，不由得感叹MS的财大气粗。不过转念一想，估计这场发布会的成本也不过就是欧盟一天罚单的零头，也就释然了……

就整个发布会的效果来看，还是相当的不错了。前面的领导致辞暂且跳过不谈，作为今天发布会的主题：Win Server 2008、SQL Server 2008和Visual Studio 2008这三款产品的发布自然是重头戏，MS采用了一种别出心裁的现场演示手段：构建了一个虚拟的网上咖啡公司，由六位MS员工分别扮演三组角色，就公司日常业务中出现的三个场景进行了现场演绎，比起其它一上来就对着ppt猛讲的发布会来说无疑要生动了许多，并且也很好的切合了其发布会“企业级应用平台”的主题。像我这种一听人开讲就忍不住在下面开始打瞌睡的惯犯，今天竟也饶有兴致的听完了全场。

首先上来的一组扮演的是这个虚拟网上咖啡公司的业务经理与IT经理，几组看似随意的问答很好的穿插进了Win Server 2008的几个重点新特性，并同时在现场的服务器上进行了实际操作的演示。给我留下比较深印象的有三个：

• 服务器核心、Server Kernel部署模式：采用这种模式安装的Win Server 2008将没有GUI界面，只提供最基本的命令行管理方式。摒弃了花哨的外观，开始专注于服务器操作系统的本质工作，不知道是不是可以看作MS对UNIX阵线的妥协呢？
• 虚拟化、Hypervisor技术：可以在一台物理Win Server 2008服务器上虚拟出多个虚拟服务器。可以看出MS在收购了Virtual PC 5年之后，终于很好的消化了虚拟机的技术，并整合到了Win 2008当中。除了基本的虚拟机功能之外，还打出了“安全性”、“性能”和“易用性”的卖点，并且能够按照业务应用灵活调整虚拟服务器的CPU、内存资源占用情况。现在一台性能强劲的服务器终于也不用再被低端的应用平白浪费资源了，可以通过Hypervisor技术把多个轻量级的应用用虚拟服务器的方式整合到一台物理服务器上来（这样也意味着MS又能卖出更多的copy——如果都是用正版的话，呵呵）。看上去很美，至于实际的应用情况又如何，我们拭目以待了。
• 远程服务、RemoteApp技术：这个东西比较类似远程桌面，但可以看作是应用级的远程桌面系统。在演示的过程中，IT经理现场在服务器上添加了一个报销系统的RemoteApp链接，随后用浏览器登录公司的内部门户系统网站首页，就可以看到一个新增的报销系统链接，点击这个链接，经过短暂等待，就在本地桌面上启动了远程服务器上的报销系统应用。感觉比较类似SSL VPN，但RemoteApp的后台其实都是跑在HTTP或者HTTPS协议上的，而且这种基于应用级的远程业务在灵活性上应该会是远远高于VPN的。感觉会比较有前途。

第二个上台的一对扮演的是公司的销售经理和数据库管理人员，演示的主题自然是SQL Server 2008了。SQL Server 2008也加入了不少花哨的新功能：

• 可以很好的和微软现在力推的SilverLight结合，直接通过SilverLight进行统计数据的报表呈现，应用方便并且花样繁多。看到这个我就在考虑，我们的自己的系统如果迁移到SQL Server 2008上来，是不是也不用去买水晶报表就能做出这样灵活好看的统计图表了呢。
• 提供大量的数据分析模型。在演示中，数据库管理员很轻易的通过这个工具帮助销售经理分析了客户的购买行为，比如买了美式蛋糕的顾客一定会再买一杯咖啡，从而更好的制定行销策略。啊，很好很强大，只是不知道实用性怎么样。另外——这个还是数据库服务器吗……？

总的感觉，SQL Server 2008在功能性和易用性上做出了很多新的东西，但作为一套数据库系统来说，核心指标还是性能和稳定性，如果不能在这上面有所突破，恐怕还是很难撼动Oracle在这个领域的权威地位啊。

第三个上台的是网站设计者和开发人员，不用说一定是Visual Studio 2008的环节到了。虽然我比较土不懂技术，但也还是看出来了一些有意思的东西：

• VS Team System 2008：可以为团队开发提供更好的协同工作体验，似乎对于工作计划、流程的安排有了更灵活的协作方式，然后更详细的细节没讲太多，我也搞不明白了——没办法，谁叫我不懂技术呢～
• 类似“所见即所得”的特性：象Dream Waver这样的Web开发工具一样，VS 2008也能提供类似“所见即所得”（不好意思，俺不懂技术，也只能这样称呼了）的特性了，不用coding完之后编译再试运行，在开发的界面中就可以在另一个窗口里实时看到运行的效果了。我这个外行看上去挺爽，不知道程序员同学们看到会不会觉得爽。
• 与设计人员更直接的交互：VS 2008中似乎是提供了一种叫“Zara”（还是叫Z什么，没听清）的语言，设计人员在设计好网站的构图和框架之后，VS 2008就能自动根据设计生成相应的“Zara”语言，可以直接交给开发人员使用来生成最终的网站代码。似乎这样就能省去不少之前开发人员拿着美工的原图再不停切图调整修图的工夫，我的理解是这样——俺不懂技术，程序员同学们不要骂我……

  
另外还有一些有意思的花絮，也给大家分享一下：

1、专业的同声翻译：这次来的MS高层领导有MS副总裁兼大中华区COO的鲍方德同学，以及MS服务器产品线的高级副总裁。据说今天这场是全球Win 2008造势活动中规模最大的一场发布会了，也难怪，帝国人多嘛。两位领导的英语都很地道，演讲也很到位，听得也颇有意思，更有意思的是中文演讲词并不是以字幕的方式放出，而是在大屏幕上一个类似WORD的编辑器界面里面，以同声翻译的方式一个个打上去的。不知道这是个什么软件，貌似是可以多人一起进行编辑，可以很明显的看到在下一行正在一个个敲出最新的文字的同时，上面的几行也在飞快的对错字漏字进行修改。我们坐得离内场很近，低头一看，下面果然坐了几个翻译小妹子正在噼里啪啦运指如飞呢。两位老板在台上讲得行云流水，同声翻译的速度竟然一点不慢，而且准确度颇高，果然很有专业性啊！

2、再遇熟人：演示Win Server 2008的那位IT经理，名字叫孔文达，本人是MS的解决方案技术经理，之前跟我也有数面之缘，去年初就在Forefront的发布会上见识过这位孔经理，也参加过他在Technet上举行的几场在线讲座，后来还在MS总部交流的时候和他进行过面对面的沟通。感觉是个很沉稳、思路很清晰的人，发布会上的角色也确实很适合他的技术专家形象。

3、艳照门啊艳照门：演示Win Server 2008的时候，那位业务经理钱非非同学还借电脑送修的桥段小小的kuso了一下艳照门事件，现场哗然，远在米国的陈老师一定打了个结结实实的喷嚏吧。

4、中国风：可以看出MS对待北京的这个发布会还是下了很大工夫的，从演示Video到现场节目和舞台布景都有一股浓浓的中国风味在里面，期间还穿插了比较出彩的二胡和京剧表演，还是比较能引起中国人的共鸣的，也让整个发布会的气氛比较轻松

5、安检：发布会前几天就陆续接到MS会务组的若干个邀请电话，询问我是否能按时出席，并且还委婉的提醒尽量不要带包，现场会有安检。我心想是不是因为上次比尔大门同学在北大的演讲被开源斗士闹了个灰头土脸，所以现在也要严加防范了。不过到了现场也发现其实所谓的安检也都是走个过场而已，走过安检门嘟嘟响一声，后面的工作人员MM检查下门票就给放行了，跟机场的安检完全不能相提并论。想想也是，6000多人，如果都来仔细检查一遍，那下午的发布会就不要开了，观众得提前一天进场才行。

6、惠普乌龙事件：京剧表演结束后有各赞助商致辞的环节，其中惠普的某领导，不知道是太紧张还是自家的发布会去多了，张口竟然说出了“祝今天惠普2008发布会圆满成功”这样的乌龙台词，全场一愣，然后开始爆发出低低的笑声。也亏今天的场合比较严肃，观众们比较低调，如果是在什么晚会上的话，这位领导的篓子可就捅大了～

7、I&A之争：同样还是赞助商致辞环节，Intel和AMD这对老冤家不免又聚在了一起，虽然MS似乎是刻意的把双方的两位高层发言的顺序隔开在了一头一尾，但场下观众还是能闻到台上那浓浓的火药味。先是Intel的亚太区某副总裁致辞，顺便宣传了一下自己马上就要发布的45nm工艺CPU（AMD最近一直被Intel 45nm工艺的宣传造势搞得很郁闷）；后面AMD的高层也不甘示弱，大谈Win 2008一定会在AMD的“真”4核平台上发挥出最佳的性能，还特意用了高八度的重音使劲强调了这个“真”字（AMD一直炮轰Intel的4核CPU是假4核），把我们在下面乐得不可开交。想必台上MS的鲍方德同学此刻脸上表情一定很难看，后悔为什么非要把这对冤家给一起弄上台了吧……

最近看到各门户网站竞相报导“我国IPv9十进制网络安全地址投入使用”的消息，不禁有些汗颜，作为一个搞网络的IT民工，连IPv6都没完全弄清楚，这边连IPv9都出来了，连业界潮流都摸不到门，还混什么饭吃啊。

看到文章里引用的权威数据又是一惊：“据中央党校经济学部课题组提供的研究报告显示,每年,我国向美国支付的使用现有国际互联网的费用,包括域名注册费、解析费和信道资源费及其设备、软件的费用等,高达5000亿元以上”。我的神啊，整个大中华帝国互联网行业一年的总产值还不到1000亿，全部倒贴给米帝也不够啊！原来咱们这帮IT民工辛辛苦苦干了一年，到头来全部都是给很黄很暴力的米帝打义工了！

据主持IPv9研究的谢建平老师声称，IPv9的技术标准来源于IETF在1994年颁布的RFC 1606（中文翻译在这里），激愤之余，还是赶紧学习一下这先进技术文件的精神吧。但粗看一眼不免有些纳闷，作为一个重量级的技术标准，这RFC 1606的篇幅未免也太短了点吧，并且对于一个通信协议来说，最重要的报文格式、交互流程等内容没有丝毫的涉及，实在是不像IETF这个严谨专业工作组的一贯作风。仔细看下去，在标准正文中竟赫然出现了“平行宇宙”、“身体监视器”、“外太空割草机”这类科幻小说中才有的东西；再往下看，甚至已经开始正儿八经讨论到食物包装网和脚臭分析器的可行性了！回头仔细一看标准发布日期：1 April 1994 —— 这不摆明了是一个愚人节玩笑嘛？

IETF已经不止一次在愚人节发布这种搞笑的伪标准来调剂一下业界的严肃气氛了——搞IT的，谁能没有一点KUSO精神呢？但就是这样一个搞笑的标准，竟然被谢建平老师堂堂正正的拿来引经据典，作为一项“突破性的前沿技术研究成果”来大肆宣传，大敛其财。继续google一下相关的资料，原来早在04年此公开始炒作所谓“IPv9十进制网络”的时候，就已经有大量的业内人士进行怀疑了，看看谢老师是如何用四两拨千斤的妙招绕开业界的质疑，并极度宣扬自己的“伟大创造”的：

IPv9都被认为是科学家的一个不切实际的美丽幻想。所以2004年6月25日，谢建平的IPv9技术一经发表，立时招来嘲讽。
嘲讽来自于1994年4月1日发布在著名的RFC编号为 1606的文档。在这个名为《使用IP版本9的历史观》文档中，言辞确凿的指出了IPv9的很多可取之处，曾引起业内普遍的“轰动”。
但这个文件被认为是一场恶作剧。因为其发表日期正好是愚人节，另外文件最后的结论非常搞笑：不研究历史的人，注定要重复历史。
谢建平：美国人找到我了，他给我们看了当时的文档，我们也觉得很怪，是4月1日发布的！后来我们了解，这个文档还是相当严谨的，是美国互联网标准组织ITF做的。
在研究过程中，我们才发现IPv9不能解析。这把我吓出一身冷汗，如果这个技术不能突破，我的研究将和美国的星球计划一样，面临死亡的危险。
同样不能解析的问题也出现在IPv6的研究上。1990年美国开始研究IPv6，却直到1994年却还无法推出，1999年也不行——在实验室试验可以，商业化就不行。
1990年美国IPv6文本中，IP地址的表示方法为：FF：FF：FF……FF，总共128位。冒号表示URI的端口号，但是在输入这个冒号的时候却时而要和URI的端口号发生冲突，所以无法解析。
后来我们想出一个方法，加上一个“〔〕”。在计算机语言的表述方法中，除“〔〕”以外，所有的标点都有了特殊的定义。于是后来，IP地址的表示方法就变为：〔FF:FF:FF……FF〕。
1999年，在和美国的学术交流过程中，我提出自己的“中括号解决方案”。很多人都不理解，全世界这么多人在研究都无法解析，大家困惑了10年都找不到方法，一个“〔〕”就解决了——这是中国人对世界的贡献！是我谢建平解决掉的，这点很重要。

一个中括号解决世界级难题，这是多么伟大的发现！这是上了多少年小学数学的精英头脑才能想出来的绝世妙招啊！

我大中华帝国从来不乏强者，近年来尤其人才辈出。象谢建平老师这样能从洋人的搞笑标准里挖出真理，并弘扬海外为国争光之辈，也不再是凤毛麟角。如果帝国科学界砖家叫兽们能有谢老师一半的头脑和钻研精神，区区米帝日寇于我堂堂帝国何惧焉？谢建平兴，中华幸甚！

想必这两天电信的头头们过得一定很郁闷吧。从前段时间背地里搞HTTP劫持强奸用户的事情被捅出来之后，自己的星空互联也后院起火，被网友评选成为“最大的流氓软件”（相关链接：http://www.cnbeta.com//modules.php?name=News&file=...,http://www.cnbeta.com//modules.php?name=News&file=...,http://www.cnbeta.com//modules.php?name=News&file=...），在网上吵得沸沸扬扬。

不过话说回来，你一班无名小卒在下面瞎折腾，又能把世界五百强中国首席垄断巨头之一的电信怎么样呢？该收钱的照收钱，该强奸的照强奸。现在的草民和过去想比，也就多了喊喊的权力而已。哦，还不能太大声了，上头还有GFW盯着呢……

今天看到好多地方都在介绍MS新发布的这个东西，赶紧也下了一个试用一下。毕竟是MS自己的产品，跟live spaces结合得很紧密，spaces上常用的功能都能直接在本地实现，也算能缓和一下最近live spaces慢得掉渣的麻烦。

介绍&下载：

Click here

今天遇到了这样一个需求，某校园网要求校长室能够访问财务室，但反过来财务室不能访问校长室。听上去似乎很简单，但仔细一想，因为通信过程是双向的，如果只在三层设备上做策略，不用防火墙的话，用普通的ACL根本无法满足这样的需求。于是魏哥提出了使用自反ACL的方法，赶紧学习之：

自反访问表是CISCO提供给企业网络的一种较强的安全手段，利用自反访问表可以很好的保护企业内部网络，免受外部非法用户的攻击。
自反访问表的基本的工作原理是：
只能由内部网络始发的，外部网络的响应流量可以进入，
由外部网络始发的流量如果没有明确的允许，是禁止进入的。

1)Reflexive-ACL的工作流程：

a.由内网始发的流量到达配置了自反访问表的路由器，路由器根据此流量的第三层和第四层信息自动生成一个临时性的访问表，
临时性访问表的创建依据下列原则：

●protocol不变，
●source-IP地址 , destination-IP地址严格对调，
●source-port,destination-port严格对调，
●对于ICMP这样的协议，会根据类型号进行匹配。

b.路由器将此流量传出，流量到达目标，然后响应流量从目标返回到配置了自反访问表的路由器。

c.路由器对入站的响应流量进行评估，只有当返回流量的第三、四层信息与先前基于出站流量创建的临时性访问表的第三、四层
信息严格匹配时，路由器才会允许此流量进入内部网络。

2)自反访问表的超时：

a.对于TCP流量，当下列三种情况中任何一种出现时，才会删除临时性的访问表：
a)两个连续的FIN标志被检测到，之后5秒钟删除。

在正常情况下，TCP在断开连接时需要经历四次握手：

　TCP是一个双向的协议,前两次握手，断开从source到destination的连接，
　　　　　　　　　　　后两次握手，断开从destination到source的连接。

　临时性访问表的删除之所以要延迟5秒，是为了给TCP连接的断开一个缓冲的时间，保证TCP能够平滑的断开连接。

b)RST标志被检测到，立即删除。
c)配置的空闲超时值到期(缺省是300秒)。

b.对于UDP，由于没有各种标志，所以只有当配置的空闲超时值(300秒)到期才会删除临时性的访问表。

3)解决自反访问表对FTP的缺陷：

FTP的两种模式：
a)standard-mode(标准模式)：

标准模式的特点：
1)ftp-server端使用两个wellknown端口，21和20 , 21号端口为控制信道，20号端口为数据信息。
2)数据由ftp-server端始发。

b)passive-mode(被动模式)：

被动模式的特点：
1)ftp-server端使用一个wellknown端口和一个 >1024的随机端口，此例中为21和1800 , 21号端口为控制信道，1800号端口为数据信息。
2)数据由ftp-client端始发。

通过以上分析，我们发现对于被动模式的FTP，自反访问表可以正常工作(因为数据是由ftp-client端始发)
但是对于标准模式的FTP，自反访问表将不能正常工作
(因为数据由ftp-server端从20号端口始发，当ftp-server向client返回数据时，与临时性访问表不匹配)

利用ACL解决自反访问表对于FTP的缺陷：

例：
　

允许由内部192.168.10.0/24始发的HTTP，SMTP, TCP流量可以出去, 其余的流量全部拒绝。

RA：
!
ip access-list extended OUTBOUND
permit tcp 192.168.10.0 0.0.0.255 any eq www reflect CISCO
permit tcp 192.168.10.0 0.0.0.255 any eq smtp reflect CISCO
permit tcp 192.168.10.0 0.0.0.255 any eq reflect CISCO
!
!
ip access-list extended INBOUND
permit tcp any eq ftp-data 192.168.10.0 0.0.0.255
evaluate CISCO
!
int s0
ip access-group OUBOUND out
ip access-group INBOUND in
!
ip reflexive-list timeout 300 (设置临时性访问条目的生存期，缺省为300秒)