我知道实时版本肯定会比本地版本慢。但是，考虑到我的系统规格和带宽，延迟量似乎太不成比例，不能（仅仅）归咎于此。
我的系统规格和速度测试如下：
无论网络负载如何，延迟都会始终发生，并且似乎存在于所有实用程序中 - 事实上，即使仅启动explorer.exe到 SysInternals UNC 目录也会显示出显着的加载时间（并且系统没有承受任何显着的负载/压力）。
我唯一能想到的可能是问题出在服务器端，但我不想简单地做出这样的假设。有没有什么方法可以明确确定根本原因（并希望实施纠正/预防措施）？
答案1
它与您的系统规格或带宽无关。
UNC 路径不表示协议，因此 Windows 会尝试通过其已知的几种协议进行连接。在大多数系统中，它按此顺序使用 SMB 和WebDAV。1
live.sysinternals.com 是一个 HTTP/WebDAV 服务器，不支持 SMB，更糟糕的是，它甚至不支持回应尝试建立 SMB 连接。2当Windows 首先尝试连接 TCP 端口 445（现代 SMB），然后连接端口 139（NetBIOS）时，它甚至不会收到拒绝 - 它只是在那里等待，直到超时倒计时。
几秒钟后，Windows 网络客户端放弃 SMB 并尝试 WebDAV（通过端口 80），成功了，但此时已经出现延迟。如果您直接通过 UNC 路径（而不是映射驱动器号）访问服务器，则此过程可能会对每个文件操作重复，因为 Windows 似乎无法长时间记住服务器的类型，只是不断重试 SMB。
还有一个问题：1) 服务器可能在物理上离您很远，即使请求成功也会增加延迟；2) WebDAV 本身是一种冗长的基于 XML 的协议，没有批处理。两者都会增加总延迟。
1（从历史上看，当 Windows 开始使用 UNC 路径时，许多LAN 协议套件。类似这样的简短非 DNS 名称\\mypc可能至少以三种不同的方式表示 SMB/NetBIOS - 通过 IPv4 或 IPX 或 NBFrames - 但它也可能是 NetWare NCP、AppleTalk AFP，或者可能是 VINES 和 DECnet 以及其他奇怪的东西。）
2（实际上，即使服务器正确配置为立即拒绝与不受支持的端口的连接，也会出现另一个问题：一些互联网服务提供商阻止与 SMB 相关的端口的连接，以减少恶意软件传播的可能性。