警告，前面有主观问题！但希望一个不会被关闭的好。
设想：
我有一个分支机构，目前没有本地服务器。他们通过 12Mbps WAN 链路 (MPLS) 访问包括 DC 在内的所有内容。链路未饱和，平均利用率约为 20%。该电路非常稳定，具有高 SLA 和出色的正常运行时间。
但是，通过 WAN 从文件服务器传输大文件（主要是读取，而不是写入）可能会很慢。我们目前不使用 DFS。
研究完成：
我知道 WAN 加速，例如使用专用硬件 (Riverbed) 或专用软件 VM (Silver Peak)。但定价超出了我们当前的预算，从我们的角度来看，需求还没有完全满足（因为问题主要是在“拉动”场景中，不一定是推/拉）。
我主要考虑在这个分支机构部署 Windows 服务器并使用 DFS-R 或 BranchCache。查看表比较并假设我们正在查看“托管分支缓存服务器”而不是简单地分发：
即使两者都“托管”在服务器上，两者似乎都有好处。
我实际遇到的问题：
- 这些技术中的每一个在什么情况下都会发光，你在哪里选择一个而不是另一个？
- 查看托管的 Branchcache 服务器，您是否可以在中央文件服务器上设置某些文件夹/文件的“预取”，以便在分支本地立即访问它们？您是否必须按计划执行此操作（如果可能）？
- 看着 DFS-R，我担心（并且显然通过 3rd 方应用程序解决了）是文件锁定并确保文件在写入操作期间得到正确更新（即，确保两个副本都被访问并且都被写入，哪个文件需要优先级以及更改会发生什么？）。理想的情况似乎是锁定数据的任何备用副本，但这真的有那么大的问题吗？
- Branchcache 是否锁定中央文件以进行编辑？
- 分支缓存是否仅将增量传输回已更改的中央文件？
- 如果分支办公室服务器也将用作域控制器，是否会不建议使用任何一种技术？
BranchCache 是只读的，不预缓存。它主要用于更新分发等 - 它是一个缓存。
DFS 没有锁定。没有弹性的 WAN 技术会锁定，因为如果/当 WAN 链路断开时，锁定是不可能的——所以它要么是弹性，要么是锁定。
如果您需要版本控制/锁定才能正常工作，您只能使用中央服务器。此时，BranchCache 可以帮助提高重复下载的下载速度。仅有的。
如果您都没有 - 即您需要从许多地方进行大量更新（这是一个非常不寻常的情况 - 大多数时候文件没有像公司那样锁定），那么您必须支付更多带宽需要出现。或者你可以使用一些thind party DFS-R item，但是你有另一个问题......这是确保带宽不会因为复制大量未使用的东西而下降，因为DFS-Replication完全沿着文件共享线，而不是按需元素。
这真的是一个“该死的如果你这样做，如果你不这样做”的场景。尤其是在有 LAN（高延迟，一定的不可靠性）的情况下。
例如，BranchCache 作为更新缓存大放异彩 - 无需在分支机构拥有本地 WSUS 服务器。没有锁定，因为它是一种纯缓存机制 - 您不能编辑 BranchCache 文件。也就是说，由于没有锁定写入将锁定 CENTRAL 文件 - 然后更新版本传播，所以它实际上可能对你有用；）
DFS 非常适合只读内容（安装映像、用于安装的软件映像、集中编辑的策略文档等）。有趣的是，我拥有的大部分文件都属于这一类——我们在这里编辑的东西大多是与其他同步技术（共享点文档管理）一起使用的中心存储。DFS 是满足技术复制需求的绝佳技术解决方案。
http://pertorben.wordpress.com/2012/05/29/dfs-r-or-branchcache/
有很好的深入解释。
BranchCache 可能会工作....它不会停止单个下载延迟，但它会处理重复读取。它还允许锁定。
编辑：经过进一步检查，现在似乎可以进行预加载。请参阅
http://technet.microsoft.com/en-us/library/jj127252.aspx