Windows TCP 窗口缩放过早达到稳定状态

Question 1

您是否尝试过启用复合TCP（CTCP）在您的 Windows 7/8 客户端中。

请阅读：

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

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

...

这些算法适用于小型 BDP以及较小的接收窗口大小。但是，当您的 TCP 连接具有较大的接收窗口大小和大型 BDP比如在高速网络上的两台服务器之间复制数据WAN 链路往返时间为 100ms，这些算法增加发送窗口的速度不够快，无法充分利用连接的带宽。

为了在这些情况下更好地利用 TCP 连接的带宽，下一代 TCP/IP 堆栈包括复合 TCP (CTCP)。CTCP 更积极地增加发送窗口 具有较大接收窗口大小和 BDP 的连接。CTCP 尝试通过监控延迟变化和丢失来最大化此类连接的吞吐量。此外，CTCP 确保其行为不会对其他 TCP 连接产生负面影响。

...

在运行 Windows Server 2008 的计算机中，CTCP 默认启用；在运行 Windows Vista 的计算机中，CTCP 默认禁用。您可以使用该netsh interface tcp set global congestionprovider=ctcp命令启用 CTCP。您可以使用该命令禁用 CTCP netsh interface tcp set global congestionprovider=none。

编辑 2014/6/30

看看 CTCP 是否真的“开启”

> netsh int tcp show global

IE

在此处输入图片描述

PO 说：

如果我理解正确的话，此设置会增加 拥塞窗口被放大，而不是最大尺寸 它可以达到

CTCP 积极增加发送窗口

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

复合TCP

现有的防止发送 TCP 对等体压垮网络的算法称为慢启动和拥塞避免。这些算法增加了发送方在连接上最初发送数据时以及从丢失的段中恢复时可以发送的段数量（称为发送窗口）。慢启动会将发送窗口增加一个完整的 TCP 段，无论是对于收到的每个确认段（对于 Windows XP 和 Windows Server 2003 中的 TCP）还是对于确认的每个段（对于 Windows Vista 和 Windows Server 2008 中的 TCP）。拥塞避免会将发送窗口增加一个完整的 TCP 段，无论对于确认的每个完整数据窗口。

这些算法在 LAN 媒体速度和较小的 TCP 窗口大小下效果很好。但是，当您的 TCP 连接具有较大的接收窗口大小和较大的带宽延迟乘积（高带宽和高延迟）时，例如在往返时间为 100 毫秒的高速 WAN 链路上的两台服务器之间复制数据，这些算法无法足够快地增加发送窗口以充分利用连接的带宽。例如，在往返时间为 100 毫秒的 1 千兆位每秒 (Gbps) WAN 链路上，它可以 发送窗口最初需要一个小时才能增加到 接收方通告的大窗口大小，以及何时恢复 有丢失的片段。

为了更好地利用带宽在这些情况下，下一代 TCP/IP 堆栈包括复合TCP （CTCP）。对于接收窗口较大且带宽延迟积较大的连接，CTCP 会更积极地增加发送窗口。CTCP 会尝试通过以下方式最大化此类连接的吞吐量：监控延迟变化和丢失。CTCP 还确保其行为不会对其他 TCP 连接产生负面影响。

在 Microsoft 内部进行的测试中，对于 1 Gbps 连接和 50ms RTT，大文件备份时间减少了近一半。带宽延迟积更大的连接可以实现更好的性能。CTCP 和接收窗口自动调整协同工作以提高链路利用率，并可为大带宽延迟积连接带来显著的性能提升。

Answer

您是否尝试过启用复合TCP（CTCP）在您的 Windows 7/8 客户端中。

请阅读：

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

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

...

这些算法适用于小型 BDP以及较小的接收窗口大小。但是，当您的 TCP 连接具有较大的接收窗口大小和大型 BDP比如在高速网络上的两台服务器之间复制数据WAN 链路往返时间为 100ms，这些算法增加发送窗口的速度不够快，无法充分利用连接的带宽。

