Windows TCP窗口缩放太早打高原

你有没有尝试在Windows 7/8客户端启用化合物TCP （CTCP）。

请阅读：

提高发送端的高BDP传输性能

http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx

…

这些algorithm适用于小BDP和较小的接收窗口大小。 但是，如果您的TCP连接具有较大的接收窗口大小和较大的BDP ，例如在跨越高速WAN链接的两台服务器之间复制数据（往返时间为100ms） ，则这些algorithm不会增加发送窗口快到足以充分利用连接的带宽 。

为了在这些情况下更好地利用TCP连接的带宽，下一代TCP / IP协议栈包括复合TCP（CTCP）。 CTCP更积极地增加 大接收窗口大小和BDP连接 的发送窗口 。 CTCP试图通过监测延迟变化和损失来使这些types的连接的吞吐量最大化。 此外，CTCP确保其行为不会对其他TCP连接产生负面影响。

…

运行Windows Server 2008的计算机默认情况下启用CTCP，并且在运行Windows Vista的计算机上默认情况下禁用CTCP。 你可以使用netsh interface tcp set global congestionprovider=ctcp命令启用CTCP。 你可以使用netsh interface tcp set global congestionprovider=none命令禁用CTCP。

编辑6/30/2014

看CTCP是否真的“开”

 > netsh int tcp show global 

即

PO说：

如果我正确地理解了这个，这个设置增加了 拥塞窗口被放大 的速度， 而不是 它可以达到 的最大大小

CTCP积极增加发送窗口

http://technet.microsoft.com/en-us/library/bb878127.aspx

复合TCP

现有的防止发送TCP对等体压倒networking的algorithm称为慢启动和拥塞避免。 当最初在连接上发送数据时以及从丢失的段中恢复时，这些algorithm增加了发送者可以发送的段（称为发送窗口）的数量。 对于接收到的每个确认段（对于Windows XP和Windows Server 2003中的TCP）或确认的每个段（对于Windows Vista和Windows Server 2008中的TCP），启动速度较慢均会使发送窗口增加一个完整的TCP段。 拥塞避免将发送窗口增加一个完整的TCP段，以确认每个完整的数据窗口。

这些algorithm适用于LAN介质速度和较小的TCP窗口大小。 但是，如果您的TCP接口的接收窗口大小较大，带宽延迟较大（高带宽和高延迟），则可能需要在跨越高速WAN链路的两台服务器之间复制数据（往返时间为100 ms）时间，这些algorithm不会足够快地增加发送窗口以充分利用连接的带宽。 例如，在往返时间（RTT）为100毫秒的1千兆比特每秒（Gbps）WAN链路上， 发送窗口最初 可能 需要一个小时才能增加到 由接收方广播 的 大窗口大小，当 有丢失的部分 时恢复 。

为了在这些情况下更好地利用 TCP连接的带宽 ，下一代TCP / IP协议栈包括复合TCP （CTCP）。 CTCP更积极地增加大接收窗口大小和大带宽延迟产品连接的发送窗口。 CTCP试图通过监测延迟变化和损失来使这些types的连接的吞吐量最大化。 CTCP还确保其行为不会对其他TCP连接产生负面影响。

在Microsoft内部进行的testing中，使用50ms RTT进行1 Gbps连接的大文件备份时间减less了将近一半。 具有更大带宽延迟产品的连接可以具有更好的性能。 CTCP和接收窗口自动调谐一起工作，以提高链路利用率，并可为大带宽延迟产品连接带来显着的性能提升。

澄清问题：

TCP有两个窗口：

• 接收窗口：缓冲区中剩下多less个字节。 这是接收器施加的stream量控制。 您可以在wireshark中看到接收窗口的大小，因为它是由TCP报头内的窗口大小和窗口缩放因子组成的。 TCP连接的两端将通告他们的接收窗口，但是通常你关心的是接收大量数据的那个。 在你的情况下，这是客户端上传到服务器的“服务器”
• 拥塞窗口。 这是发件人强加的stream量控制。 这由操作系统维护，并不会显示在TCP标头中。 它控制着数据传输的速度。

在你提供的捕获文件中。 我们可以看到接收缓冲区永远不会溢出：

我的分析是发送者发送速度不够快，因为发送窗口（也就是拥塞控制窗口）没有足够的开放来满足接收者的RWIN。 所以简而言之，接收者说“给我更多”，当Windows是发送者时，发送速度不够快。

