从握手到交付：拆解可靠数据传输的核心机制

date
Mar 7, 2025
slug
From-Handshake-to-Delivery-Disassembling-the-Core-Mechanisms-of-Reliable-Data-Transmission
status
Published
tags
Network
summary
type
Post
Created Time
Mar 7, 2025 08:13 AM
Updated Time
Mar 7, 2025 08:39 AM
AI summary
Status
当我们在网页上流畅观看视频时，背后是数十个可靠传输机制在精密协作。本文将深入解析这些守护互联网通信的"隐形卫士"，揭示它们如何协同构建可靠的数字传输通道。

一、可靠传输的本质挑战

在不可靠的IP协议之上构建可靠通信，就像在颠簸的货运通道中确保瓷器无损送达。核心需要解决三大问题：
  1. 数据损坏：信号干扰导致比特翻转
  1. 数据丢失：路由器拥塞引发丢包
  1. 数据乱序：网络路径差异造成顺序错乱

二、核心防御机制详解

1. 检验和（Checksum）

工作原理：
发送方将数据分割为16位字，通过二进制反码求和运算生成校验码。接收方重复计算并与校验码比对，误差检出率可达99.998%。
典型场景：
TCP首部校验发现错误时直接丢弃报文，不发送任何确认，触发发送方超时重传。

2. 定时器（Timer）

动态调整策略（Jacobson 算法）：
  • RTT （往返时间，Round - Trip Time）样本测量：在发送每个数据包时记录发送时间，当收到该数据包的确认信息时记录接收时间，两者之差即为该数据包的 RTT 样本（RTTsample）。
  • 平滑 RTT 估算：使用一个指数加权移动平均（EWMA）公式来估算平滑的 RTT（EstimatedRTT）。公式为EstimatedRTT=(1−α)×EstimatedRTT+α×RTTsample，其中 α 是一个介于 0 和 1 之间的平滑因子，通常取值为 0.125。这个公式的作用是让新的 RTT 样本在估算中占有一定的权重，同时保留之前估算结果的影响，使得估算结果更加稳定。
  • RTT 偏差估算：除了估算平滑的 RTT，还需要估算 RTT 的偏差（DevRTT），它反映了 RTT 样本的波动情况。公式为 DevRTT=(1−β)×DevRTT+β×｜RTTsample−EstimatedRTT｜，其中 β 是另一个平滑因子，通常取值为 0.25。
  • 定时器时长设置：根据估算的平滑 RTT 和 RTT 偏差，定时器的时长（TimeoutInterval）可以通过公式 TimeoutInterval=EstimatedRTT+4×DevRTT 来计算。加上 4 倍的 RTT 偏差是为了在 RTT 波动较大时，能够避免过早超时。
问题提出：在使用 Jacobson 算法时，如果发生了重传，就会出现一个问题：当收到一个确认信息时，无法确定这个确认信息是针对原始数据包的还是针对重传数据包的。如果将这个确认信息对应的时间差当作 RTT 样本，可能会导致估算结果不准确。
解决方法：Karn 算法规定，在计算 RTT 样本时，不考虑重传数据包的确认信息。当发生重传时，只使用第一次发送数据包时记录的时间来计算 RTT 样本。同时，为了避免因重传导致的定时器时长不准确，在重传时会将定时器时长加倍。例如，第一次超时后重传，新的定时器时长为原来的 2 倍；如果再次超时重传，定时器时长将变为上一次的 2 倍，以此类推。
重传策略演进：
早期 TCP 采用固定超时阈值，现代实现如 Linux TCP 使用更精细的时钟粒度（最小1ms）和动态调整算法。

3. 序号（Sequence Number）

设计精妙：
  • 32 位循环序号空间可支持 10Gbps 网络持续传输 4 小时不重复
  • 初始序号（ISN）采用时钟驱动，每 4 微秒+1，避免旧连接干扰
乱序处理：
接收端维护接收窗口，对超前到达的数据执行缓存，直到收到缺失的报文段。

4. 确认与否定确认

ACK优化策略：
  • 累积确认：ACK n 表示已正确接收 n 之前所有字节
  • 延迟确认：等待 500ms 合并多个 ACK（可配置）
  • 选择性确认（SACK）：RFC 2018扩展，标记接收缓存中的不连续块
NAK创新应用：
QUIC 协议中的否定确认可携带丢失报文的具体位置信息，实现精准重传。

5. 滑动窗口与流水线

