TCP 超时重传机制是为了解决什么问题？

【核心定义】
TCP 超时重传机制是为了解决数据包在不可靠的 IP 网络中可能丢失、延迟或乱序的问题，确保数据可靠传输。

【关键要点】

1. 解决丢包问题：当发送方发送的数据包未在预期时间内收到确认（ACK），会触发重传，避免因网络丢包导致通信中断。
2. 动态适应网络：通过计算往返时间（RTT）动态调整超时重传时间（RTO），避免过早或过晚重传，提升传输效率。
3. 保障数据有序性：结合序列号和确认机制，重传时只重传丢失的报文段，接收方按序重组数据，确保应用层获得有序字节流。

【深度推导/细节】

• RTO 计算逻辑：
  • Step 1：采样 RTT（从发送数据到收到 ACK 的时间），使用平滑算法（如 Karn/ Jacobson 算法）过滤异常值（如重传导致的 ACK 混淆）。
  • Step 2：基于平滑 RTT（SRTT）和波动范围（RTTVAR），按公式 RTO = SRTT + 4 × RTTVAR 计算，确保 RTO 略大于实际 RTT，兼顾效率和容错。
• 快速重传优化：若连续收到 3 个重复 ACK（如 ACK 号相同），立即重传对应数据包，而不等待 RTO 超时，减少延迟（TCP Reno/NewReno 算法）。
• 重传歧义处理：重传后收到的 ACK 可能对应原始包或重传包，Karn 算法规定重传时不更新 RTT 采样，避免误差。

【关联/对比】

• 与 UDP 对比：UDP 无重传机制，依赖应用层处理丢包，适合实时性要求高、可容忍丢失的场景（如音视频流）。
• 与 QUIC 对比：QUIC 在 UDP 上实现类似 TCP 的重传，但使用独立 Packet Number 消除重传歧义，避免“队头阻塞”。

『面试官追问』

1. 超时重传时间（RTO）设置过长或过短有什么问题？
   • 过短：导致不必要的重传，浪费带宽，加剧网络拥塞。
   • 过长：丢包后等待确认时间久，降低吞吐量，影响实时性。
2. 什么是 Karn 算法？为什么需要它？
   • 解决重传歧义：重传后无法判断 ACK 对应原始包还是重传包，因此重传时不更新 RTT 采样，避免 RTO 计算失真。
3. TCP 有哪些重传机制？区别是什么？
   • 超时重传：基于 RTO 计时器，应对严重丢包。
   • 快速重传：基于重复 ACK，应对单包丢失，效率更高。
   • 选择性重传（SACK）：通过 SACK 选项告知发送方已接收的数据块，只重传真正丢失的片段，减少冗余。

【直击痛点】

• 初始 RTO 值：Linux 默认为 1 秒（RFC 6298 建议），避免初始阶段因 RTT 采样不足导致频繁超时。
• RTO 下限与上限：通常下限为 200ms（防止过度敏感），上限为 60s（避免等待时间无限延长）。
• 指数退避：重传失败后 RTO 加倍（如 1s → 2s → 4s…），避免拥塞恶化，体现“拥塞控制”协同设计。

【逻辑复现：超时重传触发流程】
Step 1：发送方发送 Seq=100 的数据包，启动重传计时器（初始 RTO=1s）。
Step 2：若在 1s 内收到 ACK=150（确认收到 100-149 数据），则取消计时器，正常推进窗口。
Step 3：若 1s 内未收到 ACK，判定丢包，重传 Seq=100 的数据包，并将 RTO 翻倍（退避至 2s）。
Step 4：重复 Step 3 直到收到 ACK 或达到重传上限（如 15 次）后断开连接。

【版本差异】

• 早期 TCP（Tahoe）：只支持超时重传，遇到丢包时窗口骤降至 1，效率低。
• TCP Reno：引入快速重传和快速恢复，收到 3 个重复 ACK 后不重置窗口，提升性能。
• TCP NewReno：改进快速恢复，能处理多个包丢失的场景，避免多次重传超时。
• Linux 内核优化：采用更精确的 RTT 测量（如 TCP Timestamps 选项），并支持 SACK 默认启用，重传精度更高。

（注：本题未涉及数据结构与核心算法外的其他要求，故未扩展线程安全等内容，聚焦于 TCP 重传机制本身。）