在上一篇中，我们聊到了“半双工以太网是否可以执行连续ARQ协议”，结论是：在原理层面存在严重冲突，实践中更难落地。

今天，我们不再停留在“能不能”的层面，而是进一步来聊一聊——到底“卡”在哪儿？连续ARQ为啥在半双工以太网里这么水土不服？

答案，得从以太网的链路控制机制说起。

什么是半双工以太网的底层控制机制？

早期的10M/100M以太网主要依靠 CSMA/CD（Carrier Sense Multiple Access with Collision Detection，载波监听多路访问/冲突检测）来协调通信。

简单理解这个机制就是：“先听后说，边说边听，有冲突就闭嘴、退避。”

关键步骤：

监听链路是否空闲；如果空闲就开始发送；如果同时有人也开始说话——发生冲突（Collision）；所有冲突方停止发送，进入退避算法（随机等待一段时间后重试）。

这套机制天生适配广播型的共享链路，但同时也导致了一种极端依赖时序的通信行为。

那连续ARQ要什么条件？

连续ARQ（如滑动窗口协议）希望：

发送方能连续发多个数据帧，不用等确认；

接收方能随时返回ACK，让发送方知道哪些包收到、哪些该重传；

理想的是：ACK还能插队优先传出，避免窗口阻塞。

听起来很美好，问题是……

这些条件，在半双工以太网上，全都卡住了！

来，一条一条分析：

阻碍一：无法“边发边收”ACK

连续ARQ的核心优势在于实时反馈。

但半双工链路物理上不能同时传输双向数据，ACK只能在数据帧发送间隙返回。

一旦数据帧接连不断，接收方就插不进ACK。发送方窗口满了，只能停下来，等超时——这就失去了连续ARQ的效率优势。

阻碍二：冲突检测让ACK“发不出去”

你可能会说：那我等一帧发完就立刻抢链路发ACK不就行了？

理论上可行，但：

ACK体积小，容易和下一帧发送产生时间竞争；

一旦冲突，ACK发不出去；

然后退避、等待、冲突、再退避……

这在CSMA/CD下会造成不确定延迟，滑动窗口就崩了。

阻碍三：退避机制破坏了滑窗节奏

假设发生冲突，ACK触发指数退避（Binary Exponential Backoff），它的随机等待会引起整个传输节奏紊乱。

连续ARQ的“精细节拍”一下就被打乱，帧序号、ACK对齐、窗口移动都乱套，从而频繁超时、误重传。

阻碍四：缺乏信道控制，无法优先调度ACK

现代全双工链路中，ACK往往可以作为高优先级“控制帧”被调度快速送出（如TCP ACK Piggyback机制）。

但在半双工以太网中，没有类似QoS或优先级调度机制，ACK和数据帧抢一样的“时间资源”，而且抢不过大帧。

这也意味着：连续ARQ的反馈链条容易“断”。

举个工程类比：全双工就像高速路，半双工像村道

连续ARQ就像一套智能物流系统，要想跑起来：

路必须够宽（支持双向）；

车辆（ACK帧）要能灵活调度；

没有红绿灯和逆行限制；

不能一会儿堵、一会儿开。

而半双工以太网就像一条单车道乡村小路：

一边来车，另一边必须停；

谁先谁后全靠礼让和等待；

稍微一堵，就全线瘫痪。

再高效的物流系统，放在村道上也只能“停等式”跑。

那为什么还有人用半双工链路？

因为它简单、成本低、抗干扰强。比如：

工业现场的RS485串口；无线对讲信道；某些低成本嵌入式通信接口。

这些场景对吞吐率没那么敏感，更关心稳定性和物理兼容性。

这时候就会用停等ARQ或者干脆“简单重发+CRC”方案，不玩连续ARQ那套复杂机制。

总结一下

连续ARQ需要高速、双向、低延迟、可预测的反馈链路；

而半双工以太网是非实时、抢占式、不可预期的链路。

所以说——

理论上连续ARQ可以跑，但实践中根本跑不动；不但跑不动，还可能跑得比停等还差；更别说TCP这种建立在连续ARQ之上的协议。