51Testing软件测试论坛

标题: 测试工具(3)---OmniPeek (出自WildPackets的著名的抓包软件) [打印本页]

作者: 阿七 时间: 2010-4-2 15:18
标题: 测试工具(3)---OmniPeek (出自WildPackets的著名的抓包软件)
全面对比OmniPeek与Sniffer (一) 概述

从DOS版本的Sniffer/EtherPeek开始，这两个产品就一直是这个领域的一对欢喜冤家。1997年Sniffer当时所拥有的公司NGC(Network General Coporation)收购了Cinco Systems，后者拥有当时最为闻名遐迩的Windows下的分析软件NetXray。从此Sniffer披上了Windows的外套，在Windows下也实现了Sniffer引以为傲的专家系统。1997年底，NGC和McAfee合并组成Network Associates，从此踏上了大规模商业化的道路。

AG Group早期发展EtherPeek的步伐有些缓慢，在推出了Macintosh版本的分析软件并且垄断了相应市场以后，其发展轨迹也变得更为技术化。
到2000年以后，WildPackets脱胎于AG Group的传统建构，并且收购了Net3、Optimal Engineering和PMG等一系列产品、培训、服务企业，顿时实力大增，WildPackets也进一步把专家系统技术引入到EtherPeek产品线中，出现了EtherPeek NX等新的产品。从DOS/Mac跨越到windows 2000平台，EtherPeek几乎被从头进行代码。到了2003年以后，WildPackets逐渐羽翼丰满，终于推出了分布式分析产品OmniPeek。这个产品足足晚了Sniffer Distributed 8年。

Wireless LAN进入市场以后，网络分析产品逐渐发现了一个新的战场，在Hub时代，网络分析产品不需要配置就可以使用，而且当时网络又确实漏洞百出。到了Switch时代，网络分析产品逐渐变得更难部署，即使部署，成本也很高。到了无线网络环境，人们发现，又一个新的hub环境驾临了。

可惜的是从1998年完成合并之后，到2004年NAI分裂之前，NAI始终不能对Sniffer投注于高昂的激情。相对于防病毒市场而言，网络分析工具无论是从市场总量还是增长趋势都不能与之相提并论。而且更大的问题是网络分析通常会被认为比防病毒要高几个技术level，Sniffer和McAfee在核心价值上遇到了巨大的抵触。Sniffer停滞了三四年之后，终于获得了重生的机会。但是在这个不短的时机中，WildPackets已经快速逼近，甚至已经超越。

Network Magazine是网络产业的风向标之一，在网络分析领域，Sniffer曾一直荣获1997, 1998, 1999, 2000, 2001的年度最佳网络分析类产品，然而之后，2002, 2003年的年度最佳产品桂冠就转移到了WildPackets手中。工欲善其事，必先利其器。我们在从事网络分析、优化之前，很重要的一环就是要准备好最佳的工具，之后我们试图用比较客观的一下Sniffer和OmniPeek的各类功能以及实现效果。希望通过这些比较，能够帮助我们更加深入地了解这两个产品，熟悉各类功能的使用和应用，同时找到最最适合自己的称手的兵刃。

[ 本帖最后由阿七于 2010-4-3 15:08 编辑 ]

