为什么我们在传输层和数据链路层需要滑动窗口机制?TCP有自己的滑动窗口机制来管理流和错误。数据链路层也有类似的机制。这不是多余的吗?
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传输协议也是如此。