这可以从以下事实得到证实：在上面的图中，RWIN保持打开状态，往返时间为.09秒，RWIN为〜500,000字节，我们可以根据带宽延迟乘积得出最大吞吐量（500000 /0.09）* 8 =〜42 Mbit / s（而且你只能获得大约5分的胜利）。

如何解决它？

我不知道。 interface tcp set global congestionprovider=ctcp听起来像是对我做的正确的事情，因为它会增加发送窗口（这是拥塞窗口的另一个术语）。 你说这是行不通的。 所以只是为了确保：

1. 启用后重新启动了吗？
2. 烟囱卸载了吗？ 如果它可能试图把它closures作为一个实验。 我不知道什么时候启用，但是如果控制发送窗口是其中之一，也许拥塞提供者没有任何效果时，这是启用…我只是猜测…
3. 此外，我认为这可能是Windows 7之前，但您可以尝试添加和使用名为DefaultSendWindow和DefaultReceiveWindow HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-Parameters中的两个registry项。 如果这些甚至工作，你可能会说它有ctcpclosures。
4. 还有一个猜测，试试看netsh interface tcp show heuristics 。 我认为这可能是RWIN，但它并没有说，所以也许玩禁用/启用，如果它影响发送窗口。
5. 另外，请确保您的驱动程序在您的testing客户端上是最新的。 也许有什么东西坏了。

我会尝试所有这些实验，所有你卸载function，以消除networking驱动程序正在做一些重写/修改的东西（保持眼睛CPU卸载时禁用）的可能性开始。 TCP_OFFLOAD_STATE_DELEGATED结构似乎至less意味着CWnd卸载至less是可能的。

@Pat和@Kyle有一些很棒的信息。 肯定要注意@Kyle对TCP的接收和发送窗口的解释 ，我觉得周围有一些困惑。 为了进一步混淆事件，iperf使用术语“TCP窗口”和-w设置，这是关于接收，发送或整体滑动窗口的模糊术语。 它实际上是为-c （客户机）实例设置套接字发送缓冲区，并在-s （服务器）实例上设置套接字接收缓冲区。 在src/tcp_window_size.c ：

 if ( !inSend ) { /* receive buffer -- set * note: results are verified after connect() or listen(), * since some OS's don't show the corrected value until then. */ newTCPWin = inTCPWin; rc = setsockopt( inSock, SOL_SOCKET, SO_RCVBUF, (char*) &newTCPWin, sizeof( newTCPWin )); } else { /* send buffer -- set * note: results are verified after connect() or listen(), * since some OS's don't show the corrected value until then. */ newTCPWin = inTCPWin; rc = setsockopt( inSock, SOL_SOCKET, SO_SNDBUF, (char*) &newTCPWin, sizeof( newTCPWin )); } 

正如凯尔提到的那样，问题不在于Linux机器上的接收窗口，而是发送器没有足够的开放发送窗口。 这并不是说它的开放速度不够快，它只能达到64k。

Windows 7上的默认套接字缓冲区大小是64k。 以下是文档中关于与MSDN吞吐量相关的套接字缓冲区大小的说明

使用Windows套接字通过TCP连接发送数据时，为了实现最高的吞吐量，在TCP中保留足够数量的未完成数据（发送但尚未确认）是非常重要的。 为了达到TCP连接的最佳吞吐量而突出的数据量的理想值被称为理想发送积压（ISB）大小。 ISB值是TCP连接和接收者公布的接收窗口的带宽延迟乘积（部分是networking拥塞量）的函数。

好吧，等等等等，现在我们走了：

一次执行一个阻塞或非阻塞发送请求的应用程序通常依靠Winsock的内部发送缓冲来实现相当的吞吐量。 给定连接的发送缓冲区限制由SO_SNDBUF套接字选项控制。 对于阻塞和非阻塞发送方法， 发送缓冲区限制决定了TCP中有多less数据保持未完成状态 。 如果连接的ISB值大于发送缓冲区限制，则在连接上达到的吞吐量将不是最佳的。

最近使用64k窗口的iperftesting的平均吞吐量是5.8Mbps。 这是来自统计>摘要在Wireshark，统计所有的位。 可能，iperf正在计算TCP数据吞吐量为5.7Mbps。 我们也看到与FTPtesting相同的性能，〜5.6Mbps。

具有64k发送缓冲器和91ms RTT的理论吞吐量是…. 5.5Mbps。 足够接近我。

如果我们看你的1MB窗口iperftesting，输出是88.2Mbps（TCP数据为86.2Mbps）。 具有1MB窗口的理论输出是87.9Mbps。 再次，足够接近政府工作。

