TCP处理丢失ACK的机制及无线物理层下的适配问题咨询

一、TCP针对丢失ACK的默认响应机制 #

TCP从设计之初就是为有线网络打造的，它的核心假设是：所有丢包（包括丢失ACK）都是网络拥塞导致的——也就是中间路由器的队列满了，没法处理更多数据包。

当TCP检测到ACK丢失时，主要有两种响应路径：

• 快速重传+快速恢复：如果收到3个重复的ACK（意味着对方没收到某个分段，一直在发重复确认），TCP会立刻重传丢失的分段，同时把拥塞窗口（cwnd）减半，将慢启动阈值（ssthresh）设为当前cwnd的一半，然后进入拥塞避免阶段，缓慢增大窗口。
• 超时重传（RTO）：如果超过了重传定时器还没收到ACK，TCP会认为这个分段彻底丢了，直接重传，同时把cwnd重置为1，ssthresh设为之前cwnd的一半，重新进入慢启动阶段，一点点增大窗口。

不管哪种情况，核心逻辑都是收缩发送速率，避免加剧“拥塞”。

二、为什么这套机制在无线物理层场景下不适用？ #

无线物理层的丢包和有线网络的拥塞丢包本质完全不同：

• 无线丢包的原因是链路质量问题：比如信号衰减、电磁干扰、多径衰落、移动过程中的切换丢包，这些情况下，网络核心（路由器、交换机）根本没有拥塞，链路本身还有富余带宽。
• TCP的“拥塞应对”完全搞错了问题根源：它看到丢ACK就立刻降速，相当于“明明是路滑（无线链路差），却非要把油门踩到底再松掉（降窗口）”，完全没必要。

举个例子：假设无线链路的实际带宽是10Mbps，但因为偶尔的信号干扰丢了一个ACK，TCP直接把窗口砍半，发送速率降到5Mbps以下，这就白白浪费了一半的可用带宽。

三、错误响应带来的具体后果 #

• 吞吐量严重不足：无线链路的潜在带宽没法被充分利用，TCP的发送速率被人为限制，导致数据传输效率极低。
• 延迟波动大：超时重传时窗口重置为1，需要重新慢启动，这个过程会导致数据发送突然变慢，延迟陡增，对实时业务（比如视频通话、在线游戏）极其不友好。
• 链路资源浪费：TCP的重传机制会发送重复数据，反而增加了无线链路的负载，可能进一步加剧链路错误（比如干扰），形成恶性循环。
• 协议适配性差：如果不做修改，TCP在无线环境下的表现会比UDP差很多，甚至没法满足基本的传输需求。

内容的提问来源于stack exchange，提问作者James Ferry