1. 从一次真实的网络卡顿说起为什么我们要聊 NewReno几年前我在一个跨区域的数据同步项目里踩过一个很典型的坑。两台服务器之间跑批量文件传输链路本身带宽不算小但一旦中间某条路径出现偶发丢包整个传输速率就像被人踩了刹车一样半天爬不起来。当时抓包看了很久最后定位到的根因就出在 TCP 的拥塞控制行为上——具体来说是经典的 Reno 算法在“多个包同时丢失”这个场景下表现得过于保守频繁地把拥塞窗口砍半导致吞吐量长期上不去。后来我们把拥塞控制换成了 NewReno同样的链路、同样的丢包率传输效率肉眼可见地改善了。这件事让我意识到很多人学计算机网络时把 Reno、NewReno 当成考试里的名词背下来就完事了但真正到了工程现场这些算法的一个小改动直接决定了你的服务是“能用”还是“好用”。这篇内容就是围绕对 Reno 算法的优化——NewReno 算法展开的。我会从 Reno 到底哪里不够好讲起把 NewReno 的核心改进、快速恢复阶段的完整状态机、和 Reno 的逐帧对比、以及实际抓包验证的方法都拆开讲清楚。适合正在学计算机网络的学生、准备面试的开发者也适合像我这样在真实项目里被拥塞控制坑过、想彻底搞明白的人。读完你至少能做到两件事一是能对着抓包图说清楚 NewReno 在快速恢复阶段到底做了什么二是知道在什么场景下该考虑它、什么场景下它也不是万能药。2. 先把地基打牢Reno 的拥塞控制到底在干什么2.1 拥塞窗口与四个核心阶段要理解 NewReno 优化了什么必须先搞清楚 Reno 的工作机制。TCP 拥塞控制的核心变量叫拥塞窗口cwnd它决定了发送方在收到确认之前最多能往网络里塞多少数据。你可以把 cwnd 想象成一个水龙头的开度开得越大往管道里灌的水越多但管道网络承受能力有限灌太猛就会溢出丢包。Reno 把整个发送过程划分成几个阶段最关键的四个是慢启动Slow Startcwnd 从很小通常 1 个 MSS开始每收到一个 ACK 就翻倍式增长呈指数上升。目的是快速探测网络可用带宽。拥塞避免Congestion Avoidance当 cwnd 达到慢启动阈值 ssthresh 后改为每个 RTT 只加 1 个 MSS线性增长谨慎逼近网络容量。快速重传Fast Retransmit当发送方连续收到 3 个重复 ACKdupACK时不等超时就直接重传那个丢失的报文段。快速恢复Fast Recovery重传之后不回到慢启动而是把 cwnd 减半后继续在拥塞避免区间运行避免吞吐量断崖式下跌。这四个阶段里快速重传和快速恢复是 Reno 的灵魂也是 NewReno 动刀的地方。慢启动和拥塞避免这两个阶段NewReno 基本没改所以我们后面重点全放在快速恢复上。2.2 三个重复 ACK 背后的信号含义为什么是“3 个重复 ACK”而不是 1 个或 2 个这里有个容易被忽略的细节。当接收方收到一个乱序报文段时它会立刻回一个重复 ACK告诉发送方“我还在等某个序号的数据”。如果只是网络轻微乱序可能只产生一两个重复 ACK随后缺失的包就到了。但如果连续收到 3 个重复 ACK说明缺失的报文段大概率是真的丢了而不是乱序。提示3 这个数字是经验值不是理论推导出来的。它是在“误判乱序”和“及时重传”之间取的平衡点。设得太小容易把乱序误判成丢包设得太大则重传延迟过高。Reno 在收到 3 个 dupACK 后会把 ssthresh 设为当前 cwnd 的一半cwnd 也设为一半有些实现是 ssthresh 3然后重传丢失的包进入快速恢复。问题就出在Reno 假设一次拥塞事件里只丢一个包。这个假设在早期网络里勉强成立但在今天的高带宽、大窗口场景下一个窗口里同时丢好几个包是家常便饭。2.3 Reno 的致命短板一个窗口丢多个包会怎样假设发送方窗口里有 10 个报文段其中第 3 个和第 7 个都丢了。接收方收到第 1、2 个正常收到第 4、5、6 个时因为第 3 个没到会连续回重复 ACK。发送方收到 3 个 dupACK重传第 3 个进入快速恢复。关键来了当第 3 个包重传成功、接收方把后续缓存的数据一起 ACK 回来时这个 ACK 只确认到第 6 个包因为第 7 个还缺着。Reno 看到这个“部分 ACK”会认为快速恢复结束了于是把 cwnd 降回一半并退出快速恢复。可实际上第 7 个包还丢着发送方接下来要么等超时重传慢得要命要么再等新的 3 个 dupACK 重新走一遍快速重传。结果就是一个窗口里丢 N 个包Reno 可能要经历 N 次“减半—重传”的循环cwnd 被反复腰斩吞吐量雪崩。这就是 Reno 在多包丢失场景下的核心缺陷也是 NewReno 要解决的头号问题。3. NewReno 的核心改进一个“部分 ACK”识别机制3.1 部分 ACK 是什么为什么它是关键NewReno 的全部精髓可以浓缩成一个概念部分 ACKPartial ACK。在快速恢复期间发送方会记录一个变量叫recover它等于进入快速恢复时的最大序列号也就是那个“最高已发送字节”。当发送方收到一个 ACK 时分三种情况ACK 确认号小于 recover但比之前确认的更多这叫部分 ACK说明又有一个或多个包被成功接收但快速恢复期间丢失的包还没全部补完。ACK 确认号大于等于 recover这叫完全 ACKFull ACK说明进入快速恢复时窗口里所有的包都已经被确认快速恢复可以真正结束了。ACK 确认号没有前进这是重复 ACK继续维持快速恢复状态。Reno 的问题在于它不区分部分 ACK 和完全 ACK只要收到一个能推进确认号的 ACK就以为快速恢复结束了。NewReno 则明确规定只要收到的是部分 ACK就继续留在快速恢复状态并立刻重传下一个疑似丢失的包。3.2 重传时机与 cwnd 的调整逻辑NewReno 在快速恢复期间的具体行为是这样的收到 3 个 dupACKssthresh 设为 cwnd/2重传第一个丢失包记录 recover 最高已发送序列号进入快速恢复。每收到一个部分 ACK立刻重传该 ACK 所指示的下一个丢失包因为部分 ACK 的确认号之后那个包很可能也丢了同时把 cwnd 适当调整常见做法是 cwnd cwnd - 已确认数据量 MSS保持窗口“注满”。每收到一个重复 ACKcwnd 加 1 个 MSS这叫窗口膨胀用于补偿网络里还在传输的数据。收到完全 ACK把 cwnd 设为 ssthresh退出快速恢复回到拥塞避免。这套逻辑的妙处在于它不需要超时也不需要等新的 3 个 dupACK就能在一个 RTT 内把同一个窗口里丢失的多个包全部重传完。相比 Reno 的“丢一个补一个、补完再发现下一个”NewReno 是“一次性把这一轮丢的都补上”。3.3 用一个具体数字例子走一遍光说逻辑容易晕我们拿具体数字跑一遍。假设 MSS 1000 字节发送方当前 cwnd 10 个 MSS也就是能发 10 个包序列号从 1 到 10简化成包编号。第 3 号包和第 7 号包丢失其余正常到达。接收方收到 1、2 号正常 ACK。收到 4、5、6 号时因为缺 3 号连续回 dupACK(3)。发送方收到 3 个 dupACK(3)ssthresh 5重传 3 号recover 10进入快速恢复。接收方收到重传的 3 号此时它缓存了 4、5、6于是回 ACK(7)因为它还在等 7 号。这个 ACK(7) 小于 recover(10)是部分 ACK。NewReno 收到部分 ACK(7)立刻重传 7 号继续留在快速恢复。接收方收到 7 号加上之前缓存的 8、9、10回 ACK(11)。这个 ACK 大于 recover(10)是完全 ACK。发送方收到完全 ACKcwnd ssthresh 5退出快速恢复。整个过程只经历了一次减半两个丢失包在一个往返内全部补完。如果换成 Reno第 6 步收到 ACK(7) 时它会误以为快速恢复结束退出后才发现 7 号还丢着只能靠超时或者新一轮 dupACK 再来一次cwnd 又要再砍一刀。4. Reno 与 NewReno 逐项对比差异到底有多大4.1 关键行为对照表为了让你一眼看清两者的区别我把核心行为整理成一张表对比维度RenoNewReno多包丢失处理每个丢失包触发一次减半一轮快速恢复内补完所有丢失包部分 ACK 识别不区分误判为恢复结束明确识别继续快速恢复快速恢复退出条件收到任何推进确认号的 ACK收到覆盖 recover 的完全 ACKcwnd 削减次数丢 N 个包可能减半 N 次通常只减半 1 次是否需要超时多包丢失时经常需要大幅减少超时概率实现复杂度简单略复杂需维护 recover 变量适用场景低丢包、单包丢失为主高带宽、多包丢失场景从表里能看出来NewReno 的改进不是“锦上添花”而是直接针对 Reno 在多包丢失下的结构性缺陷。它没有引入全新的机制只是在快速恢复的状态判断上加了一个“部分 ACK”的分支改动量很小但收益很明显。4.2 吞吐量差异的直观理解有人可能会问不就是少减半几次吗能有多大差别我们粗略算一下。假设链路 RTT 100ms初始 cwnd 20 MSS一个窗口丢 3 个包。Reno 的情况下cwnd 可能经历 20 → 10 → 5 → 2.5 这样的连续腰斩恢复回 20 需要好几个 RTT 的线性增长。而 NewReno 只减到 10然后线性爬升。粗算下来同样传 1MB 数据Reno 可能要 3 到 4 秒NewReno 可能 1.5 秒左右就完成了。当然这是理想化估算实际受链路、缓冲、RTT 波动影响很大但量级上的差距是真实存在的。注意NewReno 并不是“无损”的它依然会在每次拥塞事件里把 cwnd 减半。它优化的是“一次事件里丢多个包”的处理效率而不是消除减半本身。真正想进一步减少减半影响那是后面 CUBIC、BBR 这些算法要解决的问题了。4.3 为什么 NewReno 没有成为“终极方案”这里必须说句公道话。NewReno 解决了 Reno 的多包丢失问题但它仍然基于“丢包即拥塞”这个假设。在高带宽、长肥管道LFN场景下它线性增长的 cwnd 恢复速度依然偏慢。而且它对“部分 ACK”的处理依赖接收方的 ACK 行为如果接收方做了延迟 ACK 或者 ACK 聚合效果会打折扣。所以 NewReno 更像是 Reno 的“补丁版”而不是革命性替代。它的价值在于改动小、兼容好、在中等丢包场景下性价比极高。很多操作系统至今仍把 NewReno 作为默认或备选拥塞控制算法就是因为它足够稳、足够简单。5. 动手验证抓包看 NewReno 的真实行为5.1 实验环境搭建思路光看理论不过瘾我们实际抓一次包看看。思路是这样的搭建一个可控的链路环境人为制造多包丢失然后分别用 Reno 和 NewReno 跑一遍对比抓包结果。具体做法基于常见实践补充用两台虚拟机或者容器做发送端和接收端中间加一个可以注入丢包的中间节点。发送端用iperf3或者自己写个 socket 程序持续发送数据。用tcpdump在发送端抓包保存成 pcap 文件。通过系统参数切换拥塞控制算法Linux 下可以查看/proc/sys/net/ipv4/tcp_congestion_control支持的算法列表。人为设置丢包规则让一个窗口里连续丢两个包。提示不同系统对拥塞控制算法的命名和可用性不一样有些系统默认只带 Reno 和 CUBICNewReno 可能需要内核模块支持。实验前先确认你的环境支持哪些算法别白忙一场。5.2 抓包结果怎么读抓到包之后重点看这几个字段Sequence Number看哪些包被重传了重传了几次。Acknowledgment Number看 ACK 的推进节奏识别哪些是部分 ACK。TCP Analysis Flags抓包工具通常会自动标记“快速重传”“重复 ACK”“重传”等事件非常方便。时间戳看从第一次丢包到完全恢复花了多少时间。在 NewReno 的抓包里你会看到这样的模式3 个 dupACK 之后紧跟一次快速重传然后是一个部分 ACK紧接着又一次重传最后是完全 ACK。整个过程紧凑没有超时。而在 Reno 的抓包里你很可能看到第一次快速恢复结束后隔了一段时间又出现一次超时重传中间有明显的“空窗期”。5.3 一个容易踩的坑接收端缓存的影响我第一次做这个实验时结果和理论对不上NewReno 的表现没有想象中好。排查后发现是接收端的接收缓存设置得太小导致部分已经到达的乱序包被丢弃接收方无法缓存它们自然也就回不出理想的部分 ACK。把接收缓存调大之后NewReno 的优势才体现出来。这个坑很典型NewReno 的效果高度依赖接收方能否缓存乱序报文段。如果接收缓存不足乱序包被丢那 NewReno 和 Reno 的差别就被抹平了。所以做实验或者调优时接收窗口和接收缓存一定要给够。6. 实操中的经验与常见问题排查6.1 什么时候该考虑 NewReno不是所有场景都值得折腾 NewReno。根据我的经验下面这几种情况可以考虑链路有一定丢包率且丢包呈现“突发性”一个窗口里经常丢多个包。带宽中等、RTT 不算特别大线性恢复还能接受。系统或设备对拥塞控制算法的支持有限只能用相对简单的算法。需要和大量老旧设备互通兼容性优先于极致性能。反过来如果是超高速、超长距离的链路或者对延迟极其敏感的场景NewReno 可能就不够看了得考虑更激进的算法。6.2 常见问题速查表现象可能原因排查方向NewReno 效果和 Reno 差不多接收缓存太小乱序包被丢调大接收窗口和缓存快速恢复迟迟不退出recover 变量计算有误检查实现里 recover 的赋值时机频繁超时重传部分 ACK 没被正确识别抓包确认 ACK 序列号推进情况吞吐量忽高忽低链路本身抖动大结合 RTT 和丢包率综合判断切换算法后无变化算法未真正生效确认系统实际加载的算法6.3 几条实打实的避坑心得第一别迷信算法本身先看链路质量。如果链路丢包率已经高到离谱换什么算法都救不回来该修链路先修链路。第二抓包是唯一真相。理论分析再漂亮也要用抓包验证。我见过太多“以为改了参数就好了”的情况结果抓包一看根本没生效。第三注意 ACK 延迟的影响。如果接收端开了延迟 ACKdupACK 的产生节奏会变慢快速重传的触发也会延迟这会掩盖 NewReno 的部分优势。实验时最好把延迟 ACK 关掉或者调小。第四recover 变量的边界要小心。在实现或分析时recover 应该记录进入快速恢复那一刻的最高已发送序列号而不是最高已确认序列号。这两个搞混了部分 ACK 的判断就会出错。7. 从 NewReno 往后看它在拥塞控制演进里的位置把 NewReno 放回整个 TCP 拥塞控制的发展脉络里它的定位其实很清晰它是从“单包丢失假设”走向“多包丢失现实”的第一步。在它之前Reno 用简单粗暴的方式处理拥塞在它之后SACK、CUBIC、BBR 等算法从不同角度继续优化——SACK 用选择性确认精确告诉发送方哪些包到了CUBIC 用三次函数替代线性增长以适应高带宽BBR 干脆不再把丢包当拥塞信号。但 NewReno 的价值不会因为后来者出现而消失。它的思路——用部分 ACK 识别未完成的恢复状态——是很多后续算法的基础组件。理解了 NewReno你再去看 SACK 的“选择性重传”、CUBIC 的“窗口增长函数”会发现它们都在解决同一类问题的不同侧面。我自己在实际项目里的体会是拥塞控制没有银弹只有匹配场景的取舍。NewReno 不是最快的但它足够简单、足够稳、足够兼容。当你面对的是一个混杂着新旧设备、链路质量参差不齐的真实网络时这种“稳”往往比“快”更值钱。最后再分享一个小技巧如果你不确定该用哪个算法不妨先用 NewReno 打底抓一轮包看看瓶颈到底在哪再决定要不要上更激进的方案。盲目追新有时候反而会把简单问题搞复杂。