这certificate了发送套接字缓冲区直接控制发送窗口，并且与另一端的接收窗口一起控制吞吐量。 广告的接收窗口有空间，所以我们不受接收机的限制。

抱起来，这个自动调整业务呢？ Windows 7不会自动处理这些东西？ 如前所述，Windows不会处理接收窗口的自动缩放，但它也可以dynamic地处理发送缓冲区。 我们回到MSDN页面：

在Windows 7和Windows Server 2008 R2上添加了针对TCP的dynamic发送缓冲。 默认情况下，除非应用程序在stream套接字上设置SO_SNDBUF套接字选项，否则将启用TCP的dynamic发送缓冲。

当使用-w选项时，iperf使用SO_SNDBUF ，所以dynamic发送缓冲将被禁用。 但是，如果您不使用-w那么它不会使用SO_SNDBUF 。 dynamic发送缓冲应该在默认情况下，但你可以检查：

 netsh winsock show autotuning 

该文件说，你可以禁用它：

 netsh winsock set autotuning off 

但是这对我没有用。 我不得不做一个registry更改，并将其设置为0：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable

我不认为禁用这将有助于; 这只是一个FYI。

为什么当发送数据到一个在接收窗口中有足够空间的Linux机器时，你的发送缓冲区不能扩展到默认的64k以上呢？ 伟大的问题。 Linux内核也有一个自动调整的TCP栈。 就像T-Pain和Kanye一起做自动调音，听起来可能不太好。 也许这两个自动调整的TCP协议栈之间存在一些问题。

另一个人就像你的问题，并能修复registry编辑，以增加默认的发送缓冲区大小。 不幸的是，这似乎不再起作用，至less在我尝试时并不适合我。

在这一点上，我认为很明显，限制因素是Windows主机上的发送缓冲区大小。 鉴于它似乎没有dynamic增长，女孩子该做什么？

您可以：

• 使用应用程序，允许您设置发送缓冲区，即窗口选项
• 使用本地Linux代理
• 使用远程Windows代理？
• 与Microsofhahahahahahaha开​​个案
• 啤酒

免责声明：我花了很多时间研究这个问题，这是我的最好的知识和谷歌福是正确的。 但我不会在我母亲的坟墓上发誓（她还活着）。

一旦你调整了TCP堆栈，你可能仍然在Winsock层有一个瓶颈。 我发现在Windows 7中configurationWinsock（辅助function驱动程序）对于上传速度（将数据推送到服务器）有很大的不同。微软已经承认TCP自动调用非阻塞套接字中的一个错误 – 只是浏览器使用的一种套接字;-)

为DefaultSendWindow添加DWORD键并将其设置为BDP或更高版本。 我正在使用256000。

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters\DefaultSendWindow 

更改下载Winsock设置可能会有所帮助 – 为DefaultReceiveWindow添加一个密钥。

您可以使用Fiddler Proxy和命令来调整客户端和服务器套接字缓冲区大小，以尝试各种套接字级别设置：

 prefs set fiddler.network.sockets.Server_SO_SNDBUF 65536 fiddler.network.sockets.Client_SO_SNDBUF fiddler.network.sockets.Client_SO_RCVBUF fiddler.network.sockets.Server_SO_SNDBUF fiddler.network.sockets.Server_SO_RCVBUF 

在阅读了答案中的所有分析之后，这个问题听起来像是在运行Windows7 / 2008R2又名Windows 6.1

Windows 6.1中的networking堆栈（TCP / IP＆Winsock）存在可怕的缺陷，并且存在大量的错误和性能问题，微软最终从6.1的最初版本开始就经历了多年的修复。

应用这些修补程序的最佳方法是手动筛选support.microsoft.com上的所有相关页面，并手动请求并下载networking堆栈修补程序的LDR版本（其中包含许多这样的修复程序）。

要查找相关修补程序，必须将www.bing.com与以下search查询site:support.microsoft.com 6.1.7601 tcpip.sys

您还需要了解LDR / GDR修复程序在Windows 6.1中如何工作

我通常用来维护我自己的Windows 6.1的LDR修复列表（不只是networking堆栈修复），然后主动将这些修复应用到我遇到的任何Windows 6.1服务器/客户端。 定期检查新的LDR修补程序是非常耗时的工作。

幸运的是，微软已经停止了使用较新的操作系统版本的LDR修补程序的做法，现在可以通过微软的自动更新服务来修复错误。

