第三章 第4节

第三章第三节：

SR选择重传机制：基于GBN使用独立确认，也就是说在GBN收到乱序的后续包的同时缓存到缓存区，并且发送确认，只重传丢失的包，其他包由各自的定时器独立处理比如说（2丢了，GBN要求重传2345,SR只要求2重传），只要收到ACK，对应位置标记说明已确认。基序号收到之后往后滑动。

SR=缓存乱序包+独立确认+只重传丢失包

适用范围 出错率低：比较适合GBN，出错非常罕见，没有必要用复杂的SR，为罕见的事件做日常的准备和复杂处理 •带宽延迟积小，或出错率小

链路容量大（延迟大、带宽大）：比较适合SR而不是GBN，一点出错如 果回退N步代价太大 •带宽延迟积大，且出错率高

还需要知道SR机制中，窗口长度比必须小于等于序号空间大小的一般

假设我们只用 2个比特 来表示序号，那么序号空间就是 0、1、2、3（共4个序号）。再假设我们违法规定，把窗口长度设为 3（大于一半，4/2=2）。

发送方一次性发了分组0、1、2（窗口大小=3）。

糟糕的情况发生了：

· 接收方成功收到了0、1、2，并且回复的ACK（确认包）全部丢失了。

· 发送方等了很久，收不到ACK，以为这三个分组都丢了。

· 于是发送方超时重传，再次发送分组0、1、2（这是第二批的0、1、2）。

接收方现在面临致命的困惑：

· 接收方的窗口本来已经滑倒了期待接收3、0、1（序号绕回后）。

· 当它收到这批重传的“分组0”时，它无法判断：

· 这个“分组0”是第一批里迟到的那个旧的0？（如果是，应该丢弃）

· 还是第二批里正常的新的0？（如果是，应该收下）

因为窗口长度3（0,1,2）和剩余的序号空间（3,0,1）有大量重叠（0和1重叠了），接收方无法区分序号0到底是旧包还是新包。

如果知道窗口长度 ≤ 序号空间的一半

现在我们把窗口长度限制为 2（≤ 4/2）。

发送方一次性发分组0、1。

假设ACK全丢了，发送方超时重传0、1。

接收方：

· 接收方的窗口这时已经滑倒了期待接收2、3。

· 当它收到重传的“分组0”时，它看一眼自己的窗口：“我当前只期待2和3，这个0根本不在我的窗口内，所以它一定是迟到的旧包，直接丢弃。”

· 同时，它继续等待真正的2和3。

结论：

因为窗口大小不超过序号空间的一半，所以接收方的“期待窗口”和发送方的“可发送窗口”在任何时候都不会有重叠。接收方就可以根据“这个序号是否在当前期待窗口内”来明确判断分组是新的（接收）还是旧的（丢弃）。

把窗口大小限制在序号空间的一半，就是为了确保即使所有ACK都丢失，导致发送方把旧分组重传一遍，接收方也能根据自己当前滑动的窗口，明确地判断出这个重传的分组是“迟到的旧垃圾”还是“期待的新宝贝”，从而彻底消除了序号回绕带来的混淆。

第三章第四节：TCP和UDP协议：

TCP 序号, 确认号 序号: 段数据的第一个字节在整个 字节流中的位置（以字节）确认: 作为接收方期待对端从该字节开始传输，累积性确认

Q:接收方如何处理乱序到达的段？ A: 协议规范没有规定，取决于实现者

也就是说上图那个654的4就是一个序号，发送之后接收方回复4确认号，具体实现可能是ASCII码，也不一定。

大概就是说发送方发了一个42（这个不是C的ASCII码，反正就表示说要确认C），然后接收方发送43，是42+1表明收到C了，然后接受方再发79告诉发送方从43-79全部收到了，发送方响应回复79+1=80表明知道自己发的C被收到了。

重传机制：

如果发送方收到对某个段的3 个冗余ack，重新传送具有最 小序号的段，即使其还未超时 大概率未确认的段丢失了，虽超时，仍然快速重发，提高恢复的速度

TCP流量控制：接收方控制发送方，这样发送方就不会发送的太快、太多，以至于淹没接收方的缓冲区，导致接收方的应用程序来不及读取。

核心问题就是速度不匹配，解决方案就是流量控制：

具体每个操作步骤不需要了解了，计算起来非常麻烦，大概就是说接收方通告自己的空闲容量，接收方会把空闲空间的大小，放在每个TCP报文段头部的rwnd字段里，发送方收到遵守限量发送，确保不会超过对方通告的rwnd，等对方确认之后，再刷新重新进行。

TCP 的手段：

· 接收方：通过 TCP 头部里的 rwnd 字段，实时广播自己还有多少“空闲缓冲区”。

· 发送方：根据收到的 rwnd 值，动态限制自己的发送速度，确保已发未确认的数据量 ≤ rwnd。

· 最终目标：保证接收方的缓冲区不会溢出，实现“发送速度”与“处理速度”的匹配。

拥塞控制我不会~哈哈这块主要是计算呀，我后面会刷几套计网的题，我又不是计算机专业，计算什么的就不学了，主要还是学esp8266与w5500的tcp客户端之类的

喜欢的可以看下后面的计算，下节开第四章网络层到ipv4