作者: 阿七 时间: 2010-4-2 15:30
标题: 全面对比OmniPeek与Sniffer (二) 软件设计
从Sniffer Pro和OmniPeek的设计而言，两者代表了不同时代的设计理念。
Sniffer Pro从netxray里获得了图形化界面以后，就开始试图建立新的网络分析软件标准。用过Netxray的同志们应该都知道，Matrix、Dashboard其实都是Netxray里就已经存在的设计。而NGC Sniffer 的最大长处就是Expert System和对各类链路的支持。 Expert System顾名思义就是专家系统，自动地根据网络捕获的数据进行分析并提供分析结果。
Netxray的界面设计应用了后Win31时代和早Win95时期的界面元素，一直保持到现在，颇有点清涩古风。在底层设计上，现在的Sniffer Pro其实大量地基于COM/OLE编程，到了Sniffer Distributed，分布式产品，Sniffer 又把结构延续到DCOM。当时并不知道后来会有病毒直接利用DCOM，因此整个产品设计非常理想化。 DCOM调用的规范相对较为复杂，这也造成了后期的Sniffer Distributed陷入了很多问题，诸如界面更新速度、数据显示延迟等等。这也造成了当时的Sniffer人决定把整个产品推向到Web based，事实证明把这样复杂的分析软件转换到Web环境是个彻头彻尾的错误，但是路一旦踏上，就很难有回头的余地。我不知道有多少人真正使用过Web-based Sniffer UI，从我个人而言，我并不推荐再去尝试那个已经被停止前进的Java applet+Web based的东东。我深深体会到，作为一个分析工具，必须保证自身的快捷、迅速、准确，否则，哪怕功能强大、跨平台，分析人员也绝对无法依赖一个笨拙、不稳定的分析环境。
Sniffer Pro的界面在最近6年没有发生大的变化，除了因为Wireless LAN的产品引入了一些新的元件之外，整个UI一直保持当初NetXray时代的样子。这既是缺点，也是优点，一旦熟悉也就可以不用更改任何习惯。
如果来看看OmniPeek，就会发现故事在这里是完全不一样。OmniPeek的设计元素里大量应用了 Flat Button、TreeView、IE View，使得整个产品很适应Windows XP/2000的环境。这一点也是后起之秀的优势，可以充分运用最新的技术。我特地关注了一下OmniPeek在分布应用时候的通讯协议，很值得一提的是，OmniPeek避免了任何DCOM的应用，采用了自行开发的一个加密通讯协议。很久以来的经验都告诉我DCOM协议既复杂又不安全，而且不适合Internet应用，因为DCOM采用了动态端口范围进行通讯，很难从Firewall上简单过滤。大家可以google一下DCOM + Firewall，会有一大堆文章讨论如何设置这种情况。
OmniPeek的开发环境迅速从VC++迁移到了VC.net，在OmniPeek的很多设计里都已经有了一些基本的.NET特性。而相对而言，Sniffer则拘泥于VC 6.0不能自拔。
OmniPeek产品带来了很多新的气象，让我在长期浸淫在Sniffer Pro之后，重新发现了一个更具魅力的世界。

作者: 阿七 时间: 2010-4-2 15:31
标题: 三、安装文件结构
1、 Sniffer Pro 4.75 SP4 (最新是4.8) 安装好以后，占地面积为60M左右。
目录结构如下
C:\PROGRAM FILES\NAI
└─SnifferNT
├─Driver
├─NetMibs
└─Program
      ├─AI
      ├─gbic
      ├─HTML
      │  └─JavaChart
      │    └─chart
      ├─Local
      ├─Local_2
      ├─Switch
      ├─voiceBU
      ├─Win2K
      └─WinXP
Driver目录下放置了Sniffer Pro支持的几乎所有网卡适配器的驱动程序。
NetMibs里放置了部分SNMP mib文件，主要是用来描述Sniffer的Alarm Trap的格式，以及Expert-Event trap的格式。这几个mib用来和SNMP 平台例如HP OV等系统集成时有点用。令人感到有兴趣的是，NetMibs里还有一个文件叫做art.mib，打开以后可以看到作者是NetScout公司。暂时无法准确揣度放在这里的目的，但是至少可以看到网络分析行业里的几个大腕还是互相承认的。

Program 目录里是主要的Sniffer Pro核心文件。每次创建一个Profile会多一个Local打头的目录。
比较有用的文件是Sniffer.bet ，可以用来编辑网卡生产厂商的vendor ID，进而影响在Sniffer Pro里的显示结果。

