TCP重传报文：正常范围判断及非抓包工具排查方法

一、TCP重传报文的正常数值范围 #

没有绝对固定的正常数值，核心要看重传率（重传报文数/总发送报文数），而非单一的重传数量：

• 低流量服务器（重启数小时内发送报文数几万级）：重传数0-50、重传率低于0.1%都属于正常范畴；
• 高流量服务器（发送报文数十万甚至百万级）：重传率控制在0.1%以内都没问题，哪怕重传数几百，只要比例达标就无需担心。
  比如你当前的30个重传，需要结合netstat -s -t里的segments sent out数值计算比例——如果总发送量是10万，30个的重传率仅0.03%，完全正常；如果总发送量才几百，那这个比例就偏高了。

二、无需Wireshark时的快速排查方法 #

• 先算重传率：执行netstat -s -t，找到segments sent out（总发送报文数）和segments retransmitted（重传数），计算比例。只有当比例超过0.5%时，才需要重点排查。
• 排查链路丢包：
  • 用ping -c 100 <目标IP>测试网关、上游节点或常用外部节点的丢包情况，看输出的丢包率；
  • 用mtr <目标IP>持续跟踪链路各节点的丢包，快速定位是本地网络、运营商链路还是目标端的问题。
• 检查TCP内核参数：
  • 执行sysctl -a | grep tcp，重点看tcp_retries2（默认15，对应约13分钟重传超时）、tcp_syn_retries等重传相关参数，若参数被异常修改，可能导致不必要的重传。
• 查看服务器硬件/负载状态：
  • 用top或uptime看CPU、内存负载，若负载过高，内核可能来不及处理TCP报文引发丢包重传；
  • 执行netstat -i查看网卡统计，若rx_errors、tx_errors、dropped数值持续增长，说明网卡硬件或驱动存在问题。
• 定位应用层问题：
  • 查看业务应用日志（如Web服务、数据库日志），看是否存在连接超时、处理阻塞的情况，应用层卡顿会导致TCP ACK迟迟无法返回，触发重传；
  • 用ss -t state retrans查看当前处于重传状态的连接，通过目标IP、端口定位对应的业务服务，针对性排查。

内容的提问来源于stack exchange，提问作者binaryanomaly