一站式学习Wireshark（转载）

一站式学习Wireshark（一）：Wireshark基本用法

2014/06/10 · IT技术 · 4 评论 · WireShark

分享到： 115

• 与《YII框架》不得不说的故事—扩展篇
• sass进阶篇
• IOS基础教程之界面初体验
• Spring事务管理

原文出处： 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网络协议实现细节，检查安全问题，网络协议内部构件等等。

 

一站式学习Wireshark（二）：应用Wireshark观察基本网络协议

2014/06/10 · IT技术 · WireShark

分享到： 25

• CSS3图片动态提示效果
• Python操做MySQL数据库
• C++远征之多态篇
• python进阶

原文出处： EMC中文支持论坛   欢迎分享原创到伯乐头条

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 Panel中右键报文，而且选择Follow TCP Stream。这就建立了一个只显示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地址获取物理地址的一个TCP/IP协议。其功能是：主机将ARP请求广播到网络上的全部主机，并接收返回消息，肯定目标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报文被mark成Type 8，回复报文mark成Type 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过程。

 

一站式学习Wireshark（三）：应用Wireshark IO图形工具分析数据流

2014/06/10 · IT技术 · WireShark

分享到： 17

• Struts2拦截器浅析
• 使用Struts2+Hibernate开发学生信息管理功能
• C#开发轻松入门
• 神奇的JpGraph类库

原文出处： EMC中文支持论坛   欢迎分享原创到伯乐头条

基本IO Graphs:

IO graphs是一个很是好用的工具。基本的Wireshark IO graph会显示抓包文件中的总体流量状况，一般是以每秒为单位（报文数或字节数）。默认X轴时间间隔是1秒，Y轴是每一时间间隔的报文数。若是想要查看 每秒bit数或byte数，点击“Unit”，在“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_delta”过滤条件看清楚帧延时，并使得往返延时更为明显。若是抓包文件中包含不一样主机之间的多个会话，而只想知道其中一个pair，可将“frame.time_delta”结合源和目标主机条件如“ip.addr==x.x.x.x &&ip.addr==y.y.y.y”。以下图所示：

咱们作了如下步骤：

