我们在数据传输的时候都希望能够大量准确的传输数据，但是当流量过大时，接收方就可能来不及接受，造成数据的丢失。
流量控制： 就是让发送方的发送频率不要太快，要让接收方来得及接收
使用滑动窗口可以很方便的实现对发送方的流量控制。
直接看上面的图：
首先在建立连接的时候，B把自己的窗口rwnd定义为400，这就代表一次发送的数据不能超过400。
正式发送数据：
- 第一个，第二个每次正常发送100单位的数据
- 第三次出现了发送数据丢失的问题。
- 然后就接收方向发送方回发数据，这里面有两个重要的数据：
一个就是已经接收到的数据序号ack
二是自己接下来的接收窗口rwnd
这里因为201-300的数据丢失了，所以ack=201，awnd是根据自己的缓存窗口进行改变
- 根据上一条接受方的回发消息，自己200-300的数据丢失了，而且接收出窗口的大小从400变为了300
所以发送了两次新数301和401
然后重新发送了丢失的201-300的数据
- 此时接收方又回传消息，已经接收序号是500，接收窗口是100
- 然后发送方就发送了501-600的数据
- 最后回发接收窗口是0，说明不再接收数据了。
我们再来看另一个问题
上面说了发送方向接收方发送数据如果丢失的处理方法，如果接收方向发送方回发数据丢失了呢？
这里就要用到了一个新的的东西：持续计时器。
用法：
- 只要TCP连接一方收到了对方的零窗口通知，就会启动持续计时器。
- 如果时间到了，就会发送一个零窗口探测报文段（仅携带1字节的数据）
- 而对方就在确认这个探测报文段时给出了现在的窗口值。如果是零，则重新设置持续计时器。如果不是零，这个僵局就打破了。
我在其中的两个问题：
问题一，看上面这个图，接收方什么回发消息，或者跟什么有关
解释：TCP通信是全双工的，所以可以接收一个消息发送一次，也可以一接收多个再回发。
eg：
- 一次发送0-500的字节，每次发送100，然后201-300的丢失了
- 那么接收方回复201的消息
- 发送方重传201-300的消息
- 接收方接收到之后，回复301-500已经接收到了，下一个从501开始发
问题二：如果发送方会发消息丢失怎么半？
- 有时钟过时，超时重传计时器等做保障。