滑动窗口协议是否需要全双工数据流支持？

滑动窗口协议运行是否必须建立全双工连接？ #

结论：协议本身不强制要求全双工，但所有实际商用实现都运行在全双工链路上。
从协议规范层面看，滑动窗口没有对链路的双工模式做强制约束，半双工链路（同一时间仅支持单向数据传输）理论上也能运行滑动窗口逻辑，但这种场景下滑动窗口的连续传输、捎带确认等性能优势会完全消失，传输效率会退化到和停等协议差不多，属于理论可行但毫无工程价值的用法，因此你能接触到的L2层滑动窗口实现（比如HDLC、PPP的流量控制机制）全部默认运行在全双工链路上。

关于ACK回传时机的理解是否正确？ #

核心方向正确，但细节上不存在“同步回传”“固定帧序号对应回传时机”的强制要求：

• 滑动窗口的核心规则是发送方不需要等待前序帧的ACK返回，就可以连续发送窗口大小范围内的所有帧。以你举的窗口大小为5的场景为例，发送方完全可以在未收到任何ACK的情况下，连续发完第1到第5个共5个数据帧，不需要在发送第3个帧的节点等待第1个帧的ACK。
• 接收方的ACK回传时机非常灵活：可以每收到1个帧就立刻回传对应ACK，也可以攒多个收到的帧后回传1个累计ACK（比如收到第1、2个帧后，回传ACK值为3，表示序号3之前的所有帧都已正确接收，发送方接下来可以从第3个帧开始继续发），还可以把ACK信息捎带在自身要发给对端的数据帧里传输，完全不需要和发送方的发帧动作做严格时间同步。
• 协议层面唯一的硬约束是：当发送方把当前窗口内的所有帧都发送完毕、仍未收到新的ACK推进窗口滑动时，必须暂停发送等待ACK，不能发送超出窗口大小范围的帧。实际实现中接收方只会在缓存快占满、检测到发送方即将发完窗口内帧、或者出现帧丢失需要触发重传时回传ACK，不存在“发送方传第3个帧时必须回传第1个帧ACK”的固定规则。

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