范伟导老师Sniffer课程资料(二)

才郎三号

好，大家都打开了吗，有问题随时告诉我，（跑去解答问题去了）如果大家在上课的时候有任何疑问，随时可以打断我，不用给我面子，我也不一定能回答所有问题，不过没关系，交流总会进步的。
好，我们继续第一个我要介绍的是local agent。
什么叫local agent，大家打开fileSelect settings




这时候，大家可能只看到一个local 下面是你的网卡,这就叫做一个local agent。
事实上，一个local agent 就像一个探针。
我们知道Sniffer的工作原理很简单，就是把网卡设成混杂模式（叫做promiscuous），所谓混杂模式，就是把所有数据包接受下来放入内存，大家知道一般情况下,PC机只接受目的mac地址为自己网卡或广播、组播的数据包。sniffer就是这样把所有数据包都接收下来，在进行分析。
大家看我这里有多个agent,怎样可以做多个agent呢，可以不同网卡做不同的agent，就像你们的分布式sniffer一样，有多个网卡，那就是多个agent,infinistream也一样。
其实一个网卡，也可以做多个agent,大家试一下，new一个，给他加上说明，就叫101把，选中你们的网卡，下面选no pod，copy setting留空，那个pod是你外接sniffer book时候用的。大家看看你们的agent多了一个，101括号local_2。对不对（同学们：对）
好，不错。
我们为什么建立多个agent 呢。不同的agent可以定义不同的阀值，可以有不同的过滤器，可以有不同的触发器，不同的地址本。
比如说，你们有一台笔记本装着sniffer，大家都用它，那不同的工程师可以自己定义一个agent，自己定义自己的过滤器，互不干涉，比如不同的网段有不同的阀值，也可以定义不同的agent。
那agent的参数保存在哪里呢，大家打开c:\program files\nai\sniffernt\program,大家看到local local_2,这就是两个不同的agent保存参数的地方。大家看到两个CSF文件，一个是sniffer.csf，另外一个是Snifferdisplay.csf。这是过滤器文件，当我们使用sniffer一段时间之后，大家会累积许多好的过滤器，一定记得保存下来，就是把这两个文件考出来就行了，如果你看到别人那里有好的过滤器，也可以拷过来。不过当你要倒回去的时候，4.8比较好办直接倒入就行了，4.75比较麻烦，我后面讲定义过滤器的时候再教大家。过滤器是sniffer最难、最有意思、最重要的一部分，大家放心，我能让大家成为高手。（同学们笑）
好，local agent讲完了，local agent是什么？事实上就是定义一个环境变量，不同的环境不同的参数。
好，休息一下，待会儿讲monitor功能。
中间休息的时候，我问了范老师一个问题：我看书上说，TCP是可靠的,UDP是不可靠的，那要不可靠UDP来干什么？（各位：我的问题是不是很傻？但我确实不知道呀）
范老师：不错，这个问题非常好！（嘿嘿！）
TCP叫传输控制协议，他的特点是：有连接，有流控，有顺序号/确认号，开销比较大，一般是20个字节的头。
UDP叫用户数据报协议，开销小，8个字节的头，无可靠保证。
我后面有详细介绍TCP和UDP，我们先看您的问题。
首先，UDP，不可靠，是指，在传输层不提供可靠保证，并不意味着所有使用UDP的应用都不可靠。
我们来比较几个应用（范老师用他的trace file 给我演示）
DNS，53端口，进行查询时，用的是UDP，因为要求速度快，比如我要查networkgeneral的地址，你只要告诉我ip是多少就行了，如果要进行3次握手建立连接，再去取到IP，那就慢了，所以用的是UDP,一个字：快。没响应怎么办，事实你看（他在演示）它会同时向多个DNS查询，所以没响应也没关系，你看这个响应名字错误，找不到。所以UDP还是有用的，特别是像DNS查询这种应用，丢了也就丢了，我再查。但DNS也有用TCP的时候，比如DNS服务器的同步，用的就是TCP的53端口
TFTP，您所了解的TFTP,用的是UDP吧，他不可靠吗，事实上文件传输,必须保证可靠。不但要保证能知道丢包重传，还要有顺序号，应付错序到达的情况，也就是我们常说的后发先至。事实上TFTP是怎样工作的，你看（他在演示），每一个数据块都有Id号，一块512字节，一次传输，一次确认，这就相当于TCP的顺序号和确认号。所以UDP是不可靠的，但很多使用UDP协议的应用是可靠的，只是在应用层去保证可靠性，很多人说用UDP效率高，事实上TFTP在传输大文件的时候,比FTP效率更地，我们后面有专门的实验。
视频流量，（没有演示）对于视频流量，也是需要可靠保证的，但要求不是很高，所以不会像TFTP那样每一个数据报都确认，而是传多个数据包确认一次，要不效率就太低了，究竟多少个数据包确认一次，开发人员需要不断测试。
我的解释清楚吗，（我说：明白了！谢谢！）
（确实看着演示，很容易就理解了，中间我们有许多对话，我省略了，确实如果只听录音是不明白的，这是我为什么要整理成文字给大家看，好累呀！大家给我加油！）
好，我们继续！

