TCP滑动窗口（发送窗口和接受窗口）

TCP窗口机制

TCP header中有一个Window Size字段&＃xff0c;它其实是指接收端的窗口&＃xff0c;即接收窗口。用来告知发送端自己所能接收的数据量&＃xff0c;从而达到一部分流控的目的。

其实TCP在整个发送过程中&＃xff0c;也在度量当前的网络状态&＃xff0c;目的是为了维持一个健康稳定的发送过程&＃xff0c;比如拥塞控制。因此&＃xff0c;数据是在某些机制的控制下进行传输的&＃xff0c;就是窗口机制。

窗口缩放因子(Window Scaling)

以前&＃xff0c;window size最大为2的16次方&＃xff0c;为65535&＃xff0c;随着宽带不断提高&＃xff0c;65535字节已经小了&＃xff0c;为了突破限制&＃xff0c;便有了Window Size Scaling选项&＃xff0c;假设window scale为7&＃xff0c;也就是要将Window Size的值左移七位&＃xff0c;即乘以128。window scale最大为14.

在整个双方的交互过程中&＃xff0c;发送方和接收方Window size scaling factor乘积因子必须保持不变&＃xff0c;但是发送方的乘积因子和接收方的乘积因子可以不同&＃xff0c;由各自决定。

在标志位中有SYN的消息&＃xff0c;会在选项中通知接收方&＃xff0c;本端具体的放大因子&＃xff0c;该消息本身不放大

上图中的放大因子扩大了256倍&＃xff0c;8212*256&＃61;2102272

发送窗口

窗口滑动发送数据

&＃xff08;1&＃xff09;已经发送并且对端确认&＃xff08;Sent/ACKed&＃xff09;---------------发送窗外 缓冲区外

&＃xff08;2&＃xff09;已经发送但未收到确认数据&＃xff08;Sent/UnACKed&＃xff09;----- --发送窗内 缓冲区内

&＃xff08;3&＃xff09;允许发送但尚未防的数据&＃xff08;Unsent/Inside&＃xff09;-----------发送窗内 缓冲区内

&＃xff08;4&＃xff09;未发送暂不允许&＃xff08;Unsent/Outside&＃xff09;-------------------发送窗外 缓冲区内

2&＃xff0c;3两部分为发送窗口

接受窗口

对于TCP的接收方&＃xff0c;在某一时刻在它的接收缓存内存在3种。“已接收”&＃xff0c;“未接收准备接收”&＃xff0c;“未接收并未准备接收”&＃xff08;由于ACK直接由TCP协议栈回复&＃xff0c;默认无应用延迟&＃xff0c;不存在“已接收未回复ACK”&＃xff09;。其中“未接收准备接收”称之为接收窗口。

发送窗口与接收窗口关系

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

滑动窗口

TCP并不是每一个报文段都会回复ACK的&＃xff0c;可能会对两个报文段发送一个ACK&＃xff0c;也可能会对多个报文段发送1个ACK【累计ACK】&＃xff0c;比如说发送方有1/2/3 3个报文段&＃xff0c;先发送了2,3 两个报文段&＃xff0c;但是接收方期望收到1报文段&＃xff0c;这个时候2,3报文段就只能放在缓存中等待报文1的空洞被填上&＃xff0c;如果报文1&＃xff0c;一直不来&＃xff0c;报文2/3也将被丢弃&＃xff0c;如果报文1来了&＃xff0c;那么会发送一个ACK对这3个报文进行一次确认。

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

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

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

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

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

滑动窗口的流控特性

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

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

滑动窗口动态调整

主要是根据接收端的接收情况&＃xff0c;动态去调整Window Size&＃xff0c;然后来控制发送端的数据流量

客户端不断快速发送数据&＃xff0c;服务器接收相对较慢&＃xff0c;看下实验的结果

a. 包175&＃xff0c;发送ACK携带WIN &＃61; 384&＃xff0c;告知客户端&＃xff0c;现在只能接收384个字节

b. 包176&＃xff0c;客户端果真只发送了384个字节&＃xff0c;Wireshark也比较智能&＃xff0c;也宣告TCP Window Full

c. 包177&＃xff0c;服务器回复一个ACK&＃xff0c;并通告窗口为0&＃xff0c;说明接收方已经收到所有数据&＃xff0c;并保存到缓冲区&＃xff0c;但是这个时候应用程序并没有接收这些数据&＃xff0c;导致缓冲区没有更多的空间&＃xff0c;故通告窗口为0, 这也就是所谓的零窗口&＃xff0c;零窗口期间&＃xff0c;发送方停止发送数据

d. 客户端察觉到窗口为0&＃xff0c;则不再发送数据给接收方

e. 包178&＃xff0c;接收方发送一个窗口通告&＃xff0c;告知发送方已经有接收数据的能力了&＃xff0c;可以发送数据包了

f. 包179&＃xff0c;收到窗口通告之后&＃xff0c;就发送缓冲区内的数据了.

总结一点&＃xff0c;就是接收端可以根据自己的状况通告窗口大小&＃xff0c;从而控制发送端的接收&＃xff0c;进行流量控制

参考&＃xff1a;

TCP 滑动窗口&＃xff08;发送窗口和接收窗口&＃xff09;

解析TCP之滑动窗口(动画演示)

TCP-IP详解&＃xff1a;滑动窗口&＃xff08;Sliding Window&＃xff09;