• 将Y轴设置为“Advanced”，让Caculation域可见。不作这一步就看不到计算选项。
• X轴时间间隔1秒，因此每一个柱状图表明1秒间隔的计算结果。
• 过滤出两个特定IP地址的HTTP会话，使用条件：“(ip.addr==192.168.1.4&& ip.addr==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序列号至关稳定地增长，表示传输平稳，没有过多重传或丢包。

 

一站式学习Wireshark（四）：网络性能排查之TCP重传与重复ACK

2014/06/17 · IT技术 · WireShark

分享到： 54

• 侧栏工具条开发
• PHP入门篇
• C++远征之继承篇
• 观察者模式

原文出处： EMC中文支持论坛   欢迎分享原创到伯乐头条

做为网络管理员，不少时间必然会耗费在修复慢速服务器和其余终端。但用户感到网络运行缓慢并不意味着就是网络问题。

解决网络性能问题，首先从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报文①，包含648字节数据②，从10.3.30.1发送至10.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面板中查看Time栏，以下图所示。这里能够看到RTO值的翻倍增加关系。

TCP重复ACK以及快速重传：

重复ACK是指在接收方收到乱序报文时，所发出的一类TCP报文。TCP使用报文头的序列号和确认号以有效保证数据按照发送的顺序接收和重组。

当TCP链接创建之后，握手过程当中交换的一个最重要的信息是初始序列号（ISN）。一旦链接双方设定了ISN以后，接下来发送的报文所包含的序列号增长一个数据载荷值。

假设有个主机ISN是5000，发送500字节报文至接收方。一旦报文接收以后，接收端回复一个ACK号为5500的TCP ACK报文，基于如下公式：

Sequence Number In + Bytes of Data Received = Acknowledgment Number 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。

 

一站式学习Wireshark（五）：TCP窗口与拥塞处理

2014/06/24 · IT技术 · WireShark

分享到： 14

• 前端开发工具技巧介绍—Sublime篇
• 瀑布流布局
• SEO在网页制做中的应用
• MySQL开发技巧（三）

原文出处： EMC中文支持论坛   欢迎分享原创到伯乐头条

TCP经过滑动窗口机制检测丢包，并在丢包发生时调整数据传输速率。滑动窗口机制利用数据接收端的接收窗口来控制数据流。

接收窗口值由数据接收端指定，以字节数形式存储于TCP报文头，并告知传输设备有多少数据将会存储在TCP缓冲区。缓冲区就是数据暂时放置的地方， 直至传递至应用层协议等待处理。所以，发送端每次只能发送Window 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发送的零窗口报文，以下图所示：

这与上一个例子中的零窗口报文十分相似，但结果显著不一样，172.31.136.85主机不是发送一个窗口更新并回复通信，而是一个探测报文，以下图所示：

此报文被Wireshark标注为探测报文①。时间栏告诉咱们这一报文发生于最后一个接收到的报文3.4秒以后。这一过程持续若干次，一端发送零窗口报文另外一端发送探测报文，以下图所示：

探测报文发送间隙为3.4，6.8，13.5秒。这一过程可能会持续至关长一段时间，取决于通信设备的操做系统。该状况下，把时间栏的值加起来，通信暂停了25秒。

TCP差错控制和流控排查总结：

重传报文

重 传的发生是因为客户端检测到服务器没有接收到它所发送的数据。所以，取决于你所分析的是通信的哪一端，有多是看不见重传的。若是从服务器端抓取数据，并 且它确实没有接收到客户端所发送的和重传报文，可能会一无所得由于没法看见重传报文。若是怀疑并非服务器端致使的报文丢失，能够考虑在客户端尝试抓取报 文，以查看实际是否有重传发生。

重复ACK

能够将重复ACK看做重传的“所谓相反面”，由于它是在服务器检测到客户端发送报文丢失的时候产生的。大多数状况下，在通信两端抓取流量时均可以看 到重复ACK。需记住当接收报文乱序时会触发重复ACK。例如，若是服务器之接收到发送的第一个和第三个报文，就会致使发送重复ACK引发客户端对第二个 报文的快速重传，由于你已经收到了第一个和第三个报文，所以无论致使第二个报文丢弃的缘由是什么，都颇有多是暂时的，所以大多数状况下重复ACK都会成 功发送和接收。固然，这种情形并不必定永远会发生，所以当你怀疑在服务器端丢失报文而又看不到任何重复ACK，考虑从通信的客户端抓取报文。

零窗口和探测报文

滑动窗口直接与服务器没法接收和处理报文有关，任何窗口大小的缩小以及零值都是服务器问题的直接结果。因此若是你在哪里看到这二者之一发生，就应该在那里深刻研究。一般应当在网络通信两端一直主机窗口更新报文。

 

一站式学习Wireshark（六）：狙击网络高延时点

2014/07/14 · IT技术 · WireShark

分享到： 15

• 与《YII框架》不得不说的故事—扩展篇
• sass进阶篇
• IOS基础教程之界面初体验
• Spring事务管理

原文出处： EMC中文支持论坛   欢迎分享原创到伯乐头条

在某些状况下，丢包可能并非形成延时的缘由。你可能会发现尽管两台主机之间通信速度很慢，但这种慢速并无伴随着TCP重传或是重复ACK的征兆。在这种状况下，须要使用另外一种方式来定位高延时点。

查找高延时点最有效的方法之一是检查最初的握手信号以及跟随其后的几个报文。例如，一个简单的客户端与网络服务器的链接，客户端尝试经过浏览器访问 网络服务器的站点。咱们只关心这一通讯序列的前六个报文，包括TCP握手过程，首次HTTP GET请求，对此GET请求的确认，以及从服务器发至客户端的第一个数据报文。

更多信息

正常通信:

在讨论高延时情况以前，找一个正常的通信做为参照。在第二节已经介绍过TCP握手过程以及HTTP通信，这里再也不赘述。在下面这张图里，咱们关心的部分只有Time列：

这一通信序列是很是快速的，整个过程耗时不到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 0.98秒以后才到达。报文5和6的传送过程与咱们在前一个场景所见ACK和GTE请求的传送相似。可是，在这一状况下，服务器是咱们关注的焦点。

报文5是服务器对从客户端接收GET请求的回应。只要该报文被发送，服务器就应当当即发送数据。这一读取，封装，传送的过程是由HTTP协议完成 的，因为这是应用层协议，须要服务器参与处理过程。这一报文的延迟接收代表服务器没法在合理的时间内处理数据，最终指向服务器是延时点。

延时定位思路：

经过六个报文，咱们可以定位服务器与客户端之间的网络高延时点。这些场景可能看起来有点复杂，可是下图能使你的定位延时过程变得简单快捷。这一原则几乎能应用于任何基于TCP的通信。

 

一站式学习Wireshark（七）：Statistics统计工具功能详解与应用

2014/07/14 · IT技术 · WireShark

分享到： 14

• jQuery源码解析（架构与依赖模块）
• Android高级特效-3D画廊
• 从D2到D2(大话游戏开发实战技巧)
• 与《YII框架》不得不说的故事—高效篇

原文出处： EMC中文支持论坛   欢迎分享原创到伯乐头条

Wireshark 一个强大的功能在于它的统计工具。使用Wireshark的时候，咱们有各类类型的工具可供选择，从简单的如显示终端节点和会话到复杂的如Flow和IO 图表。本文将介绍基本网络统计工具。包括：捕捉文件摘要（Summary）,捕捉包的层次结构（Protocol Hirarchy）, 会话（Conversations）, 终端节点（Endpoints）, HTTP。

更多信息

Summary:

从statistics菜单，选择Summary：

以下图的截屏所示，你会看到：

File：

捕捉文件的通常信息，如文件名和路径，长度，等等

Time：

第一个包和最后一个包的时间戳，以及抓包过程持续时间

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. 另外一方面，TCP占总数据的75.70%，在TCP协议以内，只有12.74%的报文是HTTP，除此以外没有其余统计。这是因为Wireshark只统计有HTTP头的报文。它不统计如确认报文或数据报文这样没有HTTP头的报文。

3. 为了使Wireshark同时统计数据报文，例如，TCP报文内部的HTTP报文，关闭Allow sub-dissector选项，对TCP数据流从新统计。可在Preferences菜单或Packet Details面板中右键TCP来实现。

Conversations：

1. 在Statistics菜单中，选择Coversations。

2. 会看到如下窗口：

3. 能够选择第2层以太网统计数据，第3层IP统计数据，或第4层TCP或UDP统计数据。

4. 能够选择如下统计工具：

• On layer 2(Ethernet)：查找并过滤广播风暴或
• On layer 3 or 4(TCP/IP)：经过互联网路由器端口并行链接，查看谁在向ISP传输数据

小贴士：

若是你看到互联网上某一IP地址经过端口80（HTTP）向外传输大量数据流，你就须要将该地址复制入浏览器而且查看你的用户与哪个网站通信最多。

若是没有获得结果，只需到标准DNS查询站点（Google一下DNS lookup）查看哪种流量占用了你的网线。

5. 也能够经过选择位于窗口左下方的Limit to display filter复选框，将会话统计信息进行显示过滤。这样，仅呈现全部经过显示过滤条件的统计数据。

6.要查看IP地址对应名称，能够选择Name resolution复选框。要查看IP名称解析，进入View | Name Resolution | Enable for Network layer进行激活。

7. 对于TCP或UDP，能够在Packet list中对指定报文进行标记，以后从菜单中选择Follow TCP Stream或Follow UDP Stream。从而定义一个显示过滤条件，仅显示指定数据流。

使用要点：

网络会话是两个指定终端之间的数据流。例如，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地址，192.168.110.58，发送ICMP报文至192.170.3.44, 192.170.3.45, 192.170.3.46, 192.170.3.47,等等（上图仅显示扫描的很小一部分）。这种状况下咱们有一个蠕虫病毒感染了网络上的全部PC，在它感染PC的时候，它就开始产 生ICMP请求并将它们发送至网络。这些窄带链接（例如：WAN链接）能够很容易地被封锁。

TCP/UDP会话统计

• 查看带有太多TCP链接的设备。每个PC合理的链接数是10到20个，上百个则是不正常的。
• 尝试查找没法辨识的端口号。它多是正常的，但也多是有问题的。下图显示了一次典型的TCP扫描：

Endpoints:

1. 从statistics菜单，选择Endpoints：

2. 出现如下窗口：

3. 此窗口中，可以看到第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, 192.168.30.0，以及其余网络地址。

HTTP:

1. 从statistics菜单，选择HTTP，将会出现如下窗口：

在HTTP子菜单中，能够看到如下信息：

Packet Counter：

每个网站的报文数量。帮助识别有多少响应和请求。

Requests：

各网站的请求分布。

Load Distribution：

各网站的负载分布。

按照如下操做步骤查看Packet Counter统计信息：

1. 进入Statistics | HTTP | Packet Counter。

2. 显示如下过滤窗口：

3. 此窗口中，可设置过滤条件以查看符合过滤条件的统计信息。若是想要查看整个抓包文件的统计信息，留白不填。这就会显示IP层之上的统计信息，也就是全部HTTP报文。

4. 点击Create Stat按钮，会看到如下窗口：

若是要查看某一特定节点的HTTP统计信息，能够经过display filter的方式配置过滤条件。

按照如下操做步骤查看HTTP Requests统计信息：

1. 进入Statistics | HTTP | Requests，出现如下窗口：

2. 选择所需过滤条件。对于全部数据，留白。

3. 点击Create Stat按钮，会出现如下窗口：

4. 要得到指定HTTP主机的统计信息，设置过滤条件http.host contains <host_name> 或 http.host==<host_name>。

5. 例如，经过设置过滤条件http.host contains ndi-com.com，能够得到站点 www.ndi-com.com的统计信息，以下图所示：

6. 结果以下图所示：

按照如下操做步骤查看Load Distribution统计信息：

1. 进入Statistics | HTTP | Load Distribution。

2. 出现如下窗口：

3. 选择所需过滤条件。对于全部数据，留白。

4. 点击Create Stat按钮，会出现如下窗口：

使用要点：

当咱们打开一个网页，一般会向若干个URL发送请求。本例中，咱们打开的其中一个网页是www.cnn.com，并将咱们导向edition.cnn.com。咱们发送了若干个请求：到root URL，到breaking_news URL，以及主页上两个其余位置。

 

一站式学习Wireshark（八）：应用Wireshark过滤条件抓取特定数据流

2014/07/22 · IT技术 · WireShark

分享到： 18

• Android-多平台分享
• C++远征之模板篇
• Sass入门篇
• PHP实现微信公众平台开发—提高篇

原文出处： EMC中文支持论坛   欢迎分享原创到伯乐头条

应用抓包过滤，选择Capture | Options，扩展窗口查看到Capture Filter栏。双击选定的接口，以下图所示，弹出Edit Interface Settints窗口。

下图显示了Edit Interface Settings窗口，这里能够设置抓包过滤条件。若是你确知抓包过 滤条件的语法，直接在Capture Filter区域输入。在输入错误时，Wireshark经过红色背景区域代表没法处理过滤条件。最有可能的状况是，过滤条件中含有输入错误，或是使用了 display filter的语法。

点击Capture Filter按钮查看并选择已保存的抓包过滤条件。

更多信息

抓取指定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)格式或使用mask参数。

