tcp - 传输层和数据链路层的滑动窗口

Question

为什么我们在传输层和数据链路层都需要滑动窗口机制？TCP 有自己的滑动窗口机制来管理流和错误。此外，数据链路层也有类似的机制。这不是多余的吗？

Answer 1

TCP 和 UDP 的错误控制是覆盖每个数据包的单个校验和。如果失败，则必须丢弃整个数据包，然后，当接收方超时后无法确认接收到数据时，必须重新发送数据。即使在网络路径上的两个路由器之间的一条数据链路上引入了数据损坏，数据也必须从原始发送方重新发送，并再次跨越多个网络跃点。这是相当昂贵的，因此这种数据完整性检查适用于错误率很低并且重传成本分摊在许多成功传输的数据包上的情况。此外，简单的校验和不是那么健壮，它会遗漏一些错误。

某些类型的网络链接的错误率可能太高，以至于 IP 传输协议无法有效处理，因此它们应该提供自己的错误检测层（甚至前向纠错）以使 IP 正常工作远远超过他们。最初，众所周知，（模拟）调制解调器引入了这种完整性保护（例如V.42），因为它们的速度越来越高。我不太了解这些天流行的各种物理链接的细节，但我会说一个或多个DOCSIS是一个不错的选择、ADSL、wifi 和/或 3G/4G/LTE 采用了这种技术。我还要指出，我认为所有这些都发生在物理层（第 1 层），而不是数据链路层（第 2 层），尽管可能对此进行辩论，因为 OSI 层模型永远不会完全适合真实的网络世界。

这种错误控制并不一定意味着物理层（或数据链路层，如果您愿意）具有任何类型的滑动窗口。它可能具有为最不可靠的物理链路类型设计的一些更复杂的方案，但所有最简单的错误检查类型都没有：例如，PPP 和以太网FCS。使用 FCS，就像使用 UDP 校验和一样，损坏的数据包将被简单地丢弃，并且协议没有用于重新传输失败帧的内存或窗口，并且它不会向发送者确认成功接收的帧（即在任何类型的滑动窗口协议中都需要推进窗口）。

尽管如此，传输层错误控制机制仍然是必不可少的，因为它是端到端的。只有在这一层才会捕获传输介质引入的错误以外的错误。IP 传输协议的校验和将捕获发生在路由器内部的损坏、由不能或不能捕获错误的物理介质引入的错误，或者主机设备或设备驱动程序中的错误。

那是为了控制错误。关于流量控制也可以这样说：虽然可以存在一些复杂的方案来处理各种物理链路，否则这些物理链路会导致 IP 无法正常工作，但大多数简单方案不涉及任何类型的滑动窗口。例如，当通过RS-232串行链路进行通信时，流控制是一条简单的二进制控制线：当它被断言时，另一端发送数据，当它被取消断言时，另一端暂停。它不会记住窗口中任何先前传输的数据，也不会收到确认。

最后一条评论：UDP 是一种不可靠的传输协议。使用 UDP 时，应用程序负责管理超时和重传。单个应用程序处理它的程度有很多变化。有些对它很糟糕。由于（前向）纠错至少是由一些最臭名昭著的不可靠物理链路层提供的，因此至少这种情况在 UDP 中是可以容忍的，尽管不可靠，但“通常”可以工作。对于一些非 TCP、非 UDP 传输协议也可以这样说。