TCP超时与重传：RTO计算、快速重传与SACK排障实战

有一年做某跨地域数据同步项目线上服务一切正常偏偏文件传输模块隔三差五就卡上几十秒。抓包看了很久链路层的丢包率其实并不高真正的问题是TCP把大量时间花在了等超时、然后重传这件事上。那段时间我把《TCP-IP详解卷一协议》第21章翻来覆去读了好几遍才算把RTO、快速重传、SACK这一串机制真正串起来。今天这篇笔记就是基于那一章做的拆解和补充讲清楚TCP的超时与重传到底怎么工作、为什么超时时间忽大忽小、以及在实际排障里怎么判断是哪一类重传在拖后腿。适合正在啃协议细节的人也适合被弱网环境反复折磨的运维和开发。1. 为什么说超时重传是TCP保底的那张网1.1 可靠性承诺的代价丢包之后谁来兜底TCP对外承诺的是可靠、有序、不重不漏的字节流传输。这个承诺不是靠网络本身实现的因为IP层的理念本来就是尽力而为包丢了它不会主动告诉谁。真正把这个承诺落地的是发送端的确认机制和重传机制发送端发出数据后必须收到接收端的ACK才算数如果在一个约定的时间内没等到ACK发送端就默认数据丢了于是重发一次。这就是超时重传的起点。它听起来很简单但魔鬼全在细节里。“约定的时间”到底是什么设短了网络稍微慢一点就疯狂重传造成一连串重复包反而把拥塞加剧设长了丢一个包要等好几秒才恢复用户感知就是卡顿、超时、连接假死。所以这个时间不能是拍脑袋定的必须跟着网络的真实往返时延动态走。这里要引入两个绕不开的概念RTT和RTO。RTTRound-Trip Time是一个数据段从发出到收到对应ACK所经过的往返时间RTORetransmission Timeout是发送端为这次传输设置的等待时限。RTO的取值完全建立在RTT的测量之上但又不能简单等于RTT因为网络延迟本身有波动你得留出合理的余量。把这个余量算准就是第21章花大量篇幅讲RTO估算的原因。1.2 超时重传在不同网络环境下的表现差异同一个TCP连接在不同网络环境下的重传行为差异非常大。我最早意识到这一点是在对比一个跨机房传输场景和本机回环测试时发现的。本机回环RTT极低重传几乎不发生而跨地域链路上RTT动辄几十毫秒一旦发生一次丢包影响范围就明显扩大。原因不难理解RTO是跟着RTT走的。低延迟链路把RTO压得很小丢包后很快就能被发现、被重传代价是链路轻微抖动就可能造成不必要的重传高延迟链路把RTO放得很大容忍了抖动但也意味着真正的丢包需要更久才能被发现。还有一个容易被忽视的因素是RTT的方差。同样是平均50毫秒的链路一个稳定在45到55毫秒之间另一个在10到90毫秒之间剧烈波动后者的RTO必须设计得更大才能避免误判。这就引出了一个核心问题RTO估算不仅要看平均值还要看波动程度。2. 超时时间怎么定RTT测量与RTO计算的三个关键演进2.1 经典RTO估算从加权平均值到波动度量早期TCP的RTO计算思路比较朴素就是维护一个平滑的RTT估计值每次拿到新的RTT样本后用加权平均的方式更新旧值然后把这个平滑RTT乘以一个固定系数当作RTO。公式大致是SRTT α × SRTT (1-α) × RTT其中α取0.8到0.9之间而RTO则设成SRTT的两倍左右。这个办法在平滑网络里够用但碰上RTT抖动大的场景就会露馅。假设平均RTT是100毫秒经常有一半的样本在50毫秒、一半在150毫秒两倍平滑RTT也就是200毫秒看似安全可一旦出现连续几次高延迟200毫秒的超时窗口就很容易被打穿导致大量不必要的重传。后来出现了基于方差估算的RTO算法思路是给RTO留出“平均延迟加上若干倍波动幅度”的余量。具体做法是维护两个量平滑RTTSRTT和平滑RTT偏差RTTVAR然后按公式RTO SRTT max(G, 4 × RTTVAR)计算。G是系统时钟粒度如果时钟粒度比4倍偏差还大就用G兜底。这个算法的核心洞察是超时预算不应该按平均值给而应该按最坏情况给方差越大预留越多。实测下来这个算法对绝大多数业务链路都足够稳。它需要调整的只有初始化阶段一开始没有样本时RTO一般会被设成1秒钟的默认值等积累到一定数量的RTT样本后再切换到动态估算。2.2 重传歧义与Karn规则为什么重传包不能参与RTT采样RTO估算看起来只是数学问题真正让实现者头疼的是“重传歧义”。这个概念值得展开说清楚。场景是这样的发送端发出序号1000的包超时了没收到ACK于是重传一次。这时候来了一个ACK确认序号到2000。问题来了这个ACK是对应第一次发送的那个包还是对应重传的那个包如果对应第一次发送的包那这个ACK的到达时间包含了完整的网络往返是干净样本如果对应的是重传包那这个RTT样本里已经掺入了发送端白白等待超时的那段时间用它去更新RTO会把估计值严重拉偏。这种歧义在报文层面根本无法区分因为TCP的ACK只携带序号不携带“你确认的是哪一次发送”的标识。于是有了Karn规则它是重传处理里必须遵守的判据如果某报文发生了重传那么这个报文对应的ACK就不允许作为RTT样本参与更新同时重传后的RTO继续保持退避值直到收到一个非重传报文的ACK为止。换句话说只有在确认了“这次收到ACK的报文肯定没有被重传过”的前提下RTT测量才有意义。这条规则在工程上带来一个副作用越是网络差、丢包多的时候能用来更新RTO的干净样本就越少RTO反而偏向保守。这是故意为之的宁可暂时保持一个大一点的超时值也不能用脏数据把RTO带偏。实际调优时如果发现RTO异常大先别怀疑算法找找是不是链路丢包率偏高导致样本不足。2.3 时间戳选项给RTT采样提供一份“干净证据”Karn规则避免了使用脏样本但代价是丢包期间RTO更新停滞。有没有更彻底的办法有就是TCP时间戳选项它在TCP头里额外携带两个字段发送时的时间戳TSval以及回显对端最近一次收到的时间戳TSecr。它的精妙之处在于接收端在ACK里会把发送端最近一次发来的TSval原样回显。发送端收到ACK后用当前时间减去TSecr得到的就是这个数据段从发出到被确认所经历的真实时间。因为这个时间是针对“某个具体数据段”的即使该数据段被重传过ACK里回显的时间戳也能精确指出它对应哪一次发送歧义迎刃而解。时间戳选项的好处不仅是能精确测量还让发送端可以在重传发生后继续采用重传包的RTT样本因为现在能确认那个ACK到底在回应哪一次发送。现代操作系统的TCP实现几乎都默认开启这个选项除非协议栈把它关掉或者中间设备出于某些原因剥离了时间戳。如果遇到链路正常但RTO估算不合理的现象可以检查一下两端是否都启用了时间戳以及是否有中间设备对TCP选项做了过滤。3. 超时后的连锁反应指数退避与拥塞窗口修正3.1 指数退避的工程意义第一次超时之后如果再次重传又超时RTO不能保持原样而要成倍增大。这个机制叫指数退避1倍、2倍、4倍、8倍这样涨上去直到达到一个上限值通常不少于60秒。为什么必须退避最直接的理由是如果连着两个包都超时说明网络大概率已经进入拥塞或劣化状态而不是偶发丢包。此时如果还用一个比较小的间隔反复重传等于往已经拥堵的网络里持续灌重复流量只会让情况更糟。退避则给了网络恢复的时间也降低了发送端在恶劣条件下加剧拥塞的概率。还有一个容易被忽略的细节指数退避不仅作用于RTO数值还会在Karn规则下影响后续的RTT测量窗口。重传发生后在收到非重传报文的ACK之前RTO始终保持退避后的值这样做是为了避免把超时等待时间误当成网络延迟的一部分。我自己在实际抓包时见过不少连接RTO一路退避到几十秒的场景最典型的诱因是中间链路闪断或对端假死这种情况下再激进的快速重传也救不回来只能等退避上限到达后由对端或上层应用主动断开。3.2 超时事件后的cwnd与ssthresh变化超时重传不只是一次单纯的数据重发它同时会触发拥塞控制状态的调整。因为TCP把超时视为链路拥塞的强信号而不是单纯的随机丢包。标准的行为是先把慢启动门限ssthresh设置为当前发送窗口中未被确认数据量的一半再乘以一个下限约束至少不能小于两个最大报文段然后把拥塞窗口cwnd压到1个最大报文段重新进入慢启动阶段。这样做的意图很明确链路已经出现拥塞TCP要主动降速用一个小窗口重新探测网络容量再逐步爬升。这里有个值得记住的对比超时重传和快速重传对拥塞窗口的影响不同。快速重传进入快速恢复时cwnd通常只减半ssthresh也设为减半值但不会降到1个报文段恢复速度明显更快。所以实际调优时如果看到连接频繁发生超时重传就要意识到拥塞窗口被反复清零吞吐曲线会出现剧烈锯齿这时候单独调大socket缓冲区往往没用得先解决超时事件本身。3.3 定时器管理一个超时定时器怎么服务所有连接TCP的定时器管理在实现层面也很有讲究。不是每个连接、每个报文一个独立定时器那样系统开销会爆炸。多数实现采用单一的重传定时器模型每个连接只有一个重传定时器同时只跟踪一个“最紧急”的重传对象。具体逻辑是当发送新数据时如果定时器没有运行就按RTO启动如果已有数据在等待确认且定时器在运行新数据的发送不会重置定时器只有当ACK推进了序号、把所有待确认数据都清空后定时器才会关闭。这么做保证了定时器的过早点火不会因为连续发送而反复重置也避免了一个连接上同时存在多个超时源头的复杂度。工程上容易踩的坑是某些上层应用通过socket选项或用户态库自行实现了超时管理和内核的RTO计时器叠加使用导致要么超时过短提前断开要么超时过长让用户干等。判断的办法很简单用抓包观察重传间隔是否符合指数退避规律如果看到的是固定的、与TCP重传无关的超时断开那基本是应用层自己的定时器在起作用。4. 不等超时的救兵快速重传与选择性确认4.1 三个重复ACK背后的判定逻辑等超时再重传最短也要一个RTO时间高延迟链路上这可是不短的时间。有没有办法更早发现丢包有那就是快速重传它的触发信号不是超时而是连续收到三个重复ACK。原理不复杂。接收端收到乱序数据时TCP协议要求重复确认最后收到的连续序号而不是对乱序数据直接确认。比如发送端发了序号1000、2000、3000三个段如果2000丢了3000先到接收端会连续回复确认序号1000的ACK。发送端只要看到三次重复的ACK就能推断2000这个段大概率丢了于是不等RTO立即重传2000。为什么阈值是三个而不是一个或两个因为乱序本身也会产生重复ACK比如某个包只是绕了一下路晚到后面跟着的包先到了同样会触发重复ACK。两个重复ACK尚不能排除乱序的干扰三个则在误判概率和恢复速度之间取得了较好的平衡。实际网络中如果乱序严重频繁触发快速重传但抓包看并没有真正丢包那就是“伪重传”后续的排障里我再细说。4.2 SACK告诉发送端哪些数据真的收到了快速重传解决了发现丢包的速度问题但还有一个低效之处一次窗口内如果丢了多个不连续的段发送端并不清楚哪些丢了只能从ACK中推断一个大概然后可能把已经收到的数据又重传一遍。选择确认SACK就是来解决这个问题的。SACK的工作方式是在TCP选项里携带一个或多个序号区间明确告诉发送端这些区间的数据我都收到了你只需要重传那些缺口里的数据。每块SACK区间描述一个连续收到的字节范围用8个字节编码而TCP头选项空间只有40字节所以一次最多携带4个SACK块在某些场景下还会启用扩展选项来容纳更多。启用SACK需要双方在连接建立阶段交换SACK-Permitted选项确认支持。Linux系统里它默认是打开的但有些嵌入式设备或老协议栈可能没开或者中间设备会改写TCP选项造成SACK协商失败。判断标准很简单抓包里看SYN阶段是否出现了SACK-Permitted选项如果没看到说明双方只能做基础的重传效率会打折扣。4.3 快速恢复和NewReno丢包后不必退回慢启动快速重传之后不能只重传一个包就完事还要处理拥塞窗口的削减与后续恢复。这个过程叫快速恢复核心约束是进入快速恢复时ssthresh减半cwnd也做相应调整但不会像超时重传那样直接降到1这样可以让连接在确认网络仍有余量的情况下继续发送数据。NewReno是对早期快速恢复算法的一个关键改良。它解决了一个具体问题快速重传后如果收到的是部分确认partial ACK即这个ACK确认了重传数据的一部分但仍然没有覆盖全部发送数据这说明丢的不止一个包。NewReno要求此时不能退出恢复状态要继续重传下一个缺失段直到收到一个覆盖所有发送数据的完整确认才退出。这个细节在现场非常有用它避免了多个数据段丢失时反复进入快速恢复、反复削窗口的抖动。5. 高延迟和弱网环境下的重传调优实操5.1 先分清重传类型再动手排障的第一步不是调参数而是看清楚当前发生的是哪一种重传。从抓包里可以明显区分普通超时重传表现为等待了一个RTO时间后同一序号的数据再次出现在链路上且没有收到对应的重复ACK快速重传则表现为连续三个重复ACK之后立刻出现同一序号的重传SACK重传则更精细通常跟随SACK选项的指示重传缺失的区间。区分它们意义重大因为处置方向完全不同。超时重传占主导优先检查是否有网络层硬丢包、拥塞丢包、接收端缓冲区溢出快速重传占主导优先关注是否存在乱序、中间设备缓存太小导致同一数据被丢弃SACK相关的异常则更多和两端协商结果、中间设备对选项的处理有关。一上来就调内核参数往往掩盖了真实问题。我曾经在一个跨地域项目里抓包看到大量快速重传但链路几乎没有丢包最后发现是中间负载均衡设备对同一连接的不同包走了不同路径导致持续乱序。这种情况下调TCP栈参数基本无效把路径收敛成单一路径后一切恢复。这类问题不抓包根本定位不到。5.2 几类常用参数的调整思路确认重传类型之后有一些参数值得按场景调。Linux下最常碰到的几个是net.ipv4.tcp_syn_retries、net.ipv4.tcp_retries1和net.ipv4.tcp_retries2。tcp_syn_retries控制SYN重传次数默认通常为6延迟敏感的短连接可以适当减小tcp_retries2则决定数据段重传达到多少次后放弃连接默认15左右换算成时间接近15到30分钟某些应用希望更快失败的话可以调低。RTO相关参数在Linux里通常不建议用户直接改因为它由内核动态估算。真正值得检查的是TCP时间戳是否开启以及是否存在中间设备干扰SACK协商。另外如果链路是高带宽高延迟的长肥管道还要关注接收窗口是否足够大以及是否启用了窗口缩放。很多时候重传率看着高实际上是接收窗口太小导致数据段频繁被接收端丢弃进而触发发送端重传。5.3 容易踩坑的配置细节第一个坑是盲目调小RTO下限。某些加速方案会把RTO下限改得很低短平快场景下看似有效一旦进入抖动链路就频繁误判丢包反而引发重传风暴。任何修改RTO下限的操作都要用真实链路的延迟分布来验证。第二个坑是忽略接收缓冲区大小。吞吐要求高的连接如果接收缓冲区小于带宽延迟积接收端会频繁丢弃超窗数据发送端看到的表象就是大量超时重传。这时调发送端参数无效必须增大接收端缓冲区。第三个坑是硬件卸载带来重传统计假象。比如TCP分段卸载TSO/GRO开启时内核统计的重传次数和实际链路重传并不完全对应因为卸载引擎可能先把大段数据分成多个小段一次重传在内核统计里只算一次。看到异常的重传计数时先检查卸载状态避免被统计值误导。6. 常见重传问题速查与排查顺序6.1 问题现象与处置对照表实际操作中反复遇到的场景可以整理成一张对照表遇到问题直接按表排查能省下不少时间。现象可能原因优先检查项参考处置大量超时重传RTO不断退避链路拥塞或对端处理卡顿中间链路丢包率、对端CPU负载优化路径、调整对端处理能力快速重传频繁但链路丢包很低路径乱序或中间设备多路径抓包看是否有OOS标记收敛路径、关闭设备负载均衡RTO异常偏大且长期不收敛重传样本被Karn规则屏蔽链路丢包率、是否频繁超时先降低丢包再观察RTO同序号重复收取窗口推进慢接收端缓冲区不足或应用不读接收窗口、缓冲区大小增大缓冲区或优化接收端读取抓包看不到SACK选项协商未通过或中间设备剥离SYN阶段是否交换SACK-Permitted确认设备行为必要时更换中间设备重传计数与链路现象不符TSO/GRO卸载影响统计网卡卸载状态按卸载逻辑核对统计口径这张表不能覆盖所有情况但它对应的几类问题是我在实际项目里遇到频率最高的可以作为第一轮排查的起点。6.2 我惯用的四步排查流程排查重传问题时我基本固定按四个步骤走顺序很重要顺序错了容易绕弯路。第一步先抓包拿到证据。用tcpdump或等价工具在发送端或接收端抓包保存为pcap文件重点看TCP层带的分析标记。只要确认了重传类型和频率问题方向就清晰了一半。抓包建议双向都抓单边抓包很难确认是发出去丢了还是回包丢了。第二步核对链路与设备状态。关注中间链路的丢包率、延迟抖动、是否有路径切换事件。常见手段是看对端的RTT曲线、丢包计数以及直接在关键节点做ping或mtr。这一步能快速排除物理链路的问题。第三步检查两端协议栈状态。用系统命令查看重传统计、连接状态、发送和接收缓冲区使用量、拥塞窗口变化曲线。重点看是否存在接收窗口为0、发送队列堆积、ssthresh被频繁压低的情况。第四步才是调参数。到了这一步问题原因基本确定调整才有意义。调整时一次只改一个参数改完重新抓包对比前后重传行为。切忌同时调多个参数否则数据被污染很难判断哪个改动真正生效。这四步走完绝大多数TCP重传问题都能定位到具体环节。再补充一个我觉得最值得记住的体会不要把重传率当成一个需要归零的指标。TCP的重传机制是设计用来吸收网络噪声的完整长连接里完全没有重传反而不正常说明链路状况好到没给TCP任何自我修正的机会但这在广域网上很少见。真正需要警觉的是重传趋势是否恶化、RTO是否持续退避、恢复时间是否越来越长。把这些核心指标盯住了TCP的可靠性才能实实在在为你所用。