性能指标之资源指标-网络IO--初步诊断-trace查看

如果从应用层面或者ping等手段定位到网络有延时、抖动、丢包、中断等异常情况时，需要进行深入的诊断分析。

此时最好的方法是采用专业的网络抓包设备进行网络包捕获，并采用该厂商相应的工具进行分析诊断。不但不影响服务器本身的性能，并且可以比较快速地得出一些诊断结论。目前市场上这方面的厂商和工具也比较多。

然而本节将介绍另一种初步分析问题的手段-iptrace。通过在业务系统上监控iptrace日志，之后通过wireshark工具进行分析，即可对问题有个大致的判断。

1、iptrace抓取

举例说明

开启监控：startsrc -s iptrace "-a -s 目标机IP -b -S 1500 -L 1073741824 /var/trace/iptrace.out"

该命令的含义是：iptrace记录本机与目标机双向传输的信息，抓取的数据包最大限制为1500字节，日志记录最大为1073741824字节（1G大小）。

关闭监控：stopsrc -s iptrace

2、Wireshark简介

Wireshark是windows平台用于查看网口数据包的工具。核心功能是快速筛选自己需要的信息然后快速定位问题。使用Wireshark打开iptrace.out文件如下图：





No --- 截获的网络包序号

Time --- 时间

Source --- 数据源IP

Destination --- 目标IP

Length --- 消息包总字节长度

Protocol --- 消息包协议类型

Info --- 消息包相关基本信息

以下是对应的OSI七层模型




Frame：物理层的数据帧概况

Ethernet II：数据链路层以太网帧头部信息

Internet Protocol Version 4：互联网层IP包头部信息

Transmission Control Protocol：传输层TCP的数据段头部信息

WebSphere MQ：应用层的信息，此处是MQ

常用筛选命令

可以按照需求筛选显示网络包列表，常用筛选条件如下：

1 按消息包长度筛选frame.len== （Length的值）

2 按数据源ip 筛选 ip.src eq 10.x.x.x

3 同时筛选源IP 以及协议类型ip.src eq 10.x.x.x && mq

4 按需求的协议类型筛选 mq && tcp

3、分析实例

打开iptrace文件后，首先查看右侧标黑色的部分，这是wireshark认为有问题的网络传输。




以作者实践当中的一个例子，系统环境当中网络延时非常不稳定，抓取iptrace用wireshark打开之后，发现大量的黑色条带，几乎找不到不出错的时间段。

这其中的问题五花八门，例如有：

1. 大量的tcp keep-alive ack/ tcp keep-alive

2. 大量下一个回复包的SEQ值不等于ACK

3. RST ACK

4. 大量Retransmission

5. Previous segment uncaptured

6. ACKed Unseen segment

7. 大量Dup ack

8. Destination unreachable

在几分钟的trace当中竟然有这么多问题，也是醉了。

3.1 大量的tcp keep-alive / tcp keep-alive ack

几乎10个数据包里面就有2个tcp keep-alive / tcp keep-alive ack的数据包，大量占用网络带宽




首先，服务器的keep alive相关参数设置略有问题

no -a| grep tcp

tcp_keepcnt = 8

tcp_keepidle = 20

tcp_keepinit = 50

tcp_keepintvl = 2

这些参数的含义是：如果tcp连接有10秒钟空闲，没有报文传输（tcp_keepidle = 20，单位是0.5秒），那么开始发送探测（tcp alive），如果探测不成功，则后续每1秒发送一次 （tcp_keepintvl = 2），如果连续发送8次，对方没反应，把这个tcp连接关了。

这个探测比默认值来讲的确有些频繁，但试想，如果探测一次成功了的话，后续就不需要探测了。为什么有这么多的探测呢？

3.2 大量下一个回复包的SEQ值不等于ACK

正常情况下回复的seq数值=等于上一条请求的ACK数值，而trace中看到几乎所有keep alive的确认包（ACK）中的SEQ值=keep alive发起方的ACK+1。即每次探测后，对方的回复都不是期望的结果，因此后续不停的继续探测，导致了大量的keep alive包。

Seq和Ack两个字段是TCP可靠传输服务的关键部分，Seq是网络包序列号(TCP把数据看成是有序的字节流，TCP隐式地对数据流的每个字节进行编号)。Ack是期望得到的下一个回复包的序列号（即Seq值）。

3.3 RST ACK

RST可能是B发的太多，A告诉B 不要发包，直到A再次通知B可以发包。 或者是A关闭异常连接，清空缓存。

由于只发现一条RST ACK，因此并未深入分析。

3.4 大量Retransmission重传

重传意味着网络质量不佳，可能的原因有拥堵、目标机回复延迟、网络设备丢包、网线质量不佳、接口松动、电磁干扰等。

3.5 Previous segment uncaptured

先前片段未能捕获，当前收到报文的序列号值高于该连接的下一个期望序列号值时，表明之前的一个或多个网络包未捕获到。Previous segment uncaptured在正常通讯过程中也经常出现，且出现次数不多，因此并未深入分析。

3.6 ACKed Unseen segment

Tcp ACKed unseen segment 网络包回复的先前片段未截获到，与Tcp Previoud segment not captured先前片段未能捕获，问题相似。由于Previous segment uncaptured在正常通讯过程中也经常出现，且出现次数不多，因此并未深入分析。

3.7 大量Dup ack

Dup ACK是没有收到对方的应答（ACK），需要对方重复应答，3次以上的Dup ACK会造成重传和传输降速。后分析发现，系统环境中对方服务器发送出来的数据包在核心交换大机侧的接口处就有大量乱序。

3.8 Destination unreachable

目标不可达。由于只出现一次这个报错，因此并未深入分析

综上，从iptrace的结果中可以看到表现出来的问题很多，但经过初步分析，主要问题归结起来是1）对端回复的TCP包的SEQ值不是预期值，2）网络质量不佳。下一步就需要研究出问题的对端节点以及采用网络抓包设备判断哪一段网络质量不佳。