本新闻共2页,当前在第1页  1  
2



范伟导老师Sniffer课程资料(二)
www.net130.com
     日期：2006-5-28    浏览次数：
10083
出处：www.netexpert.cn
我们来看一下Sniffer的七大monitor功能，有Dashboard,hosttable,matrix,ART，protocol distribution,history sample,global statistics
我们一个一个来看，先看dashboard。

这个大家很熟悉了，我不用多讲，dashboard有3个仪表，分别是使用率，每秒钟包数量，每秒钟错误率，下面都有两个数字，前面一个表示当前值，后面一个表示最大值。
下面还有long term,和short term
Long term 每30分钟采样一次，一共可以采样24小时，short term 每30秒钟采样一次，可以采样25分钟
大家自己试一下，首先把file里面的loopback 选上，这样我们发的数据包就不会发到网络中去，然后打开101目录里的TCPdemo7a那个trace file ,再用packet general 发包，选send current buffer，连续发送。（我们是跟着范老师做的）
好了，大家试了一遍，感觉应该是一样的，就是这有什么用？没用，对吧，我也这样觉得（同学们笑）
但如果你要监控某一台服务器的时候，这个是有用的，比如你把一台服务器的接口monitor 过来，这样你就可以看到这台服务器的流量状况了，这就是一个很好的基准线呀。当然大家用的是硬件产品，就更方便了。
大家注意到下面还有错误报的统计，要注意的是一般的网卡是抓不了错误包的，要用专用网卡，一块网卡上万块，NG好黑呀（同学们笑）
其实大家知道通过交换机的存储转发，基本上很少错误包，所以不用关注它。
在这里我想解释一下以太网的错误包，这对大家学习网络是很有帮助的，特别是了解一下封装的概念。
（请看下一页：以太网为什么要64个字节）

