1. 前言
emmm，说起网络知识学习肯定离不来wireshark工具，这个工具能够帮助我们快速地定位网络问题以及帮助正在学习网络协议这块的知识的同学验证理论与实际的一大利器，平时更多的只是停留在初步的使用阶段。也是利用部门内部的网络兴趣小组的讨论机会，私下对wireshark的一些进阶功能，比如专家模式、图表等功能进行调研，并结合实际场景抓包分析对功能进行对照说明。
2. wireshark中的分析菜单——专家模式
2.1什么是专家模式？
2.2 严重性级别的每种分类分别代表什么含义？
◦对话（Chat）：关于正常通信的基本信息；
◦注意（Note）：正常通信时的异常数据包；
◦警告（Warn）：不是正常通信中的异常数据包（个人理解为：非正常的通信产生的数据包）；
◦错误（Error）：数据包中的错误，或者解析器解析时的错误；
2.3 除了严重性级别之外，专家信息项还按组进行了分类：
◦假设(Assumption)：协议字段的数据不完整，根据假定值进行了剖析
◦检验和(Checksum)：校验和无效
◦注释(Comment)：数据包注释
◦调试(Debug)：调试信息，你不应该在wireshark的发布版本中看到这个组
◦解密(Decryption)：解密问题
◦已弃用(Deprecated)：协议字段已经被弃用
◦畸形的(Malformed)：格式错误的数据包或者解析程序有错误。此数据报的解析已中止
◦协议(Protocol)：违反协议规范(比如无效字段值或者非法长度)。可能会继续对该数据包进行解析
◦重新组装()：重新组装时出现问题。比如，不是所有的碎片都可用，或者在重新组装期间发生异常
◦请求代码(Request Code)：一个应用程序请求。通常分配聊天级别。
◦响应代码(Response Code)：应用程序响应代码表示潜在问题，比如找不到HTTP 404
◦安全(Security)：安全问题，比如不安全的实现
◦序列(Sequence)：协议序列号可疑，比如它不连续或者检测到重传
◦未编码(Undecoded)：解析不完整或者数据因为其他问题无法解码
2.4 TCP的14种专家模式？
◦对话消息（Chat）：
窗口更新（window update）_：_由接收者发送，用来通知发送者TCP接收窗口的大小已经发生变化。
◦注意消息（Note）：
▪ 重复ACK（Duplicate ACK ）_：_当一台主机没有收到下一个期望序列号的数据包时，会生成最近一次收到的数据的重复ACK。
▪TCP重传（retransmission）_：_数据包丢失的结果。发生在收到重传的ACK, 或者数据包的重传计时器超时的时候。
▪零窗口探查_：_在一个零窗口包被发送出去后，用来监视TCP接收窗口的状态。
▪零窗口探查ACK：用来响应零窗口探查数据包。
▪保活（TCP Keep-Alive Segment）：当一个连接的保活数据出现时触发。
▪保活ACK(ACK to Tcp keep-alive)：用来响应保活数据包。
▪窗口已满：用来通知传输主机接受者的TCP窗口已满。
•警告信息(Warn):
◦上一段丢失(Previous segments not captured)：指明数据包丢失。发生在当数据流中一个期望序列号被跳过时。
◦收到丢失数据包的ACK(ACKed segment that was not captured)：发生在当一个数据包被确认丢失但在之后收到了这个已经被确认丢失的数据包的ACK数据包。
◦零窗口(TCP Zero Window)：当接收方已经达到TCP接收窗口大小时，发出一个零窗口通知，要求发送方停止传输数据。可能是网络拥塞或接收方未及时处理数据等原因导致的。
◦乱序：当数据包被乱序接收时，会利用序列号进行检测。
◦快速重传输：一次重传会在收到一个重复ACK的20毫秒内进行。
3. 统计菜单——IO图表、数据流图
3.1 IO图表的用途？
3.2 一些常用的排错过滤条件？
对于排查网络延时/应用问题有一些过滤条件是非常有用的，下面罗列了一些常用的过滤条件：
◦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。如果这一时间间隔比较长那可能表示某种类型的网络延时（报文丢失，拥塞，等等）。
3.3 IO图表中的一些常用的函数？
◦MIN（）, AVG（）, MAX（）
MIN、AVG、MAX分别表示帧/报文之间的最小、平均、最大时间，对于查看帧/报文之间的延时非常有用。
从上图可见，在第106秒时数据流的MAX frame.delta_time达到0.7秒，这是一个严重延时并且导致了报文丢失。
◦Count（）
此函数计算时间间隔内事件发生的次数，在查看TCP分析标识符时很有用，例如重传。
◦Sum（）
该函数统计事件的累加值。有两种常见的用例是看在捕获TCP数据量，以及检查TCP序列号。
参数设置：分别使用客户端IP 192.168.1.4为源、目的地址，并将SUM功能结合tcp.len过滤条件；
从图表中我们可以看到，发送到客户端的数据量（IP.DST = = 192.168.1.4过滤条件）比来自客户端的数据量要高。在图中红色表示。黑条显示从客户端到服务器的数据，相对数据量很小。这是有道理的，因为客户只是请求文件和收到之后发送确认数据，而服务器发送大文件。很重要的一点是，如果你交换了图的顺序，把客户端的IP作为图1的目标地址，并且客户端IP作为图2的源地址，采用了FBAR的时候可能看不到正确的数据显示。因为图编号越低表示在前台显示，可能会覆盖较高图号。
4. 实例场景分析
参数设置：1是HTTP总体流量，显示形式为packets/tick，时间间隔1秒。图2是TCP丢失报文片段。图3是TCP 重复ACK。图4是TCP重传。
图1：HTTP总体流量图
图2：TCP丢失报文片段图
图3：TCP 重复ACK
从这张图可以看到：整体的HTTP流量，TCP重传以及重复ACK的流量，这些事件发生的时间点，以及在整体流量中所占的比例。
•数据包丢失和延迟的TCP序列号场景：我们可以在下面的图中看到若干峰值和下降，表示TCP传输有问题。
图4：数据包丢失和延迟的TCP序列号场景
这张图可以看到TCP序列号相当稳定地增加，表示传输平稳，没有过多重传或丢包。
•对比视频会议在网络卡顿与流畅时的IO图表实例场景：
5. 总结
如果只是简单的排查网络问题，只需要使用wireshark中简单的添加过滤规则，通过观察抓取到的数据包就可以达到定位问题的目的，其实这几个进阶的功能，无论是专家模式、还是IO图表，底层其实还是需要配置规则，亦或者是通过wireshark的内置规则做了一个集成。针对一些场景，比如观测网络是否拥塞，可以通过IO图表直观的进行判断,以上。
