Windows TCP: TCP接收窗口自动调谐(Auto-Tuning)原理介绍
Windows TCP: TCP接收窗口自动调谐(Auto-Tuning)原理介绍
TCP连接上的吞吐量可以通过发送和接收应用程序、TCP的发送和接收实现以及TCP对等体之间的传输路径来限制。在本文我将介绍TCP接收窗口及其对TCP吞吐量的影响、TCP窗口扩展的使用以及Windows Vista和Windows Server 2008中新的接收窗口自动调整功能，这些功能可优化接收数据的TCP吞吐量。
什么是TCP接收窗口
在介绍TCP接收窗口前，让我们回顾一下TCP连接具有的一些重要特性。
- 首先，它们是两个应用层协议之间的逻辑点对点电路连接。TCP不提供一对多广播传输服务，它只提供一对一传输服务。
- 第二，TCP连接是面向连接的。在传输数据之前，两个应用层进程必须使用TCP连接建立进程正式协商TCP连接。类似地，在使用TCP连接终止过程协商之后，TCP连接被正式关闭。
- 第三，对TCP连接上发送的可靠数据进行排序，并且期望从接收端得到肯定的确认。如果没有接收到肯定确认，则重发该段。在接收端处，丢弃重复的报文，并且以适当的顺序将无序到达的段排序。
- 第四，TCP连接是全双工的。对于每个TCP对等体，TCP连接由两个逻辑管道组成:输出管道和输入管道。TCP报头包含输出数据的序列号和输入数据的确认( ACK )。
- 此外，TCP将通过传入和传出逻辑管道发送的数据视为连续字节流。每个TCP报头中的序列号和确认号是沿字节边界定义的。TCP不关心字节流中的记录或消息边界。应用层协议必须提供对传入字节流的正确解析。
为了限制发送端任何一次可以发送的数据量，并为接收端提供流量控制，TCP对等体使用一个窗口，这个窗口是接收端允许发送端发送的字节流上的数据跨度。发送方只能发送位于窗口内的字节流的字节。窗口沿发送方的出站字节流和接收方的入站字节流滑动，因此又称为TCP滑动窗口。
对于给定的逻辑管道(全双工TCP连接的一个方向)，发送方维护发送窗口，接收方维护接收窗口。当传输中没有数据或ACK段时，将匹配逻辑管道的发送和接收窗口。换句话说，允许发送方发送的出站字节流中的数据跨度与接收方能够接收的入站字节流中的数据跨度相匹配。图1说明了这种发送和接收关系。
为了指示接收窗口的大小，TCP报头包含16位窗口字段。当接收方获得数据时，它将向发送方发送回指示成功接收字节的ACKs。在每个ACK中，“窗口”字段记录接收窗口中剩余的字节数。当应用程序发送、确认和检索数据时，发送和接收窗口都会向右滑动。“接收”窗口是控制从发送方到接收方的未确认数据传输量的窗口。
因为接收窗口中可能有应用程序尚未检索到的数据和已接收但未确认的数据，所以TCP接收窗口具有额外的结构，如图2所示。
请注意最大和当前接收窗口之间的差异。最大接收窗口是固定大小。当前接收窗口具有可变大小，并且对应于接收方允许发送方发送的剩余数据量。当前接收窗口的大小是在发送回发送方的ACKs中通告的窗口字段的值，是最大接收窗口大小与应用程序已接收和确认但未检索的数据量之间的差值。
传输控制协议接收窗口和传输控制协议吞吐量
为了优化TCP吞吐量(假定传输路径合理无误)，发送方应发送足够的数据包以填充发送方和接收方之间的逻辑管道。逻辑管道的容量可通过以下公式计算:
吞吐量(bit) =路径带宽(bit/秒为单位) *往返时间( RTT ) (以秒为单位)
例如： 路径带宽是1Gbps，往返时间( RTT )是100毫秒，则 吞吐量 = (102410241024) * 0.1秒 = 107374183 bit = 13421773 byte
该容量称为带宽延迟乘积( BDP )。管道根据路径带宽和往返时间进行区分，可以是胖(高带宽)、瘦(低带宽)、短(低RTT )、(高RTT )。长而胖的管道具有最高的BDP（又称长肥管道）。高BDP传输路径的示例是通过卫星或企业广域网( WANs )的传输路径，包括洲际光纤链路。
提高高BDP路径传输的发送端性能
新的接收窗口自动调整功能为通过高BDP链路接收数据提供了增强的性能，但发送方性能如何？
防止发送TCP对等体压倒网络的现有算法称为慢启动和拥塞避免。当最初在连接上发送数据时以及从丢失的段恢复时，这些算法增加了发送窗口(发送方可以发送的段的数量)。
慢速启动会为收到的每个确认段( Windows XP和Windows Server 2003中的TCP )或确认的每个段( Windows Vista和Windows Server 2008中的TCP )增加一个完整的TCP段。拥塞避免为每个确认的完整数据窗口增加一个完整TCP段的发送窗口。
这些算法适用于较小的BDPs和较小的接收窗口大小。但是，当TCP连接具有较大的接收窗口大小和较大的BDP (例如，在位于高速WAN链路上的两台服务器之间以100毫秒的往返时间复制数据)时，这些算法不能足够快地增加发送窗口以充分利用连接的带宽。
为了在这些情况下更好地利用TCP连接的带宽，新一代TCP / IP堆栈包括复合TCP ( CTCP )。CTCP更积极地增加具有大接收窗口大小和BDPs的连接的发送窗口。CTCP试图通过监视延迟变化和损耗来最大化这些类型连接的吞吐量。此外，CTCP确保其行为不会对其他TCP连接产生负面影响。
在Microsoft内部执行的测试中，使用50毫秒RTT进行1Gbps连接时，大型文件备份时间缩短了近一半。具有较大BDP的连接可以具有更好的性能。CTCP和Receive Window自动调谐一起工作，以提高链路利用率，并可为与大型BDP的连接带来显著的性能提升。
CTCP默认在运行Windows Server 2008的计算机中启用，在运行Windows Vista的计算机中默认禁用。您可以使用“netsh接口TCP设置全局拥塞提供程序= CTCP”命令启用CTCP。您可以使用“netsh interface tcp set global congestionprovider=none”命令禁用CTCP。
TCP报头中窗口字段的大小为16位，允许TCP对等体通告65，535字节的最大接收窗口大小。您可以根据以下公式计算给定TCP窗口大小的近似吞吐量:
吞吐量= TCP最大接收窗口大小/实时传输
例如，使用65535字节的接收窗口，无论传输路径的实际带宽如何，在100毫秒RTT的路径上，您只能获得大约5.24兆位/秒( Mbps )的吞吐量。在当今的高BDP传输路径中，最初设计的TCP窗口大小，即使是最大值，也会成为吞吐量瓶颈。
TCP窗口缩放因子
对于适应高速传输路径的较大窗口大小，RFC 1323 ( IETF.org/RFC/RFC323.txt )定义窗口缩放，其允许接收器通告大于65535字节的窗口大小。TCP窗口缩放选项包括窗口缩放因子，当与TCP报头中的16位窗口字段组合时，可以将接收窗口大小增加到最大值约1GB。在连接建立过程中，窗口缩放选项仅在同步( SYN )段中发送。两个TCP对等体都可以指示用于其接收窗口大小的不同窗口缩放因子。通过允许发送方在连接上发送更多数据，TCP窗口缩放允许TCP节点更好地利用具有高BDP的某些类型的传输路径。
虽然接收窗口大小对于TCP吞吐量很重要，但是确定最佳TCP吞吐量的另一个重要因素是应用程序在接收窗口缓冲区中获取累积数据的速度(应用程序获取速率)。如果应用程序未获取数据，则接收窗口会开始堆积数据，从而导致接收器通告较小的当前窗口大小。在极端情况下，整个最大接收窗口被填满，导致接收器通告窗口大小为0字节。在这种情况下，发送方必须停止发送数据，直到清除接收窗口。因此，为了优化TCP吞吐量，应将连接的TCP接收窗口设置为既反映连接传输路径的BDP又反映应用程序获取速率的值。
即使您可以正确地确定BDP和应用程序检索速率，它们也可以随时间变化。BDP速率可以基于传输路径中的拥塞而变化，并且app检索速率可以基于app正在其上接收数据的连接的数量而变化。
windows XP中的TCP接收窗口
对于Windows XP (和Windows Server 2003 )中的TCP/IP协议栈，最大接收窗口大小具有许多重要属性。首先，默认值基于发送接口的链路速度。实际值自动调整为TCP连接建立期间协商的最大段大小( MSS )的偶数增量。
其次，可以手动配置最大接收窗口大小。HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize和HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize注册表值最多可以设置为65535字节(不进行窗口缩放)或1073741823 (进行窗口缩放)
第三，最大接收窗口大小可以使用窗口缩放。您可以通过将HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts的注册表值设置为1或3来启用窗口缩放。默认情况下，仅当接收到的SYN段碰巧包含“窗口缩放”选项时，才会在连接上使用窗口缩放。
最后，应用程序可以在启动连接时使用SO_RCVBUF窗口套接字选项指定最大接收窗口大小。对于窗口缩放，应用程序必须指定大于65535字节的窗口大小。
尽管支持可扩展窗口，但Windows XP中的最大接收窗口大小仍然可以限制吞吐量，因为它是所有TCP连接的固定最大大小(除非应用程序指定)，这可以增加某些连接的吞吐量，而降低其他连接的吞吐量。此外，TCP连接的固定最大接收窗口大小不会随应用程序检索速率的变化或传输路径中的拥塞而变化。
Windows Vista及之后的Windows(win7/win8/win10) TCP接收窗口自动调整
为了优化TCP吞吐量，特别是对于具有高BDP的传输路径，从Windows Vista和Windows Server 2008起，微软新一代TCP / IP堆栈支持接收窗口自动调整。此功能通过测量BDP和应用程序获取数据速率并根据正在进行的传输路径和应用程序条件调整窗口大小来确定最佳接收窗口大小。
默认情况下，接收窗口自动调整启用TCP窗口缩放，最多允许16MB的最大接收窗口大小。当数据在连接上流动时，下一代TCP / IP堆栈将监视连接，测量其当前BDP和应用程序检索速率，并调整接收窗口大小以优化吞吐量。新一代TCP / IP堆栈不再使用TCPWindowSize注册表值。
接收窗口自动调整有许多好处。它会自动确定每个连接的最佳接收窗口大小。在Windows XP中，TCPWindowSize注册表值适用于所有连接。应用程序不再需要通过Windows套接字选项指定TCP窗口大小。并且IT管理员不再需要为特定计算机手动配置TCP接收窗口大小。
通过接收窗口自动调整，基于Windows Vista的TCP对等体通常会通告比基于Windows XP的TCP对等体大得多的接收窗口大小。这允许另一个TCP对等体通过发送更多的TCP数据段来填充到基于Windows Vista的TCP对等体的管道，而不必等待ACK (受TCP拥塞控制的约束)。对于典型的基于客户端的网络流量(例如网页或电子邮件)，Web服务器或电子邮件服务器将能够更快地向客户端计算机发送更多TCP数据，从而导致网络性能的总体提高。连接的BDP和应用程序检索率越高，性能提高越好。
对网络的影响是，通常以较低的测量速度发送的TCP数据包流被发送得快得多，从而导致在数据传输期间网络利用率的较大峰值。对于基于Windows XP和Windows Vista的计算机，通过长而胖的管道执行相同的数据传输，传输的数据量相同。但是，基于Windows Vista的客户端计算机的数据传输速度更快，因为接收窗口较大，而且服务器能够将管道从服务器填充到客户端。
因为接收窗口自动调谐将增加高BDP传输路径的网络利用率，所以服务质量( QoS )或应用发送速率限制的使用对于以或接近容量运行的传输路径可能变得重要。为了满足这种可能的需求，Windows Vista支持基于组策略的QoS设置，允许您基于IP地址或TCP端口定义已发送流量的限制速率。
提高在高丢包网络的TCP吞吐量
由于频繁的超时和重传，高丢包网络会显著降低TCP吞吐量。高损耗网络的示例是无线网络，诸如基于IEEE 802.11、通用分组无线业务( GPRS )或通用移动电信系统( UMTS )的无线网络，其可以具有取决于网络条件、信号衰减、电磁干扰和计算机的变化位置的高分组丢包。
Windows新一代TCP / IP堆栈支持以下四个RFCs，以便在高损耗环境中优化吞吐量。
- RFC2582: TCP快速恢复算法的NewReno改进 RFC 2001中定义的快速恢复算法基于Reno算法，该算法增加了当由于快速重传事件而重传段时发送方可以发送的数据量。虽然Reno算法对于单个丢失段工作良好，但是当存在多个丢失段时，它的性能不太好。NewReno算法通过改变发送方在数据窗口中的多个段丢失且发送方接收到部分确认(仅针对已成功接收的部分数据的确认)时在快速恢复期间增加其发送速率的方式来提供更快的吞吐量。
- RFC 2288 :对TCP的选择性确认( SACK )选项的扩展 SACK在RFC 2018中定义，允许接收器通过使用SACK TCP选项来指示多达四个不连续的接收数据块。RFC 2288定义了SACK TCP选项中字段的附加使用，以确认重复数据包。通过这样做，发送方能够确定其何时不必要地重发了段，并且调整其行为以防止将来不必要地重发。发送的重传越少，总吞吐量就越好。
- RFC3517 ：一种保守的基于选择性确认的TCP丢包恢复算法 当前在Windows Server 2003和Windows XP中实现的TCP / IP仅使用SACK信息来确定哪些TCP段尚未到达目的地。RFC 3321定义了一种在接收到重复确认时使用SACK信息来执行丢失恢复的方法，从而在连接上启用SACK时替换旧的快速恢复算法。新一代TCP / IP堆栈基于每个连接跟踪SACK信息，并监视传入确认以及重复确认，以便在目标未接收到多个段时更快地恢复。
- RFC4138：转发恢复( F - RTO ) :一种检测虚假重传超时的算法 TCP段的虚假重传可以随着RTT的突然增加而发生，导致先前发送的段的重传超时( RTOs )开始期满并且TCP开始重传它们。如果RTT的增加发生在发送整个数据窗口之前，则发送方可以重新发送整个数据窗口。F - RTO算法通过以下行为防止TCP段的虚假重传。 当多个段的RTO到期时，TCP仅重新传输第一个段。当接收到第一个ACK时，TCP开始发送新段(如果广告窗口大小允许)。如果下一个ACK确认已超时但尚未重新传输的其他段，则TCP确定超时是假的，并且不会重新传输已超时的其他段。 结果是，对于RTT突然和临时增加的环境，例如当无线客户端从一个接入点漫游到另一接入点时，F - RTO防止不必要的段重传，并且更快地返回到其正常发送速率。使用基于SACK的丢失恢复和F - RTO最适合使用GPRS链路的连接。
本文系外文翻译，前往查看
如有侵权，请联系?cloudcommunity@tencent.com?删除。
本文系外文翻译，前往查看
如有侵权，请联系?cloudcommunity@tencent.com 删除。