跳到主要内容

4.2. 生成确认 (Generating Acknowledgments)

延迟 ACK 算法 (Delayed ACK Algorithm)​

TCP 接收方应该使用 [RFC1122] 中规定的 delayed ACK 算法.

使用 delayed ACK 时, TCP 接收方不得过度延迟确认. 具体而言:

  • 至少每收到第二个 full-sized segment, 应该生成一个 ACK
  • 第一个未确认 packet 到达后 500 ms 内必须生成一个 ACK

对应该与必须的澄清​

"至少每收到第二个 full-sized segment 就应该生成一个 ACK" 这一要求在 [RFC1122] 中一处列为应该, 另一处列为必须. 这里明确说明它是应该.

我们还强调, 这是一个应该, 意味着实现者确实只有在仔细考虑其影响之后才应偏离此要求. 关于生成 ACK 的频率低于每第二个 full-sized segment 可能带来的性能问题, 参见 [RFC2525] 中对 "Stretch ACK violation" 的讨论及其引用文献.

Full-Sized Segment 的一致性​

在某些情况下, 发送方和接收方可能无法就什么构成 full-sized segment 达成一致. 如果一个实现每次从发送方接收 2*RMSS 字节新数据时至少发送一个确认, 则认为它符合此要求. 其中 RMSS 是接收方向发送方指定的 Maximum Segment Size (最大报文段大小), 如果接收方在连接建立期间未指定 MSS option, 则按 [RFC1122] 使用默认值 536 字节.

Path MTU Discovery 考虑事项​

由于以下原因, 发送方可能被迫使用小于 RMSS 的 segment size:

  • Maximum Transmission Unit (MTU)
  • Path MTU Discovery 算法
  • 其他因素

例如, 考虑接收方通告的 RMSS 为 X 字节, 但发送方由于 Path MTU Discovery (或发送方的 MTU 大小) 最终使用 Y 字节的 segment size (Y < X) 的情况. 如果接收方等待 2*X 字节到达后才发送 ACK, 它将生成 stretch ACK. 显然, 这需要超过 2 个大小为 Y 字节的 segment.

因此, 虽然本文档不定义具体算法, 但希望接收方尝试避免这种情况, 例如无论大小如何, 至少每第二个 segment 就进行确认.

最大延迟​

最后, 我们重申, ACK 为等待第二个 full-sized segment 到达而被延迟的时间不得超过 500 ms.

乱序 Segment​

乱序 data segment 应该立即确认, 以加速 loss recovery.

为了触发 fast retransmit 算法, 当接收方收到 sequence space 中某个缺口之后的数据 segment 时, 应该立即发送 duplicate ACK.

为了向正在从丢失中恢复的发送方提供反馈, 当接收方收到填补 sequence space 中全部或部分缺口的数据 segment 时, 应该立即发送 ACK.

ACK 频率限制​

除非接收应用消耗新数据时需要更新 advertised window (参见 [RFC813] 和 [RFC793] 第 42 页), TCP 接收方对每个传入 segment 生成的 ACK 不得超过一个.

最后于 更新