TCP滑动窗口控制流量的原理

TCP滑动窗口控制流量的原理

转载自：https://www.cnblogs.com/luoquan/p/4886345.html

参考：https://www.cnblogs.com/freebird92/p/6442155.html

TCP的滑动窗口机制 
      TCP这个协议是网络中使用的比较广泛，他是一个面向连接的可靠的传输协议。既然是一个可靠的传输协议就需要对数据进行确认。TCP协议里窗口机制有2种：一种是固定的窗口大小；一种是滑动的窗口。这个窗口大小就是我们一次传输几个数据。对所有数据帧按顺序赋予编号，发送方在发送过程中始终保持着一个发送窗口，只有落在发送窗口内的帧才允许被发送；同时接收方也维持着一个接收窗口，只有落在接收窗口内的帧才允许接收。这样通过调整发送方窗口和接收方窗口的大小可以实现流量控制。

      TCP滑动窗口技术通过动态改变窗口大小来调节两台主机间数据传输。每个TCP/IP主机支持全双工数据传输，因此TCP有两个滑动窗口：一个用于接收数据，另一个用于发送数据。TCP使用肯定确认技术，其确认号指的是下一个所期待的字节。 假定发送方设备以每一次三个数据包的方式发送数据，也就是说，窗口大小为3。发送方发送***为1、2、3的三个数据包，接收方设备成功接收数据包，用***4确认。发送方设备收到确认，继续以窗口大小3发送数据。当接收方设备要求降低或者增大网络流量时，可以对窗口大小进行减小或者增加，本例降低窗口大小为2，每一次发送两个数据包。当接收方设备要求窗口大小为0，表明接收方已经接收了全部数据，或者接收方应用程序没有时间读取数据，要求暂停发送。发送方接收到携带窗口号为0的确认，停止这一方向的数据传输。

   
我们可以看下面一张图来分析一下固定窗口大小有什么问题。 
 
这里我们可以看到假设窗口的大小是1，也是就每次只能发送一个数据只有接受方对这个数据进行确认了以后才能发送第2个数据。我们可以看到发送方每发送一个数据接受方就要给发送方一个ACK对这个数据进行确认。只有接受到了这个确认数据以后发送方才能传输下个数据。 这样我们考虑一下如果说窗口过小，那么当传输比较大的数据的时候需要不停的对数据进行确认，这个时候就会造成很大的延迟。如果说窗口的大小定义的过大。我们假设发送方一次发送100个数据。但是接收方只能处理50个数据。这样每次都会只对这50个数据进行确认。发送方下一次还是发送100个数据，但是接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。所以我们就引入了滑动窗口机制，窗口的大小并不是固定的而是根据我们之间的链路的带宽的大小，这个时候链路是否拥护塞。接受方是否能处理这么多数据了。  
我们看看滑动窗口是如何工作的。我们看下面几张图。 

 

 
首先是第一次发送数据这个时候的窗口大小是根据链路带宽的大小来决定的。我们假设这个时候窗口的大小是3。这个时候接受方收到数据以后会对数据进行确认告诉发送方我下次希望手到的是数据是多少。这里我们看到接收方发送的ACK=3(这是发送方发送序列2的回答确认，下一次接收方期望接收到的是3序列信号)。这个时候发送方收到这个数据以后就知道我第一次发送的3个数据对方只收到了2个。就知道第3个数据对方没有收到。下次在发送的时候就从第3个数据开始发。这个时候窗口大小就变成了2 。 
 

这个时候发送方发送2个数据。 

 
看到接收方发送的ACK是5就表示他下一次希望收到的数据是5，发送方就知道我刚才发送的2个数据对方收了这个时候开始发送第5个数据。 
这就是滑动窗口的工作机制，当链路变好了或者变差了这个窗口还会发生变话，并不是第一次协商好了以后就永远不变了。                 
滑动窗口协议 
滑动窗口协议，是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。 
只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。    
收发两端的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。    
当发送窗口和接收窗口的大小都等于1时，就是停止等待协议。

#-----------------------------------------------------------------------------------------------------------------------------------------------------------

TCP滑动窗口和socket缓冲区之间的关系 

一、TCP的滑动窗口大小实际上就是socket的接收缓冲区大小的字节数

二、对于server端的socket一定要在listen之前设置缓冲区大小，因为，accept时新产生的socket会继承监听socket的缓冲区大小。对于client端的socket一定要在connet之前设置缓冲区大小，因为connet时需要进行三次握手过程，会通知对方自己的窗口大小。在connet之后再设置缓冲区，已经没有什么意义。

三、由于缓冲区大小在TCP头部只有16位来表示，所以它的最大值是65536，但是对于一些情况来说需要使用更大的滑动窗口，这时候就要使用扩展的滑动窗口，如光纤高速通信网络，或者是卫星长连接网络，需要窗口尽可能的大。这时会使用扩展的32位的滑动窗口大小。

【额外补充】

滑动窗口协议可以用图四来形象表示。

 

 图中我们已经将字节进行了1到11的编号。由接收者通告的窗口称为提议窗口（offered window），它覆盖了第4到第9个字节，意味着接收方已经确认了第3字节之前（包括第3字节）的数据，并且通告窗口的大小是6。窗口大小与确认的顺序号（acknowledged sequence number）有关。发送者计算它的可用窗口（usable window），用以度量它可以立即发送多少数据。

随着接收者对收到数据的确认，滑动窗口随时向右移动。窗口两端的相关运动增加或减少着窗口大小。我们使用3个术语来描述窗口边缘（edge）的左右运动。

1．当窗口左边缘靠近右边缘时称窗口闭合（window closes）。窗口闭合发生在数据已经发送并被确认的情况下。

2．当窗口右边缘向右移动时称窗口打开（window opens）。窗口打开发生在另一端的接收进程读取已确认数据的时候，它释放了TCP接收缓冲区的空间。

3．当窗口右边缘向左移动时称窗口收缩（window shrinks）。Host Requirement RFC强烈不鼓励这种做法，但TCP必须能够在一端发生这种情况时进行处理。

     图五表示了这三个术语。由于窗口的左边缘是受从连接另一端收到的确认号来控制的，因此它不会向左移动。如果收到一个ACK要求将左边缘向左移动，那么它是一个重复的（duplicate）的确认，并被丢弃。

 

总结：

        1）发送方不必发送一个全窗口大小的数据。

        2）来自接收方的一个报文段确认数据并把窗口向右边滑动。

        3）窗口大小可以减少，根据上图段7和段8确认。

        4）通过设置服务端接收缓存大小【TCP滑动窗口大小】，可以有效减少ACK回复，增加传输效率。