我比大家多一个 voiceBU子目录，大家也可以猜猜是为什么。

2、OmniPeek 2.0 安装完毕以后，大致占用70M左右空间。

├─1033
│  ├─Alarms
│  ├─Documents
│  │  └─Peek SDK
│  │    ├─Docs
│  │    └─Wizards
│  ├─Expert
│  ├─Filters
│  │  └─AppleTalk
│  ├─Graphs
│  ├─Html
│  │  └─QuickTour
│  │    └─images
│  ├─Names
│  ├─PluginRes
│  ├─Reports
│  │  ├─Auxiliary
│  │  ├─Control
│  │  └─Templates
│  └─Security Audit Template
├─2052
├─Bin
├─Decodes
├─Driver
├─MIBs
├─Plugins
│  └─Mibs
├─RMONGrabber
└─Samples

OmniPeek 目录下有个名为1033的大目录，各类模版、文件、HTML的文件都放在该目录下。
为什么叫做1033呢？因为1033代码代表美国英语。而2052则代表中文..
从文件树可以看到，OmniPeek的设计直接面向了国际化，多语言支持可以比较好的实现在OmniPeek中。这也是困扰Sniffer Pro的多年未有中文版本的原因之一。

OmniPeek的安装中已经包含了所有的SDK开发包，而Sniffer 的二次开发需要安装另外一个额外的被称为PDK的附加。

作者: 阿七 时间: 2010-4-2 15:31
标题: 四、设计理念
从两个软件的初始界面可以看出非常不同的设计理念。
Sniffer启动完毕以后，出现的是经典的DashBoard界面

这个界面也是当初cinco systems的NetXRay的经典起始界面，Sniffer Pro从4.0版本开始在Dashboard里加入了不少Java特征，从此也引入了很多不稳定性和不兼容性，造成了一系列小麻烦。对不起大家，我平时痛恨Java，因此恨乌及屋。

我先来对比一下OmniPeek的起始界面，

可以看到同样也是差不多的仪表盘。发明汽车上的仪表盘的工程师们也许没有想到在信息科技时代仍然可以在网络分析领域获得大力应用。
Sniffer Pro的设计目标偏向于“任务”，因此在DashBoard里还加入了监控的特征，能够很方便地在初始界面里观察短期网络流量历史曲线以及Packet尺寸分布等数据。而OmniPeek的设计更加面向于“工作”，他会把历史上打开过的Trace文件列举在初始界面里，包括帮助、引导文件，以及安全审计模板等，都可以在起始界面里直接引用。
另一个面向任务的设计体现在捕获的设计中，在Sniffer Pro里，过滤条件、捕获设置是在登录到某一个Profile以后可以随意设置的，例如，默认的过滤器是”default”，如果按三角形的捕获按钮，可以直接应用当前的过滤器开始捕获。而OmniPeek的面向工作的设计就不完全一样，如果点击开始新的捕获，可以当时选择所需捕获的网卡、过滤器、环境设置等一系列选项。在Sniffer Pro里，如果要更换当前捕获用的网卡，必须更换Settings，如下图

在Sniffer Pro里的这种设计更加证明了面向任务的设计，即当前的任务只需要分析一种网络，如果更换捕获网络，前提是更换任务。不同的Settings保持着完全不同的过滤设置以及工作习惯选项。也许Sniffer Pro更加为咨询人员设计，而OmniPeek更加为网络管理人员设计。
OmniPeek里的每次捕获前设置捕获参数和捕获网卡的界面：