(这是范老师的板书,我画不出来,大家将就点吧)
(这是范老师的板书,我画不出来,大家将就点吧)
以太网是无连接的，不可靠的服务，采用尽力传输的机制。以太网CSMA/CD我就不多讲了，我相信大家都了解这个原理。
以太网是不可靠的，这意味着它并不知道对方有没有收到自己发出的数据包，但如果他发出的数据包发生错误，他会进行重传。以太网的错误主要是发生碰撞，碰撞是指两台机器同时监听到网络是空闲的，同时发送数据，就会发生碰撞，碰撞对于以太网来说是正常的。
我们来看一下，假设A检测到网络是空闲的，开始发数据包，尽力传输，当数据包还没有到达B时，B也监测到网络是空闲的，开始发数据包，这时就会发生碰撞，B首先发现发生碰撞，开始发送碰撞信号，所谓碰撞信号，就是连续的01010101或者10101010,十六进制就是55或AA。这个碰撞信号会返回到A，如果碰撞信号到达A时，A还没有发完这个数据包，A就知道这个数据包发生了错误，就会重传这个数据包。但如果碰撞信号会返回到A时，数据包已经发完，则A不会重传这个数据包。
我们先看一下，以太网为什么要设计这样的重传机制。首先，以太网不想采用连接机制，因为会降低效率，但他又想有一定的重传机制，因为以太网的重传是微秒级，而传输层的重传，如TCP的重传达到毫秒级，应用层的重传更达到秒级，我们可以看到越底层的重传，速度越快，所以对于以太网错误，以太网必须有重传机制。
要保证以太网的重传，必须保证A收到碰撞信号的时候，数据包没有传完，要实现这一要求，A和B之间的距离很关键，也就是说信号在A和B之间传输的来回时间必须控制在一定范围之内。IEEE定义了这个标准，一个碰撞域内，最远的两台机器之间的round-trip time 要小于512bit time.(来回时间小于512位时，所谓位时就是传输一个比特需要的时间）。这也是我们常说的一个碰撞域的直径。
512个位时，也就是64字节的传输时间，如果以太网数据包大于或等于64个字节，就能保证碰撞信号到达A的时候，数据包还没有传完。
这就是为什么以太网要最小64个字节，同样，在正常的情况下，碰撞信号应该出现在64个字节之内，这是正常的以太网碰撞，如果碰撞信号出现在64个字节之后，叫 late collision。这是不正常的。
我们以前学习CISCO网络的时候，CISCO交换机有一种转发方式叫fragment-free，叫无碎片转发，他就是检查64个字节之内有没有错误，有的话不转发，这样就排除了正常的以太网错误包。
(这是范老师的板书,我画不出来,大家将就点吧)
我们再来看一看以太网的帧结构。

要讲帧结构，就要说一说OSI七层参考模型。七层参考模型大家很熟悉，以前我们看书的时候会觉得不知所云，我刚学的时候就是这感觉，其实我们只要掌握两点就行了。
一个是访问服务点，每一层都对上层提供访问服务点（SAP），或者我们可以说，每一层的头里面都有一个字段来区分上层协议。
比如说传输层对应上层的访问服务点就是端口号，比如说23端口是telnet，80端口是http。IP层的SAP是什么？（同学们没说话）
其实就是protocol字段，17表示上层是UDP，6是TCP,89是OSPF，88是EGIRP,1是ICMP等等。
以太网对应上层的SAP是什么呢？就是这个type或length。比如 0800表示上层是IP，0806表示上层是ARP。我后面还会将各种以太网的帧类型。
第二个要了解的就是对等层通讯，对等层通讯比较好理解，发送端某一层的封装，接收端要同一层才能解封装。
我们再来看看帧结构，以太网发送方式是一个帧一个帧发送的，帧与帧之间需要间隙。这个叫帧间隙IFG—InterFrame Gap
IFG长度是96bit。当然还可能有Idle时间。
以太网的帧是从目的MAC地址到FCS,事实上以太网帧的前面还有preamble，我们把它叫做先导字段。作用是用来同步的，当接受端收到preamble，就知道以太网帧就要来了。preamble有8个字节前面7个字节是10101010也就是16进制的AA，最后一个字节是10101011,也就是AB，当接受端接受到连续的两个高点平，就知道接着来的就是D_mac。所以最后一个字节AB我们也叫他SFD（帧开始标示符）。
所以在以太网传输过程中，即使没有idle，也就是连续传输，也有20个字节的间隔。对于大量64字节数据来说，效率也就显得不高。
所以，有时我们用下载数据来检查我们的网速，这是不完全准确地，我们要了解他的传输特征，才能准确判断电信究竟给了你多少带宽。我有一个移动的学员，他说用户总怀疑我给他的带宽不够，其实我肯定给他两兆了，所以有时运营商也挺不容易（同学们笑）。后来我告诉他怎么样用sniffer来测带宽，不知道他后来成功了吗，我没有得到反馈。后面我会介绍怎样用Sniffer来做带宽测试，非常精确的喔。我给很多用户作过带宽测试，他们大多都是怀疑电信给的带宽不够。（同学们问：有没有不够的时候？）我测试的案例里还没有。还有就是帮集成商作方案验证，比如，集成商给用户作了多链路捆绑，或路由负载均衡，用户说比原来更慢了，我去证明给用户看，负载均衡确实做起来了，流量分担很正常。（同学们问：那为什么会慢呢），这就涉及到应用的特征和不同厂商采用均衡的机制。我还没试过作进一步分析。因为这是集成商的朋友叫我去帮忙的，我只要证明给用户看方案没问题，并告诉集成商如何给用户解释就行了，在做下去，就会画蛇添足了，因为可能让用户觉得我的水平比我朋友高，那不是帮倒忙了。（同学们笑）所以帮忙也要适可而止。 （同学们笑）
好了，有点扯远了。前面讲这些主要是帮大家复习以下以太网知识，大家别担心，时间是足够的，因为这门课里有很一些基础的知识，比如交换原理、vlan原理，那些知识我都会跳过，我第一天的内容不会很难，考虑到大家远道而来，第一天都很累。但后面回越来越难，大家要有心理准备。晚上要早点睡觉（同学们笑）。还有一个，就是大家别指望能记得住我讲得全部内容，今天讲得明天还记得一点，后天就全忘了，（同学们笑），到了课程结束的时候，基本上全忘光了，（同学们大笑），所以做笔记很重要，我建议大家把笔记写在书上，到时才对得起来。我也注意到一些同学在录音，我知道的，不用放在桌子底下(同学们笑），那样效果不好，（同学们大笑），其实这是不允许的，不过没关系，只有一个要求，不要放在互联网上。
（编者：写到这里，有点写不下去了，觉得很内疚，觉得对不起范老师。我参加过很多培训，范老师是我很喜欢的一个老师，他讲课不会非常幽默，但很实用，这是因为他有很多经历，他在讲课过程中，会补充很多课程以外的东西，比如很多网络中的细节知识，很多工作中的思路，我觉得这方面收获很大，我个人觉得是对我知识的全面补充，学完之后觉得不仅学会了Sniffer，网络管理的思路更清晰了，现在我指导工程师时，套了很多范老师的话，我觉得范老师很好。怎么办？我在进行思想斗争。。。该不该再写下去。我想在论坛里发起投票，听听大家的意见，我该不该再写下去。）
（编者：范老师的课程内容： 第一天 monitor功能，Sniffer的部署
  第二天 expert，capture filter ，troubleshooting
第三天 decode，display filter ，trigger
第四天 应用的类型，应用的剖析，应用的分析思路
第五天 应用性能的分析，应用性能预测）
本新闻共2页,当前在第2页  
1
  2

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/16912/showart_205423.html