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

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

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

某些类型的网络链路的错误率可能过高，IP传输协议无法有效处理，因此它们应该提供自己的错误检测层（甚至前向纠错层），以便IP在其上正常工作。最初，（模拟）调制解调器因其速度越来越高而引入了这种完整性保护（例如）。我不太了解目前流行的物理链路种类的细节，但我想说的是，ADSL、wifi和/或3G/4G/LTE中的一种或多种结合了这种技术。我还注意到，我认为所有这一切都发生在物理层（第1层），而不是在数据链路层（第2层），虽然辩论是可能的，因为OSI层模型从来都不适合于真实的网络世界。 这种错误控制并不一定意味着物理层（或者数据链路层，如果您愿意的话）有任何类型的滑动窗口。在为最不可靠的物理链路设计的一些更复杂的方案中，它可能有，但所有最简单的错误检查都没有：例如，PPP和以太网。对于FCS，就像UDP校验和一样，损坏的数据包将被丢弃，协议没有内存或窗口来重新传输失败的帧，并且不会向发送方确认成功接收到的帧（这在任何滑动窗口协议中都是推进窗口所必需的）

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

这是用于错误控制的。关于流量控制，也可以这样说：尽管存在一些复杂的方案来处理各种物理链路，否则IP将无法正常工作，但大多数简单的方案不涉及任何类型的滑动窗口。例如，当通过串行链路进行通信时，流控制是一条简单的二进制控制线：断言时，另一端发送数据，解除断言时，另一端暂停。它不记得以前在窗口中传输的任何数据，也不接收确认

---

最后一点意见：UDP是一种不可靠的传输协议。使用UDP时，应用程序负责管理超时和重新传输。在单个应用程序处理它的能力方面存在很多差异。有些人对此非常反感。由于（前向）纠错至少由一些最不可靠的物理链路层提供，因此至少在UDP中这种情况是可以容忍的，尽管不可靠，“通常”是有效的。一些非TCP、非UDP传输协议也是如此。

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

某些类型的网络链路的错误率可能过高，IP传输协议无法有效处理，因此它们应该提供自己的错误检测层（甚至前向纠错层），以便IP在其上正常工作。最初，（模拟）调制解调器因其速度越来越高而引入了这种完整性保护（例如）。我不太了解目前流行的物理链路种类的细节，但我想说的是，ADSL、wifi和/或3G/4G/LTE中的一种或多种结合了这种技术。我还注意到，我认为所有这一切都发生在物理层（第1层），而不是在数据链路层（第2层），虽然辩论是可能的，因为OSI层模型从来都不适合于真实的网络世界。 这种错误控制并不一定意味着物理层（或者数据链路层，如果您愿意的话）有任何类型的滑动窗口。它可能在一些为最不可靠的物理链路设计的更复杂的方案中存在，但所有simp