我们在相距约 200 英里的地点之间建立了一对新的不同路由 1Gbps 以太网链路。“客户端”是一台性能相当强大的新机器（HP DL380 G6、双 E56xx Xeon、48GB DDR3、R1 对 300GB 10krpm SAS 磁盘、W2K8R2-x64），“服务器”也是一台相当不错的机器（HP BL460c G6、双 E55xx Xeon、72GB、R1 对 146GB 10krpm SAS 磁盘、双端口 Emulex 4Gbps FC HBA 连接到双 Cisco MDS9509，然后连接到专用的 HP EVA 8400，配备 128 x 450GB 15krpm FC 磁盘，RHEL 5.3-x64）。
使用客户端的 SFTP，我们发现使用大型文件（>2GB）时，吞吐量仅为 40Kbps。我们已执行服务器到“其他本地服务器”的测试，通过本地交换机（Cat 6509s）看到吞吐量约为 500Mbps，我们将在客户端执行同样的测试，但那还需要一天左右的时间。
您会使用哪些其他测试方法来向链接提供商证明问题出在他们身上？
答案1
调整大象：
这可能需要调整，但可能不是 pQd 所说的问题。这种链接被称为“长而粗的管道”或大象（见RFC 1072)。因为这是一个跨越一段距离的粗千兆位管道（在这种情况下，距离实际上是时间/延迟），所以 TCP 接收窗口需要很大（请参阅 TCP/IP 图解第 1 卷，TCP 扩展部分中的图片）。
要确定接收窗口需要什么，需要计算带宽延迟乘积：
Bandwidth * Delay = Product
如果有10MS的延迟，这个计算器估计您需要大约 1.2 MBytes 的接收窗口。我们可以自己使用上述公式进行计算：
echo $(( (1000000.00/.01)/8 ))
12500000
因此，您可能需要运行数据包转储来查看TCP 窗口缩放一旦你弄清楚了最大的问题是什么，就可以立即调整（允许更大窗口的 TCP 扩展）。
窗口边界：
如果这是问题所在，即窗口大小受限而没有缩放，如果没有进行窗口缩放并且无论管道大小如何都有大约 200 毫秒的延迟，我预计会出现以下结果：
Throughput = Recieve Window/Round Trip Time
所以：
echo $(( 65536/.2 ))
327680 #Bytes/second
为了获得您看到的结果，您只需要解决延迟问题，即：
RTT = RWIN/Throughput
因此（对于40kBytes/s）：
echo $(( 65536.0/40000.0 ))
1.63 #Seconds of Latency
（请检查我的数学，这些当然不包括所有的协议/标头开销）
答案2
40kbps 非常低 [以至于我怀疑媒体转换器有故障/双工不匹配 [但您有千兆位，所以没有半双工的空间！] 等等]。一定有数据包丢失或非常高的抖动。
iperf 是我想到的第一个测量可用吞吐量的工具。
iperf -s
另一方面：
iperf -t 60 -c 10.11.12.13
然后您可以交换客户端/服务器角色，使用 -d 进行双工等。在开始测试之前在两台机器之间运行 mtr，查看未使用的链路上的延迟/数据包丢失，以及它们在数据传输过程中如何变化。
您希望看到：抖动非常小并且没有数据包丢失，直到链路饱和到其容量的 90% 左右。
答案3
tracepath 可以向您显示两个站点之间的路由问题。
iperf、ttcp 和 bwping 可以为您提供有用的信息。
您知道这个 1GB 链接是如何配置的吗？您是通过这个链接进行桥接还是路由？您对这个链接的 SLA 是什么？您的链接提供商可能会对您进行调整吗？
如果你只能得到 40kbs，那么问题就很严重了，你确定这不是 1MB 的链接，而是 1GB/s 的链接吗？你可能会发现链接的速度不是你想象的那样 :-)
答案4
RFC 2544 或Y.156萨姆
这些是运营商为验证 SLA 而进行的网络测试。IPERF 等不是可验证的网络测试方法。