我目前正在研究相当基本的网络，我目前正在研究可靠的传输问题。我正在使用Kurrose＆amp; amp; Ross和两个评论问题如下：
使用selective-repeat / go-back-n协议，有可能 发送方接收不属于其的数据包的ACK 当前窗口？
对于SR版本，我对问题的回答如下：
是的，如果窗口大小对于序列号空间来说太大。对于 例如，接收器获得的数据包数等于空间 序号。它的接收窗口因此而移动 期待一组新的数据包与序列号相同 最后一个。接收器现在为每个数据包发送一个ACK，但是 所有这些都在路上丢失了。这最终会导致发件人 为每个前一组数据包超时，并重新发送 他们每个人。接收方认为这是一组重复的数据包 真的是它所期待的新的，并且它发送了ACK 每个成功到达发件人的人。发件人现在 遇到类似的困惑，它认为是ACK 确认已收到每个旧数据包， 当它们确实是针对新的，尚未发送的数据包的时候。
我很确定这是正确的（否则，请告诉我！），因为这种情况似乎是为什么窗口大小应该小于或等于序列号空间大小的一半的经典理由谈到SR协议，但GBN怎么样？
是否会出现同样的环绕问题，使答案大致相同？如果没有，是否有任何其他情况可能导致典型的GBN发送者在其窗口外接收到ACK？
关于后者，我能想到的唯一例子是：
GBN发送方发送数据包A＆amp; B按顺序排列。接收器按顺序接收两者，并发送一个累积ACK覆盖A之前和之前的每个分组，然后发送另一个覆盖B之前和之前的每个分组（包括A）。第一个是如此严重延迟，第二个首先到达发送者，导致其窗口超出A＆amp; B.当第一个终于到达时，当A已经在发送者窗口之外时，它不必要地确认已经正确接收到A之前的所有内容。
这个例子看起来相当无害，与上一张相比不太可能，所以我怀疑它是正确的（但是，如果我错了，请再次纠正我！）。
答案 0 :(得分：1)
在实际的世界中，重复的 ACK延迟了多长时间才能脱离窗口？
协议位于发送方和接收方之间，但它无法控制媒体（网络路径）的行为方式。
根据设计，协议仍然可靠，但实现应能够处理这种窗外重复的ACK。