![解决大量 TCP 重传/重复确认/段丢失问题](https://linux22.com/image/569923/%E8%A7%A3%E5%86%B3%E5%A4%A7%E9%87%8F%20TCP%20%E9%87%8D%E4%BC%A0%2F%E9%87%8D%E5%A4%8D%E7%A1%AE%E8%AE%A4%2F%E6%AE%B5%E4%B8%A2%E5%A4%B1%E9%97%AE%E9%A2%98.png)
我遇到了 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。
其他远程客户端在连接服务器时没有问题(无论是速度还是断开连接)。客户端位置还使用了其他几台笔记本电脑来验证这不是硬件问题。电缆调制解调器也已更换。
答案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 数据包始终在设置“不分段”位的情况下发送。
答案2
请注意,网络监视器通常会在捕获开始时将捕获前已开始的任何 TCP 对话的数据包错误地标记为“段丢失”。
这是因为 Netmanager 会看到在捕获开始之前发生的数据包的确认(序列号)。由于它看到 ACK 而没有看到相应的数据包,因此它假设数据包已丢失并将其标记为“段丢失”。请注意不要将捕获丢失的段与实际丢失的段混淆。如果您按单个 IP 流对对话进行排序,则这些应该排在最前面。
或者,您可以将捕获保存到文件中,然后将其重新加载回 Netmanager。我注意到,重新加载后,它将不再将捕获确认的开始标记为“段丢失”。
答案3
您将收到以下包裹:
- TCP 重传
- 重复确认
- 片段丢失
如果您收到 TCP 重传,这是因为服务器未收到您发送的 ACK。服务器不知道已收到 TCP 数据包,认为它在传输过程中丢失,因此将再次发送。
发送方通常会在以下情况下收到重复的 ACK:
- 接收方接收数据包 1
- 接收方发送数据包 1 的 ACK
- 接收方收到数据包 3
- 接收方发送数据包 1(收到的最大数据包序列号)的 ACK。对于发送方来说,这是重复的 ACK。
- 接收方收到数据包 4
- 接收方发送数据包 1(收到的最大数据包序列号)的 ACK。对于发送方来说,这是重复的 ACK。
第三个错误(Segment Lost)就是这种情况,但发生在接收方。它表示数据包 3 在数据包 2 之前被接收。
所有这些错误都表明存在拥塞:数据包在某个地方被丢弃。这可能有很多原因,所以我们确实需要对您的网络架构有一个良好的了解,才能告诉您原因是什么。
通常,拥塞并不是一件坏事。TCP 会自动适应这种情况,增加传输速率,直到开始出现丢包/速度变慢。拥塞在这里造成问题可能有许多不同的原因:
- 您的网络过于拥挤,无法满足 RDP 所需的最低传输速率。2G 手机连接就是这种情况。
- 服务器或客户端的算法配置不当。某些 ADSL“优化器”程序可能会导致此问题,从而干扰 Windows 中的 Vegas TCP 算法的参数。
- 存在其他错误(服务器或客户端负载非常高、网卡固件/驱动程序不良等)