1. 项目概述为什么TCP重传率是系统健康的“晴雨表”在分布式系统、微服务架构和云原生应用大行其道的今天网络通信的稳定性直接决定了服务的SLA服务等级协议。我们常常会监控CPU、内存、磁盘I/O但网络层面的指标尤其是TCP层的表现却容易被忽视。而TCP重传率正是衡量网络通信质量最核心、最直接的指标之一。它不像丢包率那样受制于底层硬件或驱动统计的准确性也不像RTT往返时延那样容易受到路径上突发流量的干扰。重传率是TCP协议栈自身行为的一个真实反馈当网络出现丢包、拥塞、乱序或接收端处理不及时时发送方就会触发重传。因此一个持续偏高的重传率就像系统持续低烧预示着网络链路或对端服务存在潜在问题。我处理过不少线上故障表象是应用接口超时、服务调用失败但根因追溯下去往往是某条链路的TCP重传率悄然攀升到了1%甚至更高。对于追求低延迟、高可用的金融服务或实时通信场景0.1%的重传率可能就已经是不可接受的噪音了。所以学会计算和监控TCP重传率不是一项可选的技能而是每一位后端工程师、SRE站点可靠性工程师乃至全栈开发者都应该掌握的“内功”。这能帮助你在用户投诉之前提前发现并定位网络层面的退化从被动救火转向主动防御。2. 核心原理TCP重传是如何发生的要计算和监控首先得理解重传触发的机制。TCP是一个可靠的、面向连接的协议其可靠性正是通过确认ACK和重传机制来保证的。重传并非单一原因导致而是多种网络异常状况下的共同结果。2.1 重传的主要触发场景超时重传Retransmission Timeout, RTO这是最经典的重传机制。发送方每发送一个数据段都会启动一个重传定时器。如果在RTO时间内没有收到该数据段的确认ACK发送方就认为该数据包已丢失会立即重传。RTO的值是动态计算的基于对RTT的持续测量其算法如标准RFC 6298旨在适应网络延迟的变化。当网络突然变差实际RTT超过当前RTO估值时就会触发超时重传。快速重传Fast Retransmit这是为了优化超时重传效率低下的问题。当接收方收到一个失序的数据段时例如收到了Seq100-199 紧接着收到了Seq300-399它会立即重复发送对最后一个按序到达数据的ACK即对Seq199的ACK。当发送方连续收到3个相同的重复ACKDup-ACK时它就“有理由相信”该ACK之后的数据段Seq200-299已经丢失无需等待超时立即重传该数据段。快速重传能显著降低丢包恢复的延迟。选择性确认SACK触发的重传在启用SACK选项后接收方可以在ACK中明确告知发送方哪些数据块已经收到哪些中间的数据块缺失。发送方可以根据SACK信息精确地只重传丢失的数据段而不是重传整个窗口的数据效率更高。早期重传Early Retransmit在某些情况下例如当发送窗口很小无法产生足够多的数据包来触发三个Dup-ACK时标准快速重传会失效。早期重传机制允许在收到较少数量的Dup-ACK例如2个且满足一定条件时就触发重传适用于低流量连接。2.2 影响重传率的网络因素理解触发机制后我们就能分析哪些情况会导致重传率升高网络拥塞路由器缓冲区满导致数据包被丢弃。这是生产环境中最常见的原因。链路质量差无线网络、跨洲际光纤等场景下比特错误可能导致数据包损坏而被丢弃。接收方处理能力不足接收方应用处理过慢导致TCP接收缓冲区满进而通过零窗口通告或丢包来反压发送方间接引发重传。网络路径变化或路由抖动可能导致数据包乱序虽然乱序本身不直接导致重传但可能触发不必要的快速重传如果乱序被误判为丢包。系统资源瓶颈发送方或接收方主机CPU、内存紧张导致协议栈处理不及时定时器异常等。注意并非所有重传都意味着“坏事情”。在一个动态变化的网络中极低比例的重传如低于0.01%是TCP协议正常工作的体现是它保证可靠性的代价。我们监控的目标是识别出异常升高的、持续的重传。3. 计算方法从内核统计到业务指标计算重传率核心是获取两个关键计数器重传的数据段总数和发送的数据段总数。公式很简单重传率 (重传的报文段数 / 发送的报文段总数) * 100%。难点在于如何准确、高效地获取这些数据。3.1 操作系统级统计netstat与/proc/net/snmp这是最基础、最通用的方法适用于所有Linux/Unix系统。1. 使用netstat -s命令运行netstat -s -t可以输出TCP协议的详细统计信息。你需要关注以下两行具体标签可能因系统略有差异TCP: ... segments sent out: 2500000 # 发送的总报文段数含重传 segments retransmitted: 12500 # 重传的报文段数 ...计算某一时刻的快照重传率12500 / 2500000 * 100% 0.5%2. 使用/proc/net/snmp文件这是一个更易于脚本化采集的接口。查看该文件cat /proc/net/snmp | grep Tcp输出类似Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 1 200 120000 -1 100 50 2 1 10 50000 2500000 12500 0 5其中OutSegs: 发送的报文段总数对应segments sent out。RetransSegs: 重传的报文段数对应segments retransmitted。计算方法与注意事项差值计算才是关键/proc/net/snmp和netstat -s显示的是自系统启动以来的累积值。要计算周期内的重传率必须计算两个时间点之间的差值。周期内重传率 (RetransSegs_t2 - RetransSegs_t1) / (OutSegs_t2 - OutSegs_t1) * 100%精度问题OutSegs包含了重传的报文段。这意味着分母本身就包含了分子的一部分。在重传率很低时这种计算方式足够精确。公式在数学上是合理的因为它衡量的是“发出的所有报文中有多少是用于重传的”。粒度问题这是整个TCP层的全局统计无法区分不同连接、不同端口或不同目标IP。适用于监控主机整体的网络健康度。3.2 连接级细粒度统计ss命令如果你想定位到具体有问题的连接ss命令是比netstat更强大的工具。ss -t -i在输出中每个TCP连接都会显示详细的拥塞控制参数其中包含... cubic wscale:7,7 rto:204 rtt:1.349/0.314 ato:40 mss:1448 pmtu:1500 rcvmss:536 advmss:1448 cwnd:10 bytes_sent:1500000 bytes_retrans:15000 segs_out:1200 segs_in:1050 data_segs_out:1100 data_segs_in:1000 send 10.0Mbps lastsnd:1000 lastrcv:1000 lastack:1000 pacing_rate 20.0Mbps delivery_rate 1.2Mbps busy:101ms rcv_space:14600 rcv_ssthresh:64088 minrtt:0.8关注bytes_retrans: 该连接重传的字节数。bytes_sent: 该连接发送的总字节数。data_segs_out: 该连接发送的数据段数量不含纯ACK等控制段。你可以用bytes_retrans / bytes_sent估算字节重传率或者寻找bytes_retrans绝对值很高的连接。这对于调试单个异常连接非常有用。3.3 使用eBPF进行深度追踪对于需要极致细粒度和实时性的场景例如监控一个大型微服务集群中所有RPC调用的重传情况操作系统级的统计就显得力不从心了。这时eBPF扩展伯克利包过滤器技术就派上了用场。原理eBPF允许你向Linux内核注入安全的、沙盒化的程序在内核态直接捕获和处理特定事件。你可以编写eBPF程序挂载到tcp_retransmit_skb这个内核函数上。每当任何TCP连接发生重传时你的eBPF程序就会被触发从而可以捕获到当前进程的PID、进程名。连接的源IP、源端口、目的IP、目的端口四元组。重传的数据序列号、长度。重传的原因超时快速重传。优势维度丰富可以按进程、按目标IP、按端口聚合重传指标。实时性强近乎实时地感知到重传事件。开销极低相比于全流量抓包tcpdumpeBPF的内核过滤和聚合能力使其性能开销几乎可以忽略不计。简易实现思路使用BCC工具集 虽然直接编写eBPF代码有门槛但可以利用BCC项目提供的现成工具例如tcpretranssudo /usr/share/bcc/tools/tcpretrans这个工具会实时打印出系统中发生的所有TCP重传事件包含四元组和进程信息是进行问题初步定位的神器。4. 监控体系搭建从数据采集到告警掌握了计算方法下一步就是构建一个可持续的监控体系。我们的目标是不仅能看到当前值还能看到历史趋势并能在异常时及时告警。4.1 数据采集层你需要一个代理Agent定期采集数据。选择取决于你的技术栈Node ExporterPrometheus生态这是云原生场景下的标准选择。Node Exporter的netstat收集器默认就会抓取/proc/net/snmp中的数据并暴露为Prometheus格式的指标。指标名通常为node_netstat_Tcp_RetransSegs和node_netstat_Tcp_OutSegs。你需要部署Node Exporter到所有需要监控的主机上。TelegrafInfluxDB生态如果使用时序数据库InfluxDBTelegraf是完美的采集器。它的net插件同样可以收集/proc/net/snmp的数据。配置示例[[inputs.net]] fielddrop [icmp*, ip*, tcp*, udp*] # 先丢弃所有再只取需要的 [[inputs.netstat]] fieldpass [tcp_retrans_segs, tcp_out_segs]自定义脚本对于小型环境或特殊需求可以编写一个简单的Shell或Python脚本定期读取/proc/net/snmp计算差值后推送到监控系统如Zabbix、Open-Falcon等。#!/bin/bash # 获取当前值 read tcp_out_segs tcp_retrans_segs $(awk /^Tcp:/ {print $11, $13} /proc/net/snmp) # 与上一分钟保存的值计算差值并计算重传率 # ... (此处需实现差值逻辑和持久化存储如写入文件) # 将计算出的重传率指标推送到监控网关 echo tcp.retrans.rate $retrans_rate $(date %s) | nc monitor-gateway 20034.2 指标计算与存储层采集到的是累积计数器监控系统需要负责计算瞬时速率或比率。Prometheus PromQLPrometheus天生擅长处理计数器。你可以使用increase()函数计算一段时间内的增量。# 计算最近5分钟的主机全局TCP重传率 ( increase(node_netstat_Tcp_RetransSegs[5m]) / increase(node_netstat_Tcp_OutSegs[5m]) ) * 100这个查询会返回一个0-100的数值表示百分比重传率。你可以将其记录到Grafana面板或用于告警规则。InfluxDB Flux/InfluxQL在InfluxDB中你可以使用difference()函数类似地计算差值然后进行除法运算。4.3 可视化与告警层可视化Grafana全局视图创建一个仪表盘展示整个集群或数据中心所有主机TCP重传率的Top N排行。这能帮你快速定位“问题区域”。趋势视图为重要服务的主机绘制重传率的历史趋势图例如过去24小时。观察其基线Baseline和周期性规律。关联视图将TCP重传率与同一时间段的应用监控指标如接口P99延迟、错误率放在同一个面板中便于直观地关联分析。告警规则 设置告警的关键在于避免噪音。不要对绝对值报警而应该对相对变化或持续异常报警。基于阈值对于已知网络质量要求极高的服务如交易核心可以设置静态阈值告警例如重传率 0.1%持续2分钟。基于突变使用rate()或increase()计算重传的绝对速率。TCP重传速率突然飙升例如1分钟内重传超过1000个报文这可能比比率更能敏感地发现突发问题。基于历史异常检测更高级的做法是利用监控系统如Prometheus的ALERTS或Thanos的异常检测能力或者使用机器学习模型识别出与历史模式不符的重传率升高这能有效减少误报。Prometheus告警规则示例groups: - name: tcp_network rules: - alert: HighTCPRetransmissionRate expr: (increase(node_netstat_Tcp_RetransSegs[2m]) / increase(node_netstat_Tcp_OutSegs[2m])) * 100 0.5 for: 3m # 持续3分钟高于阈值才告警避免瞬时抖动 labels: severity: warning annotations: summary: 主机 {{ $labels.instance }} TCP重传率过高 description: {{ $labels.instance }} 过去2分钟TCP重传率为 {{ $value }}% 超过阈值0.5%。这可能表明网络拥塞或对端异常。 - alert: TCPRetransmissionSpike expr: rate(node_netstat_Tcp_RetransSegs[1m]) 100 for: 1m labels: severity: critical annotations: summary: 主机 {{ $labels.instance }} TCP重传速率激增 description: {{ $labels.instance }} TCP重传速率高达 {{ $value }} 个/秒网络可能出现严重问题。5. 实战排查当重传率告警响起之后监控告警只是开始真正的价值在于如何利用这个指标快速定位和解决问题。下面是一个典型的排查流程。5.1 初步诊断与定位确认告警有效性首先登录告警主机用netstat -s或cat /proc/net/snmp快速验证当前重传率是否确实很高。排除监控系统自身采集或计算错误。判断影响范围单机问题如果只有这一台主机告警问题可能出在该主机的网络配置、系统负载、或与它通信的某个特定对端。集群性问题如果同一服务的一组主机或同一机柜的主机同时告警问题很可能出在共享的网络设备如TOR交换机、负载均衡器或上游网络链路上。定位问题连接使用ss -t -i或eBPF工具如tcpretrans。观察bytes_retrans异常高的连接。重点关注对端IP是否集中如果重传都指向同一个目标IP例如某个数据库或缓存服务那么问题很可能在目标端或通往目标端的链路上。本地端口是否集中如果重传集中在某个本地端口可能是该端口对应的应用进程有问题。使用ss -t -i state established dst 问题IP过滤查看具体连接详情。5.2 深入排查工具链初步定位后需要更深入的证据。使用tcpdump进行抓包分析这是网络问题排查的“终极武器”。在客户端或服务端抓取问题连接的流量。# 抓取与特定目标IP的所有TCP流量并写入文件 tcpdump -i any -w problem.pcap host 目标IP and tcp分析要点查看重复的Seq号在Wireshark中可以通过tcp.analysis.retransmission过滤器直接显示所有重传包。分析是超时重传前后报文间隔约RTO还是快速重传连续收到Dup-ACKs。计算实际丢包率对比发送的Seq号和收到的ACK号。观察RTT和窗口大小巨大的RTT波动或急剧缩小的接收窗口可能指向网络拥塞或接收方处理缓慢。检查SACK信息如果启用了SACK可以清晰看到哪些数据块丢失。结合系统监控检查系统负载vmstat 1,top查看CPU、内存、上下文切换是否异常。系统负载过高可能导致协议栈处理缓慢引发重传。检查网络栈参数sysctl -a | grep net.ipv4.tcp查看是否有参数设置不当如过小的缓冲区。检查对端状态如果怀疑对端服务有问题查看对端服务的日志、监控指标如GC时间、线程池队列。5.3 常见根因与解决思路根据排查结果通常可以归为以下几类网络链路拥塞现象多台主机到同一目标或同一网段出现高重传tcpdump显示RTT增大、窗口缩小。排查联系网络团队检查交换机端口流量、错误计数、QoS策略。使用mtr或traceroute定位具体在哪一跳出现延迟或丢包。解决优化路由、扩容带宽、调整流量调度策略。对端服务过载或异常现象重传集中指向某个服务IP对端监控显示高延迟、高错误率。排查检查对端服务的CPU、内存、磁盘I/O、Full GC日志、线程池状态。解决扩容对端服务实例、优化对端应用性能、增加客户端超时和重试机制。本地主机问题现象仅单机有问题ss显示许多连接的bytes_retrans都高。排查系统参数检查net.core.rmem_max,wmem_max,tcp_rmem,tcp_wmem等缓冲区设置是否过小。并发连接数检查net.ipv4.tcp_max_syn_backlog,somaxconn是否过小导致新连接被丢弃。软中断softirq不均检查mpstat -P ALL 1观察是否某个CPU核的%soft使用率100%这可能是因为网卡多队列RSS未配置好导致单个CPU处理所有网络中断而成为瓶颈。解决根据排查结果调整内核参数优化网卡多队列和IRQ亲和性。应用层设计缺陷现象特定接口或操作期间重传率周期性升高。排查检查应用是否在单次请求中传输超大报文超过MSS是否使用了不合理的Nagle算法TCP_NODELAY设置或者在接收数据时处理得太慢滑动窗口为零。解决优化应用协议拆分大包根据场景合理设置TCP_NODELAY优化接收端数据处理逻辑避免阻塞TCP接收线程。6. 进阶优化与最佳实践将监控和排查流程固化下来并前瞻性地优化能防患于未然。6.1 建立基线与健康档案不要等到告警才关注重传率。你应该为每类服务Web服务、数据库、缓存、中间件建立正常的重传率基线。例如同机房微服务调用基线可能低于0.01%。跨可用区调用基线可能在0.05%-0.1%。跨地域公网调用基线可能容忍到0.5%甚至更高取决于线路质量。建立基线后告警可以设置为“超过基线3个标准差”或“超过基线值的200%”这样更智能减少误报。6.2 内核参数调优谨慎操作对于高性能服务适当调整TCP参数可以提升抗丢包能力和传输效率。但务必在测试环境充分验证并理解每个参数的含义。# 示例针对高带宽、高延迟网络如跨洋的调优 # 增大TCP窗口大小以提升吞吐量 sysctl -w net.core.rmem_max16777216 sysctl -w net.core.wmem_max16777216 sysctl -w net.ipv4.tcp_rmem4096 87380 16777216 sysctl -w net.ipv4.tcp_wmem4096 65536 16777216 # 启用更先进的拥塞控制算法如BBR其对丢包容忍度更高能更充分利用带宽 sysctl -w net.ipv4.tcp_congestion_controlbbr # 启用TCP快速打开TFO减少握手延迟需客户端和服务端同时支持 sysctl -w net.ipv4.tcp_fastopen3 # 减少TIME_WAIT状态连接的影响适用于短连接频繁的服务 sysctl -w net.ipv4.tcp_tw_reuse1 sysctl -w net.ipv4.tcp_tw_recycle0 # 注意tcp_tw_recycle在NAT环境下有问题Linux 4.12已移除建议设为0或不用重要提示内核调优是一把双刃剑。盲目增大缓冲区可能消耗过多内存更改拥塞控制算法可能对邻居流量造成影响。最佳实践是参考云服务商或硬件供应商的建议并结合实际压测数据进行调整。6.3 将重传率纳入SLO/SLI对于关键业务可以考虑将网络质量纳入服务等级目标SLO。例如定义“API网关到用户服务的网络重传率”作为一项服务等级指标SLI并承诺其99.9%的时间低于0.1%。这能将网络基础设施的稳定性提升到与应用服务同等的重视高度驱动基础设施团队和应用团队共同优化。6.4 全链路追踪集成在微服务架构中一次用户请求可能穿越数十个服务。如果能在全链路追踪系统如Jaeger, SkyWalking中为每个Span跨度打上本次RPC调用的TCP重传次数或标记那么当某个接口变慢时你不仅能看出是哪个服务慢还能一眼看出是不是因为网络重传导致的延迟。这需要改造服务框架或Sidecar代理在发起和接收网络调用时通过eBPF或系统调用钩子获取该连接的重传信息并上报到追踪系统。这实现了网络问题与应用性能问题的关联定位是高级可观测性的体现。监控TCP重传率本质上是在监控“信任”的成本。在不可靠的网络上构建可靠的服务TCP重传是必需的代价但我们必须让这个代价变得可见、可衡量、可优化。从全局的/proc统计到细粒度的 eBPF 追踪从简单的阈值告警到基于基线的智能检测再到与全链路追踪的融合这条监控之路的尽头是一个对网络异常高度敏感、能快速自愈的韧性系统。我自己的经验是把重传率监控作为新服务上线的标准检查项之一就像检查CPU和内存配置一样自然很多潜在的、诡异的性能问题在早期就被扼杀了。
TCP重传率监控：从原理到实战的完整指南
发布时间：2026/8/1 17:33:51
1. 项目概述为什么TCP重传率是系统健康的“晴雨表”在分布式系统、微服务架构和云原生应用大行其道的今天网络通信的稳定性直接决定了服务的SLA服务等级协议。我们常常会监控CPU、内存、磁盘I/O但网络层面的指标尤其是TCP层的表现却容易被忽视。而TCP重传率正是衡量网络通信质量最核心、最直接的指标之一。它不像丢包率那样受制于底层硬件或驱动统计的准确性也不像RTT往返时延那样容易受到路径上突发流量的干扰。重传率是TCP协议栈自身行为的一个真实反馈当网络出现丢包、拥塞、乱序或接收端处理不及时时发送方就会触发重传。因此一个持续偏高的重传率就像系统持续低烧预示着网络链路或对端服务存在潜在问题。我处理过不少线上故障表象是应用接口超时、服务调用失败但根因追溯下去往往是某条链路的TCP重传率悄然攀升到了1%甚至更高。对于追求低延迟、高可用的金融服务或实时通信场景0.1%的重传率可能就已经是不可接受的噪音了。所以学会计算和监控TCP重传率不是一项可选的技能而是每一位后端工程师、SRE站点可靠性工程师乃至全栈开发者都应该掌握的“内功”。这能帮助你在用户投诉之前提前发现并定位网络层面的退化从被动救火转向主动防御。2. 核心原理TCP重传是如何发生的要计算和监控首先得理解重传触发的机制。TCP是一个可靠的、面向连接的协议其可靠性正是通过确认ACK和重传机制来保证的。重传并非单一原因导致而是多种网络异常状况下的共同结果。2.1 重传的主要触发场景超时重传Retransmission Timeout, RTO这是最经典的重传机制。发送方每发送一个数据段都会启动一个重传定时器。如果在RTO时间内没有收到该数据段的确认ACK发送方就认为该数据包已丢失会立即重传。RTO的值是动态计算的基于对RTT的持续测量其算法如标准RFC 6298旨在适应网络延迟的变化。当网络突然变差实际RTT超过当前RTO估值时就会触发超时重传。快速重传Fast Retransmit这是为了优化超时重传效率低下的问题。当接收方收到一个失序的数据段时例如收到了Seq100-199 紧接着收到了Seq300-399它会立即重复发送对最后一个按序到达数据的ACK即对Seq199的ACK。当发送方连续收到3个相同的重复ACKDup-ACK时它就“有理由相信”该ACK之后的数据段Seq200-299已经丢失无需等待超时立即重传该数据段。快速重传能显著降低丢包恢复的延迟。选择性确认SACK触发的重传在启用SACK选项后接收方可以在ACK中明确告知发送方哪些数据块已经收到哪些中间的数据块缺失。发送方可以根据SACK信息精确地只重传丢失的数据段而不是重传整个窗口的数据效率更高。早期重传Early Retransmit在某些情况下例如当发送窗口很小无法产生足够多的数据包来触发三个Dup-ACK时标准快速重传会失效。早期重传机制允许在收到较少数量的Dup-ACK例如2个且满足一定条件时就触发重传适用于低流量连接。2.2 影响重传率的网络因素理解触发机制后我们就能分析哪些情况会导致重传率升高网络拥塞路由器缓冲区满导致数据包被丢弃。这是生产环境中最常见的原因。链路质量差无线网络、跨洲际光纤等场景下比特错误可能导致数据包损坏而被丢弃。接收方处理能力不足接收方应用处理过慢导致TCP接收缓冲区满进而通过零窗口通告或丢包来反压发送方间接引发重传。网络路径变化或路由抖动可能导致数据包乱序虽然乱序本身不直接导致重传但可能触发不必要的快速重传如果乱序被误判为丢包。系统资源瓶颈发送方或接收方主机CPU、内存紧张导致协议栈处理不及时定时器异常等。注意并非所有重传都意味着“坏事情”。在一个动态变化的网络中极低比例的重传如低于0.01%是TCP协议正常工作的体现是它保证可靠性的代价。我们监控的目标是识别出异常升高的、持续的重传。3. 计算方法从内核统计到业务指标计算重传率核心是获取两个关键计数器重传的数据段总数和发送的数据段总数。公式很简单重传率 (重传的报文段数 / 发送的报文段总数) * 100%。难点在于如何准确、高效地获取这些数据。3.1 操作系统级统计netstat与/proc/net/snmp这是最基础、最通用的方法适用于所有Linux/Unix系统。1. 使用netstat -s命令运行netstat -s -t可以输出TCP协议的详细统计信息。你需要关注以下两行具体标签可能因系统略有差异TCP: ... segments sent out: 2500000 # 发送的总报文段数含重传 segments retransmitted: 12500 # 重传的报文段数 ...计算某一时刻的快照重传率12500 / 2500000 * 100% 0.5%2. 使用/proc/net/snmp文件这是一个更易于脚本化采集的接口。查看该文件cat /proc/net/snmp | grep Tcp输出类似Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 1 200 120000 -1 100 50 2 1 10 50000 2500000 12500 0 5其中OutSegs: 发送的报文段总数对应segments sent out。RetransSegs: 重传的报文段数对应segments retransmitted。计算方法与注意事项差值计算才是关键/proc/net/snmp和netstat -s显示的是自系统启动以来的累积值。要计算周期内的重传率必须计算两个时间点之间的差值。周期内重传率 (RetransSegs_t2 - RetransSegs_t1) / (OutSegs_t2 - OutSegs_t1) * 100%精度问题OutSegs包含了重传的报文段。这意味着分母本身就包含了分子的一部分。在重传率很低时这种计算方式足够精确。公式在数学上是合理的因为它衡量的是“发出的所有报文中有多少是用于重传的”。粒度问题这是整个TCP层的全局统计无法区分不同连接、不同端口或不同目标IP。适用于监控主机整体的网络健康度。3.2 连接级细粒度统计ss命令如果你想定位到具体有问题的连接ss命令是比netstat更强大的工具。ss -t -i在输出中每个TCP连接都会显示详细的拥塞控制参数其中包含... cubic wscale:7,7 rto:204 rtt:1.349/0.314 ato:40 mss:1448 pmtu:1500 rcvmss:536 advmss:1448 cwnd:10 bytes_sent:1500000 bytes_retrans:15000 segs_out:1200 segs_in:1050 data_segs_out:1100 data_segs_in:1000 send 10.0Mbps lastsnd:1000 lastrcv:1000 lastack:1000 pacing_rate 20.0Mbps delivery_rate 1.2Mbps busy:101ms rcv_space:14600 rcv_ssthresh:64088 minrtt:0.8关注bytes_retrans: 该连接重传的字节数。bytes_sent: 该连接发送的总字节数。data_segs_out: 该连接发送的数据段数量不含纯ACK等控制段。你可以用bytes_retrans / bytes_sent估算字节重传率或者寻找bytes_retrans绝对值很高的连接。这对于调试单个异常连接非常有用。3.3 使用eBPF进行深度追踪对于需要极致细粒度和实时性的场景例如监控一个大型微服务集群中所有RPC调用的重传情况操作系统级的统计就显得力不从心了。这时eBPF扩展伯克利包过滤器技术就派上了用场。原理eBPF允许你向Linux内核注入安全的、沙盒化的程序在内核态直接捕获和处理特定事件。你可以编写eBPF程序挂载到tcp_retransmit_skb这个内核函数上。每当任何TCP连接发生重传时你的eBPF程序就会被触发从而可以捕获到当前进程的PID、进程名。连接的源IP、源端口、目的IP、目的端口四元组。重传的数据序列号、长度。重传的原因超时快速重传。优势维度丰富可以按进程、按目标IP、按端口聚合重传指标。实时性强近乎实时地感知到重传事件。开销极低相比于全流量抓包tcpdumpeBPF的内核过滤和聚合能力使其性能开销几乎可以忽略不计。简易实现思路使用BCC工具集 虽然直接编写eBPF代码有门槛但可以利用BCC项目提供的现成工具例如tcpretranssudo /usr/share/bcc/tools/tcpretrans这个工具会实时打印出系统中发生的所有TCP重传事件包含四元组和进程信息是进行问题初步定位的神器。4. 监控体系搭建从数据采集到告警掌握了计算方法下一步就是构建一个可持续的监控体系。我们的目标是不仅能看到当前值还能看到历史趋势并能在异常时及时告警。4.1 数据采集层你需要一个代理Agent定期采集数据。选择取决于你的技术栈Node ExporterPrometheus生态这是云原生场景下的标准选择。Node Exporter的netstat收集器默认就会抓取/proc/net/snmp中的数据并暴露为Prometheus格式的指标。指标名通常为node_netstat_Tcp_RetransSegs和node_netstat_Tcp_OutSegs。你需要部署Node Exporter到所有需要监控的主机上。TelegrafInfluxDB生态如果使用时序数据库InfluxDBTelegraf是完美的采集器。它的net插件同样可以收集/proc/net/snmp的数据。配置示例[[inputs.net]] fielddrop [icmp*, ip*, tcp*, udp*] # 先丢弃所有再只取需要的 [[inputs.netstat]] fieldpass [tcp_retrans_segs, tcp_out_segs]自定义脚本对于小型环境或特殊需求可以编写一个简单的Shell或Python脚本定期读取/proc/net/snmp计算差值后推送到监控系统如Zabbix、Open-Falcon等。#!/bin/bash # 获取当前值 read tcp_out_segs tcp_retrans_segs $(awk /^Tcp:/ {print $11, $13} /proc/net/snmp) # 与上一分钟保存的值计算差值并计算重传率 # ... (此处需实现差值逻辑和持久化存储如写入文件) # 将计算出的重传率指标推送到监控网关 echo tcp.retrans.rate $retrans_rate $(date %s) | nc monitor-gateway 20034.2 指标计算与存储层采集到的是累积计数器监控系统需要负责计算瞬时速率或比率。Prometheus PromQLPrometheus天生擅长处理计数器。你可以使用increase()函数计算一段时间内的增量。# 计算最近5分钟的主机全局TCP重传率 ( increase(node_netstat_Tcp_RetransSegs[5m]) / increase(node_netstat_Tcp_OutSegs[5m]) ) * 100这个查询会返回一个0-100的数值表示百分比重传率。你可以将其记录到Grafana面板或用于告警规则。InfluxDB Flux/InfluxQL在InfluxDB中你可以使用difference()函数类似地计算差值然后进行除法运算。4.3 可视化与告警层可视化Grafana全局视图创建一个仪表盘展示整个集群或数据中心所有主机TCP重传率的Top N排行。这能帮你快速定位“问题区域”。趋势视图为重要服务的主机绘制重传率的历史趋势图例如过去24小时。观察其基线Baseline和周期性规律。关联视图将TCP重传率与同一时间段的应用监控指标如接口P99延迟、错误率放在同一个面板中便于直观地关联分析。告警规则 设置告警的关键在于避免噪音。不要对绝对值报警而应该对相对变化或持续异常报警。基于阈值对于已知网络质量要求极高的服务如交易核心可以设置静态阈值告警例如重传率 0.1%持续2分钟。基于突变使用rate()或increase()计算重传的绝对速率。TCP重传速率突然飙升例如1分钟内重传超过1000个报文这可能比比率更能敏感地发现突发问题。基于历史异常检测更高级的做法是利用监控系统如Prometheus的ALERTS或Thanos的异常检测能力或者使用机器学习模型识别出与历史模式不符的重传率升高这能有效减少误报。Prometheus告警规则示例groups: - name: tcp_network rules: - alert: HighTCPRetransmissionRate expr: (increase(node_netstat_Tcp_RetransSegs[2m]) / increase(node_netstat_Tcp_OutSegs[2m])) * 100 0.5 for: 3m # 持续3分钟高于阈值才告警避免瞬时抖动 labels: severity: warning annotations: summary: 主机 {{ $labels.instance }} TCP重传率过高 description: {{ $labels.instance }} 过去2分钟TCP重传率为 {{ $value }}% 超过阈值0.5%。这可能表明网络拥塞或对端异常。 - alert: TCPRetransmissionSpike expr: rate(node_netstat_Tcp_RetransSegs[1m]) 100 for: 1m labels: severity: critical annotations: summary: 主机 {{ $labels.instance }} TCP重传速率激增 description: {{ $labels.instance }} TCP重传速率高达 {{ $value }} 个/秒网络可能出现严重问题。5. 实战排查当重传率告警响起之后监控告警只是开始真正的价值在于如何利用这个指标快速定位和解决问题。下面是一个典型的排查流程。5.1 初步诊断与定位确认告警有效性首先登录告警主机用netstat -s或cat /proc/net/snmp快速验证当前重传率是否确实很高。排除监控系统自身采集或计算错误。判断影响范围单机问题如果只有这一台主机告警问题可能出在该主机的网络配置、系统负载、或与它通信的某个特定对端。集群性问题如果同一服务的一组主机或同一机柜的主机同时告警问题很可能出在共享的网络设备如TOR交换机、负载均衡器或上游网络链路上。定位问题连接使用ss -t -i或eBPF工具如tcpretrans。观察bytes_retrans异常高的连接。重点关注对端IP是否集中如果重传都指向同一个目标IP例如某个数据库或缓存服务那么问题很可能在目标端或通往目标端的链路上。本地端口是否集中如果重传集中在某个本地端口可能是该端口对应的应用进程有问题。使用ss -t -i state established dst 问题IP过滤查看具体连接详情。5.2 深入排查工具链初步定位后需要更深入的证据。使用tcpdump进行抓包分析这是网络问题排查的“终极武器”。在客户端或服务端抓取问题连接的流量。# 抓取与特定目标IP的所有TCP流量并写入文件 tcpdump -i any -w problem.pcap host 目标IP and tcp分析要点查看重复的Seq号在Wireshark中可以通过tcp.analysis.retransmission过滤器直接显示所有重传包。分析是超时重传前后报文间隔约RTO还是快速重传连续收到Dup-ACKs。计算实际丢包率对比发送的Seq号和收到的ACK号。观察RTT和窗口大小巨大的RTT波动或急剧缩小的接收窗口可能指向网络拥塞或接收方处理缓慢。检查SACK信息如果启用了SACK可以清晰看到哪些数据块丢失。结合系统监控检查系统负载vmstat 1,top查看CPU、内存、上下文切换是否异常。系统负载过高可能导致协议栈处理缓慢引发重传。检查网络栈参数sysctl -a | grep net.ipv4.tcp查看是否有参数设置不当如过小的缓冲区。检查对端状态如果怀疑对端服务有问题查看对端服务的日志、监控指标如GC时间、线程池队列。5.3 常见根因与解决思路根据排查结果通常可以归为以下几类网络链路拥塞现象多台主机到同一目标或同一网段出现高重传tcpdump显示RTT增大、窗口缩小。排查联系网络团队检查交换机端口流量、错误计数、QoS策略。使用mtr或traceroute定位具体在哪一跳出现延迟或丢包。解决优化路由、扩容带宽、调整流量调度策略。对端服务过载或异常现象重传集中指向某个服务IP对端监控显示高延迟、高错误率。排查检查对端服务的CPU、内存、磁盘I/O、Full GC日志、线程池状态。解决扩容对端服务实例、优化对端应用性能、增加客户端超时和重试机制。本地主机问题现象仅单机有问题ss显示许多连接的bytes_retrans都高。排查系统参数检查net.core.rmem_max,wmem_max,tcp_rmem,tcp_wmem等缓冲区设置是否过小。并发连接数检查net.ipv4.tcp_max_syn_backlog,somaxconn是否过小导致新连接被丢弃。软中断softirq不均检查mpstat -P ALL 1观察是否某个CPU核的%soft使用率100%这可能是因为网卡多队列RSS未配置好导致单个CPU处理所有网络中断而成为瓶颈。解决根据排查结果调整内核参数优化网卡多队列和IRQ亲和性。应用层设计缺陷现象特定接口或操作期间重传率周期性升高。排查检查应用是否在单次请求中传输超大报文超过MSS是否使用了不合理的Nagle算法TCP_NODELAY设置或者在接收数据时处理得太慢滑动窗口为零。解决优化应用协议拆分大包根据场景合理设置TCP_NODELAY优化接收端数据处理逻辑避免阻塞TCP接收线程。6. 进阶优化与最佳实践将监控和排查流程固化下来并前瞻性地优化能防患于未然。6.1 建立基线与健康档案不要等到告警才关注重传率。你应该为每类服务Web服务、数据库、缓存、中间件建立正常的重传率基线。例如同机房微服务调用基线可能低于0.01%。跨可用区调用基线可能在0.05%-0.1%。跨地域公网调用基线可能容忍到0.5%甚至更高取决于线路质量。建立基线后告警可以设置为“超过基线3个标准差”或“超过基线值的200%”这样更智能减少误报。6.2 内核参数调优谨慎操作对于高性能服务适当调整TCP参数可以提升抗丢包能力和传输效率。但务必在测试环境充分验证并理解每个参数的含义。# 示例针对高带宽、高延迟网络如跨洋的调优 # 增大TCP窗口大小以提升吞吐量 sysctl -w net.core.rmem_max16777216 sysctl -w net.core.wmem_max16777216 sysctl -w net.ipv4.tcp_rmem4096 87380 16777216 sysctl -w net.ipv4.tcp_wmem4096 65536 16777216 # 启用更先进的拥塞控制算法如BBR其对丢包容忍度更高能更充分利用带宽 sysctl -w net.ipv4.tcp_congestion_controlbbr # 启用TCP快速打开TFO减少握手延迟需客户端和服务端同时支持 sysctl -w net.ipv4.tcp_fastopen3 # 减少TIME_WAIT状态连接的影响适用于短连接频繁的服务 sysctl -w net.ipv4.tcp_tw_reuse1 sysctl -w net.ipv4.tcp_tw_recycle0 # 注意tcp_tw_recycle在NAT环境下有问题Linux 4.12已移除建议设为0或不用重要提示内核调优是一把双刃剑。盲目增大缓冲区可能消耗过多内存更改拥塞控制算法可能对邻居流量造成影响。最佳实践是参考云服务商或硬件供应商的建议并结合实际压测数据进行调整。6.3 将重传率纳入SLO/SLI对于关键业务可以考虑将网络质量纳入服务等级目标SLO。例如定义“API网关到用户服务的网络重传率”作为一项服务等级指标SLI并承诺其99.9%的时间低于0.1%。这能将网络基础设施的稳定性提升到与应用服务同等的重视高度驱动基础设施团队和应用团队共同优化。6.4 全链路追踪集成在微服务架构中一次用户请求可能穿越数十个服务。如果能在全链路追踪系统如Jaeger, SkyWalking中为每个Span跨度打上本次RPC调用的TCP重传次数或标记那么当某个接口变慢时你不仅能看出是哪个服务慢还能一眼看出是不是因为网络重传导致的延迟。这需要改造服务框架或Sidecar代理在发起和接收网络调用时通过eBPF或系统调用钩子获取该连接的重传信息并上报到追踪系统。这实现了网络问题与应用性能问题的关联定位是高级可观测性的体现。监控TCP重传率本质上是在监控“信任”的成本。在不可靠的网络上构建可靠的服务TCP重传是必需的代价但我们必须让这个代价变得可见、可衡量、可优化。从全局的/proc统计到细粒度的 eBPF 追踪从简单的阈值告警到基于基线的智能检测再到与全链路追踪的融合这条监控之路的尽头是一个对网络异常高度敏感、能快速自愈的韧性系统。我自己的经验是把重传率监控作为新服务上线的标准检查项之一就像检查CPU和内存配置一样自然很多潜在的、诡异的性能问题在早期就被扼杀了。
