扫一扫
关注公众号
有一天收到TCP重传严重告警。我们知道,主机报文重传是TCP最基本的错误恢复功能,它的目的是防止报文丢失
报文丢失的可能因素有很多种
先抓包生成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 backlog积压数值,这里显示为0,实际上会取内核参数net.core.somaxconn的值
非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%,于是去找网络组的同事检查
其实我们还可以使用tshrak进行分析重传情况,它是Wiresherk的命令行增强版本。示例如下:
指令:tshark -i any -s 60 -n -R “tcp.analysis.retransmission” -T fields -e frame.time_epoch -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport -e tcp.analysis.retransmission -a duration:3
–
指令说明: i 指定网口,-s指定抓取60字节(以太网首部+ip首部+tcp首部),-n不解析端口协议,-R 指定抓取数据过滤规则(-G 参数可以详细查看可抓取的每个参数),-T指定输出格式,-e 指定输出字段,-a指定终止时间为3秒
1、Statistics->Conversations会话统计功能,统计通信会话之间接收和发送的数据包和字节数,通过这个工具可以找出网络中哪个会话(IP地址或端口号)最占用带宽,进一步作出网络策略
2、Statistics–>Flow graph会话通信过程图形可视化,还可以看到是否有TCP的延迟包括延迟确认(Delayed ACK),服务端是否开启Nagle算法