我在两个数据中心之间同步大量数据时遇到了问题。两台机器都有千兆位连接，并没有完全占用，但我能获得的最快速度是 6 到 10 Mbit => 不可接受！
昨天我进行了一些跟踪路由，结果表明 LEVEL3 路由器上的负载非常大，但这个问题已经存在数周了，而且高响应时间已经消失（20 毫秒而不是 300 毫秒）。
我该如何跟踪以找到实际的慢速节点？考虑过使用更大的包进行跟踪，但这会起作用吗？
此外，这个问题可能与我们的某台服务器无关，因为到其他服务器或客户端的传输速率要高得多。实际上办公室 => 服务器比服务器 <=> 服务器！
任何想法都值得赞赏；）
更新
我们实际上使用 rsync 通过 ssh 复制文件。由于加密往往会产生更多瓶颈，我尝试了 HTTP 请求，但不幸的是它同样很慢。
我们与其中一个数据中心签订了 SLA。他们说他们已经尝试更改路由，因为他们说这与流量通过的廉价网络有关。确实，它将通过“廉价网络”进行路由，但只能反过来。我们的方向通过 LEVEL3，而另一条路通过 lambdanet（他们说这不是一个好的网络）。如果我没记错的话（我是网络中间人），他们模拟了一条更长的路径来强制通过 LEVEL3 进行路由，并在 AS 路径中宣布 LEVEL3。
我基本上想知道他们是对的还是他们只是想推卸责任。问题是问题存在于两个方向（虽然是不同的路线），所以我认为这是我们的托管商的责任。老实说，我不相信有一个 DC2DC 连接只能处理 600kb/s - 1.5 MB/s 数周！问题是如何检测这个瓶颈在哪里
答案1
如果你被路由到公共互联网上的慢速链接，那么你唯一的选择就是强行绕过它。最简单的方法是尝试在两个端点之间传输文件，其中一个是“点 A”（数据来源），另一个是中间站点该地点在地理位置上不与您的目的地“B 点”位于同一位置。
一旦你找到一个“点 C”，即一个可以不是通过您所面临的慢速互联网路由器进行路由，您可以在点 A 和点 C 之间设置 VPN，这样流量就可以“绕过”慢速节点。
如果您拥有较高的商业价值（$$$$$$）或在 ISP 中具有影响力，您也可以直接向 Level 3 提出问题。但是，L3 是一级 ISP，可能不会特别接受有关服务质量或网络饱和度的投诉，因为如果他们不能、不会或无力扩展与下游或其他在其节点上制造争用的一级提供商的对等协议，他们对此无能为力。
由于您说“办公室到服务器”的链接速度更快，您可以尝试使用中等功能的计算机（双核服务器级系统应该可以）在“办公室”站点设置 VPN。
噢，还有！如果“点 A”和“点 B”之间的延迟（端到端）非常高（在服务器世界中大于 100 毫秒就很高），则应确保您没有使用聊天网络协议. Samba（也称为 SMB 或 Windows 文件共享）是极其健谈；其他“同步”协议也可能是健谈的。
繁琐协议是指需要大量同步“来回”往返才能传输数据的协议。如果您的协议过于繁琐，那么无论链接速度有多快，延迟本身就可能成为传输的瓶颈。
要确定聊天是否真的影响了你的吞吐量，你可以使用一个已知的不爱说话协议，例如 HTTP，进行测试传输。因此，尝试通过“慢速”的 Level3 路由器从“点 A”到“点 B”进行常规的旧 HTTP 传输，如果延迟较高但吞吐量仍然良好，那么你知道您的传输速度慢的原因是您的协议太繁琐，因此您需要更改协议。
因此，让我通过简要定义和解释来结束讨论三种网络损害以及原因任何人其中可能对此问题负责的人有：
潜伏-- 数据报从一端到另一端需要多长时间。在大多数情况下，您无法直接改善延迟，除非您的某台计算机超载到其网络堆栈、内核或应用程序产生显著的额外延迟。公共互联网上的大部分延迟源自互联网路由器，而不是您的计算机或端点。
带宽-- 带宽是计算机与终端之间最慢链路的最大吞吐量。在大多数现代网络中，带宽并不是真正的限制，因为在带宽成为真正问题之前，其他网络障碍就已经出现并减慢了网络速度。
数据包丢失-- 数据包丢失可能会增加感知可靠数据报（如 TCP）的延迟，通常是由于严重饱和的链路不得不将数据包从 TCP 传输或接收缓冲区中丢弃，因为缓冲区已经太满。此外，数据包丢失可能发生在“时间敏感”数据包中，几乎所有 TCP 数据包都是如此，因为如果数据包在截止时间之后到达，则会被丢弃。如果较大的 TCP 数据包被分割成多个 IP 数据报，并且接收端的 TCP 协议只能等待固定时间让所有片段到达，然后决定中止接收数据包，就会发生这种情况。因此，数据包丢失间接源于饱和问题（这是带宽问题）或者硬件问题或故障。
源于基本的网络损伤，您可以采取一些缓解措施来提高程序的可靠性，而无需改变基本损伤，因为大多数时候，您几乎无法甚至根本无法控制它们：
缓解措施一是让你的协议不那么繁琐（或者，从系统集成的角度来看，使用现有的协议比您当前的解决方案更简洁）。在端点之间同步数据所需的“往返”次数越少，您的情况就越好。某些协议可以设计为需要可变的同步频率——如果是这种情况，如果您检测到高延迟或数据包丢失，则应尽可能动态地降低同步频率。减少繁琐有助于缓解延迟和数据包丢失，但不能解决带宽上限问题。
缓解措施二是配置所有跳数（即您在管理/硬件级别直接控制的跳数），以使用最佳的主动队列管理 (AQM) 算法，目前是公平队列控制延迟 AQM。这在 Linux 内核 3.5 或更高版本中作为fq_codelqdisc 实现提供，它的作用是动态减少传输和接收缓冲区的大小，以减少这些缓冲区必然产生的延迟。这可以减少数据包丢失并帮助使用 TCP 协议应对延迟，因为如果您将数据包在通过链路发送之前必须经历的等待时间最小化，则碎片数据包过期的可能性较小。请注意，这种缓解措施只有在节点“饱和”时才会产生影响（即，如果 TCP 缓冲区为空，则不起作用）。只要数据写入网络套接字的速率超过上行链路的传输速率，节点就会饱和。TCP 堆栈对这种情况的典型响应是使缓冲区更大，这实际上会产生负面影响，因为它会增加延迟，并导致各种问题 - 因此 fq_codel 有助于缓解这种情况。
这两种缓解措施都有助于解决所有三种基本的网络损害，没有绕过故障节点，并没有更改任何硬件或者联系 ISP。