通过 VPN 远程工作时，当我将大型文件保存到我们的文件服务器时，我无法在此期间浏览服务器上的任何其他文件共享。基本上，Windows 资源管理器会挂断并卡住，如果它确实有响应，则需要几分钟并且非常慢。当文件传输取消或完成时，文件夹会立即弹出。
为了重现此问题，我将文件从本地（远程连接）计算机拖放到工作网络上另一台设备上的文件共享中。在文件传输过程中，我尝试浏览远程文件共享上的其他文件夹。例如，现在，我尝试浏览\\<host ip>\c$\Windows，但 10 分钟后它仍在尝试加载目录列表，目前仅显示了几十个文件夹/文件。
我花了几天时间解决这个问题。这是 WAN/VPN 连接特有的问题。我在使用不同 VPN 技术的其他网络上也遇到了类似的“缓慢”文件浏览行为 - 但它不会在那里停留几分钟而不做任何事情。延迟以秒为单位。我使用的是 Cisco AnyConnect，问题非常严重。
该问题影响了多个用户（我测试过的所有用户），通过任何互联网连接、通过我们的任何网关、到我们的任何服务器。但是，它只影响 SMB。在文件传输过程中，不会影响其他服务。Ping 时间保持正常，与同一服务器的 RDP 会话响应良好，等等。
我关注了许多不同的可能性。我使用 MTU 设置，没有进行任何更改。我看到 SMB 以单通道模式运行。我尝试调整各种 SMB 客户端/服务器设置。我在 wireshark 跟踪中看到，在我尝试导航到文件夹后很久才发送请求。但是，请求和服务器响应之间似乎没有任何明显的滞后。服务器或客户端上没有 CPU 核心/线程达到最大值。我无法在本地 LAN 上重现这种行为。
那么，这种行为有什么解释吗？为什么客户端似乎直到文件传输取消后才发送 SMB 请求，或者只是在很晚之后才发送？有队列吗？缓冲区？是否可以通过虚拟网络适配器（如 VPN）使用 SMB 多通道？这能解决问题吗？我可以运行哪些命令来查看服务器或客户端是否正在排队？还有其他可以测试的想法吗？
答案1
- SMB 在慢速 WAN 链路上通常较慢。这是协议中的设计流程，由于 SMB 严重依赖广播名称请求和 WAN 中/通过 WAN 无法提供的其他类型的名称解析，因此情况更加恶化。
- 大多数 SMB 服务器通常位于 NAT 后面的 LAN 内，其中路径 MTU 发现根本不起作用
- MTU 本身和碎片/碎片整理问题只是问题的一半，另一半是 TCP MSS。当 TCP 组装不正确时，TCP 会话很容易停滞 - 这会导致多次重新传输和过早关闭会话。
所有这些因素结合在一起，就会对速度产生累积效应。
PS，不要忘记 3 个锁定级别，当 RTTA 较小时，它们几乎可以完美运行，但在 WAN 上却非常麻烦。