相同的WMI请求在其他机器上要慢得多

我前段时间发布了这个问题在stackoverflow ，但不幸的是，我还没有得到任何答案。 这实际上并不是很紧急，因为这个问题似乎只存在于我的机器上 – 现在。 但是我被告知，在使用WMI的时候，我们networking中的其他机器上也出现过类似的问题。

原来的问题：

所以我有这个方法，读取用户的配额：

public ulong GetQuotaLimit(string username, string domain, char volume) { var scope = GetManagementScope(this, @"root\cimv2"); var path = new ManagementPath( string.Format( "Win32_DiskQuota.QuotaVolume='Win32_LogicalDisk.DeviceID=\"{0}:\"',User='Win32_Account.Domain=\"{1}\",Name=\"{2}\"'", volume, domain, username)); var diskQuotaObj = new ManagementObject(scope, path, null); var result = Convert.ToUInt64(diskQuotaObj.Properties["Limit"].Value); return result; } 

它在我的同事的机器上运行良好（〜200ms），但由于某种原因，它不在我自己的机器上 – 从机器获得响应需要很长时间，维持用户的配额（〜2000ms）。 两台机器的规格几乎相同（相同的操作系统，相同的硬件），它们位于相同的networking和相同的域中。

• 重命名NTFS文件以通过批处理消除多个句点
• 穆宁Windows总和堆栈图
• 在无线连接上运行计划任务
• Windows环境部署
• 外部访问内部networking和网站 – 微软networking

所以我检查了这个请求的两台机器上的networkingstream量，发现了一件奇怪的事情：连接build立和authentication后，我的同事的机器直接继续实际的请求（从第491帧开始）。

机器是192.168.131.95 ，保持配额

192.168.131.175是我同事的机器

192.168.144.11是我的机器

logging被这些IP过滤

但是，我的机器继续进行TCP三次握手（帧90-92），然后等待一段时间（导致延迟）并继续进行第二次validation（从第126帧开始），然后才终于达到应有的效果做 – 发送实际的请求。

似乎客户端（我的机器）已经失去了连接，但我没有看到任何框架，这实际上表明了这一点。 我也听说WMI在碎片方面存在一些问题，但是段/数据报实际上比通常碎片化阈值（1500Bytes？）的碎片小，Wireshark没有表明帧被重新组装，所以这不应该是原因。

任何人都知道为什么会发生这种行为？