设计理念的第二个环节是打开某一个捕获的trace 文件后的默认初始界面，在这里我不抓屏了。
大家可以发现，在Sniffer Pro 打开某一个捕获文件以后，默认初始的界面是Expert，即专家系统。而OmniPeek默认初始的界面是Decode，即解码。这也体现了这两个产品的非常大的不同思想，Sniffer Pro试图证明其包含270余种专家系统的分析模块是最值得察看也同时是最有价值的功能，可以最大化帮助网络分析人员的任务。而OmniPeek到目前为止仍然坚持Decode/解码是最有效、最核心的策略，尽管OmniPeek也提供90余种专家系统。专家系统到底有没有用，如何去用？这个问题我们暂且搁置一下，以后我会专门来对比讨论。至少我们可以从这些初始的界面中，对两者的不同设计理念大致可见一斑。

作者: 阿七 时间: 2010-4-2 15:35
标题: 五、按键习惯
嗯？按键习惯也能独立成章吗？这恰恰是网络分析软件的历史问题的集中表现。大家谁能够记得Sniffer Pro按什么快捷键启动捕获吗？
F10
那么OmniPeek呢？
Ctrl-Y
有点摸不清头脑了吧？事实上，这只是一个开始。
如果大家打开Sniffer Pro，打开一个以前保存的捕获文件，或立即捕获几个包，然后Stop Display。选择Decode Tab，展示著名的三栏解码界面。按键盘F4按键，嗯？！，当前的栏位被扩展成全屏；再按F4，恢复原有状态。如果按F6，则当前活动状态在三个栏位之间轮换，操作键盘上下键可以非常快速地在解码域、包列表里上下浏览。
如果当前切换到解码栏中，按F4，当前包的解完码的信息被扩展到全屏。这时候如果我们想切换到下一个包怎么办？是不是要F4切换回来然后再用鼠标？不必的，直接在解码全屏情况下按F8就往下浏览一个包，而按F7则往前浏览一个包。Sniffer Pro思路里的网络分析人员和编程人员一样，要达到如臻化境的状态，必须能以极快的速度进行快速解析分析，如果分析的时候还需要依赖到鼠标移来移去，或者在菜单里选来选去，那么很难及时在有限的时间里比别人更快地处理复杂的问题。
如果更进一步挖掘键盘功能，就会发现，如果要在解码内容里搜索一些关键字，可以用Alt+F3来打开一个搜索框…(我经常不小心按成Alt+F4….)，为什么快捷键会设置成这样？似乎和平是的习惯相差很远。熟悉Sniffer Pro的同志们就会明白，这些按键都是从DOS时代继承下来的。从前的Network General的DOSSniffer就用这些按键进行快速使用，当时也没有鼠标，所以这些按键成为了分析的必须。DOS Sniffer还有很多更多的快速按键，很多当初的Sniffer专家直到现在还在坚持使用DOS Sniffer，用异乎寻常的快速速度沉浸在包与包的切换之中。当人们向他们展示Windows Sniffer，他们目瞪口呆，居然Sniffer已经成为现在的样子。
OmniPeek的快速按键同样也是为了大力提高分析人员的速度，但是更加具备现代气息，和很多Windows程序一样，是Ctrl+一系列其他的按键。如果能够熟悉使用，同样可以很大地提高效率。
尽管微软曾经提出过Windows程序界面设计指南，要求所有鼠标可以完成的工作必须用键盘也能操作。可能至今仍然如此矜持的，除了MS Office之外，网络分析软件们也算是个异数。不过大多数网络分析人员可能并不领这个情，这些按键逐渐成为历史，成为尘封的记忆…

作者: 阿七 时间: 2010-4-2 15:35
标题: 六、专家系统
计算机帮助人类甚至代替人类一直是自小获得的科普教育中的一个组成部分，自打阿兰图灵发明了那个图灵测试以后，计算机智能水平的考量总算是有点标准了，尽管是如此主观的标准。拥有一个具有人工智能的计算机后盾一直是大多数科学男孩也许还有女孩的梦想。有幸的是，我们在网络分析系统里看到了居然存在被定义为早期的人工智能表现的“专家系统”，真让人有点莫名兴奋，不知所措了。