为了在这些情况下更好地利用 TCP 连接的带宽，下一代 TCP/IP 堆栈包括复合 TCP (CTCP)。CTCP 更积极地增加发送窗口 具有较大接收窗口大小和 BDP 的连接。CTCP 尝试通过监控延迟变化和丢失来最大化此类连接的吞吐量。此外，CTCP 确保其行为不会对其他 TCP 连接产生负面影响。

...

在运行 Windows Server 2008 的计算机中，CTCP 默认启用；在运行 Windows Vista 的计算机中，CTCP 默认禁用。您可以使用该netsh interface tcp set global congestionprovider=ctcp命令启用 CTCP。您可以使用该命令禁用 CTCP netsh interface tcp set global congestionprovider=none。

编辑 2014/6/30

看看 CTCP 是否真的“开启”

> netsh int tcp show global

IE

在此处输入图片描述

PO 说：

如果我理解正确的话，此设置会增加 拥塞窗口被放大，而不是最大尺寸 它可以达到

CTCP 积极增加发送窗口

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

复合TCP

现有的防止发送 TCP 对等体压垮网络的算法称为慢启动和拥塞避免。这些算法增加了发送方在连接上最初发送数据时以及从丢失的段中恢复时可以发送的段数量（称为发送窗口）。慢启动会将发送窗口增加一个完整的 TCP 段，无论是对于收到的每个确认段（对于 Windows XP 和 Windows Server 2003 中的 TCP）还是对于确认的每个段（对于 Windows Vista 和 Windows Server 2008 中的 TCP）。拥塞避免会将发送窗口增加一个完整的 TCP 段，无论对于确认的每个完整数据窗口。

这些算法在 LAN 媒体速度和较小的 TCP 窗口大小下效果很好。但是，当您的 TCP 连接具有较大的接收窗口大小和较大的带宽延迟乘积（高带宽和高延迟）时，例如在往返时间为 100 毫秒的高速 WAN 链路上的两台服务器之间复制数据，这些算法无法足够快地增加发送窗口以充分利用连接的带宽。例如，在往返时间为 100 毫秒的 1 千兆位每秒 (Gbps) WAN 链路上，它可以 发送窗口最初需要一个小时才能增加到 接收方通告的大窗口大小，以及何时恢复 有丢失的片段。

为了更好地利用带宽在这些情况下，下一代 TCP/IP 堆栈包括复合TCP （CTCP）。对于接收窗口较大且带宽延迟积较大的连接，CTCP 会更积极地增加发送窗口。CTCP 会尝试通过以下方式最大化此类连接的吞吐量：监控延迟变化和丢失。CTCP 还确保其行为不会对其他 TCP 连接产生负面影响。

在 Microsoft 内部进行的测试中，对于 1 Gbps 连接和 50ms RTT，大文件备份时间减少了近一半。带宽延迟积更大的连接可以实现更好的性能。CTCP 和接收窗口自动调整协同工作以提高链路利用率，并可为大带宽延迟积连接带来显著的性能提升。

Question 2

澄清问题：

TCP 有两个窗口：

接收窗口：缓冲区中剩余多少字节。这是接收器施加的流量控制。您可以在 wireshark 中看到接收窗口的大小，因为它由 TCP 标头内的窗口大小和窗口缩放因子组成。TCP 连接的两端都会公布其接收窗口，但通常您关心的是接收大量数据的那一个。在您的例子中，它是“服务器”，因为客户端正在上传到服务器
拥塞窗口。这是发送方施加的流量控制。它由操作系统维护，不会显示在 TCP 标头中。它控制发送数据的速率。

在您提供的捕获文件中。我们可以看到接收缓冲区从未溢出：

在此处输入图片描述

我的分析是，发送方发送速度不够快，因为发送窗口（又称拥塞控制窗口）的打开程度不足以满足接收方的 RWIN。简而言之，接收方说“给我更多”，而当 Windows 是发送方时，它发送速度不够快。

事实证明，上图中 RWIN 保持打开状态，往返时间为 0.09 秒，RWIN 约为 500,000 字节，根据带宽延迟积，我们预计最大吞吐量为 (500000/0.09) * 8 =~ 42 Mbit/s（而您在 win to Linux 捕获中只获得了大约 ~5）。

