RDC缓慢爬行或完全断开连接时遇到问题。 客户端是XP SP3 w / RDC 6，服务器是Win 2k8 R2。 两者都被彻底扫描，发现无病毒。
我在客户端计算机上下载并安装Wireshark，并在RDC会话期间运行数据包捕获。 日志显示在正常使用期间，每分钟至less有10-20次重传/重传/分段丢失。 然后，当我断开连接的时候，每秒钟就会出现几十个这样的数据。
仅供参考，我对Wireshark工具知之甚less，或者对如何对这个问题进行全面的分析。
**编辑**
一点关于我的networking架构：
客户端 –
服务器 –
其他远程客户端连接到服务器没有问题（速度或断开连接）。 在客户端使用了其他几台笔记本电脑来validation这不是硬件问题。 电缆调制解调器也被replace了。
可能没有足够的信息，但这里有一些一般的指导：
如果其他远程客户端没有问题，并且没有遇到问题，则问题可能与服务器无关。 这可能是该客户的连接。
重传通常意味着数据包未被确认，所以在数据包捕获中通常不会有实际的“错误”。 这意味着一端正在发送数据包，另一端未被确认。 您可能希望从两端执行捕获，以确定重新传输是单向还是两种方式。
如果你从客户端ping主机，响应时间是多less？ 如果超过150毫秒，则可能会有不理想的连接。
大型发送卸载的服务器networking适配器设置应该被禁用。 Windows应该足够聪明，知道它不能将大包发送到不同子网上的机器，但遗憾的是并非总是如此。 如果你的服务器是一个超v客户，这几乎肯定是问题。
MTU。 一般来说，如果不在同一个子网上远程访问服务器，则MTU应始终为两个端点之间最小的MTU。 这通常意味着客户。 对于通过VPN连接的远程客户端，具有1400或甚至更低的MTU并不罕见。 将服务器MTU设置为匹配最低MTU将是有益的，以避免无法正确发现MTU（有时称为黑洞路由器）的问题。 要find连接的MTU，可以从客户端input以下命令：
ping -f -l xxxx <server ip> 其中xxxx是MTU的大小。 从1400开始。如果有效，请增加它，直到显示消息“数据包需要被分段但DF设置”。 如果1400不起作用，那就减less它。 工作的最高数字是您的有效载荷大小。 添加28到有效负载大小，这是你的MTU。
您可以在以下registry位置设置服务器MTU：
HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{guid of the network adapter}
仅供参考 – RDP数据包始终以“不分片”位设置发送。
请注意，networking监视器经常会在捕获开始之前错误地将数据包标记为“段丢失”，以便在捕获之前开始的任何TCP对话。
这是因为Netmanager会在捕获开始之前看到数据包的确认（序列号）。 由于它看到的ACK没有看到相应的数据包，它假定数据包丢失，并标记为“段丢失”。 注意不要把这个捕获丢失段的开始与实际丢失的段落混淆起来。 如果按照个人知识产权stream量sorting对话，这些应该排在最前面。
或者，您可以将捕获保存到一个文件，然后重新加载到Netmanager。 我注意到，在重新加载之后，它不会再将捕获确认的开始标记为“分段丢失”。
您正在收到以下软件包：
如果您收到TCP重传，这是因为您发送的ACK没有被服务器接收到。 服务器不知道收到了TCP数据包，认为它正在丢失，并将再次发送。
在以下情况下，发件人通常会收到重复的ACK：
第三个错误（Segment Lost）正是这种情况，但在接收方。 它表明分组3在分组2之前被接收。
所有这些错误都表明拥塞：在丢包的过程中的某个地方。 这可能有很多原因，所以我们确实需要一个很好的networking体系结构指示来告诉你是什么原因。
通常，拥堵并不是一件坏事。 TCP会自动适应这种情况，提高传输速率，直到数据包丢失/减速开始发生。 拥挤造成问题的事实可能有多种不同的原因：