为何ACK是TCP段必含字段而非可选？连续发送段的ACK冗余疑问

问题1：为何ACK是每个TCP段必须包含的字段，而非TCP段选项部分的字段？ #

问题2：为何在连续发送两个TCP段且期间未接收任何段时，第二段仍要包含ACK？既然两段间未接收数据，ACK值不会变化，第二段的ACK未传递新信息，能否省略？ #

示例场景 #

[1] Client -> SYN, SEQ=100
[2] Client <- SYN, ACK, SEQ=700, ACK=101 <- Server
[3] Client -> ACK = 701, SEQ=101 [50 Bytes of data]
[4] Client -> ACK = 701 [未收到服务器新数据], SEQ = 151 

此示例中，[4]段的ACK=701已在[3]中说明，且两段间无接收，能否省略？

补充观点：有观点认为TCP段必须含ACK字段，与其设为无效值+ACK标志0，不如设标志1并存储有效正确值提升可靠性，不影响性能。但由此引出新问题：为何不将ACK设为可选字段（置于TCP选项部分），在上述重复场景中省略以减少冗余、提升性能？

解答 #

针对问题1：为什么ACK是固定必选字段而非选项？

1. 协议核心逻辑的统一性：TCP的核心是可靠传输，确认机制是实现可靠性的基础。把ACK设为固定字段，能让两端的协议栈处理逻辑更简单——不用额外判断报文里有没有ACK选项，直接读取固定位置的字段即可，减少了状态机的分支和出错概率。
2. 处理效率优先：早期网络设备和主机的计算能力有限，固定长度的头部字段比可变长度的选项解析速度快得多。如果把ACK放到选项里，每个报文都要遍历选项列表查找ACK，会增加解析开销，拖慢整体传输效率。
3. 兼容性与健壮性：TCP作为通用传输协议，需要保证不同设备、不同版本的协议栈都能兼容。固定字段的设计更稳定，不会因为选项的存在与否导致解析失败，避免了协议碎片化的问题。

针对问题2：为什么重复ACK不能省略？

1. ACK不止是序号——还带接收窗口信息：你看到的示例里只写了ACK序号，但实际TCP段中，ACK字段和接收窗口大小是绑定的。即使ACK序号没变，接收端的缓存状态可能已经变化（比如缓存快满了，窗口缩小），这时候必须通过后续段的ACK传递最新的窗口大小，否则发送端可能会继续发数据导致丢包。
2. 补发确认，避免不必要的重传：如果之前的ACK段（比如示例中的[3]）在传输过程中丢了，后续段（[4]）的ACK就能起到补发确认的作用，让服务器知道之前的数据已经被接收，不用触发超时重传，提升了传输的可靠性。
3. 协议规则的简化：TCP的状态机设计里，除了SYN、FIN这类初始化/终止段，正常的数据段默认要求ACK标志位为1。统一的规则让两端的协议栈不用额外判断“要不要带ACK”，减少了逻辑复杂度，也降低了出错的可能。
4. 冗余的代价远小于复杂度的代价：TCP头部固定20字节，ACK字段占4字节，看似省了4字节，但为了支持“可选ACK”，需要增加额外的标志位、解析逻辑，反而会引入更多的bug和兼容性问题，得不偿失。

针对补充疑问：为什么不把ACK放到选项里？

本质上和问题1的核心原因一致：选项是为了扩展非核心功能设计的，而ACK是TCP可靠传输的核心机制，几乎每个报文都需要用到。把核心字段放到选项里，会大幅增加协议的复杂度和解析开销，早期的网络设备根本无法高效处理这种设计。另外，固定字段的设计保证了协议的向后兼容性——老版本的协议栈不需要处理选项也能正常解析ACK，这对于TCP的大规模推广至关重要。

内容的提问来源于Stack Exchange，提问作者CS Student