TCP 协议中的 Window Size与吞吐量

原地址：http://blog.sina.com.cn/s/blog_c5c2d6690102wpxl.html

TCP协议中影响实际业务流量的参数不少，这里主要分析一下窗口的影响。

​TCP窗口目的

为了得到最优的链接速率，使用TCP窗口来控制流速率（flow control），滑动窗口就是一种主要的机制。这个窗口容许源端在给定链接传送数据分段而不用等待目标端返回ACK，一句话描述：窗口的大小决定在不须要对端响应（acknowledgement）状况下传送数据的数量。​官方定义：“The amount of octets that can be transmitted without receiving an acknowledgement from the other side”。

TCP窗口机制

​​TCP header中有一个Window Size字段，它实际上是指接收端的窗口，即接收窗口，用来告知发送端本身所能接收的数据量，从而达到一部分流控的目的。其实TCP在整个发送过程当中，也在度量当前的网络状态，目的是为了维持一个健康稳定的发送过程，好比拥塞控制。所以，数据是在某些机制的控制下进行传输的，就是窗口机制。发送端的发送窗口是基于接收端的接收窗口来计算的，也就是咱们常说的TCP是有链接的发送，数据传输须要对端确认，发送的数据分为以下四类来看

窗口滑动发送数据

（1）已经发送而且对端确认（Sent/ACKed）---------------发送窗外 缓冲区外

（2）已经发送但未收到确认数据（Sent/UnACKed）----- --发送窗内 缓冲区内​

（3）容许发送但还没有防的数据​（Unsent/Inside）-----------发送窗内 缓冲区内​

（4）未发送暂不容许（Unsent/Outside）-------------------发送窗外 缓冲区内​

TCP窗口就是这样逐渐滑动，发送新的数据，滑动的依据就是发送数据已经收到ACK，确认对端收到，才能继续窗口滑动发送新的数据。能够看到窗口大小对于吞吐量有着重要影响，同时ACK响应与系统延时又密切相关。须要说明的是：若是发送端的窗口过大会引发接收端关闭窗口，处理不过来反之，若是窗口设置较小，结果就是不能充分利用带宽，因此仔细调节窗口对于适应不一样延迟和带宽要求的系统很重要。

TCP窗口大小

最先TCP协议涉及用来大范围网络传输时候，实际上是没有超过56Kb/s的​链接速度的。所以，TCP包头中只保留了16bit用来标识窗口大小，容许的最大缓存大小不超过64KB。为了打破这一限制，RFC1323规定了TCP窗口尺寸选择，是在TCP链接开始的时候三步握手的时候协商的（SYN, SYN-ACK,ACK），会协商一个  Window size scaling factor，以后交互数据中的是Window size value，因此最终的窗口大小是两者的乘积.

Window size value: 64 or 0000 0000 0100 0000 (16 bits) 

​Window size scaling factor: 256 or 2 ^ 8 (as advertised by the 1st packet) 

The actual window size is 16,384 (64 * 256)

这里的窗口大小就意味着，直到发送16384个字节，才会中止等待对方的ACK.随着双方回话继续，窗口的大小能够修改window size value 参数完成变窄或变宽，可是注意：Window size scaling factor乘积因子​必须保持不变。在RFC1323中规定的偏移（shift count）是14，也就是说最大的窗口能够达到Gbit,很大。

Wireshark抓包实例

这一机制并不老是默认开启的和系统有关，貌似Linux默认开启，Windows默认关闭。

​TCP窗口的参数设置

TCP窗口起着控制流量的做用，实际使用时这是一个双端协调的过程，还涉及到TCP的慢启动​（Rapid Increase/Multiplicative Decrease），拥塞避免，拥塞窗口和拥塞控制。能够记住，发送速率是由min（拥塞窗口，接收窗口），接收窗口在下文有讲。

TCP窗口优化设置​

TCP​窗口既然那么重要，那要怎么设置，一个简单的原则是2倍的BDP.这里的BDP的意思是bandwidth-delay product，也就是带宽和时延的乘积，带宽对于网络取最差链接的带宽。

buffer size = 2 * bandwidth * delay​

还有一种简单的方式，使用ping来计算网络的环回时延（RTT），而后表达为：

buffer size = bandwidth * RTT​

​为何是2倍？由于能够这么想，若是滑动窗口是bandwidth*delay，当发送一次数据最后一个字节刚到时，对端要回ACK才能继续发送，就须要等待一次单向时延的时间，因此当是2倍时，恰好就能在等ACK的时间继续发送数据，等收到ACK时数据恰好发送完成，这样就提升了效率。

