tcp欢动窗口机制_TCP的滑动窗口机制

在TCP协议当中窗口机制分为两种：

1.固定的窗口大小

2.滑动窗口

固定的窗口

我们假设这个固定窗口的大小为1，也就是每次只能发送一个数据，只有接收方对这个数据进行了确认后才能发送第二个数据。在图中我们可以看到，发送方每发送一个数据接收方就要给发送方一个ACK对这个数据进行确认。只有接收了这个确认数据以后发送方才能传输下个数据。

存在的问题：如果窗口过小，当传输比较大的数据的时候需要不停的对数据进行确认，这个时候就会造成很大的延迟。

如果窗口过大，我们假设发送方一次发送100个数据，但接收方只能处理50个数据，这样每次都只对这50个数据进行确认。发送方下一次还是发送100个数据，但接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。

滑动窗口

固定窗口的缺陷太多了，为此有了滑动窗口

概念：用来告诉发送端可以发送数据的大小或者说是窗口标记了接收端缓冲区的大小

ps：窗口指的是一次批量的发送多少数据

目的：滑动窗口协议是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。

TCP的滑动窗口分为接收窗口和发送窗口

TCP是双工的协议，会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制(TCP传输速率不能大于应用的数据处理速率)。各自的“发送窗口”则要求取决于对端通告的“接收窗口”，要求相同。

发送缓存内的数据类型：

“已经发送并得到对端ACK的”

“已经发送但还未收到对端ACK的”

“未发送但对端允许发送的”

“未发送且对端不允许发送”

ps:“已经发送但还未收到对端ACK的”和“未发送但对端允许发送的”这两部分数据称之为发送窗口。

接收缓存内的数据类型：

“已接收”

“未接收准备接收”

“未接收并未准备接收”

(由于ACK直接由TCP协议栈回复，默认无应用延迟，不存在“已接收未回复ACK”)

ps:“未接收准备接收”称之为接收窗口。

滑动窗口实现面向流的可靠性:

1)最基本的传输可靠性来源于“确认重传”机制。

2)TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。

3)发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界。

4)接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。

滑动窗口的流控特性

TCP的滑动窗口是动态的，我们可以想象成小学常见的一个数学题，一个水池，体积V，每小时进水量V1，出水量V2。当水池满了就不允许再注入了，如果有个液压系统控制水池大小，那么就可以控制水的注入速率和量。这样的水池就类似TCP的窗口。应用根据自身的处理能力变化，通过本端TCP接收窗口大小控制来对对对端的发送窗口流量限制。

应用程序在需要(如内存不足)时，通过API通知TCP协议栈缩小TCP的接收窗口。然后TCP协议栈在下个段发送时包含新的窗口大小通知给对端，对端按通知的窗口来改变发送窗口，以此达到减缓发送速率的目的。

优点：

可以高效可靠的发送大量的数据

拓展

TCP协议

TCP可靠传输原理中的停止等待协议，该协议就是发送方每发送一个报文段后就停止发送，一直等收到接收方的确认后再发送下一个报文段。

流量控制：

防止发送方发的太快，耗尽接收方的资源，从而使接收方来不及处理