原文出处：EMC中文支持论坛
按照国际惯例，从最基本的说起。
抓取报文**:**
下载和安装好Wireshark之后，启动
Wireshark并且在接口列表中选择接口
名，然后开始在此接口上抓包。例
如，如果想要在无线网络上抓取流
量，点击无线接口。点击Capture
Options可以配置高级属性，但现在无
此必要。
点击接口名称之后，就可以看到实时
接收的报文。Wireshark会捕捉系统发
送和接收的每一个报文。如果抓取的
接口是无线并且选项选取的是混合模
式，那么也会看到网络上其他报文。
上端面板每一行对应一个网络报文，
默认显示报文接收时间（相对开始抓
取的时间点），源和目标IP地址，使
用协议和报文相关信息。点击某一行
可以在下面两个窗口看到更多信
息。“+”图标显示报文里面每一层的
详细信息。底端窗口同时以十六进制
和ASCII码的方式列出报文内容。
需要停止抓取报文的时候，点击左上
角的停止按键。
色彩标识**:**
进行到这里已经看到报文以绿色，蓝
色，黑色显示出来。Wireshark通过颜
色让各种流量的报文一目了然。比如
默认绿色是TCP报文，深蓝色是
DNS，浅蓝是UDP，黑色标识出有问
题的TCP报文——比如乱序报文。
报文样本**:**
比如说你在家安装了Wireshark，但家
用LAN环境下没有感兴趣的报文可供
观察，那么可以去Wireshark wiki下载
打开一个抓取文件相当简单，在主界
面上点击Open并浏览文件即可。也可
以在Wireshark里保存自己的抓包文件
并稍后打开。
过滤报文**:**
如果正在尝试分析问题，比如打电话
的时候某一程序发送的报文，可以关
闭所有其他使用网络的应用来减少流
量。但还是可能有大批报文需要筛
选，这时要用到Wireshark过滤器。
最基本的方式就是在窗口顶端过滤栏
输入并点击Apply（或按下回车）。
例如，输入“dns”就会只看到DNS报
文。输入的时候，Wireshark会帮助自
动完成过滤条件。
也可以点击Analyze菜单并选择
Display Filters来创建新的过滤条件。
另一件很有趣的事情是你可以右键报
文并选择Follow TCP Stream。
你会看到在服务器和目标端之间的全
部会话。
关闭窗口之后，你会发现过滤条件自
动被引用了——Wireshark显示构成会
话的报文。
检查报文**:**
选中一个报文之后，就可以深入挖掘
它的内容了。
也可以在这里创建过滤条件——只需
右键细节并使用Apply as Filter子菜
单，就可以根据此细节创建过滤条
件。
Wireshark是一个非常之强大的工具，
第一节只介绍它的最基本用法。网络
专家用它来debug网络协议实现细
节，检查安全问题，网络协议内部构
件等等。
TCP:
TCP/IP通过三次握手建立一个连接。
这一过程中的三种报文是：SYN，
SYN/ACK，ACK。
第一步是找到PC发送到网络服务器
的第一个SYN报文，这标识了TCP三
次握手的开始。
如果你找不到第一个SYN报文，选择
Edit -> Find Packet菜单选项。选择
Display Filter，输入过滤条件：
tcp.flags，这时会看到一个flag列表用
于选择。选择合适的flag，
tcp.flags.syn并且加上==1。点击
Find，之后trace中的第一个SYN报文
就会高亮出来了。
注意：Find Packet也可以用于搜索十
六进制字符，比如恶意软件信号，或
搜索字符串，比如抓包文件中的协议
命令。
一个快速过滤TCP报文流的方式是
在Packet List Pane l中右键报文，并
且选择Follow TCP Stre am。这就创
建了一个只显示TCP会话报文的自动
过滤条件。
这一步骤会弹出一个会话显示窗口，
默认情况下包含TCP会话的ASCII代
码，客户端报文用红色表示服务器报
文则为蓝色。
窗口类似下图所示，对于读取协议有
效载荷非常有帮助，比如HTTP，
SMTP，FTP。
更改为十六进制Dump模式查看载荷
的十六进制代码，如下图所示：
关闭弹出窗口，Wireshark就只显示所
选TCP报文流。现在可以轻松分辨出
3次握手信号。
注意：这里Wireshark自动为此TCP会
话创建了一个显示过滤。本例中：
(ip.addr eq 192.168.1.2 and ip.addr eq
209.85.227.19) and (tcp.port eq 80 and
tcp.port eq 52336)
SYN报文：
图中显示的5号报文是从客户端发送
至服务器端的SYN报文，此报文用于
与服务器建立同步，确保客户端和服
务器端的通信按次序传输。SYN报文
的头部有一个32 bit序列号。底端对
话框显示了报文一些有用信息如报文
类型，序列号。
SYN/ACK报文：
7号报文是服务器的响应。一旦服务
器接收到客户端的SYN报文，就读取
报文的序列号并且使用此编号作为响
应，也就是说它告知客户机，服务器
接收到了SYN报文，通过对原SYN报
文序列号加一并且作为响应编号来实
现，之后客户端就知道服务器能够接
收通信。
ACK报文：
8
号报文是客户端对服务器发送的确
认报文，告诉服务器客户端接收到了
SYN/ACK报文，并且与前一步一样
客户端也将序列号加一，此包发送完
毕，客户端和服务器进
入ESTABLISHED状态，完成三次握
手。
ARP & ICMP ：
开启Wireshark抓包。打开Windows控
制台窗口，使用ping命令行工具查看
与相邻机器的连接状况。
停止抓包之后，Wireshark如下图所
示。
ARP和ICMP报文相对较难辨认，创
建只显示ARP或ICMP的过滤条件。
ARP报文：
地址解析协议，即ARP（Address
Resolution Protocol），是根据IP地址
上的所有主机，并接收返回消息，确
定目标IP地址的物理地址，同时将IP
地址和硬件地址存入本机ARP缓存
中，下次请求时直接查询ARP缓存。
最初从PC发出的ARP请求确定IP地址
192.168.1.1的MAC地址，并从相邻系
统收到ARP回复。ARP请求之后，会
看到ICMP报文。
ICMP报文：
网络控制消息协定（Internet Control
Message Protocol，ICMP）用于
TCP/IP网络中发送控制消息，提供可
能发生在通信环境中的各种问题反
馈，通过这些信息，令管理者可以对
所发生的问题作出诊断，然后采取适
当的措施解决。
PC发送echo请求，收到echo回复如上
图所示。ping报文被mar k成Typ e 8，
回复报文mar k成Typ e 0。
如果多次ping同一系统，在PC上删除
ARP cache，使用如下ARP命令之
后，会产生一个新的ARP请求。
C:> ping 192.168.1.1
…
ping output …
C:> arp –d *
HTTP：
HTTP协议是目前使用最广泛的一种
基础协议，这得益于目前很多应用都
基于WEB方式，实现容易，软件开发
部署也简单，无需额外的客户端，使
用浏览器即可使用。这一过程开始于
请求服务器传送网络文件。
从上图可见报文中包括一个GET命
令，当HTTP发送初始GET命令之
后，TCP继续数据传输过程，接下来
的链接过程中HTTP会从服务器请求
数据并使用TCP将数据传回客户端。
传送数据之前，服务器通过发送
HTTP OK消息告知客户端请求有效。
如果服务器没有将目标发送给客户端
的许可，将会返回403 Forbidden。如
果服务器找不到客户端所请求的目
标，会返回404。
如果没有更多数据，连接可被终止，
类似于TCP三次握手信号的SYN和
ACK报文，这里发送的是FIN和ACK
报文。当服务器结束传送数据，就发
送FIN/ACK给客户端，此报文表示结
束连接。接下来客户端返回ACK报文
并且对FIN/ACK中的序列号加1。这
就从服务器端终止了通信。要结束这
一过程客户端必须重新对服务器端发
起这一过程。必须在客户端和服务器
端都发起并确认FIN/ACK过程。
基本IO Graphs:
IO graphs是一个非常好用的工具。基
本的Wireshark IO graph会显示抓包文
件中的整体流量情况，通常是以每秒
为单位（报文数或字节数）。默认 X
轴时间间隔是1秒，Y轴是每一时间
间隔的报文数。如果想要查看每秒bit
数或byte数，点击“Uni t”，在“Y
Axis”下拉列表中选择想要查看的内
容。这是一种基本的应用，对于查看
流量中的波峰/波谷很有帮助。要进
一步查看，点击图形中的任意点就会
看到报文的细节。
为了讲解方便，点击示例报文包，或
用自己的wireshark点击Statistics – IO
Graphs。这个抓包是HTTP下载遇到
报文丢失的情况。
注意：过滤条件为空，此图形显示所
有流量。
这个默认条件下的显示在大多数
troubleshooting中并不是非常有用。将
Y轴改为bits/tick这样就可以看到每秒
的流量。从这张图可以看到峰值速率
是300kbps左右。如果你看到有些地
方流量下降为零，那可能是一个出问
题的点。这个问题在图上很好发现，
但在看报文列表时可能不那么明显。
过滤：
每一个图形都可以应用一个过滤条
件。这里创建两个不同的graph，一
个HTTP一个ICMP。可以看到过滤条
件中Graph 1使用“http”Graph 2使
用“icmp”。图中可以看到红色ICMP
流量中有些间隙，进一步分析。
创建两个图形，一个显示ICMP
Echo（Type=8）一个显示ICMP
Reply（Type=0）。正常情况下对于
每一个echo请求会有一个连续的
reply。这里的情况是：
可以看到红色脉冲线(icmp type==0 –
ICMP Reply)中间有间隙，而整张图
中ICMP请求保持连续。这意味着有
些reply没有接收到。这是由于报文丢
失导致的reply drop。CLI中看到的
ping信息如下：
常用排错过滤条件**:**
对于排查网络延时/应用问题有一些
过滤条件是非常有用的：
tcp.analysis.lost_segment：表明已经
在抓包中看到不连续的序列号。报文
丢失会造成重复的ACK，这会导致重
传。
tcp.analysis.duplicate_ack：显示被确
认过不止一次的报文。大凉的重复
ACK是TCP端点之间高延时的迹象。
tcp.analysis.retransmission：显示抓
包中的所有重传。如果重传次数不多
的话还是正常的，过多重传可能有问
题。这通常意味着应用性能缓慢和 /
或用户报文丢失。
tcp.analysis.window_update：将传输
过程中的TCP window大小图形化。
如果看到窗口大小下降为零，这意味
着发送方已经退出了，并等待接收方
确认所有已传送数据。这可能表明接
收端已经不堪重负了。
tcp.analysis.bytes_in_flight：某一时
间点网络上未确认字节数。未确认字
节数不能超过你的TCP窗口大小（定
义于最初3此TCP握手），为了最大
化吞吐量你想要获得尽可能接近TCP
窗口大小。如果看到连续低于TCP窗
口大小，可能意味着报文丢失或路径
上其他影响吞吐量的问题。
tcp.analysis.ack_rtt：衡量抓取的TCP
报文与相应的ACK。如果这一时间间
隔比较长那可能表示某种类型的网络
延时（报文丢失，拥塞，等等）。
在抓包中应用以上一些过滤条件：
注意：Graph 1是HTTP总体流量，显
示形式为packets/tick，时间间隔1
秒。Graph 2是TCP丢失报文片段。
Graph 3是TCP 重复ACK。Graph 4是
TCP重传。
从这张图可以看到：相比于整体
HTTP流量，有很多数量的重传以及
重复ACK。从这张图中，可以看到这
些事件发生的时间点，以及在整体流
量中所占的比例。
函数**:**
IO Graphs有六个可用函数：
SUM, MIN, AVG , MAX, COUNT,
LOAD。
MIN( ), AVG( ), MAX( )
首先看一下帧之间的最小，平均和最
大时间，这对于查看帧/报文之间的
延时非常有用。我们可以将这些函数
结合“frame .time _de lta**”过滤条件
看清楚帧延时，并使得往返延时更
为明显。如果抓包文件中包含不同
主机之间的多个会话，而只想知道
其中一个pair，可
将“frame.time_delta**”结合源和目标
主机条件
如“ip.addr==x.x.x.x &&i p.addr==y.y.y.y
”
。如下图所示：
我们做了以下步骤：
将Y轴设置为“Advanced”，让
Caculation域可见。不做这一步就
看不到计算选项。
X轴时间间隔1秒，所以每个柱状
图代表1秒间隔的计算结果。
过滤出两个特定IP地址的HTTP会
话，使用条
件：“(ip.addr==192.168.1.4&& ip.a
ddr==128.173.87.169) && http”。
使用3个不同的graph，分别计算
Min(), Avg(), Max()。
对每一个计算结果应用条
件“frame.time_delta”，将style设置
成“FBar”，显示效果最佳。
从上图可见，在第106秒时数据流的
MAX frame.delta_time达到0.7秒，这
是一个严重延时并且导致了报文丢
失。如果想要深入研究，只需要点击
图中这一点，就会跳转至相应帧。对
应于本例抓包文件中第1003个报文。
如果你看见帧之间平均延时相对较低
但突然某一点延时很长，可点击这一
帧，看看这一时间点究竟发生了什
么。
Count( )
此函数计算时间间隔内事件发生的次
数，在查看TCP分析标识符时很有
用，例如重传。例图如下：
Sum( )
该函数统计事件的累加值。有两种常
见的用例是看在捕获TCP数据量，以
及检查TCP序列号。让我们看看第一
个TCP长度的例子。创建两个图，一
个使用客户端IP 192.168.1.4为源，另
一个使用客户端IP作为一个目的地
址。每个图我们将sum()功能结合
tcp.len过滤条件。拆分成两个不同的
图我们就可以看到在一个单一的方向
移动的数据量。
从图表中我们可以看到，发送到客户
端的数据量（IP.DST = = 192.168.1.4
过滤条件）比来自客户端的数据量要
高。在图中红色表示。黑条显示从客
户端到服务器的数据，相对数据量很
小。这是有道理的，因为客户只是请
求文件和收到之后发送确认数据，而
服务器发送大文件。很重要的一点
是，如果你交换了图的顺序，把客户
端的IP作为图1的目标地址，并且客
户端IP作为图2的源地址，采用了
FBAR的时候可能看不到正确的数据
显示。因为图编号越低表示在前台显
示，可能会覆盖较高图号。
现在让我们看一下同一个数据包丢失
和延迟的TCP序列号。
可以在图中看到若干峰值和下降，表
示TCP传输有问题。与正常TCP报文
比较：
这张图可以看到TCP序列号相当稳定
地增加，表示传输平稳，没有过多重
传或丢包。
作为网络管理员，很多时间必然会耗
费在修复慢速服务器和其他终端。但
用户感到网络运行缓慢并不意味着就
是网络问题。
解决网络性能问题，首先从TCP错误
恢复功能（TCP重传与重复ACK）和
流控功能说起。之后阐述如何发现网
络慢速之源。最后，对网络各组成部
分上的数据流进行概况分析。这几张
内容将会帮助读者识别，诊断，以及
排查慢速网络。
更多信息
接下来的内容，较多是黑白图片了。
虽然看起来有点不爽，但还是很值得
一看。
TCP错误恢复功能：
TCP的错误恢复功能是定位，诊断及
修复网络延时的最佳工具。延时可以
在单程也可以往返方向测量。高延时
是网络管理员的头号大敌。本节我们
讨论TCP高延时是如何导致序列号和
确认号乱序的。
TCP重传：
主机报文重传是TCP最基本的错误恢
复功能，它的目的是防止报文丢失。
报文丢失的可能因素有很多种，包括
应用故障，路由设备过载，或暂时的
服务宕机。报文级别速度是很高的，
而通常报文丢失是暂时的，因此TCP
能够发现和恢复报文丢失显得尤为重
要。
决定报文是否有必要重传的主要机制
是重传计时器（retransmission
timer），它的主要功能是维护重传超
时（RTO）值。当报文使用TCP传输
时，重传计时器启动，收到ACK时计
时器停止。报文发送至接收到ACK的
时间称为往返时间（RTT）。对若干
次时间取平均值，该值用于确定最终
RTO值。在最终RTO值确定之前，确
定每一次报文传输是否有丢包发生使
用重传计时器，下图说明了TCP重传
过程。
当报文发送之后，但接收方尚未发送
TCP ACK报文，发送方假设源报文丢
失并将其重传。重传之后，RTO值加
倍；如果在2倍RTO值到达之前还是
没有收到ACK报文，就再次重传。如
果仍然没有收到ACK，那么RTO值再
次加倍。如此持续下去，每次重传
RTO都翻倍，直到收到ACK报文或发
送方达到配置的最大重传次数。
最大重传次数取决于发送操作系统的
配置值。默认情况下，Windows主机
默认重传5次。大多数Linux系统默认
最大15次。两种操作系统都可配置。
示例如下图：
TCP重传过程发送的第一个报文如下
图所示（图片不很清楚，已经尽力
了）：
这是一个TCP PSH/ACK报文①，包含
6
1
48字节数据②，从10.3.30.1发送至
0.3.71.7。这是一个典型的数据报
文。
在通常情况下，第一个报文发送之后
很快会收到TCP ACK报文。然而，在
这个case里，第二个是重传报文。可
以在Packet list面板里看到。Info栏清
楚的标明“TCP Retransmission”，报文
以黑色背景红色字体标出。下图是
Packet List面板中的重传示例（仍然
不清楚，但可参见上图）：
也可以在Packet Details和Packet Bytes
面板中查看来确定是否是重传报文，
如下图所示：
注意此报文与源报文相同（除了IP标
识和checksum字段）。要验证这一
点，比较两个报文的Packet Bytes①。
在Packet Details面板，注意到重传报
文在SEQ/ACK Analysis下面有些额外
的信息②。这些信息是由Wireshark提
供的而并非报文本身。SEQ/ACK
Analysis告诉我们这确实是一个重传
报文，RTO值是0.206秒，此时的RTO
是基于报文1的时间增量。
检查剩下的报文会得到类似的结果，
不同之处只有IP标识和checksum，以
及RTO值。要使报文之间的时间间隔
形象化，在Packet List面板中查看
Ti me栏，如下图所示。这里可以看到
RTO值的翻倍增长关系。
TCP重复ACK以及快速重传：
重复ACK是指在接收方收到乱序报文
时，所发出的一类TCP报文。TCP使
用报文头的序列号和确认号以有效保
证数据按照发送的顺序接收和重组。
当TCP连接建立以后，握手过程中交
换的一个最重要的信息是初始序列号
（ISN）。一旦连接双方设定了ISN之
后，接下来发送的报文所包含的序列
号增加一个数据载荷值。
假设有个主机ISN是5000，发送500字
节报文至接收方。一旦报文接收之
后，接收端回复一个ACK号为5500的
TCP ACK报文，基于以下公式：
Se que nce Numbe r In + Bytes of Data
Re ce ive d = Acknowle dgme nt Numbe r
Out
按照上述计算结果，返回发送端的确
认编号实际上是接收端希望收到的序
列号。示例如下图：
数据接收方通过序列号来检查报文丢
失。接收方通过追踪接收到的序列
号，能够确认序列号是否乱序。当接
收方收到一个不正常的序列号，它会
假设传输过程中有报文丢失。为了正
确重传数据，接收方必须拥有丢失报
文，所以它发送包含有丢失报文正确
序列号的ACK报文，以便发送方重传
此报文。
当重传主机从发送端接收到3个重复
ACK时，它会假设此报文确实在传送
中丢失，并且立即发送一个快速重
传。一旦触发了快速重传，所有正在
传输的其他报文都被放入队列中，直
到快速重传报文发送为止。过程如下
图所示：
承接上文的彩图：
本例中第一个报文如下图：
这是一个TCP ACK报文，从数据接收
端（172.31.136.85）发给发送端
（
195.81.202.68）①，确认前一个报
文所发送的数据。
此报文中的确认编号是
1310973186②，应当是下一个接收报
文的序列号，如下图所示：
不幸的是接收端的序列号是
1310984130①，并不是所期望的值。
这意味着报文在传送中丢失。接收端
注意到报文乱序，并且在第三个报文
中发送重复ACK，如下图所示：
可以通过以下两种方式之一来确认这
是一个重复ACK：
在Packet Detaisl面板中的Info栏。报
文呈现黑色背景红色字体。
SEQ/ACK Analysis下的Packet Deatails
面板。扩展这一栏会发现报文显示为
duplicate ACK。接下来几个报文重复
此过程。如下图所示：
此文件中的第四个报文是发送端所发
出具有错误序列号①的另一个数据
块。因此，接收端发送第二个重复
ACK②。接收端又收到一个乱序报文
③。从而触发了第三以及最后一个重
复ACK④.
一旦发送方接收到接收方所发来的第
三个重复ACK，它就会暂停所有传输
报文并且重传丢失报文，下图显示了
快速重传过程：
重传报文同样可以通过Packet List面
板的Info栏观察到。报文呈现黑色背
景红色字体。这个报文的SEQ/ACK
Analysis截面告诉我们这可能是一个
快速重传帧。（标识报文为快速重传
的信息不是报文本身所包含的内容，
而是Wireshark的功能）。最后一个报
文是接收到快速重传的ACK。
TCP通过滑动窗口机制检测丢包，并
在丢包发生时调整数据传输速率。滑
动窗口机制利用数据接收端的接收窗
口来控制数据流。
接收窗口值由数据接收端指定，以字
节数形式存储于TCP报文头，并告知
传输设备有多少数据将会存储在TCP
缓冲区。缓冲区就是数据暂时放置的
地方，直至传递至应用层协议等待处
理。因此，发送端每次只能发送
Wi ndow Size字段指定的数据量。为
了使发送端继续传送数据，接收端必
须发送确认信息：之前的数据接收到
了。同时必须对占用缓冲区的数据进
行处理以释放缓存空间。下图显示了
接收窗口是如何工作的：
上图中，客户端向服务器发送数据，
服务器接收窗口是5000字节。客户端
发送了2500字节，服务器缓冲区还剩
2500字节，之后又发送了2000字节，
从而缓冲区只剩500字节。服务器发
送确认信息。对缓存中数据进行处理
并清空缓存。此过程重复进行，客户
端又发送3000字节和1000字节，服务
器缓存减少至1000字节，客户端再次
确认数据并处理缓存中内容。
更多信息
调整窗口大小：
当TCP堆 栈接收到数据的时候，生成
一个确认信息并以回复的方式发送，
但是放置在接收端缓存中的数据并不
总是立即被处理。当服务器忙于处理
从多个客户端接收的报文， 服务器
很有可能因为清理缓存而变得缓慢，
无法腾出空间接收新的数据，如果没
有流控，则可能会造成丢包和数据损
坏。好在，接收窗口所设定的速率无
法使服务器 正常处理数据时，能够
调整接收窗口大小。通过减小返回给
发送端的ACK报文的TCP头窗口大小
值来实现。如下图所示：
上图中，服务器初始窗口大小为5000
字节。客户端发送2000字节，之后又
发送了2000字节，缓冲区中只有1000
字节可用。服务器意识到缓冲区正在
快速填满，它知道如果数据继续以此
速率传输，很快会有报文丢失。为了
防止报文丢失，服务器发送确认信息
给客户端，更新窗口大小为1000字
节。结果，客户端减少数据发送，服
务器以可以接受的速率处理缓存内
容，即保持数据流以稳定的速率传
输。
调整窗口大小在两个方向都是可行
的。当服务器能够更加快速的处理报
文时，它会发送一个较大窗口的ACK
报文。
零窗口暂停数据流：
某些情况下，服务器无法再处理从客
户端发送的数据。可能是由于内存不
足，处理能力不够，或其他原因。这
可能会造成数据被丢弃以及传输暂
停，但接收窗口能够帮助减小负面影
响。
当上述情况发生时，服务器会发送窗
口为0的报文。当客户端接收到此报
文时，它会暂停所有数据传输，但会
保持与服务器的连接以传输探测
（
keep-alive）报文。探测报文在客
户端以稳定间隙发送，以查看服务器
接收窗口状态。一旦服务器能够再次
处理数据，将会返回非零值窗口大
小，传输会恢复。下图示例了零窗口
通知过程。
服务器初始接收数据窗口为5000字节
大小。从客户端接收4000字节数据之
后，服务器负载变得非常繁重，无法
继续处理客户端任何数据。服务器于
是发送窗口大小值为0的报文。客户
端暂停数据传输并发送一个探测报
文。探测报文之后，服务器回复以告
知客户端现在可以接收数据的报文，
以及窗口大小为1000字节。客户端恢
复传送数据。
TCP滑动窗口实战：
本例中，开始从192.168.0.20发送至
192.168.0.30。我们关心的是窗口大
小字段，可以从Packet List面板的Info
栏以及Packet Details的TCP报文头看
到。前三个报文后，可看到该值立刻
减小，如下图所示：
窗口大小值从第一个报文的8760字节
变成第二个报文的5840字节到第三个
报文的2920字节①。窗口大小值的减
小是主机延时的典型标志。在时间栏
注意到这一过程发生的非常迅速②。
当窗口大小迅速减小的时候，通常就
有可能下降为零。这就是第四个报文
所发生的，如下图所示：
第四个报文从192.168.0.20发送至
192.168.0.30，目的是告诉
192.168.0.30它不再接收任何数据。0
值见于TCP报文头①，Wireshark的
Packet List面板Info栏，以及TCP报文
头的SEQ/ACK Analysis字段②也告诉
我们这是一个0窗口报文。
一旦发送了零窗口报文，
192.168.0.30的设备不会再发送任何
数据，直到收到从192.168.0.20的窗
口更新，告知窗口大小已经增加了。
本例中导致零窗口的问题是暂时的，
所以在下一个报文中发送了窗口更新
信息，如下图所示。
本例中，窗口大小增加到一个非常健
康的数值64，240字节①。Wireshark
再次在SEQ/ACK Analysis告诉我们这
是一个窗口更新。
一旦收到更新报文，192.168.0.30的
主机就再次开始发送数据，在报文 6
和报文7中。这一过程发生很快。如
果它持续时间再长一点，就可能会导
致网络的潜在中断，引起数据传输减
慢或失败。
下一个关于滑动窗口的例子，第一个
报文是正常HTTP，从195.81.202.68
至172.31.136.85。此报文之后立刻跟
随一个从172.31.136.85发送的零窗口
报文，如下图所示：
这与上一个例子中的零窗口报文十分
类似，但结果显著不同，
1
72.31.136.85主机不是发送一个窗口
更新并回复通讯，而是一个探测报
文，如下图所示：
此报文被Wireshark标注为探测报文
①
。时间栏告诉我们这一报文发生于
最后一个接收到的报文3.4秒之后。
这一过程持续若干次，一端发送零窗
口报文另一端发送探测报文，如下图
所示：
探测报文发送间隙为3.4，6.8，13.5
秒。这一过程可能会持续相当长一段
时间，取决于通讯设备的操作系统。
该情况下，把时间栏的值加起来，通
讯暂停了25秒。
TCP差错控制和流控排查总结：
重传报文
重 传的发生是由于客户端检测到服
务器没有接收到它所发送的数据。因
此，取决于你所分析的是通讯的哪一
端，有可能是看不见重传的。如果从
服务器端抓取数据，并 且它确实没
有接收到客户端所发送的和重传报
文，可能会一无所获因为无法看见重
传报文。如果怀疑并不是服务器端导
致的报文丢失，可以考虑在客户端尝
试抓取报 文，以查看实际是否有重
传发生。
重复**ACK**
可以将重复ACK看作重传的“所谓相
反面”，因为它是在服务器检测到客
户端发送报文丢失的时候产生的。大
多数情况下，在通讯两端抓取流量时
都可以看到重复ACK。需记住当接收
报文乱序时会触发重复ACK。例如，
如果服务器之接收到发送的第一个和
第三个报文，就会导致发送重复ACK
引起客户端对第二个报文的快速重
传，因为你已经收到了第一个和第三
个报文，因此不管导致第二个报文丢
弃的原因是什么，都很有可能是暂时
的，因此大多数情况下重复ACK都会
成功发送和接收。当然，这种情形并
不一定永远会发生，因此当你怀疑在
服务器端丢失报文而又看不到任何重
复ACK，考虑从通讯的客户端抓取报
文。
零窗口和探测报文
滑动窗口直接与服务器无法接收和处
理报文有关，任何窗口大小的缩小以
及零值都是服务器问题的直接结果。
所以如果你在哪里看到这两者之一发
生，就应该在那里深入研究。通常应
当在网络通讯两端一直主机窗口更新
报文。
在某些情况下，丢包可能并不是造成
延时的原因。你可能会发现尽管两台
主机之间通讯速度很慢，但这种慢速
并没有伴随着TCP重传或是重复ACK
的征兆。在这种情况下，需要使用另
一种方式来定位高延时点。
查找高延时点最有效的方法之一是检
查最初的握手信号以及跟随其后的几
个报文。例如，一个简单的客户端与
网络服务器的连接，客户端尝试通过
浏览器访问网络服务器的站点。我们
只关心这一通信序列的前六个报文，
包括TCP握手过程，首次HTTP GET
请求，对此GET请求的确认，以及从
服务器发至客户端的第一个数据报
文。
更多信息
正常通讯**:**
在讨论高延时状况之前，找一个正常
的通讯作为参照。在第二节已经介绍
过TCP握手过程以及HTTP通讯，这
里不再赘述。在下面这张图里，我们
关心的部分只有Ti me列：
这一通讯序列是非常快速的，整个过
程耗时不到0.1秒。
接下来几个抓包文件包含同样的
traffic模式，但是在报文时序上有所
不同。
慢速通讯——线路延时：
让我们看看下面这个报文。注意到所
有报文都是相同的，除了报文2和5的
时间延时较长：
逐一分析这六个报文，立刻就会看到
第一次延时。客户端
（
172.16.16.128）发送首次SYN报文
以开始TCP握手，在服务器
74.125.95.104）返回SYN/ACK之
（
前，有0.87秒的延时。这是线路延时
的第一个信号，这是由客户端和服务
器之间的设备引起的。
我们判断这是线路延时的依据是所传
送的报文类型特征。当服务器接收到
一个SYN报文，只需花费很少的处理
过程就可发送回复，因为这一工作负
载并不包含任何传输层之上的处理。
即使服务器工作负载非常繁重，它通
常也会快速地以SYN/ACK来回复
SYN报文。这就排除了服务器是高延
时的潜在原因。
客户端也被排除的原因在于，它除了
接收SYN/ACK报文之外，没有进行
任何处理。
这一抓包的前两个报文帮我们排除了
客户端和服务器，并指出了潜在原
因。
继续分析，我们发现结束三步握手信
号的ACK报文快速出现，客户端发送
的HTTP GET请求也是如此。产生这
两个报文的所有处理在本地客户端接
收到SYN/ACK之后进行，因此在客
户端没有繁重的负载需要处理的情况
下，这两个报文预计会很快传送。
到了报文5，我们看到另一个延时高
得离谱的报文。出现在最初的HTTP
GET请求发送过后，从服务器返回的
ACK报文花费了1.15秒才收到。接收
到HTTP GET请求之后，服务器在开
始发送数据之前首先发送了一个TCP
ACK，同样只需占用服务器很少的处
理。这是另一个线路延时的信号。
不管何时你经历着线路延时，你几乎
总是会看到：在最初的握手信号期间
的SYN/ACK报文，以及整个通讯过
程的ACK报文中，存在着高延时。即
使这一信息并没有告诉你网络上延时
的确切原因，至少让你明白客户端和
服务器都不是延时点所在，因此延时
发生在两者之间的设备。这时，你应
当开始检查受影响主机之间的各种防
火墙，路由器，以及代理，以定位罪
魁祸首。
慢速通讯——客户端延时：
下一个延时场景的抓包如下图所示：
这一抓包开始时很正常，TCP握手非
常迅速，没有任何延时的迹象。正常
状态持续至第四个报文：握手信号结
束之后接收到一个HTTP GET请求。
这个报文距离前一个接收到的报文有
1.34秒的延时。
要确认网络的延时点，需要检查第 3
和第4个报文之间发生了什么。报文3
是客户端发送到服务器的TCP握手信
号中的最后一个ACK，报文4是从客
户端发送至服务器的GET请求。这两
个报文的共同之处在于都是由客户端
发送，并且独立于服务器。由于所有
这些操作都集中在客户端上，GET请
求应当在发送了ACK之后快速传送。
不幸的是对于终端用户，从ACK到
GET的传送并没有快速发生。GET报
文的创建与传输取决于应用层的处
理，这一过程中的延时意味着客户端
无法及时的执行这一功能。这表示客
户端最终为通讯中的高延时负责。
慢速通讯——服务器延时：
最后一个延时场景的抓包如下图所
示：
在这一抓包中，两个主机之间的TCP
握手过程完成得干脆利落，因此开始
时并无问题。接下来几个报文也很顺
利，首个GET请求及回复ACK报文也
在快速交付。直到最后一个报文，我
们看到了高延时的信号。
第六个报文是服务器响应客户端GET
请求的第一个HTTP数据报文，但是
在服务器发送GET请求的TCP ACK
.98秒之后才到达。报文5和6的传送
0
过程与我们在前一个场景所见ACK和
GTE请求的传送类似。但是，在这一
情况下，服务器是我们关注的焦点。
报文5是服务器对从客户端接收GET
请求的回应。只要该报文被发送，服
务器就应当立即发送数据。这一读
取，封装，传送的过程是由HTTP协
议完成的，由于这是应用层协议，需
要服务器参与处理过程。这一报文的
延迟接收表明服务器无法在合理的时
间内处理数据，最终指向服务器是延
时点。
延时定位思路：
通过六个报文，我们能够定位服务器
与客户端之间的网络高延时点。这些
场景可能看起来有点复杂，但是下图
能使你的定位延时过程变得简单快
捷。这一原则几乎能应用于任何基于
TCP的通讯。
Wireshark一个强大的功能在于它的统
计工具。使用Wireshark的时候，我们
有各种类型的工具可供选择，从简单
的如显示终端节点和会话到复杂的如
Flow和IO图表。本文将介绍基本网络
统计工具。包括：捕捉文件摘要
（
（
（
（
Summa r y）,捕捉包的层次结构
Protocol Hirarchy）, 会话
Conversations）, 终端节点
Endpoints）, HTTP。
更多信息
Summa ry :
从statistics菜单，选择Summa ry：
如下图的截屏所示，你会看到：
File：
捕捉文件的一般信息，如文件名和路
径，长度，等等
Ti me：
第一个包和最后一个包的时间戳，以
及抓包过程持续时间
Capture：
显示文件捕捉于哪一个接口，以及评
论窗口
在窗口的较低部分是Display窗口，展
示抓包文件统计信息的摘要，包括：
捕捉报文的总数与百分比
显示报文的数量（加上过滤条件之
后）
标记报文的数量
何时使用：
这一菜单简单收集所有抓包数据，在
定义了过滤条件的时候，将呈现过滤
后的数据。当想要知道每秒的平均报
文数或是字节数时，可以使用此工
具。
Protocol Hierarchy:
这一部分阐述如何确知网络运行数
据。从statistics菜单，选择Protocol
Hierarchy。
这个窗口现实的是捕捉文件包含的所
有协议的树状分支。如下图所示：
Protocol Hierarchy窗口有如下字段：
Protocol：
协议名称
%
Packets：
含有该协议的包数目在捕捉文件所有
包所占的比例
Packets：
含有该协议的包的数目
Bytes：
含有该协议的字节数
Mbit/s：
抓包时间内的协议带宽
End Packets ：
该协议中的包的数目（作为文件中的
最高协议层）
End Bytes ：
该协议中的字节数（作为文件中的最
高协议层）
End Mbit/s ：
抓包时间内的协议带宽（作为文件中
的最高协议层）
小贴士：
包通常会包含许多协议，有很多协议
会在每个包中被统计。End Packets，
End Bytes，End Mbit/s列是该层在抓
包中作为最后一层协议的统计数据
（也就是说，协议处于报文的顶层，
并且没有更高层信息了）。例如，没
有载荷的TCP报文（例如，SYN报
文），这一类没有负载任何上层信息
的报文。这就是为什么在Ethernet
层，IPv4层和UDP层报文计数为0，
因为没有接收到以这些协议作为最后
一层的帧。
何时使用：
值得注意的两点是：
百分比永远指的是相同协议层级。例
如，
使用要点：
1. Percentage永远参照的是相同协议
层。例如，上例中81.03%是IPv4报
文，8.85%是IPv6报文，10.12%是
ARP报文。第二层之上的各协议所占
百分比总和是100%。
2
7
1
. 另一方面，TCP占总数据的
5.70%，在TCP协议之内，只有
2.74%的报文是HTTP，除此之外没
有其他统计。这是由于Wireshark只统
计有HTTP头的报文。它不统计如确
认报文或数据报文这样没有HTTP头
的报文。
3. 为了使Wireshark同时统计数据报
文，例如，TCP报文内部的HTTP报
文，关闭Allow sub-disse ctor选项，对
TCP数据流重新统计。可
在Pre fe re nce s菜单或Packet Details
面板中右键TCP来实现。
Conversations：
1. 在Statistics菜单中，选择
Coversations。
2. 会看到以下窗口：
3. 可以选择第2层以太网统计数据，
第3层IP统计数据，或第4层TCP或
UDP统计数据。
4. 可以选择以下统计工具：
On layer 2(Ethe rne t)：查找并过
滤广播风暴或
On layer 3 or 4(TCP/IP)**：**通
过互联网路由器端口并行连接，
查看谁在向ISP传输数据
小贴士：
如果你看到互联网上某一IP地址通过
端口80（HTTP）向外传输大量数据
流，你就需要将该地址复制入浏览器
并且查看你的用户与哪一个网站通讯
最多。
如果没有得到结果，只需到标准DNS
查询站点（Google一下DNS lookup）
查看哪一种流量占用了你的网线。
5
. 也可以通过选择位于窗口左下方的
Limit to display filte r复选框，将会话
统计信息进行显示过滤。这样，仅呈
现所有通过显示过滤条件的统计数
据。
6.要查看IP地址对应名称，可以选择
Name re solution复选框。要查看IP名
称解析，进入Vie w | Name Resolution
|
Enable for Network laye r进行激活。
7. 对于TCP或UDP，可以在Packet list
中对指定报文进行标记，之后从菜单
中选择Follow TCP Stre am或Follow
UDP Stre am。从而定义一个显示过
滤条件，仅显示指定数据流。
使用要点：
网络会话是两个指定终端之间的数据
流。例如，IP会话是两个IP地址之间
的所有数据流，TCP会话包含了所有
TCP连接。
通过Conversations列表，能看出很多
网络问题。
以太网会话统计
在Ethernet conversations statistics中，
查找以下问题：
大量的广播风暴：可以看见较轻
微的广播风暴；而对于每秒数千
甚至数万个报文的严重广播风
暴，Wireshark会停止显示数据并
且屏幕冻结。只有断开Wireshark
连接时才能看见。
如果你看到来自某一MAC地址的
大量数据，查看会话第一部分的
vendor ID，会给你一些导致问题
的线索。即使MAC地址的第一部
分标识了vendor，但它并不一定就
标识了PC本身。这是由于MAC地
址属于PC上安装的以太网芯片厂
商，而并不一定属于PC制造商。
如果无法识别数据流来源地址，
可以ping嫌疑地址并通过ARP获取
它的MAC地址，在交换机中查找
该地址，如果有操作系统的话直
接用find命令来定位。
IP会话统计
在IP conversations statistics中，查找
以下问题：
查看收发大量数据流的IP地址。
如果是你知道的服务器（你记得
服务器的地址或地址范围），那
问题就解决了；但也有可能只是
某台设备正在扫描网络，或仅是
一台产生过多数据的PC。
查看扫描模式（scan pattern）。这
可能是一次正常的扫描，如SNMP
软件发送ping报文以查找网络，但
通常扫描都不是好事情。
一次典型的扫描模式如下图所
示：
本例中的扫描模式，一个IP地址，
1
1
1
92.168.110.58，发送ICMP报文至
92.170.3.44, 192.170.3.45,
92.170.3.46, 192.170.3.47,等等（上
图仅显示扫描的很小一部分）。这种
情况下我们有一个蠕虫病毒感染了网
络上的所有PC，在它感染PC的时
候，它就开始产生ICMP请求并将它
们发送至网络。这些窄带连接（例
如：WAN连接）可以很容易地被封
锁。
TCP/UDP会话统计
查看带有太多TCP连接的设备。
每一个PC合理的连接数是10到20
个，上百个则是不正常的。
尝试查找无法辨识的端口号。它
可能是正常的，但也可能是有问
题的。下图显示了一次典型的
TCP扫描：
Endpoints:
1
2
3
. 从statistics菜单，选择Endpoints：
. 出现以下窗口：
. 此窗口中，能够看到第2,3,4层的
endpoints，也就是以太网，IP, TCP或
UDP。
使用要点：
这一工具列出了Wireshark发现的所有
endpoints上的统计信息。可以是以下
任意一种情况：
少量以太网endpoints（MAC地
址）与大量IP终端节点（IP地
址）：可能的情况例如，一个路
由器从很多远端设备收发报文，
我们会看见路由器的MAC地址及
很多IP地址经由此处。
少量IP终端节点与大量TCP终端节
点：可能的情况是每一台主机有
很多个TCP连接。可能是有很多
连接的服务器的一个正常操作，
也可能是一种网络攻击（如SYN
攻击）。
以下是一个网络中心的抓包示例，一
个内部网络有四个HP服务器和一个
Cisco路由器，MAC地址的第一部分
已经解析了厂商名称：
当我们查看IPv4:191下的endpoints，
我们看到有很多来自192.168.10.0,
1
92.168.30.0，以及其他网络地址。
HTTP:
. 从statistics菜单，选择HTTP，将会
1
出现以下窗口：
在HTTP子菜单中，可以看到以下信
息：
Packet Counter ：
每一个网站的报文数量。帮助识别有
多少响应和请求。
Requests：
各网站的请求分布。
Load Distribution ：
各网站的负载分布。
按照以下操作步骤查看Packet
Counte r统计信息：
1
. 进入Statistics | HTTP | Packet
Counte r 。
2
3
. 显示以下过滤窗口：
. 此窗口中，可设置过滤条件以查看
符合过滤条件的统计信息。如果想要
查看整个抓包文件的统计信息，留白
不填。这就会显示IP层之上的统计信
息，也就是所有HTTP报文。
4. 点击Cre ate Stat按钮，会看到以下
窗口：
如果要查看某一特定节点的HTTP统
计信息，可以通过display filter的方式
配置过滤条件。
按照以下操作步骤查看HTTP
Re que sts统计信息：
1. 进入Statistics | HTTP | Re que sts，
出现以下窗口：
2. 选择所需过滤条件。对于所有数
据，留白。
3. 点击Cre ate Stat按钮，会出现以下
窗口：
4. 要获得指定HTTP主机的统计信
息，设置过滤条件http.host contains
或 http.host== 。
5. 例如，通过设置过滤条件http.host
contains ndi -com.com，可以获得站
点 www.ndi-com.com的统计信息，如
下图所示：
. 结果如下图所示：
6
按照以下操作步骤查看Load
Distribution统计信息：
1. 进入Statistics | HTTP | Load
Distribution。
2.出现以下窗口：
3. 选择所需过滤条件。对于所有数
据，留白。
4. 点击Cre ate Stat按钮，会出现以下
窗口：
使用要点：
当我们打开一个网页，通常会向若干
个URL发送请求。本例中，我们打开
的其中一个网页是www.cnn.com，并
将我们导向edition.cnn.com。我们发
送了若干个请求：到root URL，到
breaking_news URL，以及主页上两个
其他位置。
应用抓包过滤，选择Capture |
Options，扩展窗口查看到Capture
Filte r栏。双击选定的接口，如下图
所示，弹出Edit Inte rface Settints窗
口。
下图显示了Edit Inte rface Settings窗
口，这里可以设置抓包过滤条件。如
果你确知抓包过滤条件的语法，直接
在Capture Filter区域输入。在输入错
误时，Wireshark通过红色背景区域表
明无法处理过滤条件。最有可能的情
况是，过滤条件中含有输入错误，或
是使用了display filter的语法。
点击Capture Filte r按钮查看并选择已
保存的抓包过滤条件。
更多信息
抓取指定**IP地址的数据流: **
如果你的抓包环境下有很多主机正在
通讯，可以考虑使用所观察主机的IP
地址来进行过滤。以下为IP地址抓包
过滤示例：
host 10.3.1.1：抓取发到/来自
10.3.1.1的数据流
host 2406:da00:ff00::6b16:f02d：抓
取发到/来自IPv6地址
2406:da00:ff00::6b16:f02d的数据
流
not host 10.3.1.1：抓取除了发到/
来自10.3.1.1以外的所有数据流
src host 10.3.1.1：抓取来自
10.3.1.1的数据流
dst host 10.3.1.1：抓取发到10.3.1.1
的数据流
host 10.3.1.1 or 10.3.1.2：抓取发
到/来自10.3.1.1，以及与之通讯的
所有数据流，与10.3.1.2，以及与
之通讯的所有数据流
host www.espn.com：抓取发到/来
自所有解析为www.espn.com的IP
地址的数据流
抓取指定**IP地址范围的数据流: **
当你需要抓取来自/发到一组地址的
数据流，可以采用CIDR(无类别域间
路由，Classless Interdomain Routing)
格式或使用mas k参数。
net 10.3.0.0/16：抓取网络10.3.0.0
上发到/来自所有主机的数据流(16
表示长度)
net 10.3.0.0 mask 255.255.0.0：与
之前的过滤结果相同
ip6 net 2406:da00:ff00::/64：抓取
网络2406:da00:ff00:0000(IPv6) 上
发到/来自所有主机的数据流
not dst net 10.3.0.0/16：抓取除了
发到以10.3开头的IP地址以外的所
有数据流
not src net 10.3.0.0/16：抓取除了
来自以10.3开头的IP地址以外的所
有数据流
ip proto ：抓取ip协议字段等于值
的报文。如TCP(code 6),
UDP(code 17), ICMP(code 1)。
ip[2:2]==：ip报文大小
ip[8]==：TTL( Ti me to Live)值
ip[9]==：协议值
icmp[icmptype]==: 抓取 ICMP代码
等于identifier的ICMP报文, 如
icmp-echo 以及 icmp-request。
方括号中第一个数字表示从协议头开
始的偏移量，第二个数字表示需要观
察多少位。
抓取发到广播或多播地址的数据流
**:**
只需侦听广播或多播数据流，就可以
掌握网络上主机的许多信息。
ip broadcast：抓取广播报文
ip multicast：抓取多播报文
dst host ff02::1：抓取到IPv6多播
地址所有主机的数据流
dst host ff02::2：抓取到IPv6多播
地址所有路由器的数据流
小贴士：
Wireshark包含了一些默认的抓包过滤
条件。点击主工具栏的Edit Capture
Filte rs，跳转到已保存抓包过滤列
表。你会发现一些常见抓包过滤的示
例。
抓取基于**MAC地址的数据流:**
当你需要抓取发到/来自某一主机的
IPv4或IPv6数据流，可创建基于主机
MAC地址的抓包过滤条件。
应用MAC地址时，需确保与目标主
机处于同一网段。
ether host 00:08:15:00:08:15：抓取
发到/来自00:08:15:00:08:15的数
据流
ether src 02:0A:42:23:41:AC：抓取
来自02:0A:42:23:41:AC的数据流
ether dst 02:0A:42:23:41:AC：抓取
发到02:0A:42:23:41:AC的数据流
not ether host 00:08:15:00:08:15：
抓取除了发到/来自
00:08:15:00:08:15以外的所有数据
流
ether broadcast或ether dst
ff:ff:ff:ff:ff:ff：抓取广播报文
ether multicast：多播报文
抓取指定以太网类型的报文：
ether proto 0800
抓取指定VLAN：vlan
抓取指定几个VLAN：vlan and
vlan
抓取基于指定应用的数据流**:**
你可能需要查看基于一个或几个应用
的数据流。抓包过滤器语法无法识别
应用名，因此需要根据端口号来定义
应用。通过目标应用的TCP或UDP端
口号，将不相关的报文过滤掉。
port 53：抓取发到/来自端口53的
UDP/TCP数据流（典型是DNS数
据流）
not port 53：抓取除了发到/来自端
口53以外的UDP/TCP数据流
port 80：抓取发到/来自端口80的
UDP/TCP数据流（典型是HTTP数
据流）
udp port 67：抓取发到/来自端口
67的UDP数据流（典型是DHCP据
流）
tcp port 21：抓取发到/来自端口21
的TCP数据流（典型是FTP命令通
道）
portrange 1-80：抓取发到/来自端
口1-80的所有UDP/TCP数据流
tcp portrange 1-80：抓取发到/来自
端口1-80的所有TCP数据流
抓取结合端口的数据流**:**
当你需要抓取多个不连续端口号的数
据流，将它们通过逻辑符号连接起
来，如下图所示：
port 20 or port 21：抓取发到/来自
端口20或21的UDP/TCP数据流
（典型是FTP数据和命令端口）
host 10.3.1.1 and port 80：抓取发
到/来自10.3.1.1端口80的数据流
host 10.3.1.1 and not port 80：抓取
发到/来自10.3.1.1除了端口80以外
的数据流
udp src port 68 and udp dst port
67：抓取从端口68到端口67的所
有UDP数据流（典型是从DHCP客
户端到DHCP服务器）
udp src port 67 and udp dst port
68：抓取从端口67到端口68的所
有UDP数据流（典型是从DHCP服
务器到DHCP客户端）
抓取TCP连接的开始（SYN）和结
束（FIN）报文，配置tcp[tcpflags]
&
(tcp-syn|tcp-fin)!=0
抓取所有RST(Reset)标志位为1的
TCP报文，配置tcp[tcpflags] &
(tcp-rst)!=0
less ：抓取小于等于某一长度的
报文，等同于len
greater ：抓取大于等于某一长度
的报文，等同于len >=
SYN: 简历连接的信号
FIN: 关闭连接的信号
ACK: 确认接收数据的信号
RST: 立即关闭连接的信号
PSH: 推信号，尽快将数据转由应用
处理
tcp[13] & 0×00 = 0: No flags set
(nul l scan)
tcp[13] & 0×01 = 1: FIN set and
ACK not set
tcp[13] & 0×03 = 3: SYN set and
FIN set
tcp[13] & 0×05 = 5: RST set and
FIN set
tcp[13] & 0×06 = 6: SYN set and
RST set
tcp[13] & 0×08 = 8: PSH set and
ACK not set
tcp[13]是从协议头开始的偏移量，
0,1,3,5,6,8是标识位
尽量避免使用抓包过滤。即便多看
几个报文，也比漏看一个报文要
好。当你抓取了大量报文的时候，用
显示过滤（过滤选项也更多）来重点
查看某一数据流。
小贴士：
如果你需要查看TCP帧中的某一
ASCII字符串，用Wireshark String-
Matching Capture Filter
Generator(http://www.wireshark.org/too
ls/string-cf.html)。例如，想要抓取
HTTP GET报文，输入GET并将TCP
偏移量设置为0。
