分支机构连接问题

Question 1

您接下来应该检查以下几种明显的可能性：

也许 ISP 指定的 20Mbps 容量仅适用于传入流量。如果每个位置的传出容量较小，那么两个站点之间的通信将永远无法使用任一位置的全部传入容量。
如果任一链路在一个方向上饱和，则可能会出现往返延迟增加和数据包丢失的情况。在出现轻微的缓冲区膨胀的情况下，这可能会使往返延迟增加数十毫秒，在极端情况下，我曾看到这导致往返时间长达 60 秒。
可能有些主机处于 NAT 后面。如果您处于 NAT 后面，Skype 可能会将您的呼叫路由到其他 Skype 用户。如果您不在 NAT 后面，那么 Skype 可能会将其他用户的呼叫路由到您的主机。这两种情况都会导致糟糕的用户体验。
您可能有多层 NAT。如果您尚未检查，则无法确定您的 CPE 中是否同时存在 NAT 以及 ISP 部署的 CGN。

一旦知道了问题是什么，就可以寻找每个可能问题的解决方案。

如果到您网站的链接在一个或两个方向上都饱和，您可能需要管理带宽。管理传入带宽并非易事，因为当它到达您的设备时，它已经消耗了传入链接上的带宽。如果您面临这个特定问题，解决方案可能是不让您的用户直接访问使用 ISP 链接。相反，您将所有流量通过隧道路由到连接良好的位置（数据中心的速率为 100Mbit/s 或更高，到主干网的延迟最多为 1ms）。一旦您将所有流量通过隧道路由，您就可以在流量进入隧道时管理带宽。

如果每个站点都有 NAT，而主机位于 NAT 后面也是问题的一部分，那么您可能会从站点之间的隧道中获得一些优势，这样每个站点的主机就可以相互通信而无需 NAT。（我不知道 Skype 和 Hangouts 是否可以从中受益。）

即使其中一个站点位于 CGN 后面，两个站点之间也可以建立隧道。但如果两个站点都位于 CGN 后面，那么它们之间的隧道将不可靠。如果您恰好处于这种情况并且仍然需要站点之间的隧道，您有两个选择。要么在至少一个站点上获取公共 IPv4 地址，要么在两个站点上都获取 IPv6。

将通向连接良好的位置的隧道与站点之间的隧道相结合可能会使带宽管理变得更加困难，因为您有两个源通过同一管道发送数据包，并且都无法实时了解另一个源发送了多少数据包。解决这个问题的方法是忘记站点之间的隧道，而是通过所选的连接良好的点路由来自一个站点的所有流量，无论您是与另一个站点还是外部位置进行通信。

通过数据中心路由所有流量还可以避免由您的 ISP 引起的大部分寻址问题，因为您将使用来自数据中心而不是 ISP 的地址。您可以选择一个数据中心，在那里您可以获得具有双栈连接且没有 NAT 的主机。

由于不像最后一英里连接那样受物理位置的约束，数据中心之间的竞争更加激烈，这使得找到合适的数据中心变得更加容易。您仍然需要注意可能增加的延迟。我当然不会建议通过同一个数据中心路由来自两个不同大陆的流量，因此您必须在每个站点附近找到一个。

Answer

您接下来应该检查以下几种明显的可能性：

也许 ISP 指定的 20Mbps 容量仅适用于传入流量。如果每个位置的传出容量较小，那么两个站点之间的通信将永远无法使用任一位置的全部传入容量。
如果任一链路在一个方向上饱和，则可能会出现往返延迟增加和数据包丢失的情况。在出现轻微的缓冲区膨胀的情况下，这可能会使往返延迟增加数十毫秒，在极端情况下，我曾看到这导致往返时间长达 60 秒。
可能有些主机处于 NAT 后面。如果您处于 NAT 后面，Skype 可能会将您的呼叫路由到其他 Skype 用户。如果您不在 NAT 后面，那么 Skype 可能会将其他用户的呼叫路由到您的主机。这两种情况都会导致糟糕的用户体验。
您可能有多层 NAT。如果您尚未检查，则无法确定您的 CPE 中是否同时存在 NAT 以及 ISP 部署的 CGN。

一旦知道了问题是什么，就可以寻找每个可能问题的解决方案。

如果到您网站的链接在一个或两个方向上都饱和，您可能需要管理带宽。管理传入带宽并非易事，因为当它到达您的设备时，它已经消耗了传入链接上的带宽。如果您面临这个特定问题，解决方案可能是不让您的用户直接访问使用 ISP 链接。相反，您将所有流量通过隧道路由到连接良好的位置（数据中心的速率为 100Mbit/s 或更高，到主干网的延迟最多为 1ms）。一旦您将所有流量通过隧道路由，您就可以在流量进入隧道时管理带宽。

如果每个站点都有 NAT，而主机位于 NAT 后面也是问题的一部分，那么您可能会从站点之间的隧道中获得一些优势，这样每个站点的主机就可以相互通信而无需 NAT。（我不知道 Skype 和 Hangouts 是否可以从中受益。）

即使其中一个站点位于 CGN 后面，两个站点之间也可以建立隧道。但如果两个站点都位于 CGN 后面，那么它们之间的隧道将不可靠。如果您恰好处于这种情况并且仍然需要站点之间的隧道，您有两个选择。要么在至少一个站点上获取公共 IPv4 地址，要么在两个站点上都获取 IPv6。

将通向连接良好的位置的隧道与站点之间的隧道相结合可能会使带宽管理变得更加困难，因为您有两个源通过同一管道发送数据包，并且都无法实时了解另一个源发送了多少数据包。解决这个问题的方法是忘记站点之间的隧道，而是通过所选的连接良好的点路由来自一个站点的所有流量，无论您是与另一个站点还是外部位置进行通信。

通过数据中心路由所有流量还可以避免由您的 ISP 引起的大部分寻址问题，因为您将使用来自数据中心而不是 ISP 的地址。您可以选择一个数据中心，在那里您可以获得具有双栈连接且没有 NAT 的主机。

由于不像最后一英里连接那样受物理位置的约束，数据中心之间的竞争更加激烈，这使得找到合适的数据中心变得更加容易。您仍然需要注意可能增加的延迟。我当然不会建议通过同一个数据中心路由来自两个不同大陆的流量，因此您必须在每个站点附近找到一个。

Question 2

我们遇到了类似的问题，增加带宽也无济于事。我们遇到的主要问题是 SharePoint 和 CRM。然而，文件传输也很麻烦。

我们进行了测试然后安装Riverbed Steelhead WAN 优化器在办公室，效果非常惊人。CRM 和 SharePoint 的支持电话几乎降为零，用户也更加满意。它不一定能改善 Skype 和其他实时应用程序，但它可以释放带宽，让实时应用程序得到改善。

我们的应用程序面临的最大挑战是每个页面请求所需的往返事务数量。无论两端的管道有多大，事务都需要时间。基本上，我们监控了应用程序的 HTTP 流量，发现 CRM 或 SharePoint 中的一个简单页面需要多次往返。

安装非常简单，不到一小时就运行完毕。持续的调整可让您进一步优化流量。

我与 Riverbed 没有任何关系，只是一位非常满意的用户。

Answer