我们在通过 VPN 连接到我们的网络的 Windows Server 2003 时遇到了困难。
除了文件共享下载到本地机器之外，该服务器的一切似乎都运行正常。
本地机器运行的是 Windows XP。远程桌面与同一台服务器的连接运行良好。文件共享的上传也运行良好。（这很令人惊讶，因为我们之间的网络下载评级实际上高于上传。）
将文件拖放到本地系统时，进度条活动会延迟 10 秒以上。通过命令提示符下载文件具有相同的特征。传输每个文件都会产生延迟，而不是整个连接都会产生一次延迟。我试图ping address -f -l 1472验证这不是“黑洞路由器”问题http://support.microsoft.com/kb/314825。无论使用映射驱动器还是 UNC 路径，或者通过指定 IP 地址而不是主机名进行连接，延迟都是相同的。禁用“TCP/IP 上的 NetBIOS”也无济于事。注册表没有任何高级 TCP/IP 设置（如 MTU）从其默认值更改。我尝试在注册表中减少 MTU，但这也没有帮助。
有什么想法吗？另外，如果可能的话，非常欢迎涉及调整本地 XP 计算机配置而不是 LAN/WAN 或服务器配置的解决方法。
答案1
监听客户端和服务器之间的通信并查看发生了什么。没有比查看计算机之间通信内容更好的方法来查明协议问题了。
SMB 协议是一个狗在延迟网络上运行时。我还怀疑您在上传时看到“进度条”活动更快是因为 Windows shell 的实现工件，而不是因为数据实际上传输得更快。我猜想每次文件传输都会发生同样的事情。每个文件的延迟为这种结论提供了一些可信度。
答案2
在过去，我们通过减少 MTU 解决了文件传输问题（特别是通过 VPN）。使用 MTU 阈值附近的数据包大小进行的 Ping 测试没有用；确实可以排除黑洞，但如果存在黑洞，您可能无法通过 VPN 做任何有用的事情。
我们的问题主要出在 SMB 文件传输上，我相信这是由于数据包碎片化造成的。将 MTU 减少到 1400-1420 范围有很大帮助。请记住，VPN 封装会为每个数据包添加更多标头（时间过去很久了，所以我忘记了具体细节，今晚我也懒得去谷歌搜索了），但 1472 + ESP+AH + 以太网远远超过 1500（假设您使用的是 IPSec/ESP+AH）。根据我的经验，碎片化过度并不是一个非黑即白的问题；仅仅因为某些测试在某些时候通过并不意味着您以后可以排除它。
由于在这种情况下服务器正在发送数据，因此您可以看看是否可以在服务器上设置 MTU。它也是所有 SMB 客户端连接的公共点，因此一旦更改 MTU，就无需在所有客户端上设置 MTU（因为路径 MTU 是在端点之间协商的）。
此外，对于那些告诉他运行 wireshark 的人——你会具体告诉他要寻找什么？我不确定这是否是“协议错误”——SMB 可能因为底层延迟和/或数据包丢失而重置其连接，因此从技术上讲 SMB 正在执行其工作（它只是一个脆弱的协议）——而且我不确定 tcpdump/sniffer/wireshark 是否会为他们指出解决方案。我喜欢像下一个 CCNP 一样跟踪网络对话，但在错误的人手中，手术刀是无用/危险的。他已经说过他不是网络管理员......