举个例子：带宽是20Mbps,经过ping咱们计算单向时延是20ms，那么能够计算：20000000bps*8*0.02 = 52,428bytes​，所以咱们最优窗口用 104,856 bytes = 2 x 52,428，因此说当发送者发送104,856 bytes数据后才须要等待一个ACK响应，当发送了一半的时候，对端已经收到而且返回ACK（理想状况），等到ACK回来，又把剩下的一半发送出去了，因此发送端就无需等待ACK返回。

发现了么？这里的窗口已经明显大于64KB了，因此机制改善了，上一级。

TCP窗口流量控制​

​如今咱们看看到底如何控制流量。TCP在传输数据时和windows size 关系密切，自己窗口用来控制流量，在传输数据时，发送方数据超过接收方就会丢包，流量控制，流量控制要求数据传输双方在每次交互时声明各自的接收窗口「rwnd」大小，用来表示本身最大能保存多少数据，这主要是针对接收方而言的，通俗点儿说就是让发送方知道接收方能吃几碗饭，若是窗口衰减到零，也就是发送方不能再发了，那么就说明吃饱了，必须消化消化，若是硬撑胀漏了，那就是丢包了。

流量控制

慢启动     ​虽然流量控制能够避免发送方过载接收方，可是却没法避免过载网络，这是由于接收窗口「rwnd」只反映了服务器个体的状况，却没法反映网络总体的状况。

为了不网络过载，慢启动引入了拥塞窗口「cwnd」的概念，用来表示发送方在获得接收方确认前，最大容许传输的未经确认的数据。「cwnd」同「rwnd」相比不一样的是：它只是发送方的一个内部参数，无需通知给接收方，其初始值每每比较小，而后随着数据包被接收方确认，窗口成倍扩大，有点相似于拳击比赛，开始时不了解敌情，每每是次拳试探，慢慢内心有底了，开始逐渐加大重拳进攻的力度。

拥塞窗口扩大

在慢启动的过程当中，随着「cwnd」的增长，可能会出现网络过载，其外在表现就是丢包，一旦出现此类问题，「cwnd」的大小会迅速衰减，以便网络可以缓过来。

拥塞窗口与丢包

说明：网络中实际传输的未经确认的数据大小取决于「rwnd」和「cwnd」中的小值。

拥塞避免​  从慢启动的介绍中，咱们能看到，发送方经过对「cwnd」大小的控制，可以避免网络过载，在此过程当中，丢包与其说是一个网络问题，倒不如说是一种反馈机制，经过它咱们能够感知到发生了网络拥塞，进而调整数据传输策略，实际上，这里还有一个慢启动阈值「ssthresh」的概念，若是「cwnd」小于「ssthresh」，那么表示在慢启动阶段；若是「cwnd」大于「ssthresh」，那么表示在拥塞避免阶段，此时「cwnd」再也不像慢启动阶段那样呈指数级整整，而是趋向于线性增加，以期避免网络拥塞，此阶段有多种算法实现，一般保持缺省便可，这里就不一一说明了。

​如何调整「rwnd」到一个合理值  不少时候TCP的传输速率异常偏低，颇有多是接收窗口「rwnd」太小致使，尤为对于时延较大的网络，实际上接收窗口「rwnd」的合理值取决于BDP的大小，也就是带宽和延迟的乘积。假设带宽是 100Mbps，延迟是 100ms，那么计算过程以下：

BDP = 100Mbps * 100ms = (100 / 8) * (100 / 1000) = 1.25MB​

 

​此问题下若是想最大限度提高吞度量，接收窗口「rwnd」的大小不该小于 1.25MB。

如何调整「cwnd」到一个合理值 通常来讲「cwnd」的初始值取决于MSS的大小，计算方法以下：

min(4 * MSS, max(2 * MSS, 4380))

以太网标准的MSS大小一般是1460，因此「cwnd」的初始值是3MSS。当咱们浏览视频或者下载软件的时候，「cwnd」初始值的影响并不明显，这是由于传输的数据量比较大，时间比较长，相比之下，即使慢启动阶段「cwnd」初始值比较小，也会在相对很短的时间内加速到满窗口，基本上能够忽略不计。下图使用IxChariot完成一次设置​

设置cwnd

   不过当咱们浏览网页的时候，状况就不同了，这是由于传输的数据量比较小，时间比较短，相比之下，若是慢启动阶段「cwnd」初始值比较小，那么极可能还没来得及加速到满窗口，通信就结束了。这就比如博尔特参加百米比赛，若是起跑慢的话，即使他的加速很快，也可能拿不到好成绩，由于还没等他彻底跑起来，终点线已经到了

结语​

文中大量参考下面博客内容，好比最后一节几乎彻底来自于第一个博客，详细内容跳转连接，学习总结，记录一下。​

https://huoding.com/2013/11/21/299

https://my.oschina.net/greki/blog/264061​

​http://www.cnblogs.com/woaiyy/p/3554182.html