debugging从服务器传输速度慢

我试图解释这是简单的,但logging尽可能。 这不是这个服务器或我目前的ISP独家 。 多年来,我看到了同样的确切问题,同时与不同的ISP和我的服务器与不同的提供商(美国的GoDaddy,加拿大的iWeb和GloboTech)。 唯一常见的是Windows Server操作系统(2003和2008 R2)。 但我们现在只查看当前的服务器和当前的ISP。

问题是

我的本地工作站和远程专用服务器之间的传输速度非常慢。 我的服务器位于100 Mbps端口上,本地工作站位于光纤上的50 Mbps对称连接上。

症状

当在美国和墨西哥的不同服务器和地点进行speedtest.nettesting时,服务器和工作站都会获得极好的结果(非常接近它们的连接速度)。 如果我从Dropbox下载大文件到我的服务器或工作站,那么在一个连接上分别获得10 MBps和5 MBps的传输速率,根据每个连接速度100 Mbps和50 Mbps repectively。

然而,如果我从我的服务器(通过HTTP或FTP)传输文件到我的工作站,我甚至没有接近我应得到的50 Mbps速度(5 MBps的传输速率),而是获得相当于3 Mbps的东西(300 KBps的传输速率)。

我试图理解为什么我的传输速度很慢。 我不确定如何debugging它。 每当我提出与托pipe服务提供商的问题的票,他们问我tracert输出,最后只是在中间的一些服务器上责怪它。 但是,如果我们考虑一下我刚才所说的话,那看起来并不正确: 我在使用GoDaddy,iWeb和GloboTech的服务器时看到了这个确切的速度/问题,同时也让我自己与不同的ISP不同types的互联网服务 。 它看起来像一个固定的设置在服务器领域的某个地方。

我做的testing

SPEEDTEST

这些是来自speedtest.net的速度testing,这些testing是在我的专用服务器上针对不同的远程服务器执行的,这些远程服务器包括位于墨西哥城的ISP数据中心的服务器

加拿大 :下载94.64 Mbps,上传94.87 http://www.speedtest.net/my-result/3470801975

加利福尼亚州圣何塞 :93.58 Mbps的下载和95.48 Mbps的上传http://www.speedtest.net/my-result/3470805341

墨西哥城(服务器在我自己的ISP的数据中心) :92.99 Mbps的下载和95.39 Mbps的上传http://www.speedtest.net/my-result/3470810269

如果我从本地工作站对同一台服务器运行这些testing,则速度也接近我的50 Mbps连接。

TRACERT

这是从我的工作站执行到我的专用服务器的最近一次tracert输出:

1 <1 ms <1 ms <1 ms 192.168.7.254 2 2 ms 1 ms 1 ms 10.69.32.1 3 * 3 ms 2 ms 10.5.50.174 4 3 ms 2 ms 2 ms 10.5.50.173 5 * 5 ms 3 ms fixed-203-69-2.iusacell.net [189.203.69.2] 6 32 ms 32 ms 32 ms 8-1-33.ear1.Dallas1.Level3.net [4.71.220.89] 7 33 ms 33 ms 33 ms ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145] 8 33 ms 33 ms 33 ms ae13.dal33.ip4.tinet.net [77.67.71.221] 9 76 ms 76 ms 157 ms xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41] 10 72 ms 72 ms 72 ms te2-2.cr2.mtl3.gtcomm.net [67.215.0.160] 11 72 ms 72 ms 72 ms ae2.csr2.mtl3.gtcomm.net [67.215.0.134] 12 72 ms 72 ms 73 ms te3-4.dist1.mtl8.gtcomm.net [67.215.0.83] 13 72 ms 72 ms 72 ms ns1.marveldns.com [173.209.57.82] 

的iperf

这是一个使用我的专用服务器作为服务器和我的工作站作为客户端执行的iperftesting:

 ------------------------------------------------------------ Client connecting to ns1.marveldns.com, TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.7.2 port 60339 connected with 173.209.57.82 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.3 sec 5.62 MBytes 4.59 Mbits/sec 

的pathping

