Windows Server 2012 Branchcache与DFS-R的比较
警告，提前提出主观问题！ 但希望有一个不会closures的好的 。
场景：
我有一个分支机构，目前没有内部服务器。 他们通过12Mbps广域网链路（MPLS）访问所有设备，包括DC。 链路不饱和，平均利用率为20％左右。 该电路非常稳定，具有很高的SLA和良好的正常运行时间。
但是，通过WAN从文件服务器进行大文件传输（主要是读取，而不是写入）可能会很慢。 我们目前不使用DFS。
研究完成：
我知道WAN加速，例如使用专用硬件（Riverbed）或专用软件VM（Silver Peak）。 但是价格不在我们目前的预算之内，而且从我们的angular度来看还不是那么需要（因为这个问题主要是在“拉”的情况下，不一定是推/拉）。
我主要考虑在此分支机构部署Windows服务器，并使用DFS-R或BranchCache。 看一下表比较，并假设我们正在查看一个“托pipe的分支caching服务器”，而不是简单分发：
即使两者都“托pipe”在服务器上，似乎对两者都有好处。
问题我实际上有：
- 在哪些情况下，这些技术的每一个都会闪耀，你在哪里select一个呢？
- 查看一个托pipe的Branchcache服务器，可以设置中央文件服务器上的某些文件夹/文件的“预取”，以便在分支机构本地立即访问它们？ 你必须按时间表（如果可能的话）这样做吗？
- 看看DFS-R，我的担心（显然是用第三方应用程序解决的）是文件locking，并确保文件在写操作期间得到正确更新（即，确保是否访问了两个副本，并且都写入了哪个文件优先级和变化发生了什么？）。 理想似乎是locking数据的任何替代副本，但这真的是一个大问题？
- Branchcache是否locking中央文件进行编辑？
- branchcache是否只将delta发送回已经改变的中央文件？
- 如果分支机构服务器也将被用作域控制器，那么这两种技术都不会被build议吗？
BranchCache是只读的，不会预caching。 它主要用于更新分发等东西 – 它是一个CACHE。
DFS不locking。 没有弹性的广域网技术会locking，因为如果/当广域网链路断开时locking是不可能的 – 所以它不是弹性就是locking。
如果您需要版本控制/locking才能正常工作，则只能使用中央服务器。 此时BranchCache可以帮助下载REPEATED下载的速度。 只要。
如果你还没有 – 也就是说，你需要从很多地方做很多更新（这是一个非常不寻常的情况 – 大多数时间文件没有像公司那样locking），那么你必须付出更多的带宽需要出现。 或者你可以使用一些thind party的DFS-R项目，但你有另一个问题….这是确保带宽不下来复制大量的未使用的东西，因为DFS复制是完全沿着文件共享线，而不是一个随需应变的元素。
这真是一个“该死的，如果你这样做，该死的，如果你不”的情况。 尤其是在局域网（高延迟，某些不可靠）的情况下。
BranchCache例如作为更新caching发挥作用 – 无需在分支机构中拥有本地WSUS服务器。 没有锁，因为它是一个纯粹的caching机制 – 你不能编辑一个BranchCache文件。 也就是说，因为没有locking，所以写操作将lockingCENTRAL文件，然后更新后的版本会传播，所以它可能对您有用;）
DFS非常适合只读的东西（安装映像，安装软件映像，集中编辑的策略文档等）。 有趣的是，我所处的大部分文件都属于这一类别 – 我们在这里编辑的内容大部分是与其他同步技术（共享点文件pipe理）一起使用的中心文件。 DFS是技术复制需求的一个很好的技术解决scheme。
http://pertorben.wordpress.com/2012/05/29/dfs-r-or-branchcache/
有一个很好的深入的解释。
BranchCache可能工作….它不会停止单个下载延迟，但它会处理重复的读取。 它也允许locking。
编辑：一旦切入它看起来像预加载现在是可能的。 请参阅