当然，如果深究一下专家系统的概念，网络分析系统中的专家系统未免让人有些失望，这些专家系统往往只是一个阈值触发的机制，既没有传说中的知识库，也看不到推理引擎的微妙结构。而且勉强所谓的知识库似乎也没有维护的接口，既不能调整也不能添加，更不要提计算机实现自我学习的能力了。偏偏这些专家系统又牛得很，在根本不需要人类作出任何提示的情况下，就咔咔咔把结果就输出了，以至于让人有点疑惑，到底是人犯傻还是计算机…
书归正传，我们还是来看看Sniffer 和OmniPeek的专家系统表现吧。

之前曾经提到过Sniffer以前是Network General第一帝国时期的产物，（现在的Network General我们姑且称他第二帝国，NAI时代称为第一共和国吧），第一帝国时期，Sniffer还是主要在DOS底下运行，但是当时的Sniffer就已经开始武装Expert/专家系统了。
第一帝国时期，正是网络建设的乱世，当时星型结构的以太网逐渐统一了纷争，把一些3+网以及DecNet等踢出了主流，通过价廉物美的Hub/Repeater/Bridge把诸多节点连接在一个网络之中。在第一帝国时期，网络人才极其有限，即使有那么几个热爱钻研的老头子/小伙子，也会对从PC到网络的进化感到费解，网络分析的故障诊断的效用在这些共享式网络环境里变得十分必需，但同时如果要真的要代表广大网络人士的真实需要，没有一个自动化辅助的实现或者至少是个期望是不能满足用户的需求的。第一帝国最早推出了一个初具雏形的专家系统。

说起Network General 第一帝国的创建者，Harry Saal，哥伦比亚大学Ph.D.，在美国确实是个有头有脸的科技界人物，如今已经六十几岁了。他曾经获得过美国数学协会的全国数学竞赛最高奖项，也创建过nestar等多家公司，还曾经担任Borland/Inprise的董事局副主席，还发明过地址自行分配的原理。这位长得有点鹤发童颜的胖胖博士在1997年卖掉了公司以后还到处参加非营利机构，甚至还兼任了圣何塞博物馆的理事。尤其值得一提的是最近这位大大还被美国司法部指定作为Microsoft调查听证会的两名成员之一。
不过Harry直到现在仍然在后悔亲手颠覆了自己的第一帝国，当然在1997年脱手的时候，实际Harry只有4.3%的股份了。不过据我个人估计，这次的两个私人投资公司从McAfee手中买下Network General一定有Harry的主意。因为之前Harry一直还保留着第一共和国里的五个董事席位之一。Silver Partner和Texas两家投资公司也是做得顺水人情，当初McAfee花了十几亿买下的第一帝国现在只需要2亿五千万美元就成交了。第二帝国成功复辟。
说得远了点，这和我们的专家系统的话题已经跑的太开了。但是我想表达的是，专家系统一定是要专家打造的，就好像周星驰电影里的太阳能手电筒一样，有光它一定会亮，没有光它一定不亮。对于专家系统而言，专家打造则是很重要的环节。

OmniPeek的创造者Wildpackets则更像**武装，其创建者Mahboud Zabetian是伊朗人，由于20世纪80年代萨达姆侯赛因带来的八年的两伊战争，Mahboud Zabetian和他的家人背井离乡流落到美国街头，当时他只有16岁。Mahboud凭着超人的智力和勤奋好学的努力终于考上了普林斯顿大学攻读EE/CS。Mahboud同样拥有美国的专利，发明了电子证书认证和检验的相关装置。今年38岁的Mahboud已经创办了Wildpackets(前身AG Group)15个年头，从无到有、从外乡人到美国本土深根发芽，给我们展示了长江后浪推前浪的勇气和毅力。

下面正式开始帝国军与反叛军专家系统的对抗：

[ 本帖最后由阿七于 2010-4-2 15:36 编辑 ]

