窗口机制分类
在TCP协议当中窗口机制分为两种：
1.固定的窗口大小
2.滑动窗口
固定窗口存在的问题
我们假设这个固定窗口的大小为1，也就是每次只能发送一个数据，只有接收方对这个数据进行了确认后才能发送第二个数据。在图中我们可以看到，发送方每发送一个数据接收方就要给发送方一个ACK对这个数据进行确认。只有接收了这个确认数据以后发送方才能传输下个数据
存在的问题：
如果窗口过小，当传输比较大的数据的时候需要不停的对数据进行确认，这个时候就会造成很大的延迟
如果窗口过大，我们假设发送方一次发送100个数据，但接收方只能处理50个数据，这样每次都只对这50个数据进行确认。发送方下一次还是发送100个数据，但接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。
因此，我们引入了滑动窗口
滑动窗口(以字节为单位)
概述
滑动窗口通俗来讲就是一种流量控制技术
它本质上是描述接收方的TCP数据报缓冲区大小的数据，发送方根据这个数据来计算自己最多能发送多长的数据，如果发送方收到接收方的窗口大小为0的TCP数据报，那么发送方将停止发送数据，等到接收方发送窗口大小不为0的数据报的到来
工作原理
发送方的发送缓存内的数据都可以被分为4类:
1. 已发送，已收到ACK
2. 已发送，未收到ACK
3. 未发送，但允许发送
4. 未发送，但不允许发送
其中类型2和3都属于发送窗口
接收方的缓存数据分为3类：
1. 已接收
2. 未接收但准备接收
3. 未接收而且不准备接收
其中类型2属于接收窗口
窗口大小代表了设备一次能从对端处理多少数据，之后再传给应用层。缓存传给应用层的数据不能是乱序的，窗口机制保证了这一点。现实中，应用层可能无法立刻从缓存中读取数据
滑动机制
1.发送窗口只有收到发送窗口内字节的ACK确认，才会移动发送窗口的左边界
2.接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收 到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传
3.遵循快速重传、累计确认、选择确认等规则
4.发送方发的window size = 8192;就是接收端最多发送8192字节，这个8192一般就是发送方接收缓存的大小
发送窗口与接收窗口关系
TCP是双工的协议，会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制(TCP传输速率不能大于应用的数据处理速率)。各自的“发送窗口”则要求取决于对端通告的“接收窗口”，要求相同。
滑动窗口实现面向流的可靠性
最基本的传输可靠性来源于“确认重传”机制 TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的
发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界
接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传
滑动窗口的流控特性
TCP的滑动窗口是动态的，我们可以想象成小学常见的一个数学题，一个水池，体积V，每小时进水量V1，出水量V2。当水池满了就不允许再注入了，如果有个液压系统控制水池大小，那么就可以控制水的注入速率和量。这样的水池就类似TCP的窗口。应用根据自身的处理能力变化，通过本端TCP接收窗口大小控制来对对端的发送窗口流量限制
应用程序在需要(如内存不足)时，通过API通知TCP协议栈缩小TCP的接收窗口。然后TCP协议栈在下个段发送时包含新的窗口大小通知给对端，对端按通知的窗口来改变发送窗口，以此达到减缓发送速率的目的
滑动窗口动态调整
主要是根据接收端的接收情况，动态去调整Window Size，然后来控制发送端的数据流量
