版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/lwl2014100338/article/details/84329249
如何实现一个靠谱的协议
（1）为了保证顺序性，每一个包都有一个 ID。在建立连接的时候，会商定起始的ID是什么，然后按照ID一个个发送。为了保证不丢包，对于发送的包都要进行应答，但是这个应答不是一个一个来的，而是会应答某个之前的ID，表示都收到了，这种模式称为累计确认或者累计应答
（2）为了记录所有发送的包和接收的包，TCP也需要发送端和接收端分别都有缓存保存这些记录。发送端的缓存里是按照包的ID一个个排列，根据处理的情况分成四个部分
- 第一部分：发送了并且已经确认的。这部分就交给你下属的，并且也做完了的，应该划掉的
- 第二部分：发送了并且尚未确认的。这部分是你交代下属的，但是还没做完的，需要等待做完的回复之后，才能划掉
- 第三部分：没有发送，但是已经等待发送的。这部分是你没有交代给下属的，但是马上就要交代的
- 第四部分：没有发送，并且暂时还不会发送的。这部分是你还没有交代给下属，而且暂时还不会交代给下属的
（3）区分第三部分和第四部分的原因是：流量控制
（4）滑动窗口：在TCP里，接收端会给发送端报一个窗口的大小，叫Advertised window。这个窗口的大小应该等于上面的第二部分加上第三部分，超过了这个窗口，接收端做不过来，就不能发送了
（5）发送端的数据结构
（6）对于接收端来讲，它的缓存里记录的内容要简单一些
- 第一部分：接受并且确认过的。它就是我领导交代我的，并且我做完的
- 第二部分：还没接收，但是马上就能接收的
- 第三部分：还没接收，也没法接收的。超过工作量的部分
（7）接收端对应的数据结构如下图
流量控制
（1）在对于包的确认中，同时会携带一个窗口的大小，发送端根据窗口大小，调整发送的数据大小
（2）发送方会定时发送窗口探测数据包，看是否有机会调整窗口大小。当接收方比较慢的时候，要防止低能窗口综合征。
拥塞控制
拥塞控制的问题，也是通过窗口的大小来控制的，前面的滑动窗口rwnd是怕发送方把接收方缓存塞满，而拥塞窗口cwnd，是怕把网络塞满