作者: 阿七 时间: 2010-4-2 15:37
其实对比几个专家系统的最佳方式是在实际环境里对抗解决一些典型的问题，但是这个要求尽管简单，却又未免有点难度，我在此就随手拿起以前的Trace文件，作为对比判别的依据。因为采用的样本的限制，可能这里也仍然只能做到窥豹一斑。有一点值得申明，因为日后一定有人会挑刺，这Trace File是真正的信手拈来，绝没有任何试图造作的企图。而且在这里比较的更多是两个产品设计思想的区别和特点，而不是比较优劣。
映入眼帘的是Sniffer的专家系统，Sniffer的专家系统非常卓越的作出了对网络按照教科书式的理解进行严格的划分，并在此基础上达到了一定程度的叹为观止的技艺。
在Sniffer Expert中，首先是对Layer与目标的区分。
Layer来自于对网络包的理解，按照OSI结构，两个节点的通讯理论上通常会经过从主机甲的应用层表现层会话层传输层网络层数据链路层物理层并逐次传递到主机乙的物理、数据链路……乃至应用层，那么每一个包在其实都包含了各个层次上的数据，只要逐层剥离，就可以从一个包里看到网络各个层次上的信息。这是所谓一沙一世界的思想，Sniffer 广泛应用了这一个观点在专家系统中，在专家系统界面的左侧，展现了对应OSI七层，除了表现层在网络上没有实际的意义之外，其他每个层都能够在专家系统里找到对应关系。

在专家系统的左侧索引表格上，还包含了三类不同的目标，分别是“对象”，“征兆”和“诊断”。这一区分能够帮助使用者快速区分不同信息的重要程度。对象、征兆、诊断与各个网络层次之间形成了对应的矩阵关系，组成了Sniffer的专家系统的基础。
在图中我标记的2那个按钮是非常有用的，当我们选中某一个对象/征兆/诊断，然后点击按钮2，就会发现对应的那个对象或者事件相关联的网络数据包能够直接被过滤出来，形成一个单独的Tab，这个功能从4.0被引入以后，真正帮助分析者能够快速接近事件的本质。
左下的窗口显示着对应我们选择的那个层次里，所包含的协议。而右下的窗口里显示了对应选中的对象/征兆/诊断的补充信息。
这个trace file是以前我在Starbucks喝咖啡的时候，顺手捕捉了一段，可以看到当时咖啡厅里的人们正在专注地使用着Web浏览器。那个报成是NNTP的协议其实是当时有人在使用Yahoo Messenger。不知道这个行为本身是否具有法律问题，但至少在当时，公共场合下的Sniffer行为本身并没有被相应的法规与之关联。就好像可以很随意地在天安门广场上闻着别人买的蛋糕香味一样。
在这个共捕获了38秒钟的Trace File里，Sniffer的专家系统识别出了2个会话层诊断、1个服务层的征兆、2个应用层的征兆、42个传输层征兆和15个网络层征兆、11个无线的征兆、3个全局的征兆。
我们来看看在这个Starbuck到底发生了什么意外触发了这些专家系统。
我们点击会话层诊断，看到2个WINS NO RESPONSE。

我们可以点击右下窗口里的”?”按钮，看到这个问题的具体解释。我一直认为WINS NO RESPONSE属于Sniffer里的经典误报。以前有位Netexpert的坛友曾经尖锐指出这是因为没有在交换环境下设置端口镜像的关系，诚然确实如帮助文件解释一；但是这个文件的捕获是在一个共享的网络环境里，802.11B。看来这个问题只能遵循解释二或者三，然而这是个公共区域的Internet，用户明显也就是802.1X后DHCP的，实在不明白为什么会触发这个诊断，怎么也只应该归类到征兆吧？

