TCP滑动窗口主要有两个作用，可靠性、流控
TCP 如果都以一个包为单位，每发一个包进行一次确认应答的处理，这样的传输方式包的往返的时间越长和包的数量越多其通信性能就越低。
为了解决这个问题，TCP引入了窗口这个概念。在往返时间较长的情况下，它也能控制网络性能的下降。确认应答不再是以每个分段，而是以更大的单位进行确认。也就是说发送端在发送了一个段以后不必要一直等待确认应答，而是继续发送。
概述
TCP会话的双方都各自维护一个发送窗口和一个接收窗口。各自的接收窗口大小取决于应用、系统、硬件的限制，各自的发送窗口则要求取决于对端通告的接收窗口。
滑动窗口解决的是流量控制的问题，就是如果接收端和发送端对数据包的处理速度不同，如何让双方达成一致。接收端的缓存传输数据给应用层，但这个过程不一定是即时的，如果发送速度太快，会出现接收端数据overflow，流量控制解决的是这个问题。
滑动窗口的基本概念
A-B之间新建立了一条tcp连接，A需要发送一段很大的数据流，B无法一次性接受，所以它限制设备A每次发送数据分段的数量，每次分段中已发送的字节数得到确认之后，就会左移开始下一个分段。
任一时间点对于这一过程，发送方可以将TCP buffer中的数据分为以下四类，并把它们看作一个时间轴
1. 已发送已确认
2. 已发送但尚未确认（发送窗口）
3. 未发送但接收方允许发送的（发送窗口）
4. 未发送且接收方不允许发送
接收方的缓存数据分为3类：
1. 已接收并已确认
2. 未接受但准备好接收（接收窗口）
3. 尚未接收并尚未准备好接收
滑动机制
- 发送窗口只有收到发送窗口内字节的ACK确认，才会移动发送窗口的左边界。
- 接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。
- 遵循快速重传、累计确认、选择确认等规则。
- 发送方发的window size = 8192;就是接收端最多发送8192字节，这个8192一般就是发送方接收缓存的大小。
确认处理以及窗口缩放
假设接收方发回32-36的确认信息，发送设备接收到确认信息会将一部分（已发送但尚未确认）移到（已发送已确认）。同时如果窗口大小没有改变，窗口向右滑动5个字节。结果，同时5个字节从第二类移动到第1类，5个字节从第4类移动至第3类。
每一次确认接收以后，这一过程都会发生，从而让窗口滑动过整个数据流以供传输。
可用窗口
发送方仍被允许发送的数据量，实际上等于第3类（未发送但接收方允许发送的）的大小。
当第三类的6字节立即发送之后，这6字节从第3类转移到第2类
1. 已发送已确认（1-31）
2. 已发送但尚未确认（32-51）
3. 未发送但接收方允许发送的（0）
4. 未发送且接收方不允许发送（52-95）
参考文档： https://wizardforcel.gitbooks.io/network-basic/7.html
模拟动画：http://www.exa.unicen.edu.ar/catedras/comdat1/material/Filminas3_Practico3.swf
参考文档：https://www.jianshu.com/p/6248d667ab63
参考文档：https://blog.csdn.net/yao5hed/article/details/81046945
