摘要

  • 接收方可以暂缓确认第一个普通按序报文段，让第二个报文段或本端响应与确认共用一次发送。
  • 等待并非任意沉默：第二个完整报文段、计时器到期或丢包相关迹象都会触发 ACK。

先看接收方内部发生了什么。第一个完整报文段到达后，字节已经被接受，接收方所期望的下一个序号也已经前移；尚未发生的只是把这个事实送回发送方。若第二个完整报文段很快到达，一份累积 ACK 就能覆盖两段。若它没有到来，计时器会把确认释放出去。因此，延迟的是证据的发送时刻，不是接收事实本身。

RFC 1122 在 1989 年把这种做法写成主机要求。TCP 应实现延迟 ACK，以减少每个数据段都配一个纯确认所造成的主机与网络开销。但标准同时划了两条线：延迟必须小于 0.5 秒；在连续完整报文段中，至少每两个报文段应有一个 ACK。它从来不是无限压低确认频率的许可。

这段等待还给本端状态一次合并机会。RFC 1122 以字符式远程登录为例：应用读走字符后可能更新窗口并立即回显。略等片刻，ACK、窗口更新和回显数据便可能装进同一报文段。收益并不只在少一个首部，而在于把相邻的真实变化一起报告。

RFC 5681 进一步澄清确认频率。RFC 1122 对“每两个完整报文段确认一次”的规范措辞并不一致，RFC 5681 明确将其表述为 SHOULD，并再次规定等待第二段不得超过 500 毫秒。它还指出 RMSS 计数的陷阱：接收方宣布的 MSS 可能大于发送方因路径 MTU 实际采用的报文段。若机械等待两倍 RMSS，一个 ACK 就可能跨过两个以上的实际报文段，形成 stretch ACK。按实际报文段计数是避免这种拉长的一种办法。

一旦序号空间出现缺口，合并优先级就让位于恢复证据。高于缺口的数据应尽快触发重复 ACK；填补全部或部分缺口的数据也应得到立即反馈。此时 ACK 不只是“我收到了”，还是发送方判断丢失位置与恢复进度的输入。

RFC 2525 把 stretch ACK 记录为已知实现问题。问题不只是抓包中确认变少；ACK 到达参与发送方的控制节奏。过度合并可能拖慢窗口增长，也可能让数据以更突兀的批次释放。这个历史故障解释了为什么延迟必须既可观察又有上限。