如何修复它？

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

启用此功能后你重新启动了吗？
烟囱卸载功能是否已打开？如果已打开，可以尝试将其关闭。我不知道启用此功能后究竟会卸载哪些内容，但如果控制发送窗口是其中之一，则启用此功能后拥塞提供程序可能不起作用...我只是猜测...
另外，我认为这可能是 Windows 7 之前的版本，但您可以尝试在 HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-Parameters 中添加和使用名为 DefaultSendWindow 和 DefaultReceiveWindow 的两个注册表项。如果这些都有效，您可能已经关闭了 ctcp。
还有另一个猜测，尝试检查一下netsh interface tcp show heuristics。我认为那可能是 RWIN，但它没有说明，所以也许可以尝试禁用/启用它，以防它影响发送窗口。
另外，请确保您的测试客户端上的驱动程序是最新的。也许有些东西坏了。

我会首先关闭所有卸载功能，尝试所有这些实验，以消除网络驱动程序正在重写/修改某些内容的可能性（禁用卸载时请留意 CPU）。TCP_OFFLOAD_STATE_DELEGATED 结构似乎至少暗示 CWnd 卸载至少是可能的。

Answer

澄清问题：

TCP 有两个窗口：

接收窗口：缓冲区中剩余多少字节。这是接收器施加的流量控制。您可以在 wireshark 中看到接收窗口的大小，因为它由 TCP 标头内的窗口大小和窗口缩放因子组成。TCP 连接的两端都会公布其接收窗口，但通常您关心的是接收大量数据的那一个。在您的例子中，它是“服务器”，因为客户端正在上传到服务器
拥塞窗口。这是发送方施加的流量控制。它由操作系统维护，不会显示在 TCP 标头中。它控制发送数据的速率。

在您提供的捕获文件中。我们可以看到接收缓冲区从未溢出：

在此处输入图片描述

我的分析是，发送方发送速度不够快，因为发送窗口（又称拥塞控制窗口）的打开程度不足以满足接收方的 RWIN。简而言之，接收方说“给我更多”，而当 Windows 是发送方时，它发送速度不够快。

事实证明，上图中 RWIN 保持打开状态，往返时间为 0.09 秒，RWIN 约为 500,000 字节，根据带宽延迟积，我们预计最大吞吐量为 (500000/0.09) * 8 =~ 42 Mbit/s（而您在 win to Linux 捕获中只获得了大约 ~5）。

如何修复它？

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

启用此功能后你重新启动了吗？
烟囱卸载功能是否已打开？如果已打开，可以尝试将其关闭。我不知道启用此功能后究竟会卸载哪些内容，但如果控制发送窗口是其中之一，则启用此功能后拥塞提供程序可能不起作用...我只是猜测...
另外，我认为这可能是 Windows 7 之前的版本，但您可以尝试在 HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-Parameters 中添加和使用名为 DefaultSendWindow 和 DefaultReceiveWindow 的两个注册表项。如果这些都有效，您可能已经关闭了 ctcp。
还有另一个猜测，尝试检查一下netsh interface tcp show heuristics。我认为那可能是 RWIN，但它没有说明，所以也许可以尝试禁用/启用它，以防它影响发送窗口。
另外，请确保您的测试客户端上的驱动程序是最新的。也许有些东西坏了。

我会首先关闭所有卸载功能，尝试所有这些实验，以消除网络驱动程序正在重写/修改某些内容的可能性（禁用卸载时请留意 CPU）。TCP_OFFLOAD_STATE_DELEGATED 结构似乎至少暗示 CWnd 卸载至少是可能的。

Question 3

@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 ));
}

正如 Kyle 所说，问题不在于 Linux 机器上的接收窗口，而是发送方没有充分打开发送窗口。并不是它打开得不够快，只是上限为 64k。

Windows 7 上的默认套接字缓冲区大小为 64k。以下是文档中关于套接字缓冲区大小与吞吐量的关系微软

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

好的，现在我们开始吧：

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

