我们在相距200英里的地点之间有一对新的不同路由的1Gbps以太网链路。 “客户端”是一台function强大的新机器（HP DL380 G6，双E56xx Xeon，48GB DDR3，R1对300GB 10krpm SAS磁盘，W2K8R2-x64），“服务器”也是一台相当不错的机器（HP BL460c G6双E55xx至强72GB R1对146GB 10krpm SAS磁盘，连接双Cisco MDS9509s的双端口Emulex 4Gbps FC HBA，然后连接到带128 x 450GB 15krpm FC磁盘（RHEL 5.3-x64）的专用HP EVA 8400。
从客户端使用SFTP，我们只能看到使用大（> 2GB）文件的大约40Kbps的吞吐量。 我们已经执行服务器到“其他本地服务器”testing，通过本地交换机（Cat 6509s）看到大约500Mbps，我们将在客户端做同样的事情，但是这一天左右。
你会用什么其他testing方法向链接提供者certificate问题是他们的？
调整大象：
这可能需要调整，可能不是这个问题，因为pQd说。 这种链接被称为“长，胖pipe”或大象（见RFC 1072 ）。 由于这是一个长距离传输的胖千兆pipe道（在这种情况下距离实际上是时间/延迟），所以tcp接收窗口需要很大（参见TCP / IP图解卷1，图片的TCP扩展部分）。
为了弄清楚接收窗口需要什么，你计算带宽延迟产品：
Bandwidth * Delay = Product 如果有10MS的延迟， 这个计算器估计你想要一个大约1.2 MB的接收窗口。 我们可以用上面的公式自己做计算：
echo $(( (1000000.00/.01)/8 )) 12500000
所以你可能想要运行一个数据包转储来查看是否发生tcp窗口缩放 （允许更大的窗口的TCP扩展）正确的调整，一旦你找出大问题。
窗口绑定：
如果这是问题，你是没有缩放的窗口大小的限制，我会期望下面的结果，如果没有窗口缩放到位，无论pipe道大小有大约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
（请检查我的math，这些当然不包括所有的协议/头的开销）
40kbps是非常低的[直到我怀疑有缺陷的媒体转换器/双工不匹配[但你有吉比特，所以没有半双工的地方！]等]。 必须有数据包丢失或非常高的抖动。
iperf是我脑海中测量可用吞吐量的第一个工具。 跑在一边
iperf -s
另一方面：
iperf -t 60 -c 10.11.12.13
那么你可以交换客户机/服务器angular色，使用-d进行双工等。在testing开始之前，在两台机器之间运行mtr，查看未使用链路上的延迟/数据包丢失情况，以及在数据传输过程中它们是如何改变的。
您希望看到：在链路达到饱和容量的90％时，抖动非常小，没有丢包现象。
Iperf * nix和赢 ，阅读这里和这里关于它。
mtr为* nix和胜利 。
tracepath可以显示两个站点之间的路由问题。
iperf，ttcp和bwping可以给你有用的信息。
你知道这个1GB链接是如何configuration的吗？ 你是通过这个链接桥接或路由？ 什么是您的SLA链接？ 你可能被你的链接提供商塑造？
如果你只有40kbs，那么存在一个严重的问题，你确定它不是1MB的链接，而不是1GB / s的链接。 你可能会发现，链接的速度不是你所想的那样:-)
RFC 2544或Y.156sam
这些是networkingtesting，是为了certificate运营商的SLA。 IPERF等是不可validation的networkingtesting方法。