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