您最近使用 64k 窗口进行的 iperf 测试的平均吞吐量为 5.8Mbps。这是统计信息 > 摘要在 Wireshark 中，它计算所有位。同样，iperf 计算的 TCP 数据吞吐量为 5.7Mbps。我们在 FTP 测试中也看到了同样的性能，~5.6Mbps。

64k 发送缓冲区和 91ms RTT 的理论吞吐量为....5.5Mbps。对我来说已经足够接近了。

如果我们查看您的 1MB 窗口 iperf 测试，tput 为 88.2Mbps（仅 TCP 数据为 86.2Mbps）。1MB 窗口的理论 tput 为 87.9Mbps。同样，对于政府工作来说已经足够接近了。

这表明，发送套接字缓冲区直接控制发送窗口，并与另一端的接收窗口一起控制吞吐量。通告的接收窗口有空间，因此我们不受接收器的限制。

等等，自动调整业务怎么样？Windows 7 不是自动处理这些事情吗？如前所述，Windows 确实处理接收窗口的自动缩放，但它也可以动态处理发送缓冲区。让我们回到 MSDN 页面：

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

iperfSO_SNDBUF在使用该-w选项时使用，因此动态发送缓冲将被禁用。但是，如果您不使用，-w则它不会使用SO_SNDBUF。动态发送缓冲应该默认启用，但您可以检查：

netsh winsock show autotuning

文档说你可以使用以下方法禁用它：

netsh winsock set autotuning off

但这对我来说不起作用。我不得不更改注册表并将其设置为 0：

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

我认为禁用此功能不会有帮助；这只是一个仅供参考。

为什么在向接收窗口中有足够空间的 Linux 机器发送数据时，发送缓冲区没有扩展到默认的 64k 以上？好问题。Linux 内核也有一个自动调整的 TCP 堆栈。就像 T-Pain 和 Kanye 一起进行自动调整二重唱一样，听起来可能不太好。也许这两个自动调整的 TCP 堆栈在相互通信时存在一些问题。

另一个人遇到了和你一样的问题，可以通过编辑注册表来增加默认发送缓冲区大小来解决。不幸的是，这似乎不再起作用了，至少在我尝试的时候它对我来说不起作用。

此时，我认为很明显限制因素是 Windows 主机上的发送缓冲区大小。鉴于它似乎没有正常地动态生长，女孩该怎么办？

你可以：

使用允许您设置发送缓冲区（即窗口选项）的应用程序
使用本地 Linux 代理
使用远程 Windows 代理？
向微软投诉哈哈哈哈哈哈哈哈
啤酒

免责声明：我花了很多时间研究这个问题，据我所知和谷歌搜索，这是正确的。但我不会对我母亲的坟墓发誓（她还活着）。

Answer

@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 ));
}

正如 Kyle 所说，问题不在于 Linux 机器上的接收窗口，而是发送方没有充分打开发送窗口。并不是它打开得不够快，只是上限为 64k。

Windows 7 上的默认套接字缓冲区大小为 64k。以下是文档中关于套接字缓冲区大小与吞吐量的关系微软

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

好的，现在我们开始吧：

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

您最近使用 64k 窗口进行的 iperf 测试的平均吞吐量为 5.8Mbps。这是统计信息 > 摘要在 Wireshark 中，它计算所有位。同样，iperf 计算的 TCP 数据吞吐量为 5.7Mbps。我们在 FTP 测试中也看到了同样的性能，~5.6Mbps。

64k 发送缓冲区和 91ms RTT 的理论吞吐量为....5.5Mbps。对我来说已经足够接近了。

如果我们查看您的 1MB 窗口 iperf 测试，tput 为 88.2Mbps（仅 TCP 数据为 86.2Mbps）。1MB 窗口的理论 tput 为 87.9Mbps。同样，对于政府工作来说已经足够接近了。

这表明，发送套接字缓冲区直接控制发送窗口，并与另一端的接收窗口一起控制吞吐量。通告的接收窗口有空间，因此我们不受接收器的限制。