• 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 <protocol code>：抓取ip协议字段等于<protocol code>值的报文。如TCP(code 6), UDP(code 17), ICMP(code 1)。
• ip[2:2]==<number>：ip报文大小
• ip[8]==<number>：TTL(Time to Live)值
• ip[9]==<number>：协议值
• icmp[icmptype]==<identifier>: 抓取 ICMP代码等于identifier的ICMP报文, 如icmp-echo 以及 icmp-request。

方括号中第一个数字表示从协议头开始的偏移量，第二个数字表示须要观察多少位。

抓取发到广播或多播地址的数据流:

只需侦听广播或多播数据流，就能够掌握网络上主机的许多信息。

• ip broadcast：抓取广播报文
• ip multicast：抓取多播报文
• dst host ff02::1：抓取到IPv6多播地址全部主机的数据流
• dst host ff02::2：抓取到IPv6多播地址全部路由器的数据流

小贴士：

Wireshark包含了一些默认的抓包过滤条件。点击主工具栏的Edit Capture Filters，跳转到已保存抓包过滤列表。你会发现一些常见抓包过滤的示例。

抓取基于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 number>
• 抓取指定几个VLAN：vlan <vlan number> and vlan <vlan number>

抓取基于指定应用的数据流:

你可能须要查看基于一个或几个应用的数据流。抓包过滤器语法没法识别应用名，所以须要根据端口号来定义应用。经过目标应用的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 <length>：抓取小于等于某一长度的报文，等同于len <=<length>
• greater <length>：抓取大于等于某一长度的报文，等同于len >=<length>

SYN: 简历链接的信号

FIN: 关闭链接的信号

ACK: 确认接收数据的信号

RST: 当即关闭链接的信号

PSH: 推信号，尽快将数据转由应用处理

• tcp[13] & 0×00 = 0: No flags set (null 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/tools/string-cf.html)。例如，想要抓取HTTP GET报文，输入GET并将TCP偏移量设置为0。