为什么我们在传输层和数据链路层都需要滑动窗口机制？ TCP 有自己的滑动窗口机制来管理流和错误。此外，数据链路层也有类似的机制。这不是多余的吗？
【问题讨论】：
标签： tcp sliding-window
TCP 和 UDP 的错误控制是覆盖每个数据包的单个校验和。如果失败，则必须丢弃整个数据包，然后，当接收方超时后无法确认收到数据时，必须重新发送数据。即使在网络路径上的两个路由器之间的一条数据链路上引入了数据损坏，数据也必须从原始发送者重新发送，并再次跨越多个网络跃点。这是相当昂贵的，因此这种数据完整性检查适用于错误率很低并且重传成本分摊到许多成功传输的数据包的情况。此外，简单的校验和不是那么健壮，它会遗漏一些错误。
某些类型的网络链接的错误率可能太高，以至于 IP 传输协议无法有效处理，因此它们应该提供自己的错误检测层（甚至前向纠错），以便IP 在他们身上工作得很好。最初，众所周知，（模拟）调制解调器引入了这种完整性保护（例如V.42），因为它们的速度越来越高。我不太了解这些天流行的物理链接类型的详细信息，但我认为DOCSIS、ADSL、wifi 和/或 3G/4G/ 中的一个或多个是一个不错的选择LTE 采用了这种技术。我还要指出，我认为所有这些都发生在物理层（第 1 层），而不是数据链路层（第 2 层），尽管可能对此进行辩论，因为 OSI 层模型永远不会完全适合真实的网络世界。
这种错误控制并不一定意味着物理层（或数据链路层，如果您愿意）具有任何类型的滑动窗口。它可能有一些为最不可靠的物理链路类型设计的更复杂的方案，但所有最简单的错误检查类型都没有：例如，PPP 和以太网FCS。使用 FCS，就像使用 UDP 校验和一样，损坏的数据包将被简单地丢弃，并且协议没有内存或窗口可以从中重新传输失败的帧，并且它不会向发送者确认成功接收到的帧（即在任何类型的滑动窗口协议中都需要推进窗口）。
话虽如此，传输层错误控制机制仍然必不可少，因为它是end to end。只有在这一层才会捕获传输介质引入的错误以外的错误。 IP 传输协议的校验和将捕获发生在路由器内部的损坏、由无法或无法捕获错误的物理介质引入的错误，或者主机设备或设备驱动程序中的错误。
那是为了错误控制。关于流量控制也可以这样说：虽然可以存在一些复杂的方案来处理各种物理链路，否则这些物理链路会导致 IP 无法正常工作，但大多数简单方案不涉及任何类型的滑动窗口。例如，当通过RS-232 串行链路进行通信时，流控制是一个简单的二进制控制线：当它被断言时，另一端发送数据，当它被取消断言时，另一端暂停。它不会记住任何以前在窗口中传输的数据，也不会收到确认。
最后一条评论：UDP 是一种不可靠的传输协议。使用 UDP 时，应用程序负责管理超时和重传。单个应用程序处理它的程度有很多变化。有些对它很糟糕。由于（前向）纠错至少是由一些最臭名昭著的不可靠物理链路层提供的，因此至少这种情况在 UDP 中是可以容忍的，尽管不可靠，但“通常”可以工作。一些非 TCP、非 UDP 传输协议也是如此。
【讨论】：