等等，自动调整业务怎么样？Windows 7 不是自动处理这些事情吗？如前所述，Windows 确实处理接收窗口的自动缩放，但它也可以动态处理发送缓冲区。让我们回到 MSDN 页面：

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

iperfSO_SNDBUF在使用该-w选项时使用，因此动态发送缓冲将被禁用。但是，如果您不使用，-w则它不会使用SO_SNDBUF。动态发送缓冲应该默认启用，但您可以检查：

netsh winsock show autotuning

文档说你可以使用以下方法禁用它：

netsh winsock set autotuning off

但这对我来说不起作用。我不得不更改注册表并将其设置为 0：

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

我认为禁用此功能不会有帮助；这只是一个仅供参考。

为什么在向接收窗口中有足够空间的 Linux 机器发送数据时，发送缓冲区没有扩展到默认的 64k 以上？好问题。Linux 内核也有一个自动调整的 TCP 堆栈。就像 T-Pain 和 Kanye 一起进行自动调整二重唱一样，听起来可能不太好。也许这两个自动调整的 TCP 堆栈在相互通信时存在一些问题。

另一个人遇到了和你一样的问题，可以通过编辑注册表来增加默认发送缓冲区大小来解决。不幸的是，这似乎不再起作用了，至少在我尝试的时候它对我来说不起作用。

此时，我认为很明显限制因素是 Windows 主机上的发送缓冲区大小。鉴于它似乎没有正常地动态生长，女孩该怎么办？

你可以：

使用允许您设置发送缓冲区（即窗口选项）的应用程序
使用本地 Linux 代理
使用远程 Windows 代理？
向微软投诉哈哈哈哈哈哈哈哈
啤酒

免责声明：我花了很多时间研究这个问题，据我所知和谷歌搜索，这是正确的。但我不会对我母亲的坟墓发誓（她还活着）。

Question 4

阅读完答案中的所有分析后，这个问题听起来很像你可能正在运行 Windows7/2008R2 又名 Windows 6.1

Windows 6.1 中的网络堆栈（TCP/IP 和 Winsock）存在严重缺陷，包含大量错误和性能问题，自 6.1 首次发布以来，微软最终经过多年的修补解决了这些问题。

应用这些修补程序的最佳方法是手动筛选 support.microsoft.com 上的所有相关页面，并手动请求和下载网络堆栈修补程序的 LDR 版本（有几十个这样的版本）。

要查找相关的修补程序，您必须使用 www.bing.com 进行以下搜索查询 site:support.microsoft.com 6.1.7601 tcpip.sys

您还需要了解 LDR/GDR 修补程序序列在 Windows 6.1 中的工作方式

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

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

更新：这只是 Windows7SP1 中众多网络漏洞的一个例子 -https://support.microsoft.com/en-us/kb/2675785

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

Answer

阅读完答案中的所有分析后，这个问题听起来很像你可能正在运行 Windows7/2008R2 又名 Windows 6.1

Windows 6.1 中的网络堆栈（TCP/IP 和 Winsock）存在严重缺陷，包含大量错误和性能问题，自 6.1 首次发布以来，微软最终经过多年的修补解决了这些问题。

应用这些修补程序的最佳方法是手动筛选 support.microsoft.com 上的所有相关页面，并手动请求和下载网络堆栈修补程序的 LDR 版本（有几十个这样的版本）。

要查找相关的修补程序，您必须使用 www.bing.com 进行以下搜索查询 site:support.microsoft.com 6.1.7601 tcpip.sys

您还需要了解 LDR/GDR 修补程序序列在 Windows 6.1 中的工作方式

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

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

更新：这只是 Windows7SP1 中众多网络漏洞的一个例子 -https://support.microsoft.com/en-us/kb/2675785

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

Windows TCP 窗口缩放过早达到稳定状态

笔记

编辑

更新——6 月 30 日。

更新 2 - 6 月 30 日

更新 3 - 6 月 31 日。

更新 3 - 7 月 3 日

更新 4 - 7 月 3 日

答案1

答案2

澄清问题：

如何修复它？

答案3

答案4

相关内容