我们有以下安排：开发站点 <--vpn--> 生产站点。运行 pfSense 2 的生产站点防火墙在 SMB 端口 135-139 和 445 上接受 VPN TCP/UDP 流量。我们的开发人员可以\\Computer\C$毫无意外地连接到管理共享，实际上将单个文件上传到共享非常轻松，速度约为每秒 200-300 千字节。但是，当尝试删除包含许多子文件夹/文件的文件夹，或上传许多单个文件或修改许多单个文件时，资源管理器会停止运行，通常每秒处理大约 2-4 个文件（即使它们小于 1kb）。在运行同步作业等时，这会非常痛苦。已确认 Windows XP、2k3 Server 和 Windows 7 客户端存在速度不足的情况。有问题的服务器运行的是 Win2k3。
一些问题：
- 我可以对防火墙采取什么措施来提高性能？我如何判断这是否是防火墙问题？
- 我可以对服务器做些什么来提高性能？
- 我还能做些什么来提高 Windows 文件共享性能？
答案1
您当然应该检查办公室 ISP 的带宽，以确保它没有超额订阅，并且您可以使用 ping 来测试远程开发人员和服务器之间的延迟。我猜这两种情况都不会发生，因为您已经发现 VPN 上的 SMB 性能通常很糟糕。
您的解决方案是为这些远程用户找到另一种操作文件的方法。您可以尝试 FTP，但这会引入另一种协议，而且 FTP 本身并不是特别安全（比 VPN 更好）。但最好的办法是让用户远程桌面访问服务器，并让他们在那里进行删除。对于大量上传，他们可以上传 ZIP 文件并通过远程桌面在服务器上解压。
同步作业的问题很有挑战性，因为你很可能做必须查看每个文件。如果同步作业可以通过其他协议（psexec、FTP、SFTP、SCP 等）运行，则可能会更快。
答案2
欢迎来到 SMB 的奇妙世界，任何延迟高于 LAN 的连接都可以使用。您所描述的一切对于此类场景来说都是完全正常的，一旦超过 20 毫秒，速度就会变得非常慢，超过 50 毫秒就会非常痛苦。该协议的设计非常糟糕，不适合延迟高于 LAN 的连接。尤其是在处理包含大量文件和/或目录的共享时。
SMBv2 在某种程度上已经解决了这个问题。如果你使用的是 Server 2008 和 Vista 或更新的客户端，情况就不会那么糟糕。
请参阅此处的“性能问题”以获取更多详细信息： http://en.wikipedia.org/wiki/Server_Message_Block
答案3
数据包碎片化也可能存在问题 - 在这种情况下，您可以尝试调整链接之间的 MTU（尽管在 VPN 下的连接中可能无法做到这一点）。例如，在我的桌面上 - 我无法发送大于 1472 的 ping，除非将其拆分成多个数据包（Win7 -> Win2008R2）：
ping -f -l 1472 10.1.10.3
参数-f是不要碎片化标志，是-l大小。我建议从 1500 开始，然后逐渐减少。