作者: 阿七 时间: 2010-4-2 15:37
先不去细究，进一步察看。
服务层的征兆是Slow NNTP Server，这个怪不得Sniffer误报，Yahoo Messenger使用了119作为传输端口，使Sniffer误触发了对News Server的报警，不过略微有点怨言的是，Sniffer居然在引发专家系统征兆分析时连一点必要的协议分析也不做，不过不去深究，毕竟Yahoo Messenger是新生事物，只有7年历史。
我们把目光移动到传输层。

我们看到了数以十计的Window Frozen 和Ack Too Long，看了看Sniffer Expert的帮助，原来是接收端或者发送端的内存/缓存不足。但是这么多的Window Frozen到底代表多严重的问题呢，是不是需要去优化？
我暂时也回答不了这些问题，继续往下看

网络层上发现了很多主机无法到达，端口无法到达以及TTL马上会过期等信息。我考察了TTL过期的征兆，因为这个问题一共只报了一次，似乎有点特性。但实际发现这是Windows XP的UPNP服务进行组播的包，由于TTL只设置了1，避免被路由器转发，因此造成了触发，这又是新发现的一个通用误报，因为大家现在都用了Windows XP，一旦Sniffer针对UPNP的组播都被触发了征兆….不知道最后是专家系统帮人还是害人了。

先让Sniffer Expert休息一下，我们来看看OmniPeek同样针对这个Trace file的分析。

打开OmniPeek的专家系统可以发现

OmniPeek同样也把问题分解成了不少层次，但是布局方式却代表了完全不同的思路。在OmniPeek里，网络上的包不再是一个一个的微粒，而是类似波一样的流(Flow)，网络上的包既有微粒的特性，每一个包里包含了各个层次的信息，但是更为重要的是，一个包的信息并不代表任何东西，而相关联的一个流的包却是网络上传输通讯的最基本元素。你看看Cisco推出的网络分析技术也从最早的微粒说的NAM逐渐转变成波流说的NetFlow，呵呵。

在此我们可以得出一个结论，那就是网络通讯具有波粒二象性，那好像已经进入了量子理论，有兴趣的同志可以攻坚一下网络量子领域，我们也许也可以在netexpert.cn论坛上进行深挖，现在还是先回归Expert专家系统的讨论。
同样一个Trace file里，OmniPeek解析出了363次28个不同的事件。

OmniPeek 在应用层以及所谓的Client/Server层次上挖掘出的问题令人对比Sniffer感觉眼睛一亮。包括SMB文件系统的疑问和DNS查询失败的情况都一目了然，如果用户是遇到了上网访问问题的话，可能在此就会先有一个明确的视角。

同样对于各类问题，OmniPeek也给出解释和可能的原因，同时给出可能的解决思路。

这个简单的Trace里，似乎反而觉得OmniPeek的专家系统分析结果更翔实，而且抽象性更好，例如在OmniPeek里成功的把Window Frozen等这些问题抽象到应用HTTP Slow Response time之上，并且把问题进行归并，而不是类似Sniffer把单独的每个问题进行单列。点击在OmniPeek的问题之上，上部的窗口对应的这个流会变蓝，我们可以了解到这个问题实际影响了哪些通讯。OmniPeek并没有类似Sniffer那样深厚的Object分析功底，因此在解析具体的对象的时候，对象细节的信息并没有Sniffer那么完整。
那么传说中的Sniffer强大的专家分析问题能力到底体现在什么地方呢？诸位看官稍待，容后细表。

[ 本帖最后由阿七于 2010-4-2 15:38 编辑 ]

作者: 阿七 时间: 2010-4-2 15:39
OmniPeek的专家系统比起Sniffer而言，更加重视的是Visualize，为什么呢，这和对网络的理解息息相关，如果把网络通讯看作是粒子，那么最能反映粒子的是统计表，记录成千上万的粒子的分布。如果把网络通讯看作是流，那么最好的方式也许就是图形，把流或者说是波的形状描绘出来。
OmniPeek的Visual Expert是其Expert中闪烁的光华，我们在某一个问题多多的流上双击或者右键选择就进入了另外一个世界。

