滑动窗口rwnd

每一个包都有一个 ID。

在建立连接(3次握手)的时候，会商定起始的 ID 是什么(Seq)，然后按照 ID 一个个发送。

为了保证不丢包，对于发送的包都要进行应答，应答也不是一个一个来的，而是会应答某个之前的 ID，表示都收到了，这种模式称为累计确认或者累计应答（cumulative acknowledgment）。

发送端的缓存

里是按照包的 ID 一个个排列，根据处理的情况分成四个部分。

第一部分：已经确认收到。应该划掉的。
第二部分：等待回复确认
第三部分：准备发送的(没有超过对方接受能力)
第四部分：不准备发送, 因为再发对方就接受不了了

image

为什么要区分第三部分和第四部分:

“流量控制，把握分寸”。应该估测一下，能发多少

接收端报一个窗口的大小，叫Advertised window。超过这个数就不该发了

接受端缓存

image

第一部分是 : 已接受但是还没被应用层读取的部分

窗口 : 第二部分

其中第二部分里面，由于受到的包可能不是顺序的，会出现空挡，只有和第一部分连续的，可以

马上进行回复，中间空着的部分需要等待，哪怕后面的已经来了。

拥塞窗口 cwnd

通道的容量 = 带宽 × 往返延迟

往返时间为 8s，去 4s，回 4s，
现在速度是每秒发送一个包
已经过去了 8s，则 8 个包都发出去了，
其中前 4 个包已经到达接收端，但是 ACK 还没有返回，不能算发送成功。下一秒包1就发送成功了
5-8 后四个包还在路上，还没被接收。
这个时候，整个管道正好撑满，在发送端，已发送未确认的为 8 个包，正好等于带宽(每秒发送 1 个包)，乘以往返延迟 8s。

如果要我加速发包:

原来发送一个包，从一端到达另一端，假设一共经过四个设备，每个设备处理一个包
时间耗费 1s，所以到达另一端需要耗费 4s，如果发送的更加快速，多出来的包就会被丢弃
如这个四个设备本来每秒处理一个包，但是有缓存，包就不会丢失，但会增加时延，4s 肯定到达不了接收端了，如果时延达到一定程度，就会超时重传
TCP 的拥塞控制主要来避免两种现象，包丢失和超时重传。一旦出现了这些现象就说明，发送速度太快了，要慢一点