滑动窗口

滑动窗口的作用呢主要是用来进行流量控制，提高吞吐量作用的，如果没有滑动窗口这个特性的话我们就很有可能丢包或者网络堵塞但是具体是怎么滑动的呢让我们来看下下图

我们先来假设有两台计算机 一台为A（发送方） 以为为B（接收方）
首先是AB之间三次握手建立TCP连接。在报文的交互过程中，A将自己的缓冲区大小（窗口大小）发送给B，B同理，这样双方就知道了对端的窗口大小。但是大家千万不要以为这个时候就有滑动窗口特性了，实际上窗口滑动是出现在数据传输过程中的，也就是说滑动窗口协议是实际应用于数据传输阶段而不是链路建立阶段的。
如上图 A接到了B说我能接收20个字节大小哈，A这个时候呢就把字节的发送缓冲区弄成了3份
已发送收到确认:[26-30]
发送窗口:[31-50]
不允许发送:[51-56]

同时B这个时候呢也把字节的接收缓冲区弄成了3份
已发送过确认:[26-30]
接送窗口:[31-50]
不允许接收:[51-56]

怎么描述发送窗口的状态呢如下图

这个时候呢发送方就开始给接收方发送数据假如这个时候发了32，33，但是31没发那么这个时候接收方是如此状态32，33红色代表我暂时写入缓存，等待31的数据过来，这个时候主机B只会一直发送ack31的包过去，而不会发送32，3过去，因为接收方只会发送确认包的最大值发送过去

这个时候如果31过来了那么接收方就会把31，32，33这个数据交给应用程序，并且向前移动到34，并从接收缓冲区删除31，32，33，并给A发送确认码34，代表我已经把31，32，33确认好了哈，你A也可以移动了哈，这个时候状态就变成如下图了、

这个时候呢A收到了34的确认码会怎么样呢，我想聪明的你一看下图就知道怎么回事了吧
ps：这个时候收到了34，发送方就把窗口向前移动了3位并删掉31，32，33 到达了34的位置，并51，52，53加入了新的可以允许发送数据的窗口

还有一点有人会问如果接收方一直没ACK确认码过去，那么A会什么情况呢，这个时候其实A会有个定时器管着，超过了时间就会超时重传数据给发送方

还有一点我们要切记，这个窗口大小可不是固定的。
他们各自的“接收窗口”大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的“发送窗口”则要求取决于对端通告的“接收窗口”

太晚了，都快凌晨1点了，明天在补充