更新 ：只是Windows7SP1中的许多networking错误的一个例子 – https://support.microsoft.com/en-us/kb/2675785

更新2 ：这是另一个修补程序，它添加一个netsh开关，以便在第二次重新传输SYN数据包之后强制Window缩放（默认情况下，在重新传输2个SYN数据包之后，将禁用窗口缩放） https://support.microsoft.com/zh-cn/library-我们/ KB / 2780879

我遇到了与Windows客户端（Windows 7）类似的问题。 我经历了大部分的debugging，禁用了Naglealgorithm，TCP Chimney Offloading以及其他大量的TCP相关设置更改。 其中没有任何影响。

最后修复了AFD服务registry的默认发送窗口。 这个问题似乎与afd.sys文件有关。 我testing了几个客户端，有些显示上传缓慢，有些则没有，但都是Windows 7机器。 显示缓慢行为的机器具有相同版本的AFD.sys。 对于某些AFD.sys版本的计算机，需要使用registry解决方法（对不起，请不要回忆版本＃）。

HKLM \ CURRENTCONTROLSET \ SERVICES \ AFD \参数

添加 – DWORD – DefaultSendWindow

值 – 十进制 – 1640960

这个值是我在这里find的： https : //helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

我认为要使用适当的值，你应该使用下面的方法来计算它：

例如。 广告上传：15 Mbps = 15,000 Kbps

（15000/8）* 1024 = 1920000

据我所知，客户端软件通常应该覆盖registry中的这个设置，但是如果他们不这样做的话，就会使用默认值，而且显然AFD.sys文件的某些版本的默认值非常低。

我注意到，大多数MS产品有缓慢的上传问题（IE浏览器，迷你redirect器（WebDAV），FTP通过Windows资源pipe理器等…）当使用第三方软件（例如Filezilla），我没有相同的减速。

The AFD.sys effects all Winsock connections, so this fix should apply to FTP, HTTP, HTTPS, etc…

Also, this fix was listed above somewhere as well, so I don't want to take credit for it if it works for anybody, however there was so much information in this thread that I was afraid it might have been glossed over.

Well, I've run into a similar situation myself (my question here ), and in the end I had to disable TCP scaling heuristics, manually set the autotuning profile and enable CTCP:

 # disable heuristics C:\Windows\system32>netsh interface tcp set heuristics wsh=disabled Ok. # enable receive-side scaling C:\Windows\system32>netsh int tcp set global rss=enabled Ok. # manually set autotuning profile C:\Windows\system32>netsh interface tcp set global autotuning=experimental Ok. # set congestion provider C:\Windows\system32>netsh interface tcp set global congestionprovider=ctcp Ok. 

I see this is a little bit older post but it could help others.

In short you have to enable "Receive Window Auto-Tuning":

 netsh int tcp set global autotuninglevel=normal 

CTCP means nothing without above enabled.

If you disable "Receive Window Auto-Tuning" you will be stuck at 64KB packet size which has negative impact over long RTT's in high broadband connections. You can also experiment with "restricted" and "highlyrestricted" option.

Very good reference: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

I don't have enough points to comment, so I'll post an "answer" instead. I'm having what appears to be a similar/identical problem (see serverfault question here ). My (and probably your) problem is the send buffer of the iperf client on windows. It does not grow beyond 64 KB. Windows is supposed to dynamically grow the buffer when it is not explicitly sized by the process. But that dynamic growth is not happening.

I'm not sure about your window scaling graph that shows the window opening up to 500,000 bytes for your "slow" Windows case. I expected to see that graph open to only ~64,000 bytes given that you are limited to 5 Mbps.

This is a fascinating thread and exactly matches issues I've had using Win7/iperf to test throughput on long fat pipes.

The solution for Windows 7 is to execute the following command on both the iperf server AND the client.

netsh interface tcp set global autotuninglevel=experimental

NB: Before you do this, be sure to record the current status of autotuning:

netsh interface tcp show global

Receive Window Auto-Tuning Level : disabled

Then run the iperf server/client at each end of the pipe.

Reset the autotuning value following your tests:

netsh interface tcp set global autotuninglevel=

  autotuninglevel - One of the following values: disabled: Fix the receive window at its default value. highlyrestricted: Allow the receive window to grow beyond its default value, but do so very conservatively. restricted: Allow the receive window to grow beyond its default value, but limit such growth in some scenarios. normal: Allow the receive window to grow to accomodate almost all scenarios. experimental: Allow the receive window to grow to accomodate extreme scenarios.