我们已经build立了一个具有非常快速的上行连接1Gbps的新服务器，但由于某些原因，部分客户端的下载速度仍然非常缓慢。
在服务器驻留的国家，客户端和服务器之间的networking速度如预期的那样非常快。 但是，当客户在另一个国家时，下载速度急剧下降，我们只能测量1MB / s到2MB / s之间的数据。 这不是一个客户端带宽问题 – 有很多可用的。
我将如何去debugging这个问题？ 从互联网上读取我怀疑这可能是从客户端到服务器的path中的某个丢包问题。 traceroute可以找出有问题的节点吗？
尝试在同一地区的另一台服务器。 这听起来可能是目标服务器。 你不能指望每个人都有1Gbps的链接。
有确切的数字是有用的，你看到什么样的速度，在path上有多less跳，以及往返时间（用ping测量）。
一般来说，任何数据path的最大速度将是该path中最慢的组件。 对于国际化的道路来说，终点的速度可能并不重要：中间的环节可能会让你放慢速度。
traceroute可以是有用的。 在没有活动的情况下运行，然后在传输过程中重复。 寻找一个转移期间潜伏期跳跃高于没有活动的时刻。 如果存在这样一个问题，那就是发生瓶颈的地方。
如果等待时间在端点附近跳起，那么问题可能出在端点的networking连接上。 如果它在中间，那么问题可能就是广域网上的拥塞/争夺。
如果在任何地方都没有看到跳跃，那么就有可能在整个path上蔓延。
另外请记住，TCP，特别是旧的实现，不喜欢高延迟，长path或任何数据包丢失。 如果总延迟时间超过几十毫秒，则不太可能在千兆位速度附近实现。
一个非常可能的问题是你正在用完接收窗口。 如果您search术语BDP（带宽延迟产品）或LFN（长发networking），您可以find详细的解释。 简言之，延迟超过了接收窗口的能力来保持数据包的stream动。
计算和设置值的两个很好的来源是： http : //www.psc.edu/networking/projects/tcptune/＆http : //www.speedguide.net/bdp.php
只要盯住远端，就会知道国家和国家之间的延迟是否有显着差异