勿移除此信息
我们可以看到整个留的通讯过程，包括在其中发现问题的粒子（又是一个波粒二象性的证明）
我们也可以看到整个流到底在传输什么内容

以及流的图像特征和通讯特点，图中的不同符号有不同的含义

以及吞吐量/延迟等各类特征的流图形。

可能大家会疑问这些图形的作用，在此我又要卖一个关子，因为我正计划单独写一个OmniPeek的Visual Expert详解，这里就稍微留一点素材。但是至少有一点可以透露的是，这种以流为思路的波形分析方法改变了大多数人解析网络的思路，带来极大的不同和效率的提升。

客观的说，Sniffer能够解析的问题总数达到350多个，而OmniPeek只有150多个专家系统分析项目，按道理Sniffer解析的广度应该远远超过OmniPeek，但是从之前的分析情况而言，似乎并没有看出Sniffer的优势在任何地方。其实这一点很容易在两个产品里进行验证。
打开Sniffer 菜单Tools  Expert Options  Alarm，点击按钮”0”

这里可以获得完整的Sniffer可以触发的Expert专家系统条目，确实有三百多个条目哦。仔细浏览一下，就发现了躲在专家系统数量后的原因。
如果看官有Sniffer，可以打开到这个界面，展开ATM相关的那些树枝……哇，这么这么多分析都是相关ATM，大概数数至少有那么一百三五十种专家系统条目是和ATM相关的阿。
再去掉一些和帧中继等老迈技术相关的条目的话，实际有效的分析能力也是大概一百出头一点的样子。这样的话其实比起OmniPeek 158个专家分析系统的条目而言并没有实际的优势可言。

不过看到这么多ATM的问题诊断，不由感触，从网络分析产品里就可以看出ATM技术的复杂度，当时的人们非常矛盾地面对着这个带来很多技术领先性的转变。最终ATM技术彻底输给了POS/SDH等部署应用非常简单的，但是功能并不强大的技术。这个结果仅仅看看Sniffer的分析专家库就可以预料到了。世人投资ATM技术以及之后为了升级和迁移的成本确实不低，包括网络分析厂商们也不得不拾起了这个包袱。为了提高Sniffer分析性能，我们可以把这些ATM的功能关闭，毕竟这些功能还需要ATMBook这类专属硬件才能启用。第二帝国其实现在也已经放弃了这个产品线了，我们在Sniffer Portable里还可以为之一声叹息、默哀三秒钟。

OmniPeek的成长没有这方面的负担，可以看到OmniPeek的专家设定EventFinder Settings里面，基本上都是新技术的代表，尤其是在Internet以及无线和语音方面。
本来还想比较几个trace file，但是篇幅已经超过了我的预期，到此，我们的简单的专家系统对比暂时告以段落，我的总体感觉是，目前的网络分析专家系统尤其是Sniffer已经落后现代网络行业很远，要靠这些专家系统带来根本性的网络分析的支撑未免有点我本将心向明月，奈何明月照沟渠的无奈。OmniPeek的流可视化分析专家(Visual Expert)带来了一些新鲜的气息，然而在这个方向上，仍然有很大的值得提升的空间。我个人觉得专家分析系统在直接给出一个模棱两可的答案之前可以首先询问操作的人，获得一些提示和网络环境的定义，这样应该更有利于专家系统结果的可靠性和精确度，而且专家系统还不应该仅仅沉湎于细节，应当在总体上给出一些评价和思路....

[ 本帖最后由阿七于 2010-4-2 15:40 编辑 ]

作者: 阿七 时间: 2010-4-2 15:42
标题: 声明下
对了  本文是转载的

作者:  http://www.netexpert.cn Vader@netexpert.cn

我也是看了这个, 在学习呢

这个软件, 云层老师写的书里  第6章也介绍过哦  呵呵

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)