趣谈网络协议——TCP协议（下）：西行必定多妖孽，恒心智慧消磨难（笔记）

TCP如何成为一个靠谱的协议

为了保证顺序性，每一个包都有一个在建立连接的时商定的 ID，然后按照 ID 一个个发送。为了保证不丢包，对于发送的包都要进行应答，但是这个应答也不是一个一个来的，而是会应答某个之前的 ID，表示都收到了，这种模式称为累计确认或者累计应答。

发送端

为了记录所有发送的包和接收的包，TCP 也需要发送端和接收端分别都有缓存来保存这些记录。发送端的缓存里是按照包的 ID 一个个排列，根据处理的情况分成四个部分。
（1）发送了并且已经确认的。这部分就是你交代下属的，并且也做完了的，应该划掉的。
（2）发送了并且尚未确认的。这部分是你交代下属的，但是还没做完的，需要等待做完的回复之后，才能划掉。
（3）没有发送，但是已经等待发送的。这部分是你还没有交代给下属，但是马上就要交代的。
（4）没有发送，并且暂时还不会发送的。这部分是你还没有交代给下属，而且暂时还不会交代给下属的。
区分第三种和第四种情况是为了“流量控制”，流量控制的依据是接收端会给发送端报一个窗口（Advertised window）的大小这个窗口的大小应该等于第二部分和第三部分之和。

LastByteAcked：第一部分和第二部分的分界线
LastByteSent：第二部分和第三部分的分界线
LastByteAcked + AdvertisedWindow：第三部分和第四部分的分界线

接受端

（1）接受并且确认过的。也就是我领导交代给我，并且我做完的。
（2）还没接收，但是马上就能接收的。也即是我自己的能够接受的最大工作量。
（3）还没接收，也没法接收的。也即超过工作量的部分，实在做不完。

MaxRcvBuffer：最大缓存的量；
LastByteRead 之后是已经接收了，但是还没被应用层读取的；
NextByteExpected 是第一部分和第二部分的分界线。

AdvertisedWindow=MaxRcvBuffer-((NextByteExpected-1)-LastByteRead)。

顺序问题与丢包问题

从上面两张图片来看：在发送端来看，1、2、3 已经发送并确认；4、5、6、7、8、9 都是发送了还没确认；10、11、12 是还没发出的；13、14、15 是接收方没有空间，不准备发的。

在接收端来看，1、2、3、4、5 是已经完成 ACK，但是没读取的；6、7 是等待接收的；8、9 是已经接收，但是没有 ACK 的。
发送端和接收端当前的状态如下：

• 1、2、3 没有问题，双方达成了一致。
• 4、5 接收方说 ACK 了，但是发送方还没收到，有可能丢了，有可能在路上。
• 6、7、8、9 肯定都发了，但是 8、9 已经到了，但是 6、7 没到，出现了乱序，缓存着但是没办法 ACK。

确认与重发的机制

（1）超时重试，也即对每一个发送了，但是没有 ACK 的包，都有设一个定时器，超过了一定的时间，就重新尝试。估计往返时间，需要 TCP 通过采样 RTT 的时间，然后进行加权平均，算出一个值，而且这个值还是要不断变化的，因为网络状况不断的变化。除了采样 RTT，还要采样 RTT 的波动范围，计算出一个估计的超时时间。由于重传时间是不断变化的，我们称为自适应重传算法。

有需要重传的时候，TCP 的策略是超时间隔加倍。每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。
（2）流量控制问题我们先假设窗口不变的情况，窗口始终为 9。4 的确认来的时候，会右移一个，这个时候第 13 个包也可以发送了。

这个时候，假设发送端发送过猛，会将第三部分的 10、11、12、13 全部发送完毕，之后就停止发送了，未发送可发送部分为 0。

当对于包 5 的确认到达的时候，在客户端相当于窗口再滑动了一格，这个时候，才可以有更多的包可以发送了，例如第 14 个包才可以发送。

如果接收方实在处理的太慢，导致缓存中没有空间了，可以通过确认信息修改窗口的大小，甚至可以设置为 0，则发送方将暂时停止发送。

我们假设一个极端情况，接收端的应用一直不读取缓存中的数据，当数据包 6 确认后，窗口大小就不能再是 9 了，就要缩小一个变为 8。

这个新的窗口 8 通过 6 的确认消息到达发送端的时候，你会发现窗口没有平行右移，而是仅仅左面的边右移了，窗口的大小从 9 改成了 8。

如果接收端还是一直不处理数据，则随着确认的包越来越多，窗口越来越小，直到为 0。

当这个窗口通过包 14 的确认到达发送端的时候，发送端的窗口也调整为 0，停止发送。

如果这样的话，发送方会定时发送窗口探测数据包，看是否有机会调整窗口的大小。当接收方比较慢的时候，要防止低能窗口综合征，别空出一个字节来就赶快告诉发送方，然后马上又填满了，可以当窗口太小的时候，不更新窗口，直到达到一定大小，或者缓冲区一半为空，才更新窗口。

拥塞控制问题

LastByteSent - LastByteAcked <= min {cwnd, rwnd} ，是拥塞窗口和滑动窗口共同控制发送的速度。网络上，通道的容量 = 带宽 × 往返延迟。一旦出现包丢失和超时重传