解决大量 TCP 重传/重复确认/段丢失问题

Question

我遇到了 RDC 运行缓慢或完全断开的问题。客户端是 XP SP3 和 RDC 6，服务器是 Win 2k8 R2。两者都经过彻底扫描，发现没有病毒。

我在客户端计算机上下载并安装了 Wireshark，并在 RDC 会话期间运行了数据包捕获。日志显示，在正常使用期间，每分钟至少有 10-20 次重传/重复确认/分段丢失。然后，当我断开连接时，每秒的丢失次数激增到几十次。

仅供参考，我对 Wireshark 工具或如何对此问题进行全面分析了解甚少。

** 编辑 **

简单介绍一下我的网络架构：

客户 -

• 下载 12 Mb，上传 1Mb
• 1 台笔记本电脑直接连接到调制解调器 - 或者 - （我试过这种方法，没有任何变化）通过 Linksys DSL 电话盒插入
• 位于以色列。那里的电信服务分为基础设施和ISP，基础设施由HOT提供，ISP由Netvision提供。

服务器 -

• 下载 5 Mb，上传 5 Mb
• 中型网站/数据/应用托管网络，采用 Allied Telesyn AR410 路由
• 位于加利福尼亚州（美国）。ISP 为 Call America。

其他远程客户端在连接服务器时没有问题（无论是速度还是断开连接）。客户端位置还使用了其他几台笔记本电脑来验证这不是硬件问题。电缆调制解调器也已更换。

Answer 1

可能信息不够，但这里有一些一般指导：

如果其他远程客户端正常且未出现此症状，则问题可能不在于服务器。可能是该客户端的连接问题。

重新传输通常意味着数据包未被确认，因此数据包捕获中通常不会出现实际的“错误”。这意味着一端正在发送数据包，而另一端未被确认。您可能需要从两端执行捕获，以确定重新传输是单向的还是双向的。

如果您从客户端 ping 您的主机，响应时间是多少？如果超过 150 毫秒，则您的连接可能不太理想。

应禁用服务器网络适配器的 Large Send Offload 设置。Windows 应该足够智能，知道它不能将大数据包发送到不同子网上的机器，但遗憾的是情况并非总是如此。如果您的服务器是 Hyper-V 客户机，这几乎肯定是问题所在。

MTU。一般来说，当您不在同一子网上时远程访问服务器，MTU 应始终为两个端点之间的最小 MTU。这通常意味着客户端。对于通过 VPN 连接的远程客户端，MTU 为 1400 甚至更低的情况并不罕见。将服务器 MTU 设置为与最低 MTU 相匹配可能会有所帮助，以避免无法正确发现 MTU 的问题（有时称为黑洞路由器）。要查找连接的 MTU，您可以从客户端输入以下命令：

ping -f -l xxxx <server ip>

其中 xxxx 是 MTU 大小。从 1400 开始。如果有效，则增加它直到显示消息“数据包需要分段但设置了 DF”。如果 1400 无效，则减少它直到有效。有效的最高数字是您的有效载荷大小。将 28 添加到有效载荷大小，这就是您的 MTU。

您可以在以下注册表位置设置服务器 MTU：

HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{guid of the network adapter}  

仅供参考 - RDP 数据包始终在设置“不分段”位的情况下发送。

Answer 2

请注意，网络监视器通常会在捕获开始时将捕获前已开始的任何 TCP 对话的数据包错误地标记为“段丢失”。

这是因为 Netmanager 会看到在捕获开始之前发生的数据包的确认（序列号）。由于它看到 ACK 而没有看到相应的数据包，因此它假设数据包已丢失并将其标记为“段丢失”。请注意不要将捕获丢失的段与实际丢失的段混淆。如果您按单个 IP 流对对话进行排序，则这些应该排在最前面。

或者，您可以将捕获保存到文件中，然后将其重新加载回 Netmanager。我注意到，重新加载后，它将不再将捕获确认的开始标记为“段丢失”。

Answer 3

您将收到以下包裹：

1. TCP 重传
2. 重复确认
3. 片段丢失

如果您收到 TCP 重传，这是因为服务器未收到您发送的 ACK。服务器不知道已收到 TCP 数据包，认为它在传输过程中丢失，因此将再次发送。

发送方通常会在以下情况下收到重复的 ACK：

• 接收方接收数据包 1
• 接收方发送数据包 1 的 ACK
• 接收方收到数据包 3
• 接收方发送数据包 1（收到的最大数据包序列号）的 ACK。对于发送方来说，这是重复的 ACK。
• 接收方收到数据包 4
• 接收方发送数据包 1（收到的最大数据包序列号）的 ACK。对于发送方来说，这是重复的 ACK。

第三个错误（Segment Lost）就是这种情况，但发生在接收方。它表示数据包 3 在数据包 2 之前被接收。

所有这些错误都表明存在拥塞：数据包在某个地方被丢弃。这可能有很多原因，所以我们确实需要对您的网络架构有一个良好的了解，才能告诉您原因是什么。

通常，拥塞并不是一件坏事。TCP 会自动适应这种情况，增加传输速率，直到开始出现丢包/速度变慢。拥塞在这里造成问题可能有许多不同的原因：

1. 您的网络过于拥挤，无法满足 RDP 所需的最低传输速率。2G 手机连接就是这种情况。
2. 服务器或客户端的算法配置不当。某些 ADSL“优化器”程序可能会导致此问题，从而干扰 Windows 中的 Vegas TCP 算法的参数。
3. 存在其他错误（服务器或客户端负载非常高、网卡固件/驱动程序不良等）