也许我正在期待更多SMB2的方式，而不是现实。 这是情况。
情况1：
我有一个文件，1GB的大小。
从Win7转移到服务器A：10秒
从Win7传输到服务器B：18秒
情景2：
我有一个目录，大小为275MB，大约2700个文件。
从Win7传输到服务器A：57秒
从Win7传输到服务器B：551秒
在情景2中，只有10ms的延迟是否真的给SMB2造成了巨大的打击？ 我想这是有道理的，如果SMB2是聊天来回每个单独的文件（每个文件多个调用），除了实际传输文件所花费的时间，每个方法需要10ms（客户端 – >服务器，服务器 – >客户端）。
所以我想我只是问 – 这是否真的和SMB2通过广域网一样好，没有尝试使用SMB2加速或其他第三方技巧玩游戏？
UPDATE1：
澄清：我不是问为什么很多文件需要比一个大的文件更长的时间 – 我知道这将增加开销，尽pipe介质。 我在问具体问10ms是否足以说明场景2中服务器A和服务器B之间10分钟的差异。我知道没有确切的是或否回答。
真的只是不太熟悉SMB2是如何特别的。 我承认，它在做什么的本质上一定是健谈。 只是想知道其他人在类似情况下观察到了什么。 （传输复杂的目录结构 – 超过10毫秒1GB或更高的链接）
不，这不是一个SMB2的问题，它是一个传输小批量文件的协议问题。 除了更多的networking开销之外，你还要处理更多的查找时间，而且基本上是随机读取而不是顺序读取，所以磁盘操作也要慢很多。 例如，使用USB闪存驱动器或外部硬盘驱动器进行testing。 如果你愿意，可以使用不同的networking协议，比如FTP。
你的结果是非常相似的 – 传输大量的小文件通常比传输一个大文件需要更多的时间。 对于传输许多文件和广域网链路，SMB2可能没有得到很好的优化（太琐碎），但是无论协议如何，您所看到的基本性能问题都将持续存在。
10mc的延迟来自哪里？ 对于局域网来说太高了，对于广域网来说太小了。
是的，它会导致问题 – SMB2是相当健谈，没有优化的高延迟。 许多文件是很多操作。 很多。 AL1一个接一个地跑。 在scheme2的情况下，分割2700个文件并且同时运行多个复制操作会更好。 这是MS做SMB3的原因..