TCP SACK乱序级别reordering：重传不高但吞吐上不去的真凶-北京尧图网络

先把结论放在前面如果你在排查 TCP 性能问题时发现“重传不高、但吞吐上不去”的现象而且抓包里有大量 SACK 块那很可能就是把你今天看到的这个标题——SACK 报文乱序级别 reordering——给忽略了。它不像丢包那样一眼就能看出来但它会让 TCP 发送端反复误判网络“不行了”自我惩罚式地降速。这篇文章就从乱序的判定机制讲起把 SACK、reordering 级别、内核参数和排查手法一次讲透。1. 先从“为什么要 SACK”说起1.1 没有 SACK 的年代TCP 是怎么“猜”网络状况的要理解 reordering 级别先得理解 SACK 本身存在的意义。经典的 TCP 确认机制是累计确认接收方只能告诉发送方“我连续收到了哪个字节”。比如发送方发了 seq 1~1000 的数据中间丢了 seq 500~600接收方就只能反复回 ACK 499告诉发送方“我还在等你 500 这个字节之前的数据”。至于后面 501~1000 有没有收到接收方没法在标准 ACK 里说清楚。这就带来一个问题发送方看到重复 ACK只能靠猜。它不知道丢的是一个段还是后面其实已经到了、只是中间漏了一段。这种“盲人摸象”的状态在乱序面前尤其致命——因为乱序不是丢包数据一个没少只是到达的先后顺序被网络打乱了。如果没有 SACK发送方可能因为几个重复 ACK 就把还没超时的报文重传掉造成大量重复数据白白浪费带宽。1.2 SACK 块解决了“哪里缺、哪里不缺”的问题SACK 选项的诞生就是为了把“我已经收到哪些不连续的数据”这个信息明确告诉发送方。RFC 2018 定义了 SACK 的基本格式接收方在确认号之外额外携带若干个 (left edge, right edge) 对每个对描述一段已经收到的、但位于累计确认点之后的数据。举个例子发送方发了 seq 1、2、3、4 四个段接收方只收到了 1 和 3那么它回 ACK 2 的同时在 SACK 里带上 block (3,3)表示“seq 3 我已经有了你别再等我告诉你了我现在缺的是 2”。发送方拿到这个信息后就知道只有 seq 2 需要重传seq 3、4 的传输是成功的。这个机制本身不难但真正有意思的是它对发送方“乱序判定”的影响。因为 SACK 给了发送方一双“透视眼”发送方不再需要依赖简单的重复 ACK 计数来判断是否发生了丢包而是可以从 SACK 块里推算出当前网络的乱序到底有多严重哪些序列号是真的丢了哪些只是“晚到几天”。2. SACK 与乱序的“爱恨纠葛”为什么乱序比丢包更容易让 TCP 心态崩溃2.1 乱序与丢包在表象上的相似性在 TCP 发送端眼里乱序和丢包在一开始几乎无法区分。比如发送方发了 seq 1、2、3、4、5网络把 seq 2 和 3 的路径绕了一下接收方先收到 1、4、5再收到 2、3。接收方回 ACK 1 之后还会额外回两个“带 SACK 的重复 ACK”告诉发送方自己收到了 4 和 5。发送方看到重复 ACK第一反应是什么是“seq 2 丢了”。如果这个误判继续下去发送方就会开始快速重传 seq 2甚至把 seq 3 也捎带重传掉。真正的网络其实没丢包只是延迟稍微高了点。结果就是发送方白白重传接收方还得做去重处理带宽被无效占用RTT 时间和重传风暴叠加吞吐量反而下降。这正是 reordering 级别的价值所在。如果我们能提前告诉发送方“当前网络允许的乱序范围有多大”它就不会因为几个重复 ACK 就急着进入重传流程而是冷静地等一等让迟到的数据自己归队。2.2 reordering 级别到底在描述什么所谓 reordering 级别也叫 reordering degree 或 reordering shift本质上描述的是“在发送端看来一个报文比它的前序报文晚到了多少字节或多少段之后网络仍然可以被认为是‘正常的’”。在 Linux 内核的 TCP 实现里这个数值通常以 TCP segment 的数量或字节数来表示。经典的字段叫tp-reordering它记录的是当前允许的乱序程度。默认值是 3意思是当发送方看到 SACK 块或重复 ACK 显示的“空洞”宽度超过 3 个段时才认为网络发生了丢包。如果空洞宽度只有 1~2 个段发送方不会立即触发重传而是视为“轻度乱序”。这个阈值为什么是 3其实 RFC 5681 里规定的 dupthresh 默认值就是 3鼓励收到第 3 个重复 ACK 后进入快速重传。Linux 内核沿用这个数值作为 reordering 的初始值。但实际网络中尤其是跨机房、跨地域、经过多路径转发的链路3 个段的乱序容忍度往往不够用。后面我们再讲怎么调。2.3 乱序带来的连锁代价伪重传、拥塞窗口坍缩很多人会低估乱序对 TCP 性能的破坏力。乱序引发的最核心问题是“伪重传”spurious retransmission一旦发送方把还没丢的报文当成丢了它接下来会做三件事第一把对应的报文重传占用发送带宽第二触发拥塞控制机制把拥塞窗口cwnd减半后续发送速率直接腰斩第三进入恢复模式后续新数据的发送节奏会一直受到制约直到退出恢复状态。这一整套动作都在“网络没有任何拥塞”的情况下发生纯粹的“自己吓自己”。我见过一个比较典型的案例某跨区域链路部署了等价多路径负载均衡不同报文走不同的物理路径RTT 差别不大但乱序程度刚好比 TCP 默认的 3 段略高。表面上看链路利用率很低抓包却几乎没有真正的丢包所有问题都出在“乱序被误判成了丢包”。调整了 reordering 阈值之后吞吐从 200 多 Mbps 直接跳到 900 多 Mbps链路带宽本身就 1Gbps问题一下就明朗了。3. 深入内核reordering 级别是怎么被计算和维护的3.1 scoreboard 与 snd_una 的关系Linux TCP 处理 SACK 时核心数据结构是struct tcp_sack_block组成的 scoreboard它记录了接收方反馈的所有 SACK 块。发送方通过这些块能知道哪些字节区间已经被对端确认。真正判定乱序时发送方关注的不是 SACK 块本身而是“未确认区间的宽度”。这里有个关键指针snd_una它表示“尚未被累计确认的最小 seq”。累计确认点和最远 SACK 块右边缘之间的差距就是当前“空洞的宽度”。如果这个宽度超过了tp-reordering阈值内核就会判定发生了丢包而不仅仅是乱序。简单生活化理解你给朋友寄了 5 封信朋友回信说“第 1 封和第 5 封收到了”这时你无法确定第 2、3、4 封到底是在路上还是丢了。如果朋友后续回信又说“第 3 封也收到了”那么可以推测中间缺失的只是个别信件大概率是乱序。可如果朋友一直只告诉你“第 2、3、4 封都没到”你就要考虑是不是整批邮件都遇到问题了。TCP 的判定逻辑本质上就是这样。3.2 FACK依赖 SACK 的早期乱序估计方案早期 Linux 内核实现过 FACKForward Acknowledgment算法核心思路是维护一个snd_fack指针指向对端 SACK 块中确认的最高字节。它利用“已确认的最高字节”和“已发送但未确认的最低字节”之间的差值来判断空洞到底有多宽。FACK 的贡献在于它把 SACK 信息从“辅助确认”提升为“主判定依据”。它不再单纯靠累计 ACK 计数而是以 SACK 提供的可见空洞宽度为标准。如果空洞宽度超过了 reordering 阈值就认为丢包成立进入快速重传如果没有超过就继续等待。后来 FACK 逐渐被基于时间和包计数的 RACK 取代因为 FACK 在“重排程度动态变化”的场景下不够灵活尤其是当网络的乱序程度不是恒定值时固定阈值很难平衡“发现丢包延迟”和“伪重传误判”这对矛盾。3.3 RACK用时间度量乱序——reordering 级别的新解读RACKRecent ACKnowledgmentRFC 8985是目前 Linux 内核默认使用的乱序重传和丢包检测机制。RACK 最大的转变是不再只依赖“空洞宽度”这个空间维度而是引入了时间维度。RACK 的核心思想是如果对方已经确认收到了 seq X那么对于所有比 X 小的 seq只要时间还没超过某个“重排窗口”reordering window发送方都应该认为“这些数据可能还在路上”而不是急着重传。只有当一个较小的 seq 被 SACK 排除后、超过了重排窗口时间还没被确认才判定为丢失。这里就体现了 reordering 级别的另一层含义它不仅可以用“段数”表示也可以用“时间窗口”表示。RACK 会在启动阶段动态测量网络的乱序情况把重排窗口设置为一个可调整的时间值默认大约是 1 毫秒到几毫秒的量级具体根据 RTT 动态变化。这个设计的好处很明显——网络快的时候几毫秒时间就可能跨越几十上百个段网络慢的时候几个段可能就要几十毫秒。用时间度量天然适配不同速度的网络。3.4 DSACK 与乱序级别的反向校准顺便提一下 DSACKDuplicate SACKRFC 2883 定义的机制。接收方收到重复报文时会通过 DSACK 块告诉发送方“你之前发的某个报文我重复收到了”。发送方收到 DSACK 后可以确认自己之前确实发生了伪重传说明当时的乱序判定过于激进。DSACK 对于 reordering 级别调整的意义在于“事后修正”当发送方意识到自己误判时可以适当调高 reordering 阈值降低后续再次误判的概率。现代内核虽然不再直接依赖 DSACK 动态修改tp-reordering但在某些拥塞控制实现中DSACK 仍作为避免重传风暴的辅助信号。4. 实操Linux 下 reordering 级别怎么查、怎么调、怎么验证4.1 查看当前 reordering 参数Linux 提供了几个与 reordering 直接相关的系统参数最常用的是这两个net.ipv4.tcp_reordering表示 TCP 初始的 reordering 级别单位是 TCP 段数量默认值为 3。net.ipv4.tcp_max_reordering表示允许的最大 reordering 级别防止某些异常情况下乱序阈值被调得过大默认值通常是 300。查询方法很直接sysctl net.ipv4.tcp_reordering sysctl net.ipv4.tcp_max_reordering有些版本的内核还会暴露/proc/sys/net/ipv4/tcp_reordering和/proc/sys/net/ipv4/tcp_max_reordering内容和 sysctl 一致。另外如果你在一台服务器上只需要观察某个连接内部的 reordering 状态可以借助ss -i查看ss -ti在输出里找reordering字段它显示的是当前连接经过动态调整后的 reordering 值。如果是 3说明连接还没遇到明显乱序如果比 3 大很多说明这条连接此前经历过严重的乱序误判内核自动放宽了阈值。4.2 修改全局 reordering 阈值临时调整的命令sysctl -w net.ipv4.tcp_reordering10 sysctl -w net.ipv4.tcp_max_reordering300如果想永久生效写入/etc/sysctl.conf后执行sysctl -p即可。不过这里要提醒一句tcp_reordering只是初始值在连接建立后内核会根据实际乱序/丢包情况动态调整这个值并且每个连接的调整上限就是tcp_max_reordering。所以很多时候仅仅调大tcp_reordering并不能解决长期问题真正需要关注的是tcp_max_reordering是否有被触顶的迹象。以我自己的经验在已知网络存在高乱序的场景比如大规模 ECMP 路由、多路径接入下把tcp_reordering从 3 调到 5~10 通常能明显减少伪重传。但如果乱序程度超过 10 个段固定调阈值的方式就会变得很被动这时反而应该回到 RACK 的思路上来让时间窗口动态接管判定。4.3 用 RACK 替代固定阈值的思路在较新的 Linux 内核4.9 以后中tcp_recoverysysctl 控制着 RACK 的启用。默认值 0x1 表示启用 RACK 静态阶段0x2 表示启用动态阶段0x3 则是两者都启用。sysctl net.ipv4.tcp_recovery建议直接保持 0x3。动态 RACK 会根据实际网络情况自动调整重排窗口这是目前 Linux TCP 应对乱序最“聪明”的一个机制。我见过一些老运维手动把tcp_reordering调得很大反而不利于快速丢包恢复根源就是没意识到 RACK 的动态调整能力——它能在不牺牲丢包恢复速度的前提下把乱序和丢包区分得更加准确。另外有一个容易被忽略的参数net.ipv4.tcp_rack_reo_wnd它控制 RACK 重排窗口的最小时间值单位是毫秒默认 1。如果你发现某些路径上极短乱序微秒级却仍然被误判可能需要把这个值调小但这种情况在广域网环境中极少见。4.4 用 packetdrill 复现乱序场景纸上谈兵没意思动手验证才有说服力。packetdrill是验证 TCP 协议行为的标准化工具能模拟接收方投递带有 SACK 信息的 ACK观察发送方如何响应。下面这段脚本模拟了 seq 1~5 中 2~3 迟到的情况观察发送方是否会触发重传// 模拟一个 5 段数据的传输其中 2 号段被“暂时延后” 0 socket(..., SOCK_STREAM, IPPROTO_TCP) 3 0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) 0 0 bind(3, ..., 80, ...) 0 0 listen(3, 1) 0 0 S 0:0(0) win 16000 mss 1460 0 S. 0:0(0) ack 1 ... 0 . 1:1(0) ack 1 win 16000 0 accept(3, ..., ...) 4 // 发送 5 个段 0 write(4, ..., 7300) 7300 // 接收方先 ACK 第一个段后面都先没有 ACK模拟乱序 0 . 1:1(0) ack 1461 win 16000 // 接收方随后到达 seq 4 和 seq 5用 SACK 告诉发送方 0 . 1:1(0) ack 1461 win 16000 sack 4381:7301 // 此时发送窗口的空洞是 seq 2~3宽度是 2 段小于 reordering3 // 所以不应该触发快速重传。观察是否有重传行为。 0如果内核判定正确这个脚本的预期结果是没有立刻重传 seq 2 和 seq 3。若你把net.ipv4.tcp_reordering改成 1再跑一遍就能看到立刻触发重传的现象。这个对比实验非常直观地解释了 reordering 级别的意义。4.5 用 tcpdump 与 Wireshark 人工分析乱序packetdrill适合复现线上排查还需要杀器tcpdump。抓包时可以直接过滤指定流量tcpdump -i eth0 -s 0 -w sack_reorder.pcap tcp[tcpflags] tcp-syn ! 0 or tcp[tcpflags] tcp-ack ! 0要捕捉 SACK 信息-s 0是必须的否则默认截断报文长度SACK 选项大概率在截断区域内分析不出个所以然。抓完包后用 Wireshark 打开可以启用Analyze - Expert Info里面会列出所有“可疑重传”和“重复 ACK”事件如果你看到大量标红的“可疑重传”但实际统计丢包率为零那基本可以确定是乱序惹的祸。Wireshark 里还可以通过Statistics - TCP Stream Graph - Time-Sequence Graph (Stevens)来观察序列号随时间的变化。乱序表现在图上就是序列号出现“回退”或“断层”的锯齿状图案而这个断层恰好对应 SACK 块的空洞。5. 常见问题与排查技巧实录5.1 问题tcp_reordering 调了没效果这是最常见的问题。如果你把tcp_reordering调成 10但抓包发现快速重传依然频繁发生可能的原因有连接建立时读到的还是旧值。TCP 的 reordering 初始值在连接建立时拷贝如果你改了 sysctl但已有连接是之前建立的它们不会重新读取新值。需要新建立连接或重启服务才生效。实际乱序程度超过了tcp_max_reordering触顶。查ss -ti里每个连接的 reordering 值是否达到 300。如果大量连接停在 300说明你的网络乱序远超合理范围应该检查路由策略而不是继续调参数。RACK 介入后的判定可能不完全走 reordering 计数。旧内核里 RACK 和 reordering 逻辑并存动态 RACK 可能在 reordering 阈值之外做了独立判断。5.2 问题调整 reordering 后丢包恢复变慢了阈值调高之后真正丢包的情况下发送方需要收集到更多重复 ACK 才能触发快速重传恢复速度必然下降。这是空间的 trade-off。我见过有同学把tcp_reordering调到 50结果遇到一次真丢包吞吐瞬间下降因为等待重传的时间被拉长了好几倍。这种场景下推荐的做法不是继续加大段数阈值而是切换到基于时间的 RACK 方案。RACK 的时间窗口能模仿“乱序容限”但不受段宽影响——实际丢包时如果一个段超过重排窗口时间还没被 SACK无论空洞多窄都会立即重传恢复速度远胜于固定大阈值。5.3 问题误把乱序当丢包如何快速确认一个快速判断网络是否存在乱序的方法抓包后统计同一 TCP 流的 SACK 块数量。SACK 块数量多说明接收方频繁报告“缺口”而这些缺口有可能来自乱序也可能来自丢包。此时配合duplicate ACK的个数和重传包的数量做交叉验证重传包数量极少、SACK 块很多高概率是乱序。重传包数量与 SACK 块基本成正比大概率是真实丢包。重传请求集中在某几个序列号区间更像丢包散布在不同区间且时间跨度小更像乱序。另外一个鲜为人知的技巧使用netstat -s查看系统级统计。netstat -s | grep -i reorder输出里的TCPLostRetransmit和TCPTimeouts字段值得关注。TCPLostRetransmit表示“重传之后发现原来没丢”的次数这个数字如果很高说明之前的重传有相当一部分是伪重传也就是乱序误判的直接证据。5.4 问题应用层收到乱序数据怎么办最后再说一个方向的坑。TCP 本身会按序交付数据给应用层所以应用层通常感知不到乱序这是 TCP 相对 UDP 的巨大优势。但如果你在用 UDP 或基于 UDP 的协议比如某些自研的可靠传输协议乱序就需要应用层自己兜底。这种情况下应用层要做的不是调整内核参数而是设计合理的“重排缓冲区”参考 TCP SACK 的思路收到不连续的数据不要立刻丢弃先放在缓冲区里按序号拼接。缓冲区大小的选择直接影响性能和内存消耗——设置过小会导致频繁丢数据设置过大又浪费内存。一个经验值是缓冲区至少能容纳当前链路最大 RTT 和最大带宽的乘积BDP再乘以 1.5 的乱序余量。6. 一些实际操作中的经验与提醒最后聊几个我在排查 reordering 问题时总结的小经验。第一个经验调参前务必先确认问题真的在发送端。同一条链路上偶尔的乱序接收端的 SACK 会如实上报但如果你用ss -ti看到连接里的 reordering 值已经自动调大说明内核早就感知到乱序了这时候你再手动调tcp_reordering其实是在“干预一台已经学会自我调节的系统”。更多时候你应该关注的是为什么乱序频发——是不是多路径转发的 hash 策略不合理是不是接入层设备队列调度有差异。参数只能缓解症状不能替代网络问题本身的修复。第二个经验不要盲目追求“零伪重传”。伪重传的代价是浪费一点带宽而真正的丢包恢复延迟代价是吞吐下跌加 RTO 超时。这两者之间必须取舍。我见过有人看到TCPLostRetransmit较大就把 reordering 调到 200结果真实丢包发生时快速重传几乎完全失效故障恢复时间暴增到原来的好几倍。合理的目标是“把伪重传降到能接受的比例”而不是清零。第三个经验监控要比调参先行。如果你维护的服务器经常出现类 reordering 问题建议把ss -ti里的 per-connection reordering、sack 块数量、netstat -s里的重传和丢包计数都接入监控。这样在网络抖动出现苗头时就能提前发现而不是等用户报障后才登服务器抓包。乱序是一个持续性的、动态变化的指标一次性抓包只能看到当时的快照长期趋势才能暴露规律。第四个经验也当作最后一个收尾想说的TCP 协议的“可观测性”其实是分布式系统的缩影——发送端永远只能通过间接信号ACK、SACK、计时器来推测对端和网络的状态。reordering 级别本质上就是发送端对“不确定性”的容忍度设置。你在调整它的时候实际上是在回答一个问题你更相信网络多一点还是更相信丢包多一点这个权衡没有绝对正确答案只能根据自己的业务场景因地制宜。理解了这一点你就不会再被“为什么调大反而变慢”“为什么默认值看起来那么小”这些表面问题难住了。

TCP SACK乱序级别reordering：重传不高但吞吐上不去的真凶

相关推荐

# 多屏显示系统分辨率异常怎么办？EDID、刷新率与信号兼容性排查方法

3DMAX随机碳纳米结构RandomCarbonNanostructure建模工具开发教程

3D海森堡模型GPU加速：自旋内存布局与Metropolis核优化

更多资讯

SpringBoot集成AI服务与MCP动态管理实践

树莓派C++部署YOLOv5-Lite：Qt+OpenCV+NCNN实战

WhoDB Agent Hooks 全解析：为 AI 编码助手构建自动格式化、代码生成与构建验证钩子体系

打卡记忆单词法：告别死记硬背，让孩子爱上英语学习

SnackBar队列机制揭秘：为何始终只显示一条消息？3个Queue设计原理解析

Flutter三方库鸿蒙化适配实践：lzma压缩库迁移全记录

今日更新

小波包能量谱原理与MATLAB实现：从频带分解到故障特征提取

基于LSTM的网易云音乐评论情感分析：数据清洗与模型调优实战

Alpha-Beta剪枝与极大极小值算法：博弈树搜索原理与实战优化

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？