文章来源：www.liangsonghua.me
作者介绍：京东资深工程师 - 梁松华，长期关注稳定性保障、敏捷开发、JAVA 高级、微服务架构
收到研发反馈，TCP 重传严重。主机报文重传是 TCP 最基本的错误恢复功能，它的目的是防止报文丢失
报文丢失的可能因素有很多种
1、网络设备或线路故障
案例：设备接口常常出现的 CRC 数据校验错误
特点：问题一直持续，所有经过该节点的数据都受影响，影响服务器数量大
2、数据路径上的流量突发导致链路拥塞
案例：专线打满导致丢包严重
特点：突发性极强，持续时间短。更多时候有周期性。所有经过该节点的数据都受影响，影响服务器数量大
3、客户端服务器故障
案例：某服务器网卡故障，或者性能下降
特点：故障长时间持续，仅仅影响单台设备
4、服务器端服务器故障
案例：某服务器网卡故障
特点：故障长时间持续，所有请求到该节点的数据都受影响，影响服务器数量大
5、服务器端性能下降
案例：有运营活动的时候服务端请求量太大，导致性能下降
特点：突发，如果服务端有巨量请求会有周期性，所有请求到这台设备 (集群) 的数据都有可能受影响，影响服务器数量大
6、代理节点或者 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 演示
1、LISTEN 状态：
这两个值表示的是最大的 listen backlog 积压数值，这里显示为 0，实际上会取内核参数 net.core.somaxconn 的值
2、其他状态：
(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%，于是去找网络组的同事检查
补充一、Wiresherk 常用操作
1、Statistics->Conversations 会话统计功能，统计通信会话之间接收和发送的数据包和字节数，通过这个工具可以找出网络中哪个会话（IP 地址或端口号）最占用带宽，进一步作出网络策略
2、Statistics–>Flow graph 会话通信过程图形可视化，还可以看到是否有 TCP 的延迟包括延迟确认(Delayed ACK), 服务端是否开启 Nagle 算法
补充二、Wiresherk 的 info 常见提示
1、Packet size limited during capture
说明被标记的那个包没有抓全。一般是由抓包方式引起，有些操作系统中默认只抓每个帧的前 96 个字节
2、TCP Previous segment not captured
如果 Wireshark 发现后一个包的 Seq 大于 Seq+Len，就知道中间缺失了一段，如果缺失的那段在整个网络包中找不到（排除了乱序），就会提示
3、TCP ACKed unseen segment
当 Wireshark 发现被 Ack 的那个包没被抓到，就会提示
4、TCP Out-of-Order
当 Wireshark 发现后一个包的 Seq 号小于前一个包的 Seq+Len 时，就会认为乱序，发出提示
5、TCP Dup ACK
当乱序或丢包发生时，接收方会收到一些 Seq 号比期望值大的包。没收到一个这种包就会 Ack 一次期望的 Seq 值，提现发送方
6、TCP Fast Retransmission
当发送方收到 3 个或以上的【TCP Dup ACK】，就意识到之前发的包可能丢了，于是快速重传它
7、TCP Retransmission
如果一个包真的丢了，又没有后续包可以在接收方触发【Dup Ack】就不会快速重传，这种情况下发送方只好等到超时了再重传
8、TCP zerowindow
包种的“win”代表接收窗口的大小，当 Wireshark 在一个包中发现“win=0”时，就会发提示
9、TCP window Full
此提示表示这个包的发送方已经把对方所声明的接收窗口耗尽了
10、Time-to-live exceeded（Fragment reassembly time exceeded）
文章来源：www.liangsonghua.me
作者介绍：京东资深工程师 - 梁松华，长期关注稳定性保障、敏捷开发、JAVA 高级、微服务架构