在选择性重复协议中，窗口大小必须小于或等于SR协议的序列号空间大小的一半。为什么会这样，怎么样？
答案 0 :(得分：24)
这是为了避免错误地识别数据包。
如果窗口大小大于序列号空间的一半，那么如果ACK丢失，发送方可能会发送接收方认为是重新传输的新数据包。
例如，如果序列号范围为0-3且窗口大小为3，则可能出现这种情况。
A - ＆gt; 0 - ＆gt;乙
A - ＆gt; 1 - ＆gt;乙
A - ＆gt; 2 - ＆gt;乙
A＆lt; - 2ack＆lt; -B（这是丢失的）
A - ＆gt; 0 - ＆gt;乙
A - ＆gt; 1 - ＆gt;乙
A - ＆gt; 2 - ＆gt;乙
在丢失数据包之后，B现在期望下一个数据包具有序列号3,0和1。
但是，A发送的0和1实际上是重传，因此B无序接收它们。
通过在此示例中将窗口大小限制为2，我们避免了此问题，因为B将期望2和3，并且只有0和1可以重新传输。
答案 1 :(得分：8)
达到最大数量后，序列空间将回零。考虑所有 ACK丢失的极端情况 - 发送方不移动其窗口，但接收方确实（因为它不知道发送方没有获得ACK）。如果我们不将窗口大小限制为序列空间的一半，我们最终会重叠发送方“已发送但未确认”和接收方“有效的新”序列空间。这将导致重传被解释为新数据包。
答案 2 :(得分：3)
因为接收器无法区分旧数据包或新数据包。接收器基于序列号识别分组，并且每个连接存在有限数量的唯一编号。你不能拥有无限的缓冲区。
让我们看一下明显的失败情景：
窗口大小大于序列号空间。假设我们有序列号0,1,2。我们的窗口大小是4.这意味着窗口有两次出现0.
0,1,2,0＆lt; - modulo wrap。当我们得到一个seq为0的包时，它是第一个包还是第四个包？没有线索。现在，只要窗口大小大于序列号空间的一半，就会出现此问题。为什么？因为接收器总是有可能查看可能包含在来自发送者的数据包中的序列号，该数据包是NEW或OLD。它总是会发生吗？不，但是当它发生时，会发生以下情况：
案例1：
正确接收数据包后的接收窗口0,1,2。 0,1,2，[3,0,1]，2 但是如果发送的ACK丢失了怎么办？好吧，发件人将重新发送0,1,2。但是0,1 OLD还是NEW？接收器无法分辨。
案例2：
接收端的相同窗口。收到三个数据包。
0,1,2，[3,0,1]，2
现在，接收器正确地接收所有的acks但是ONE。让我们挑选第二个（1）。现在，它将重新发送1.但接收器正在看1！那么这是新的，因为它预期（nope），还是旧的？
因此，为了确保窗口永远不会期望潜在的未完成数据包可能使用的序列号（来自正常传输或重新传输丢失的确认），我们必须减小窗口大小或增加序号。
看看当我们将序列号空间增加到6时会发生什么。
0,1,2,3,4,5。
无论我们如何定位窗口，它都不会有接收带有旧序列号的数据包的风险。
0,1,2，[3,4,5] 0,1 ...
当窗口环绕时，我们肯定我们已按顺序收到了之前的窗口。
答案 3 :(得分：1)
此链接有一个动画，它遍历协议的每个步骤，以解释窗口大小的重要性：
http://webmuseum.mi.fh-offenburg.de/index.php?view=exh&src=73
基本上，如果窗口大小太高，那么传输中的损坏可能会导致错误的假设，并导致最终结果中的数据损坏。