也许我对 SMB2 的期望比实际的要高得多。情况如下。
- Windows 7 客户端（本地）
- A）Win2008R2 服务器（LAN-1GB，<1ms）
- B）Win2008R2 服务器（WAN-1GB，10ms）
- （相同的服务器硬件）
场景 1：
我有一个文件，大小为 1GB。
从 Win7 传输到服务器 A：10 秒
从 Win7 传输到服务器 B：18 秒
场景 2：
我有一个目录，大小为 275MB，大约有 2700 个文件。
从 Win7 传输到服务器 A：57 秒
从 Win7 传输到服务器 B：551 秒
在场景 2 中，仅 10ms 的延迟真的会对 SMB2 造成如此巨大的影响吗？我认为，如果 SMB2 正在就每个单独的文件进行来回通信（每个文件多次调用），除了实际传输文件所需的时间外，而且每个方向（客户端->服务器，服务器->客户端）都多花 10ms，那么这将是有意义的。
所以我想我只是想问——这是否真的和 SMB2 通过 WAN 一样好，而无需尝试使用 SMB2 加速或其他第三方技巧来玩游戏？
更新1：
澄清一下：我不是在问为什么大量文件比一个大文件花费的时间更长——我知道这会增加开销，尽管介质不同。我具体问的是，在场景 2 中，10ms 是否足以解释服务器 A 和服务器 B 之间 10 分钟的差异。我知道没有确切的“是”或“否”答案。
我真的不太了解 SMB2 到底有多健谈。我承认这一点有就其所做的事情而言，它很健谈。只是想知道其他人在类似情况下观察到了什么。（传输复杂的目录结构 - 超过 10ms 1GB 或更高的链接）
答案1
不，这不是 SMB2 问题，而是通过任何协议传输大量小文件问题。除了更多的网络开销之外，您还需要处理更多的寻道时间，并且基本上是随机读取而不是顺序读取，因此磁盘操作也会慢得多。例如，使用 USB 闪存驱动器或外部硬盘驱动器进行测试。如果您愿意，可以使用不同的网络协议，例如 FTP。
您的结果将非常相似 - 传输大量小文件通常比传输一个大文件花费更多时间。SMB2 可能在传输大量文件和 WAN 链接方面优化不佳（过于繁琐），但无论使用哪种协议，您看到的基本性能问题都会持续存在。
答案2
10mc 延迟从何而来？对于 LAN 来说，这个延迟太高了，而对于 WAN 来说，这个延迟又太小了。
是的，它会导致问题 - SMB2 非常繁琐，并且未针对高延迟进行优化。许多文件需要大量操作。很多。一个接一个地运行。在场景 2 的情况下，您最好拆分 2700 个文件并并行运行多个复制操作。MS 推出 SMB3 是有原因的。