我们有以下安排：Dev Site < – vpn – > Prod Site。 运行pfSense 2的Prod Site防火墙接受SMB端口135-139和445上的VPN TCP / UDP通信。我们的开发人员可以毫无例外地连接到pipe理共享\\Computer\C$ ，并且实际上将单个file upload到共享在200-300千字节每秒左右轻风轻松。 但是，当试图删除包含许多子文件夹/文件的文件夹，或者上传许多单独的文件，或修改许多单独的文件时，资源pipe理器会停下来，通常每秒处理2-4个文件（即使它们是<1KB）。 这在运行同步作业等时会非常痛苦。这种速度的不足已经被Windows XP，2k3 Server和Windows 7客户端所证实。 有问题的服务器正在运行Win2k3。
一些问题：
你当然应该检查你的办公室的ISP的带宽，以确保它没有超额认购，你可以使用ping来testing远程开发人员和你的服务器之间的延迟。 我的猜测是，既不会发生这种情况，因为您发现VPN上的SMB性能通常很糟糕。
您的解决scheme是find这些远程用户操纵文件的另一种方法。 你可以尝试FTP，但是引入了另一种协议，而FTP本身并不是特别安全（比VPN更好）。 但是最好的办法是给用户远程桌面服务器，让他们在那里做删除。 对于批量上传，他们可以上传一个ZIP文件并通过远程桌面在服务器上解压。
同步工作的问题是具有挑战性的，因为您很可能必须查看每个文件。 如果同步作业可以运行在其他协议（psexec，FTP，SFTP，SCP等）上，这可能会更快。
欢迎来到SMB高于LAN延迟的任何连接的奇妙世界。 你所描述的一切对于这样的场景来说是完全正常的，一旦你超过了20毫秒，事情会变得非常慢，超过50毫秒，这是痛苦的。 该协议是非常糟糕的devise连接高于局域网延迟。 特别是在处理大量文件和/或目录的共享时。
SMBv2已经在一定程度上解决了这个问题。 如果你严格的Server 2008与Vista或更新的客户端，它不会那么糟糕。
请参阅“性能问题”以了解更多深入信息： http ： //en.wikipedia.org/wiki/Server_Message_Block
数据包被碎片化也可能会出现问题 – 在这种情况下，您可以尝试调整链接之间的MTU（尽pipeVPN下的连接可能无法实现）。 例如，在我的桌面上 – 我无法发送一个大于1472的ping，而不需要将其拆分成多个数据包（Win7 – > Win2008R2）：
ping -f -l 1472 10.1.10.3
-f参数是-f片标志， -l是大小。 我会build议从1500开始，一路顺风。