窗口动态调节：
  • 调节的因素
    • 接收方的通告窗口（Advertised Window）: 接收方会在确认信息中告知发送方自己当前的接收缓冲区剩余空间大小，这个值就是通告窗口（rwnd）。发送方的发送窗口大小不能超过接收方的通告窗口，因为如果发送的数据量超过了接收方的处理能力，会导致接收方缓冲区溢出，造成数据丢失。
    • 网络拥塞状况：网络拥塞会导致数据包丢失、延迟增加等问题。为了避免网络拥塞，发送方需要根据网络的拥塞状况动态调整窗口大小。发送方通过观察数据包的丢失和延迟情况来判断网络是否拥塞。
  • 动态调节的算法
    • 慢启动（Slow Start）
      • 启动阶段：当发送方开始发送数据时，初始窗口大小（cwnd，拥塞窗口）通常设置为一个较小的值，例如 1 个最大段长度（MSS）。
      • 增长方式：每收到一个确认信息，拥塞窗口大小就增加 1 个 MSS。也就是说，在每个往返时间（RTT）内，拥塞窗口的大小会翻倍。例如，在第一个 RTT 内发送了 1 个 MSS 的数据，收到确认后，拥塞窗口变为 2 个 MSS；在第二个 RTT 内可以发送 2 个 MSS 的数据，收到确认后，拥塞窗口变为 4 个 MSS，以此类推。
      • 阈值设置：为了避免窗口增长过快导致网络拥塞，会设置一个慢启动阈值（ssthresh）。当拥塞窗口大小达到慢启动阈值时，慢启动阶段结束，进入拥塞避免阶段。
    • 拥塞避免（Congestion Avoidance）
      • 增长方式：在拥塞避免阶段，每收到一个确认信息，拥塞窗口大小增加 1/cwnd 个 MSS。也就是说，在每个 RTT 内，拥塞窗口大小增加 1 个 MSS。这种增长方式比慢启动阶段要缓慢，有助于避免网络拥塞。
      • 拥塞检测：如果发送方检测到数据包丢失（通常通过超时或收到 3 个重复的确认信息来判断），就认为网络发生了拥塞。此时，慢启动阈值会被设置为当前拥塞窗口大小的一半，拥塞窗口大小会被重置为 1 个 MSS，然后重新进入慢启动阶段。
    • 快速重传与快速恢复（Fast Retransmit and Fast Recovery）
      • 快速重传：当发送方收到 3 个重复的确认信息时，说明有一个数据包可能丢失了，但网络还没有完全拥塞。此时，发送方会立即重传该数据包，而不需要等待定时器超时。
      • 快速恢复：在快速重传之后，进入快速恢复阶段。拥塞窗口大小会被设置为慢启动阈值加上 3 个 MSS（因为收到了 3 个重复的确认信息，说明有 3 个数据包已经离开了网络）。然后，每收到一个重复的确认信息，拥塞窗口大小增加 1 个 MSS。当收到一个新的确认信息时，快速恢复阶段结束，拥塞窗口大小会被设置为慢启动阈值，进入拥塞避免阶段。
流水线优化：
现代 TCP 实现支持窗口缩放选项（Window Scaling），可将窗口最大值从 65KB 扩展到 1GB（通过 14位缩放因子）。

三、机制协同工作流

  1. 发送端将数据按 MSS 分块，附加序号和校验和
  1. 滑动窗口内的报文可连续发送
  1. 接收端校验后返回累积 ACK
  1. 重复 ACK 触发快速重传（三次重复 ACK）
  1. 超时触发慢启动阈值降为当前 cwnd 一半
  1. 新的 ACK 到达时窗口向右滑动

四、现代传输协议演进

  • QUIC协议：在UDP层实现多流复用，0-RTT连接建立
  • BBR拥塞控制：基于带宽和延迟估计的智能控制算法
  • 前向纠错：在视频传输中预先发送冗余数据包

五、总结思考

可靠传输机制如同精密的瑞士手表，每个齿轮的运转都影响着整个系统的精度。从早期的停等协议到现在智能化的拥塞控制，这些机制持续演进的核心逻辑始终未变：用适度的冗余换取绝对的可靠。理解这些基础原理，是我们设计高可靠分布式系统的必备基石。
"网络可靠性的实现，本质上是将不确定性转化为可控的确定性。" —— 计算机网络专家David Clark
延伸阅读：
  1. RFC 793 - TCP协议规范
  1. 《TCP/IP详解》卷1
  1. Google BBR算法白皮书
 

© 孙东辉 2022 - 2025