这是从我的工作站执行到我的专用服务器的path命令的输出:

 Tracing route to ns1.marveldns.com [173.209.57.82] over a maximum of 30 hops: 0 ws1 [192.168.7.2] 1 192.168.7.254 2 10.69.32.1 3 * 10.5.50.174 4 10.5.50.173 5 fixed-203-69-2.iusacell.net [189.203.69.2] 6 8-1-33.ear1.Dallas1.Level3.net [4.71.220.89] 7 ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145] 8 ae13.dal33.ip4.tinet.net [77.67.71.221] 9 xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41] 10 te2-2.cr2.mtl3.gtcomm.net [67.215.0.160] 11 ae2.csr2.mtl3.gtcomm.net [67.215.0.134] 12 te3-4.dist1.mtl8.gtcomm.net [67.215.0.83] 13 ns1.marveldns.com [173.209.57.82] Computing statistics for 325 seconds... Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address 0 ws1 [192.168.7.2] 0/ 100 = 0% | 1 0ms 0/ 100 = 0% 0/ 100 = 0% 192.168.7.254 0/ 100 = 0% | 2 1ms 0/ 100 = 0% 0/ 100 = 0% 10.69.32.1 0/ 100 = 0% | 3 3ms 0/ 100 = 0% 0/ 100 = 0% 10.5.50.174 0/ 100 = 0% | 4 2ms 0/ 100 = 0% 0/ 100 = 0% 10.5.50.173 0/ 100 = 0% | 5 4ms 20/ 100 = 20% 20/ 100 = 20% fixed-203-69-2.iusacell.net [189.203.69.2] 0/ 100 = 0% | 6 34ms 0/ 100 = 0% 0/ 100 = 0% 8-1-33.ear1.Dallas1.Level3.net [4.71.220.89] 0/ 100 = 0% | 7 34ms 0/ 100 = 0% 0/ 100 = 0% ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145] 0/ 100 = 0% | 8 33ms 0/ 100 = 0% 0/ 100 = 0% ae13.dal33.ip4.tinet.net [77.67.71.221] 0/ 100 = 0% | 9 79ms 0/ 100 = 0% 0/ 100 = 0% xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41] 2/ 100 = 2% | 10 73ms 14/ 100 = 14% 12/ 100 = 12% te2-2.cr2.mtl3.gtcomm.net [67.215.0.160] 0/ 100 = 0% | 11 72ms 2/ 100 = 2% 0/ 100 = 0% ae2.csr2.mtl3.gtcomm.net [67.215.0.134] 2/ 100 = 2% | 12 72ms 18/ 100 = 18% 14/ 100 = 14% te3-4.dist1.mtl8.gtcomm.net [67.215.0.83] 0/ 100 = 0% | 13 72ms 4/ 100 = 4% 0/ 100 = 0% ns1.marveldns.com [173.209.57.82] Trace complete. 

事情你可以尝试自己

如果你想尝试一下,这些是我在服务器上为了testing目的而设置的一些东西:

HTTP服务器上的大文件

我在我的服务器中放置了一个可以通过HTTP下载的5 GB文件。 你可以在这里find它: http : //www.marveldns.com/transfer_test/

Speedtest MINI应用程序

我在我的服务器上设置了“speedtest mini”testing。 你可以访问它,看看你的服务器和你自己下载和上传的速度。 你可以在这里find它: http : //www.marveldns.com/speedtest/

最后

正如我之前所说的,我试图帮助理解整个事情。 我不是TCP / IP或高端networking的专家。 我真的不清楚如何使用tracert,iperf或pingpath的结果来解决这个问题,但是我把它们包括进来,因为当我谈论这个问题的时候总是被问到。

如果我的问题没有什么更好的,请不要只是低估它,让我知道什么是错的,或者我可以添加到其中以获得一些帮助。 谢谢。

访问该URL时看到的瓶颈显然是由窗口大小造成的。

当我尝试从您的服务器下载时,我得到555KB /秒。 我有一个108ms的往返时间。 做math我得到以下窗口大小:555KB / s * 108ms = 59.94KB。

只要我从数据中心的主机那里做,我就可以得到一个非常一致的吞吐量和来回。 另外,如果我开始两个并行下载,每个得到555KB /秒。 当瓶颈是窗口大小时,这就是您将看到的症状。

没有窗口缩放,窗口不能大于64KB。 但是我确实看到窗口缩放需要协商,所以应该有更高的吞吐量。 这留下了两个假设来调查:

  • 有些东西正在改变从客户端到服务器的path上的窗口缩放选项,使得服务器认为窗口缩放了1倍。
  • 服务器可能被configuration为在每个连接上从不使用超过60KB的发送窗口。

首先很容易validation你是否可以在服务器上执行数据包捕获。 只需查看传入SYN数据包的扩展选项,即可确定服务器是否接收到高于1的比例因子。 我可以推荐使用Wireshark来分析stream量。

validation第二个假设需要您正在使用的操作系统的一些知识。 你碰巧select了一个我不知道的操作系统,所以我不能帮忙。 所以我只能帮助networking的专业知识。