1. 从“收到请回复”说起网络世界的确认与重传不知道你有没有玩过那种需要“收到请回复”的群聊。你发出一条重要通知如果没人吭声你心里就会打鼓他们到底看没看到这时候你可能会所有人或者单独再问一遍。网络世界里的数据传输面临的困境和这几乎一模一样。数据包就像你发出的消息在复杂、拥挤、充满不确定性的网络链路中穿梭随时可能“迷路”或“被挤丢”。发送方如何知道对方“收到”了如果没收到又该怎么“再问一遍”这就是ACK确认、NACK否定确认和REX重传这套组合拳要解决的核心问题。它们不是什么高深莫测的黑科技而是网络通信协议为了确保数据可靠交付设计出的一套精妙的“对话规则”。我干了这么多年音视频传输和网络优化可以说这套机制玩得熟不熟直接决定了你应用的流畅度、延迟和抗丢包能力。理解它们就像是拿到了优化网络性能的钥匙。简单来说ACK就是接收方成功签收后给发送方回的“OK”手势。NACK则更“高冷”一些它只在发现快递包裹数据包丢失时才举手报告“喂我缺了第5号包裹”。而REX就是发送方在得知包裹丢失后麻利地重新打包发货的动作。今天我们就抛开枯燥的协议文档像老朋友聊天一样把这些机制掰开揉碎了讲清楚。我会结合TCP、UDP以及一些为实时性优化的协议比如KCP、WebRTC聊聊它们具体是怎么工作的有哪些“坑”以及我们怎么根据不同的业务场景比如看网页、看直播、打视频电话来调整策略让数据传输既稳又快。2. 核心机制拆解ACK、NACK与REX如何各司其职2.1 ACK最基础的“收到回执”ACKAcknowledgement是最经典、最广泛使用的确认机制。它的逻辑非常直接发送方每发出一个或一组数据包就期待接收方回复一个ACK报文这个报文中通常包含了“我已正确收到的最大的连续数据包序号”。你可以把它想象成老师上课点名。老师发送方念一个学生的名字发一个包学生答“到”回ACK。只有听到“到”老师才会点下一个名字。这就是最简单的停等协议。但这种方式效率太低了老师点完一个名要等半天一节课点不了几个人。所以在实际应用中比如我们每天都在用的TCP协议采用的是更高效的累计确认和滑动窗口机制。接收方不用对每个包都立刻回复ACK。比如它连续收到了包1、2、3、4那么它可能只在收到包4后回复一个ACK4。这个ACK的意思是“4号及之前的所有包我都收到了请发5号及以后的吧。”发送方则维护一个“发送窗口”窗口内的数据可以一口气全发出去然后根据收到的ACK来滑动这个窗口继续发送新的数据。这种机制的优势是反馈报文ACK数量少节省带宽。但它有个明显的缺点对乱序不友好。假设发送方发了1,2,3,4,5五个包但网络抖动导致包顺序变成了1,3,4,2,5。当接收方收到1然后收到3时它发现2丢了序列号不连续。按照累计确认它只能重复发送ACK1确认1号包。发送方连续收到3个ACK1就会触发快速重传机制立即重传2号包即使此时4、5号包可能已经躺在接收方的缓存里了。这就造成了不必要的重传。我在优化一个直播推流协议时就遇到过这个问题。在无线网络环境下包乱序率有时能到5%大量本已到达的包因为前序包乱序而被判定丢失、触发重传不仅浪费带宽还增加了延迟。后来我们引入了类似选择性确认SACK的选项允许接收方在ACK里告诉发送方“我收到了1以及3-4只缺2”。这样发送方就能精准地只重传2号包效率提升非常明显。2.2 NACK按需索取的“缺件清单”与ACK的“报平安”思路不同NACKNegative Acknowledgement是一种“报忧不报喜”的机制。接收方在正常情况下保持沉默只有当它检测到有数据包丢失比如通过序列号发现中间有缺口时才会主动向发送方发送一个NACK报文明确指出“我缺了某某号包裹”。这就像仓库管理员盘点库存他不需要对每一件入库的商品都签字而是定期清点发现缺了什么才向供应商提交一份“补货清单”。NACK清单可以一次性列出多个丢失的包号。NACK最大的优势在于减少了常态下的反馈流量。在高质量网络中丢包率很低那么NACK报文就非常少绝大部分带宽都用于传输有效数据。这对于实时音视频这种上行带宽往往比下行带宽更珍贵的场景来说尤其有用。发送方比如主播端上行链路节省出来的带宽可以用来发送更高码率的视频。在WebRTC的RTP/RTCP协议中NACK就是主要的丢包反馈机制。接收方并不是一检测到丢包就立刻发送NACK而是会等待一个很短的时间比如10-20毫秒将这段时间内发现的所有丢包序号收集起来在一个NACK报文里一次性发送。这样做有两个好处一是避免了因网络短暂乱序而立刻请求重传可能包只是晚了点到二是将多个请求合并减少了协议头开销。但NACK也有它的“坑”。如果丢包非常严重或者NACK报文本身也丢了就会导致问题。因为发送方只有在收到NACK时才知道要重传如果NACK丢了这个包就彻底丢失了没有像TCP那样的超时重传兜底。因此完全依赖NACK的协议通常需要结合其他机制比如前向纠错FEC或者在应用层设置一个最终的重传超时时间。2.3 REX重传策略的艺术知道了包丢了通过ACK超时或收到NACKREXRetransmission就是执行重传的动作。但“何时重传”、“重传几次”、“先传哪个”这里面充满了权衡的艺术。首先是重传超时RTO的计算。这是重传机制的灵魂。设得太短网络稍微一波动你就认为丢包导致大量不必要的重传浪费带宽还加剧拥堵设得太长丢包后等待确认的时间太久增加应用的延迟。TCP采用了一个经典的算法持续测量往返时间RTT然后计算一个平滑的RTT值SRTT并加上一个动态的偏差值得到RTO。公式大致是RTO SRTT 4 * RTTVAR。此外系统通常会设置一个最小值如200ms防止RTT估算过小。更有意思的是退避策略。当一个包第一次重传后依然没收到确认TCP会认为网络可能比较拥堵于是将下一次重传的RTO翻倍RTO 2 * RTO这就是“指数退避”。但我在做实时传输优化时发现对于延迟敏感的业务翻倍退避太“狠”了重传延迟增长过快。像KCP这个以速度见长的协议就建议退避系数用1.5而不是2这样在保证缓解拥堵的同时重传更积极延迟更低。其次是重传的优先级。不是所有重传包都一视同仁。一个已经重传过3次的包和一个刚刚发现丢失的包谁的优先级更高通常刚丢失的包应该优先传因为它对恢复播放、减少卡顿更关键。此外对于音视频I帧关键帧的丢失比P帧预测帧影响大得多重传I帧碎片的优先级也应该更高。在实际编程中我们往往会维护多个重传队列根据包的重要性、丢失时间、重传次数来动态调整发送顺序。最后是缓存管理。发送方必须把发出去的包在内存里缓存一段时间以备重传。缓存多久这是个问题。缓存太短可能接收方的NACK还没到包就被删了无法重传缓存太长又浪费内存。一个常用的启发式方法是缓存时间 2 * RTT NACK间隔 冗余量。对于直播场景我们还会加一个绝对上限比如1秒或一个GOP图像组的时长超过这个时间的数据即使丢了也不再重传因为对播放已经没有意义了。3. 实战中的协议对比从TCP到QUIC理解了基本机制我们来看看不同协议是怎么运用它们的。这就像看不同流派的武术家如何运用相同的拳理打出风格迥异的招式。3.1 TCP稳重求全的“宗师”TCP是可靠传输的标杆它主要依靠ACK超时重传快速重传这套组合。它的设计哲学是“绝对可靠”和“公平性”一切以不丢包和网络全局拥塞控制为首要目标。确认机制以累计确认为主并支持SACK选项提供更精确的丢失信息。重传触发主要依赖RTO超时。同时通过“重复ACK”机制收到3个相同的ACK触发快速重传作为超时重传的补充减少等待时间。优点可靠性极高能适应各种复杂的网络环境是HTTP、邮件等应用的基石。缺点延迟高且不确定。它的拥塞控制算法如Cubic在检测到丢包时会剧烈降低发送速率这被称为“TCP队头阻塞”。更重要的是由于TCP是字节流协议一旦一个包丢失后续的包即使到达了也必须等待这个丢失的包重传成功后才能提交给应用这在实时音视频中会造成难以接受的卡顿。我早期做游戏服务器时曾尝试用TCP传输实时对战数据结果网络一波动延迟就从50ms飙升到500ms以上体验非常差。这就是TCP的“稳重”在实时场景下变成的“迟钝”。3.2 基于UDP的定制协议轻快灵活的“刺客”正因为TCP在实时性上的短板很多对延迟敏感的应用如实时音视频、竞技游戏都选择在UDP之上自己实现传输逻辑。它们可以更自由地搭配ACK、NACK和重传策略。KCP协议一个设计非常精巧的ARQ自动重传请求协议。它保留了类似TCP的ACK机制但在以下方面做了激进优化RTO计算更快RTT的采样更新更频繁RTO增长更平缓退避系数1.5。更快的重传除了超时重传还支持非延迟ACK下的快速重传。接收方收到乱序包时可以立即回复ACK告知缺失的包号发送方更快触发重传。选择性重传准确知道丢哪个包就重传哪个不牵连后续数据。无拥塞控制将拥塞控制完全交给应用层让业务根据自身特点如可容忍的丢包率来调整发送速率。 我曾在一次跨国视频会议项目中用KCP替换了部分TCP信道在同等丢包率下平均延迟降低了30%以上卡顿感显著减少。它的代价是牺牲了一定的公平性可能更“霸道”地占用带宽。WebRTC的RTP/RTCP这是实时音视频领域的实际标准。它采用NACK作为主要的丢包反馈机制。接收方通过RTCP协议定期如每秒100次发送NACK报文告知发送方丢失的RTP包序列号。发送方根据NACK进行选择性重传。 WebRTC的重传策略非常注重实时性。例如它有一个“包生存时间”的概念超过一定时长如网络抖动缓冲时间的包即使重传成功对播放也无益接收方可能会直接丢弃。同时WebRTC会智能地将重传与前向纠错FEC结合。在丢包率低时主要靠重传丢包率升高时动态增加FEC冗余包的比例用冗余换更低的延迟因为FEC不需要反馈可以原地解码恢复丢失包。3.3 QUIC面向未来的“集大成者”QUIC基于UDP的HTTP/3底层协议可以看作是吸取了TCP和自定义协议经验的下一代传输协议。它在重传机制上有根本性的革新。最大的革命在于“数据包编号”与“流”的分离。在TCP里序列号既用于数据排序也用于ACK确认。如果一个包丢失后重传它的序列号不变。这会导致一个歧义接收方收到一个ACK它是对原始传输的确认还是对重传的确认这个歧义会影响RTT测量的准确性这就是所谓的“重传歧义”问题。QUIC彻底解决了这个问题。它为每个数据包都赋予一个唯一且单调递增的包编号Packet Number即使重传包编号也会增加。同时数据本身在流Stream上有独立的偏移量。这样ACK确认的是包编号应用层数据按流偏移量重组。这意味着精准的RTT测量每个ACK都能明确对应到某次发送原始或重传RTT计算更准RTO也更准。消除队头阻塞QUIC支持多流复用。一个流上的包丢失只会阻塞该流的数据不会影响其他流上的数据提交。这就在传输层部分解决了队头阻塞问题。QUIC默认使用NACK-like的确认机制并支持更灵活的确认范围信息。它像TCP一样重视拥塞控制但实现更现代化、可插拔。可以说QUIC在提供TCP级别可靠性的同时获得了接近自定义UDP协议的灵活性和低延迟潜力。4. 优化策略根据你的业务“量体裁衣”了解了原理和协议我们该如何为自己的应用选择或设计重传策略呢没有银弹关键看你的业务最在乎什么。4.1 场景一在线直播与实时音视频低延迟优先核心矛盾延迟敏感可容忍少量丢包画面花屏、音频断续在一定程度内可接受。优化策略首选NACK而非超时重传减少反馈延迟。设置合理的NACK发送间隔如10-20ms合并请求。设置重传上限与生存时间例如一个包最多重传2-3次或者超过200ms还未重传成功就直接放弃。因为对于直播一个晚了300ms的视频帧已经毫无意义不如丢弃并等待下一个关键帧。区分优先级I帧切片、音频包、视频SPS/PPS参数集的丢失优先级应设为最高立即重传。普通的P帧数据可以优先级低一些。结合FEC在带宽允许的情况下为重要的数据如I帧添加FEC冗余包。这样在随机丢包时可以不依赖重传直接恢复实现零延迟修复。调整缓存策略发送端缓存不宜过大通常覆盖1-2个RTT加上NACK周期即可避免内存浪费。4.2 场景二文件传输与软件更新可靠性优先核心矛盾必须保证100%正确延迟不敏感。优化策略借鉴TCP思想使用ACK累计确认配合选择性确认SACK提高效率。保守的RTO与退避可以采用类似TCP的RTO计算和指数退避确保在网络波动时不会用重传洪流加剧拥堵。大滑动窗口由于不关心延迟可以设置较大的发送窗口充分利用带宽进行“管道化”传输。无需生存时间限制缓存可以一直保持直到收到该包的确认。甚至可以结合断点续传将缓存持久化到磁盘。4.3 场景三在线游戏与交互式应用平衡延迟与可靠性核心矛盾需要极低的延迟但对某些关键指令如射击、购买的可靠性要求又极高。优化策略消息分类处理不可靠消息如玩家实时位置更新用纯UDP发送不重传。丢了一两帧位置客户端可以插值预测追求最低延迟。可靠消息如技能释放、伤害计算使用可靠的UDP协议如ENet、自定义的类KCP协议采用快速NACK选择性重传。冗余发送对于极其重要的指令如游戏结果结算可以采用“冗余发送”策略即在连续几个包中都携带该指令只要收到一个就算成功用带宽换极致的可靠性。客户端预测与服务器回滚这是游戏领域的特定优化。客户端先根据指令立刻产生效果如移动服务器稍后校验。如果发现客户端指令因丢包无效则通知客户端“回滚”状态。这需要重传机制与游戏逻辑深度配合。4.4 通用调优参数与监控无论哪种场景在实现或配置重传机制时以下几个参数都是调优的关键旋钮需要结合监控数据来调整RTT的测量与平滑因子如何采样RTT平滑因子取多大直接影响RTO的灵敏度。NACK间隔与最大队列长度间隔太短反馈频繁太长重传延迟高。队列太长可能意味着网络状况极差需要考虑重置会话。重传次数上限防止对一个永远无法到达的包进行无意义的重传。缓存大小与淘汰策略是环形缓冲区还是链表按时间淘汰还是按大小淘汰在我的经验里最好的调优方式是埋点监控。监控关键指标应用层感知的端到端延迟、卡顿率、重传触发原因分布超时 vs NACK、重传成功率、网络RTT和丢包率的变化。通过分析这些数据你才能知道你的重传策略是在解决问题还是本身成了问题。比如如果你发现重传成功率很低但NACK发送很频繁那可能是RTT估算不准导致RTO太小或是网络乱序被误判为丢包这时就需要调整你的参数或引入乱序容忍算法了。网络优化没有一劳永逸的方案它是一个持续观察、假设、调整、验证的过程。