1 重传概述
重传（Retransmission）是通信系统提升可靠性的常用机制。其基本思路是在发送端无法确认某个数据分组是否成功到达时，于规定规则下再次发送该数据，以减少丢失或错误导致的应用层失败与级联影响。
重传并非只在“出错后才做补救”。在很多系统中，它与差错检测、确认反馈、窗口管理、拥塞控制等模块协同：一方面用来抵消信道不稳定带来的损伤，另一方面尽量避免因重发过多而浪费带宽、增加时延或进一步加剧拥塞。
1.1 基本概念与术语
重传涉及的常见术语包括：
- 数据块/分组/帧：被封装与传输的最小或较小单位。
- 发送端与接收端：分别负责发送与接收并处理确认信息。
- 确认（ACK）与否认（NACK）：接收端对成功接收或失败接收进行反馈。
- 超时（timeout）：发送端为等待反馈设置的时间上限。超时后触发重发。
- 序号（sequence number）：用于区分同一数据的不同传输实例，支持乱序处理与去重。
- 重传次数上限：避免无限重试并为上层提供失败处理路径。
1.2 重传在可靠性中的作用
在存在丢包、误码或时延抖动的信道环境中，单次发送往往无法保证完整交付。重传通过“再来一次”提供额外机会：
- 降低丢失概率：丢包不再意味着永久失败，而只是触发再次发送。
- 抑制误差传播：配合差错检测，接收端可以拒收或无法通过校验的数据，从而让发送端在规则下重发正确内容。
- 对时延波动更鲁棒：当反馈到达存在抖动时，合理的超时估计与策略选择能减少误判与不必要的重发。
1.3 与差错检测、确认机制的关系
重传通常建立在“能识别接收结果”的前提上，因此离不开差错检测与确认机制。
- 差错检测（如校验和、循环冗余校验等）帮助接收端判断数据是否可能被破坏。
- 确认机制用于通知发送端接收是否成功：成功则推进状态，失败则触发重发或等待更明确的反馈。
- 重传策略则决定“何时重发、重发哪些、重发多少次”。例如超时重传基于时间判断，ACK/NACK 重传基于接收反馈判断；序号相关方案还能处理乱序与选择性重发。
2 重传触发条件
重传触发通常由三类信号决定：时间到达（超时）、反馈信息（ACK/NACK）或对序号/顺序的判断（乱序、缺口）。在不同层次与协议中，这些触发方式会以不同形式出现。
2.1 超时重传（Timeout Retransmission）
超时重传是最直观的一类触发：发送端发出数据后，启动计时器等待确认。若在规定时间内未收到期望的反馈，就认为可能发生丢包或反馈丢失，从而重发。 超时重传的关键在于超时参数：
- 超时过短会导致“未等到但其实已到达”的误重发；
- 超时过长会让丢失后的恢复变慢。
因此系统常基于历史往返时延或估计误差来更新计时器。
2.2 基于确认的重传（ACK/NACK）
在该模式下，接收端明确告诉发送端处理结果：
- ACK表示对应分组已成功到达并通过校验；
- NACK表示数据未通过校验、无法接受或出现可识别的错误。
发送端收到否认后可立即重发，减少等待时间；若 NACK 不可靠或不可用，也可能退回到超时机制与序号检测共同完成判断。
2.3 基于序号与乱序处理的重传
序号为“重发什么”提供依据。接收端与发送端通常维护窗口内的序号集合：
- 若出现序号缺口，发送端可能推断中间某些分组未被正确接收；
- 若允许乱序到达，接收端会缓存提前到达的数据，并在补齐缺口后按序交付；
- 对于失败分组，发送端会根据反馈或缺口信息进行针对性重发。
这种方式比“整段从头重发”更节省带宽，但需要更复杂的缓冲和状态维护。
2.4 对丢包、错误与链路中断的适配
触发条件不仅来自“是否收到确认”，也来自对链路状态的理解：
- 丢包：数据或确认反馈丢失都会导致触发重传。
- 错误：差错检测失败会让接收端不确认或发出否认，从而触发重发。
- 链路中断：可能出现持续无响应。此时系统通常采用重传次数上限、退避以及上层故障上报，避免无意义重发。
3 重传策略与算法
同样的重传机制可以有不同“工作方式”，核心差异在于重发范围、确认方式和窗口管理。常见策略包括停等式、选择重传、回退式重传，以及配套的终止与退避机制。
3.1 停等式与累计确认
停等式（Stop-and-Wait）是一种简化模式：发送端一次只发送一个分组，并等待接收端反馈再继续发送下一个。其优势是实现简单；缺点是信道利用率受往返时延限制。 在一些协议中会使用累计确认：接收端对“按序到达到某个边界”的状态进行确认。例如接收端若已按序收到直到序号 N，可能会发送对 N+1 的确认，表示此前分组均可视为成功。
3.2 滑动窗口与选择重传（Selective Repeat）
滑动窗口允许发送端在未收到全部确认前继续发送多个分组，从而提高吞吐。结合选择重传（Selective Repeat），发送端只重发接收端未确认或被判定失败的特定分组：
- 接收端对窗口内分组进行单独确认；
- 对于乱序到达，接收端可缓存并在缺口补齐后再交付；
- 发送端根据缺失的确认信息进行针对性重发。
该策略通常比回退式更高效，但代价是更复杂的缓存与状态同步需求。
3.3 回退式重传（Go-Back-N）
回退式重传（Go-Back-N）适用于较少缓冲或更简单实现的场景：当检测到某个分组失败或确认缺失时，发送端会从该分组开始往后重发，导致在此期间可能已成功到达的后续分组也被重复发送。 Go-Back-N 的特点是逻辑相对直接，代价则是潜在的额外带宽占用。其效率与丢包率、窗口大小和确认粒度有关。
3.4 重传次数上限与终止条件
为了保证系统可用性，重传通常设置最大重传次数或综合终止规则：
- 超过次数后向上层报告失败；
- 或触发链路重建、连接中止、会话终止等流程；
- 在移动或无线环境中，还可能与重新协商参数、切换目标等动作联动。
终止条件并不是“越快越好”，需要兼顾错误恢复的可能性与资源浪费风险。
3.5 退避机制与抖动处理
退避用于控制重传的节奏，避免在拥塞或持续故障时形成“密集重发”。常见做法包括：
- 每次重传后延长等待时间（线性或指数退避）；
- 引入随机抖动（jitter），让多个发送方的重传时刻分散，降低同步导致的雪上加霜。
当网络时延抖动较大时，合理的退避能减少误判与重发风暴。
4 系统层次中的重传实现
重传可出现在不同协议层，其实现方式与可利用的信息不同。链路层往往关注局部链路可靠性；传输层面向端到端的可靠交付；应用层则在业务语义允许时提供更“按需”的重试。
4.1 链路层重传
链路层重传通常用于无线或易误码环境下的局部可靠性。由于链路层更接近物理与链路控制，往往能够获得更快的反馈与更精细的错误统计。 在移动或无线场景，链路层重传还能与资源调度、信道状态估计配合。
4.1.1 HARQ 的基本思想
HARQ（Hybrid Automatic Repeat reQuest）结合了两类手段：
- 通过一定的前向纠错能力先尝试直接恢复；
- 若仍无法解码，则触发重传（或增量式重传）。
这种“先尝试再重发”的混合思想旨在减少不必要的重传次数，同时在链路条件允许时提高吞吐与有效可靠性。
4.2 传输层重传
传输层重传面向端到端交付可靠性。它通常依赖序号、窗口与确认机制：
- 发送端维护未确认数据集合；
- 接收端对到达状态进行反馈；
- 发送端依据丢失判断进行重发，并配合拥塞控制限制发送速率。
在面向连接的传输中，重传与流控制、拥塞控制往往更紧密耦合。
4.3 应用层重传
应用层重传常见于：业务对象较大、可分片、或业务侧允许“幂等重试”。例如下载、表单提交、消息投递等场景会在收到失败或超时后重试。 应用层重传通常会引入业务语义机制：
- 使用请求标识保证幂等，避免重复执行带来副作用；
- 对不同错误类型采取不同策略（例如网络超时重试，校验失败不重试）。
4.4 跨层协同与设计权衡
跨层重传需要权衡可靠性与效率：
- 若链路层与传输层都做重传，可能出现“重复可靠性”，带来更多开销；
- 若上层依赖下层提供的可靠性，却遇到下层参数不匹配，可能导致超时和重试行为不一致；
- 设计上通常会明确每层的职责边界，例如链路层处理局部误码，传输层处理端到端丢失，应用层处理业务语义失败。
5 性能影响与分析指标
重传能提升成功交付概率，但会引入额外时延与带宽消耗。评估重传效果通常需要同时看可靠性、时延和吞吐，以及重传自身带来的开销。
5.1 可靠性指标（误码率、丢包率）
常用指标包括：
- 误码率/校验失败率：反映物理或链路层的损伤程度；
- 丢包率：反映传输中分组未到达或未被确认的比例；
- 最终交付成功率：在经过重传与终止条件后，业务请求成功的比例。
重传的价值往往体现在“最终交付成功率提升”，而不只是单纯降低丢包。
5.2 时延指标（往返时延、重传时延）
重传会增加等待与重发过程中的额外时延。常见评估包括：
- 往返时延（RTT）对超时与窗口推进的影响；
- 重传时延：从首次发送到最终成功确认的增量；
- 尾部时延（如高分位数）：在重传触发更频繁或排队加剧时，尾延迟可能显著变差。
5.3 吞吐与效率
吞吐与效率反映单位时间内成功交付的数据量。重传会改变有效吞吐：
- 在丢包率较低时，重传开销有限，吞吐可能接近理想；
- 在丢包率升高时，重发占用链路资源，导致有效吞吐下降；
- 选择重传与回退式重传在同样条件下可能呈现不同的吞吐表现。
5.4 重传开销与带宽占用
重传引入的直接开销包括：
- 重发的额外分组数；
- 由于确认与缓存导致的控制报文增量；
- 带宽被重复占用，使得其他有效数据的传输被挤压。
因此评估不能只看“有没有重传”，还需要统计重传比例及其对资源的影响。
6 信道与网络环境下的适用性
重传效果依赖环境特性。不同信道模型、时延特征与移动性会让触发频率与策略有效性出现差异。
6.1 有线与无线场景差异
有线链路通常误码与丢包相对可控，时延抖动较小；无线链路则更容易受到干扰、遮挡和信道衰落影响，误码与重传更频繁。 无线系统往往更强调与信道质量相关的自适应重传（如调整码率、选择 HARQ 或优化重传参数），以减少不必要的重发。
6.2 高时延链路中的重传
在高时延链路中，等待确认的成本更高。停等式会显著降低吞吐，通常需要更大的窗口或更灵活的确认与重传方式。 同时，超时参数必须更谨慎：超时过短会造成大量冗余重发，超时过长则拖慢恢复。
6.3 移动性与切换场景
移动终端在切换（漫游、基站切换）过程中可能短时间失联，表现为连续丢失反馈或确认延迟。此时系统常采用：
- 重传次数与退避配合，避免无意义重试；
- 切换触发后重新协商状态或更新计时器；
- 在链路层或传输层引入更快的状态恢复路径。
6.4 拥塞条件下的重传表现
拥塞会造成排队延迟增长、丢包上升，并可能使确认报文也延迟或丢失。结果是重传可能被频繁触发，进一步增加负载。 因此在拥塞背景下，重传策略需要与拥塞控制协同：通过降低发送速率、调整窗口或增大退避，减少“因网络拥堵而重复发送”的恶性循环。
7 与相关机制的联动
重传往往不是孤立存在的。与流量控制、拥塞控制、前向纠错以及缓存去重机制的组合，会决定最终可靠性与效率。
7.1 流量控制对重传的影响
流量控制用于限制发送端速率，避免接收端缓冲被耗尽。当接收端处理能力不足时，过多的数据可能被丢弃或无法及时确认，导致重传被频繁触发。 因此在流量控制与重传共同作用下，需要协调：
- 合理的窗口大小与接收端缓存规模；
- 避免因过量发送使得确认延迟扩大进而触发超时重发。
7.2 拥塞控制与重传的关系
拥塞控制通常通过限制发送速率来抑制网络拥塞。重传与拥塞控制之间存在紧密耦合：
- 重传分组会占用网络容量，等价于增加负载；
- 在丢包被误认为拥塞信号或反之时，控制决策可能受到影响；
- 因此许多系统会区分“因误码/丢失触发的重传”与“拥塞导致的丢包”，以更合适地调节发送策略。
7.3 FEC（前向纠错）与重传的对比与结合
FEC（前向纠错）通过在发送端添加冗余来提升接收端的纠错能力，从而减少对重传的依赖。
- 在信道误码主要由随机噪声驱动时，FEC可能能显著降低重传需求；
- 在突发丢失或严重链路不稳定时，FEC的覆盖可能不足，此时重传仍有必要；
- 两者结合的常见思路是先用FEC尽量恢复，失败后再进行重传，或用增量式冗余配合请求重发。
7.4 缓存与去重（防止重复交付）
当重传发生时，接收端可能收到重复分组。为避免重复处理带来的副作用，需要缓存与去重机制：
- 使用序号判断分组是否已处理；
- 对已交付的数据不再重复提交给上层；
- 对于应用层请求，常结合幂等键或事务标识确保重复请求不会产生重复效果。
8 工程实践与故障排查
工程上实现重传需要选择参数、收集统计，并在异常时定位根因。由于重传涉及多个环节，故障排查通常需要跨层日志与数据对照。
8.1 重传统计与监控
常见监控项包括：
- 每秒重传次数、重传比例；
- 超时触发的次数及平均超时次数；
- ACK/NACK 的成功率与延迟；
- 失败后的终止原因分布（达到上限、链路中断等）。
通过趋势分析可以判断是“偶发丢包”还是“持续性链路质量下降”，以及策略是否过于激进或过于保守。
8.2 常见异常现象（重传风暴、确认延迟）
- 重传风暴：大量分组在短时间内重复发送，通常与超时参数过短、退避不足或拥塞加剧有关。
- 确认延迟：确认报文延迟导致发送端误触发超时重传，即便数据可能已到达。
- 乱序与缓存压力：选择重传或乱序接收需要缓存，若缓存不足可能引发更复杂的失败模式。
8.3 参数调优思路（超时、窗口、退避）
调优一般遵循“先观察再调整”的原则：
- 超时：基于RTT估计与方差选择，避免频繁误重发；
- 窗口大小：在吞吐与缓存占用之间平衡；窗口过小导致链路利用率低，过大可能导致确认延迟与拥塞；
- 退避：在丢包或拥塞持续时增加间隔，并引入随机抖动降低同步重发。
调参通常应结合业务目标，例如更关注尾延迟还是平均吞吐。
8.4 与抓包/日志分析的配合
故障定位常用方法包括：
- 使用抓包对比“发送时间-确认到达时间-重发触发点”；
- 查看协议栈日志中的序号状态与窗口推进情况；
- 对照链路层与传输层事件，判断丢失发生在何处（数据丢了、确认丢了、还是超时判断偏差）。
当多层同时重传时，日志对照尤为重要，以避免误把下层恢复当作上层故障。
9 轻度“梗”与直观类比
9.1 “没收到就再来一遍”的通信直觉
重传的直观理解就是：对方没给你“收到”的回应，你就把同一份内容再发送一次。它本质上是把“不确定”用额外尝试换成“确定性”的交付结果。
9.2 ACK 缺失导致的“反复敲门”现象
如果 ACK 一直没回来，发送端可能会一次次重发。看起来就像你敲门，对方可能已经开了，但你就是听不到回应，于是继续敲得更勤快。
9.3 超时重传的“等不及了就重发”体验
超时机制可以理解为“给你一个等待的上限”。时间到了还没确认，就不再纠结等待的可能性，直接重发以争取更快的恢复。