谈谈Linux中的TCP重传抓包分析

文章来源：www.liangsonghua.me
做者介绍：京东资深工程师-梁松华，长期关注稳定性保障、敏捷开发、JAVA高级、微服务架构

收到研发反馈，TCP重传严重。主机报文重传是TCP最基本的错误恢复功能，它的目的是防止报文丢失

报文丢失的可能因素有不少种

一、 网络设备或线路故障
案例：设备接口经常出现的CRC数据校验错误
特色：问题一直持续，全部通过该节点的数据都受影响，影响服务器数量大
二、 数据路径上的流量突发致使链路拥塞
案例：专线打满致使丢包严重
特色：突发性极强，持续时间短。更多时候有周期性。全部通过该节点的数据都受影响，影响服务器数量大
三、 客户端服务器故障
案例：某服务器网卡故障，或者性能降低
特色：故障长时间持续，仅仅影响单台设备
四、 服务器端服务器故障
案例：某服务器网卡故障
特色：故障长时间持续，全部请求到该节点的数据都受影响，影响服务器数量大
五、 服务器端性能降低
案例：有运营活动的时候服务端请求量太大，致使性能降低
特色：突发，若是服务端有巨量请求会有周期性，全部请求到这台设备(集群)的数据都有可能受影响，影响服务器数量大
六、 代理节点或者VIP性能降低
案例：某一负载均衡集群故障或性能降低
特色：突发，有周期性。全部请求到该节点的数据都受影响，影响服务器数量大
先抓包生成pcap文件，tcpdump -i nsdb475e5d-86 -vvv -w tcp_retry.pcap，保留证据要紧，同时留意值班群和网络应急响应群是否有相同的反馈，若是有其余人反馈，及时确认受影响范围，服务器是否有一些共性，好比集中在某个数据中心上、某个POD下、某台物理机上

使用如下命令实时能够观察系统中每秒tcp重传报文数量，线上监控工具推荐使用阿里出品的tsar-Taobao System Activity Reporter

nstat -z -t 1 | grep -e TcpExtTCPSynRetrans -e TcpRetransSegs -e TcpOutSegs -e TcpInSegs

使用netstat -s查看总体状况，按各个协议进行统计结果以下

ss -anti |grep -B 1 retrans查看重传统计状况，具体到IP+端口，这里方便显示使用ss -tanl演示

一、 LISTEN 状态：
这两个值表示的是最大的listen backlog积压数值，这里显示为0，实际上会取内核参数net.core.somaxconn的值

二、 其余状态：
(1)、 recv-Q:表示网络接收队列，表示收到的数据已经在本地接收缓冲，可是还有多少没有被进程取走，若是短暂不为0，多是处于半链接状态，若是接收队列Recv-Q一直处于阻塞状态，多是遭受了拒绝服务 denial-of-service 攻击
(2)、send-Q:表示网路发送队列，对方没有收到的数据或者说没有Ack的,仍是在本地缓冲区.若是发送队列Send-Q不能很快的清零，多是有应用向外发送数据包过快，或者是对方接收数据包不够快
非LISTEN状态下则一般应该为0，若是不为0多是有问题的，packets在两个队列里都不该该有堆积状态，可接受短暂的非0状况

ulimit -a检查服务打开的文件句柄上限,10多万正常是足够的

经过ifconfig查看网卡是否存在持续drop、error现象

容器状态正常，开始使用wiresherk分析抓包文件

查看IO graph，确保链路不忙，不忙的链路IO会有不少高低起落，峰值以及空闲间隙

进入Analyze–>Expert Info 查看不一样标签下不一样级别的提示信息，好比重传的统计、链接的创建和重置统计

过滤重传，发现集中在22000和22001这两个内网服务框架JSF的通讯端口上

猜想是上游某个接口的服务异常或者通讯异常，点击某个note查看详情，或者回到控制面板，输入tcp.analysis.retransmission过滤再点击查看详情

大部分是DATA数据传输时发生了重传，PSH ACK报文表示开始向服务端发送数据

能够看到有不少上游接口和不一样的依赖类型(好比JMQ)都有重传，说明不是某个接口的问题，应该是网络问题。使用mtr(集成了traceroute、ping、nslookup的功能)来检查下路径上的互联地址延迟和丢包状况，发现中间某一跳丢包率为16.7%，因而去找网络组的同事检查

补充1、Wiresherk经常使用操做
一、Statistics->Conversations会话统计功能，统计通讯会话之间接收和发送的数据包和字节数，经过这个工具能够找出网络中哪一个会话（IP地址或端口号）最占用带宽，进一步做出网络策略

二、Statistics–>Flow graph会话通讯过程图形可视化，还能够看到是否有TCP的延迟包括延迟确认(Delayed ACK),服务端是否开启Nagle算法

补充2、Wiresherk的info常见提示
一、Packet size limited during capture

说明被标记的那个包没有抓全。通常是由抓包方式引发，有些操做系统中默认只抓每一个帧的前96个字节
二、TCP Previous segment not captured

若是Wireshark发现后一个包的Seq大于Seq+Len，就知道中间缺失了一段，若是缺失的那段在整个网络包中找不到（排除了乱序），就会提示
三、TCP ACKed unseen segment

当Wireshark发现被Ack的那个包没被抓到，就会提示
四、TCP Out-of-Order

当Wireshark发现后一个包的Seq号小于前一个包的Seq+Len时，就会认为乱序，发出提示
五、TCP Dup ACK

当乱序或丢包发生时，接收方会收到一些Seq号比指望值大的包。没收到一个这种包就会Ack一次指望的Seq值，提现发送方
六、TCP Fast Retransmission

当发送方收到3个或以上的【TCP Dup ACK】，就意识到以前发的包可能丢了，因而快速重传它
七、TCP Retransmission

若是一个包真的丢了，又没有后续包能够在接收方触发【Dup Ack】就不会快速重传，这种状况下发送方只好等到超时了再重传
八、TCP zerowindow

包种的“win”表明接收窗口的大小，当Wireshark在一个包中发现“win=0”时，就会发提示
九、TCP window Full

此提示表示这个包的发送方已经把对方所声明的接收窗口耗尽了
十、Time-to-live exceeded（Fragment reassembly time exceeded）

文章来源：www.liangsonghua.me做者介绍：京东资深工程师-梁松华，长期关注稳定性保障、敏捷开发、JAVA高级、微服务架构