emmm，说起网络知识学习肯定离不来 wireshark 工具，这个工具能够帮助我们快速地定位网络问题以及帮助正在学习网络协议这块的知识的同学验证理论与实际的一大利器，平时更多的只是停留在初步的使用阶段。也是利用部门内部的网络兴趣小组的讨论机会，私下对 wireshark 的一些进阶功能，比如专家模式、图表等功能进行调研，并结合实际场景抓包分析对功能进行对照说明。
Wireshark 的专家信息是非常强大的一个分析模块，分别对错误、警告、注意、对话等数据信息做出分类和注释，对网络故障分析提供了强有力的信息依据，让你准确快速地判断出故障点，并进行下一步处理。
◦对话（Chat）：关于正常通信的基本信息；
◦注意（Note）：正常通信时的异常数据包；
◦警告（Warn）：不是正常通信中的异常数据包（个人理解为：非正常的通信产生的数据包）；
◦错误（Error）：数据包中的错误，或者解析器解析时的错误；
◦假设(Assumption)：协议字段的数据不完整，根据假定值进行了剖析
◦检验和(Checksum)：校验和无效
◦注释(Comment)：数据包注释
◦调试(Debug)：调试信息，你不应该在 wireshark 的发布版本中看到这个组
◦解密(Decryption)：解密问题
◦已弃用(Deprecated)：协议字段已经被弃用
◦畸形的(Malformed)：格式错误的数据包或者解析程序有错误。此数据报的解析已中止
◦协议(Protocol)：违反协议规范 (比如无效字段值或者非法长度)。可能会继续对该数据包进行解析
◦重新组装()：重新组装时出现问题。比如，不是所有的碎片都可用，或者在重新组装期间发生异常
◦请求代码(Request Code)：一个应用程序请求。通常分配聊天级别。
◦响应代码(Response Code)：应用程序响应代码表示潜在问题，比如找不到 HTTP 404
◦安全(Security)：安全问题，比如不安全的实现
◦序列(Sequence)：协议序列号可疑，比如它不连续或者检测到重传
◦未编码(Undecoded)：解析不完整或者数据因为其他问题无法解码
◦对话消息（Chat）：
窗口更新（window update）：由接收者发送，用来通知发送者TCP*接收* 窗口的大小已经发生变化。
◦注意消息（Note）：
▪ 重复 ACK（Duplicate ACK ）：当一台主机没有收到下一个期望序列号的数据包时，会生成最近一次收到的数据的重复 ACK。
注意：其实重复确认本身并不是问题，但如果接收方连续发送多个重复确认，则可以视为网络拥塞的信号。TCP 协议中定义了一种拥塞控制机制，在发现网络拥塞时会触发这个机制，以减缓数据传输的速度，从而避免拥塞的加剧。 快速重传：当TCP 接收方连续发送三个重复确认时，发送方就会认为一个数据包已经丢失，并立即进行快速重传（Fast Retransmit）操作。它会重新发送那个没有收到确认的数据包，而不是等待超时时间后再重传。这样做可以尽快地填补丢失的数据包，提高数据传输速度和效率。
▪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 毫秒内进行。
Wireshark IO Graph 能把原始数据过滤并把数据以图表的形式展示出来，是一个非常好用的工具。 基本的 Wireshark IO Graph 会显示抓包文件中的整体流量情况。X 轴为时间，Y 轴是每一时间间隔的报文数。默认情况下，X 轴时间单位为 1s，Y 轴是 Packet/tick，可以自己调节单位。通过调节单位，对于查看流量中的波峰／波谷很有帮助。
对于排查网络延时/应用问题有一些过滤条件是非常有用的，下面罗列了一些常用的过滤条件：
◦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。如果这一时间间隔比较长那可能表示某种类型的网络延时（报文丢失，拥塞，等等）。
IO Graphs 有六个可用函数：SUM, MIN, AVG, MAX, COUNT, LOAD。
◦MIN（）, AVG（）, MAX（）
MIN、AVG、MAX 分别表示帧/报文之间的最小、平均、最大时间，对于查看帧/报文之间的延时非常有用。
我们可以将这些函数结合 “frame.time_delta” 过滤条件看清楚帧延时，并使得往返延时更为明显。如果抓包文件中包含不同主机之间的多个会话，而只想知道其中一个 pair，可将 “frame.time_delta” 结合源和目标主机条件如 “ip.addr==x.x.x.x &&ip.addr==y.y.y.y”。
从上图可见，在第 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 的时候可能看不到正确的数据显示。因为图编号越低表示在前台显示，可能会覆盖较高图号。
参数设置：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 报文比较：
这张图可以看到 TCP 序列号相当稳定地增加，表示传输平稳，没有过多重传或丢包。
•对比视频会议在网络卡顿与流畅时的 IO 图表实例场景：
如果只是简单的排查网络问题，只需要使用 wireshark 中简单的添加过滤规则，通过观察抓取到的数据包就可以达到定位问题的目的，其实这几个进阶的功能，无论是专家模式、还是 IO 图表，底层其实还是需要配置规则，亦或者是通过 wireshark 的内置规则做了一个集成。针对一些场景，比如观测网络是否拥塞，可以通过 IO 图表直观的进行判断,,,,,以上。
作者：京东科技 宋慧超
来源：京东云开发者社区 转载请注明来源
