滑动窗口原理
TCP并不是每一个报文段都会回复ACK的，可能会对两个报文段发送一个ACK，也可能会对多个报文段发送1个ACK【累计ACK】，比如说发送方有1/2/3 3个报文段，先发送了2,3 两个报文段，但是接收方期望收到1报文段，这个时候2,3报文段就只能放在缓存中等待报文1的空洞被填上，如果报文1，一直不来，报文2/3也将被丢弃，如果报文1来了，那么会发送一个ACK对这3个报文进行一次确认。
举一个例子来说明一下滑动窗口的原理：
假设32~45 这些数据，是上层Application发送给TCP的，TCP将其分成四个Segment来发往internet
seg1 32~34 seg3 35~36 seg3 37~41 seg4 42~45 这四个片段，依次发送出去，此时假设接收端之接收到了seg1 seg2 seg4
此时接收端的行为是回复一个ACK包说明已经接收到了32~36的数据，并将seg4进行缓存（保证顺序，产生一个保存seg3 的hole）
发送端收到ACK之后，就会将32~36的数据包从发送并没有确认切到发送已经确认，提出窗口，这个时候窗口向右移动
假设接收端通告的Window Size仍然不变，此时窗口右移，产生一些新的空位，这些是接收端允许发送的范畴
对于丢失的seg3，如果超过一定时间，TCP就会重新传送（重传机制），重传成功会seg3 seg4一块被确认，不成功，seg4也将被丢弃
就是不断重复着上述的过程，随着窗口不断滑动，将真个数据流发送到接收端，实际上接收端的Window Size通告也是会变化的，接收端根据这个值来确定何时及发送多少数据，从对数据流进行流控。原理图如下图所示：
滑动窗口动态调整
主要是根据接收端的接收情况，动态去调整Window Size，然后来控制发送端的数据流量
- 客户端不断快速发送数据，服务器接收相对较慢，看下实验的结果
a. 包175，发送ACK携带WIN = 384，告知客户端，现在只能接收384个字节
b. 包176，客户端果真只发送了384个字节，Wireshark也比较智能，也宣告TCP Window Full
c. 包177，服务器回复一个ACK，并通告窗口为0，说明接收方已经收到所有数据，并保存到缓冲区，但是这个时候应用程序并没有接收这些数据，导致缓冲区没有更多的空间，故通告窗口为0, 这也就是所谓的零窗口，零窗口期间，发送方停止发送数据
d. 客户端察觉到窗口为0，则不再发送数据给接收方
e. 包178，接收方发送一个窗口通告，告知发送方已经有接收数据的能力了，可以发送数据包了
f. 包179，收到窗口通告之后，就发送缓冲区内的数据了.
总结一点，就是接收端可以根据自己的状况通告窗口大小，从而控制发送端的接收，进行流量控制