为什么窗口大小小于或等于SR协议中序列号的一半？

Question

在选择性重复协议中,窗口大小必须小于或等于SR协议的序列号空间大小的一半.为什么会这样,怎么样？

Answer 1

这是为了避免错误地识别数据包.

如果窗口大小大于序列号空间的一半,则如果ACK丢失,则发送方可以发送接收方认为是重传的新分组.

例如,如果我们的序列号范围是0-3并且窗口大小是3,则可能发生这种情况.

A - > 0 - > B.

A - > 1 - > B.

A - > 2 - > B.

A < - 2ack < - B(这是丢失的)

A - > 0 - > B.

A - > 1 - > B.

A - > 2 - > B.

在丢失数据包之后,B现在期望下一个数据包具有序列号3,0和1.

但是,A发送的0和1实际上是重传,因此B无序接收它们.

通过在此示例中将窗口大小限制为2,我们避免了此问题,因为B将期望2和3,并且只有0和1可以是重新传输.

Answer 2

达到最大数量后,序列空间将回零.考虑所有 ACK丢失的极端情况 - 发送者不移动其窗口,但接收者确实(因为它不知道发送者没有得到ACK).如果我们不将窗口大小限制为序列空间的一半,我们最终会发送重叠的发送方"已发送但未确认"和接收方"有效的新"序列空间.这将导致重传被解释为新数据包.

Answer 3

因为接收方将无法区分旧数据包或新数据包。接收方根据序列号识别数据包，每个连接都有有限数量的唯一编号。你不可能拥有无限的缓冲区。

让我们看一个明显的失败场景：

窗口大小大于序列号空间。假设我们有序列号 0、1、2。我们的窗口大小是 4。这意味着该窗口出现了两次 0。

0,1,2,0 <- 模换行。当我们得到一个seq为0的包时，是第一个包还是第四个包？没有线索。现在，只要窗口大小大于序列号空间的一半，就会出现此问题。为什么？因为接收方始终有可能查看可能包含在来自发送方的新或旧数据包中的序列号。它总是发生吗？不会。但是当它发生时，会发生以下情况：

情况1：

正确接收数据包 0、1、2 后的接收窗口。0,1,2,[3,0,1],2 但是如果发送的 ACK 丢失怎么办？好吧，发送者将重新发送0,1,2。但 0,1 是旧的还是新的？接收者无法辨别。

案例2：

接收端有相同的窗口。三个数据包均已收到。

0,1,2,[3,0,1],2

现在，接收方收到了所有确认，但只有一个正确。让我们选择第二个 (1)。现在，它将重新发送 1。但是接收方正在查看 1！那么这是它所期望的新的（不是），还是旧的？

因此，为了确保窗口永远不会期望潜在的未完成数据包（来自正常传输或丢失确认的重新传输）可能使用的序列号，我们必须减小窗口大小或增加序列号。

看看当我们将序列号空间增加到 6 时会发生什么。

0,1,2,3,4,5。

无论我们如何定位窗口，它都不会面临接收具有旧序列号的数据包的风险。

0,1,2,[3,4,5]0,1...

当窗口结束时，我们确信我们已经按顺序收到了之前的邮件。