恭喜，自己找到答案，相信又进步了不少。我接触WAN时间不长，目前有个类似的issue，不知在座各位能否给些意见。 -pnpn(雁南飞) @佛州华人论坛:佛州枫下论坛 The Rolia Forum of Florida

工作学习 / 专业技术讨论 / 请教专家广域网文件传输问题。 -ready4u(就等你了); 2005-10-20 {846} (#2562693@0)
我们公司最近刚申请了MPLS 广域网专线，带宽为45Mbps, 专门用于两个数据中心的AIX系统之间的数据备份(每4小时20GB)。两个数据中心相隔2000公里。俺作为AIX的系统管理员被责令测试此专线。

我使用iperf来测试该带宽，从PC服务器到AIX都得到同样的结果：即UDP协议可以全部利用到45Mbps带宽，而使用TCP协议(iperf 或者 FTP), 却只能用到3Mbps。
我也试过调整TCP window size, delayack等参数(AIX no 命令，以及重启动inetd)，但是都没有效果。两端的服务器的ping response 是40ms，属于high bandwidth, high latency的环境。

请大虾指教下面的问题：
1、你是否曾经用到过通过MPLS广域网来传输文件？有没有类似TCP的性能问题。
2、有没有在UNIX上运行的软件可以支持parallel FTP, 例如Flashget的断点续传？要是同时启动10个FTP session来传送同一个文件，是不是就可以用足网络带宽。
3、有没有基于UDP的文件传输软件？我知道TFTP使用UDP, 但它只适合小文件。我需要传输的文件都是1GB左右的。

先谢了。

我来试试.. -elife123(elife123); 2005-10-20 {356} (#2564447@0)
1. 没有玩过MPLS (能不能发些资料我瞅瞅?). 但是既然是你所说的hi-latency网络, tcp肯定慢. 也是可以通过修改参数来提高性能的. udp是快, 但是否适合, 还不好说.

2. unix上的只要是个ftp应该都支持吧, 当然除了wuftpd. multi-session ftp应该可以了, 因为你只需要用到: 20g/4hr (11 mbps)

3. ftp不合适就用nfs吧, 它是基于udp的, 但是你是wan, 还是那句话: 是否适合?
你这个问题和MPLS没关系吧. -playtiger(INFORTIGER); 2005-10-20 (#2564483@0)
我做过MPLS广域网的设计和实际操作, 专业上叫MPLS VPN, 其实就是在两地之间给你建立一条基于路由协议层的专用通道. 带宽方面, 相对于普通的优先级要高一些, 但也只能是相对而言. -siptoronto(Flash_Flex); 2005-10-21 (#2564614@0)

具体测试上, 你可以把这个通道直接当做端到端的直连线测试, 不需要考虑服务商什么MPLS什么的. -siptoronto(Flash_Flex); 2005-10-21 (#2564615@0)

谢谢诸位答复，我试了一下同时运行10个FTP 程序，不过总的使用带宽还是3Mbps。通过调整AIX的TCP参数倒是提高了一点（5Mbps），但是还是差很多。elife说的是，高latency对于TCP可是要命的，各位还有什么高招？ -ready4u(就等你了); 2005-10-21 (#2565037@0)
this is my pm to u. -iwantcar(EnjoyStudying); 2005-10-21 {481} (#2565160@0)
From: iwantcar(EnjoyStudying) To: ready4u Reply Mark this message
Sent: 2005-10-20 12:04 (EDT)
hi. I know one new technology that can help you. UDP + some spcial technolcogy to recover and verify (resend) the data.

The biggest advantage of this technology is that it can significantly reduce the probability of resent.

Current program is only using Windows. This is a cutting edge and ever developing area. If you are interested, we may talk in detail.

good luck.
能否把你的测试数据贴一下: -iambigcat(cat); 2005-10-21 {711} (#2565405@0)
1. 端对端latency. 需要的是在正常业务时间内的平均delay; (round trip)
2. TCP window size
3. MTU
4. MSS

假设你要取得3MByte/second, 或者24MBit/second的FTP效率。
1. Bandwidth*Delay Product (BPD) = 45Mbps * 40ms / 2 = 0.9 Mb (112.5 KB)

2. TCP Buffer Size at least 2* BPD = 2* 112.5KB = 225 KB
(Note: Default TCP Buffer Size usually = 64KB, too small !!)

3. Throughput = Window size / Round trip time =>
Window size = Throughput * Round Trip Time = 3MBps * 40ms = 120 KB

不懂AIX，试试看下面这个:

"For better performance on SMP systems, try the following:

ifconfig <iface> thread
This allows the interrupt handler for a GigE interface on an SMP AIX box to be multi-threaded."

谢谢答复，下面是测试数据： -ready4u(就等你了); 2005-10-21 {1133} (#2565488@0)
本文发表在 rolia.net 枫下论坛1. 端对端latency. 需要的是在正常业务时间内的平均delay; (round trip)
我们测试ping的response是40ms，现在测试阶段只有这两台AIX服务器使用这条专线。其他的机器测试的latency也是一样的。

2. TCP window size
两个机器的发送和接收的window size 均设置为512KB, 我试过使用1MB，效果差不多。

3. MTU
MPLS Tunnel的MTU为1476 bytes， AIX上手工设置为1400。网管做过trace (Ethereal),说在此设置下没有看到fragmentation. 而且不可以使用jumbo packets (大MTU,例如9000).

4. MSS
我们使用iperf测试到的MSS是MTU-52，即1348 bytes。

下面是修改AIX TCP的参数script:
#!/usr/bin/ksh
no -D
no -o rfc1323=1
no -o tcp_sendspace=524288
no -o tcp_recvspace=524288
no -o tcp_pmtu_discover=0
no -o tcp_nodelayack=0
no -o delayack=3
no -o delayackports={5001,21}
no -o rto_length=6
route delete 10.155.15.92 192.168.158.246
route add 10.155.15.92 192.168.158.246 -mtu 1400
ifconfig en5 tcp_recvspace 524288 tcp_sendspace 524288 tcp_nodelay 0 rfc1323 1
ifconfig en5
stopsrc -s inetd; startsrc -s inetd

也试过ifconfig en5 thread, 效果也是一样。AIX 有两颗CPU，而且都特别闲置。

多谢你的有关Window Size的计算方法。我的window size 应该设到多少合适？更多精彩文章及讨论，请光临枫下论坛 rolia.net

1. ping RTT test 是 64Bytes 包还是用的MTU size? -iambigcat(cat); 2005-10-21 {206} (#2565790@0)
2. window size 太大会导致TCP重传. window size 大小可依两点计算：
i: Bandwidth * delay (我之前的帖子计算过了);
ii: 是MSS 的整数倍，如 MSS * 16, MSS * 32等等。

试着调整一下window size 再试试吧.

sorry , 应该摆整数倍改成偶数倍. -iambigcat(cat); 2005-10-21 (#2565791@0)
我认为,就这个CASE而言,增加WINDOW SIZE并不会导致RESENT问题.因为就算RESENT,也没有大的影响.小WINDOW SIZE直接影响性能,特别是延时指标不稳定的情况下. -iwantcar(EnjoyStudying); 2005-10-24 (#2569604@0)
Ping 1400 byte RTT是43ms, 根据你的建议调整了Window Size到269600byes, 还是一样。另外，我做了tcpdump 和iptrace, 发现win size是64030, 而且有很多duplicate ACKs. 不知道这能说明什么？ -ready4u(就等你了); 2005-10-24 (#2569740@0)

my 2 cents: -elife123(elife123); 2005-10-24 {510} (#2570561@0)
我忘记了你是单根的MPLS, 所以这种情况下采用多session并无好处.

你的瓶颈目前在WAN这里而非机器I/O, 调整thread没用, 集中于tcp协议有几点可以供你参考:

1. 有duplicated ACK就不要用"delayed-ack"了, 因为你现在要的是带宽
2. 启用sack和dsack以减轻拥堵 (但我不知道AIX是否支持)
3. 试着增加tcp_reordering值, ---> 例如5-6
4. 如果可能, 采用linux_2.6.13, 其tcp_bic可大幅增加性能.
5. 如果可能, 使用ssh的压缩功能来提高实际传送量

请告知测试结果, 还不行就只有走双线了, 因为目前udp file transfer protocol 还不稳定.
I remmember window size 64k is in the standard of TCP/IP. Now some modification of TCP/IP allow window size bigger than 64k. But application program and os must support it. Not very sure. You confirm it. -iwantcar(EnjoyStudying); 2005-10-25 (#2571551@0)
我觉得说明你的发起端在重复发同样的东西，发了几次，为什么会这样呢？是不是DELAY造成的？发起端等到超时了，只能重发。 -septasks(SEPT.); 2005-10-25 (#2571608@0)

Just want to clarify something after the converstation of the phone. -iwantcar(EnjoyStudying); 2005-10-21 {386} (#2565804@0)
1. The bigger buffer(fifo) of the device(the card) the better, this is hardware buffer may be as big as megabytes.

2. The buffer inside the TCP driver should be bigger. I used 1Mega bytes before.
Note: Even if you set the parameter in the TCP driver(module), application program may be able to ask the driver to change the parameter by itself. I did this in some BSD system before.

可能是tcp确认机制的问题你的mtu是多少？只改tcp window size不一定行可以考虑使用packeeter 或者steelhead这样的设备来测试一下 -wolves(脆皮狼); 2005-10-25 (#2571444@0)

不知道你用的是第二层还是第三层的MPLS VPN？原理上来讲，你只要把它看成一条45M的专线就够了。但为什么UDP可以到45M而TCP只能到3M，我觉得不外乎两种可能， -septasks(SEPT.); 2005-10-25 {297} (#2571591@0)
一是你自己的TCP测试方法有问题。

另一个就是运营商做QOS时，没有保证你的TCP流量的端到端的带宽（这种可能很小）。不知道你用的是谁的MPLS VPN，两端都是一个运营商接入吗？跨运营商做MPLS QOS难度会大些。

如果你的测试方法确实没有问题的话，你还是找运营商来看看吧，这么专业的问题你个业余选手是搞不明白的。

运营商才不管呢，他们只提供带宽，不管你上层应用。我觉得还是TCP参数要调整。 -iambigcat(cat); 2005-10-25 (#2572327@0)

你错了，SLA是他们的一个服务内容。 -septasks(SEPT.); 2005-10-25 (#2572887@0)

能不能把tcpdump的结果法上来？不然的话只能猜 -tinydog(@Where); 2005-10-25 (#2572704@0)
This is solution: 1. make point2point VPN connection using UDP. 2. Run GRE and tunnel all your traffic through. Why? -bugfree(BugFree); 2005-10-25 {215} (#2573121@0)
This is the reason:
1. You can not traffic data using plain text. So either you encrypt it, then transfer. Or using VPN based on IPsec.

2. Based on you test result. TCP connection can not reach 45M, but UDP can.
衷心谢谢各位的热情回答！我已经有解了！ -ready4u(就等你了); 2005-10-25 {831} (#2573286@0)
经过一个多星期的煎熬，翻阅N多研究资料，发现大家真正能用到全部带宽的方法，无一例外地都使用自己开发的软件，最常用的是:
1、Parallel FTP
2、Multicast FTP
3、TCP Over UDP

由于这些都没有公开的软件，我苦苦找寻，终于找到的解决问题的方法。
中心思想是：抛弃该死的TCP, 使用UDP!

软件是公开源代码的UFTP。我大概了解了一下其原理，具体做法是:
1、使用UDP协议
2、每发送15MB的数据才开始发送ACK （NAK）
3、调整AIX UDP的参数：
udp_sendspace=65535
udp_recvspace=1310720
sb_max=2621440
这个软件也有自己的缺点：不支持标准的FTP命令，不能有Client端指定存储目录。
看来还需要一些二次开发。

我测试UFTP的的结果是：
1、此MPLS专线: 最佳达到38Mbps，即每4分钟传1GB的数据。
2、大家使用AIX的FTP在现有的WAN上传输文件，速度是3Mbps。
而我使用UFTP的结果竟然也达到了36Mbps！

看来我们的文件传输协议真的得改改了。

明天有时间再和大家细细说说。

恭喜，自己找到答案，相信又进步了不少。我接触WAN时间不长，目前有个类似的issue，不知在座各位能否给些意见。 -pnpn(雁南飞); 2005-10-26 {564} (#2574653@0)
我公司有两个office，用两条T1线路连接起来，使用cisco2600，做了load balancing。我以前不知有iperf，直到看了这个帖子。我就用iperf测了两个office。tcp的结果是1.5mbps 到2mbps不等，udp只有1.5mbps左右。调了tcp window，没有什么影响。2*T1理论带宽有3M，实际应用可能最多用到2M了。

我不知道正确的测试方法是怎样的，目前我用iperf是在业务时间测的，每次10秒左右，每次结果不同。我不知道如何能测得平均带宽。

另外，如果用ftp测试带宽，具体是怎么做的？是手工记录起始时间，结束时间和文件大小来计算，还是有专门的测试软件？

谢谢

我们公司要升级wan，带宽到100M，回头我再详细说说。

iperf的目的之一在于帮助你调整网络参数已达到最佳性能。最重要的参数是window size, MTU size. UDP 协议需要在发送端设置传送带宽(例如参数 -b 3m )。看看说明书吧。AIX下的FTP提供总的传输带宽(Throughput in Mbyes/second)。 -ready4u(就等你了); 2005-10-27 (#2575347@0)

That is the final answer. You need encrypt you data before transmit. That is always the first thing you need to remember ;) -bugfree(BugFree); 2005-10-26 (#2575031@0)

在这个专线下也需要做加密吗？MPLS和T1有何不同？ -ready4u(就等你了); 2005-10-26 (#2575333@0)

dedicated line and T1 both need to encrypt before you do data transmition, I mean for enterprise implementation. I am seriously, you may lost you job someday if you did not do that. -bugfree(BugFree); 2005-10-27 (#2575438@0)

我们公司要上100m wan.我问了他们的工程师，说是不用encrypt，是dedicated。我对此比较关注，能否给予解释？ -pnpn(雁南飞); 2005-10-31 (#2582780@0)

对不起,没看懂. 在你第一贴你就说udp可以达到45M,而tcp只有3M. 可你研究后的结果还是使用udp.你并没有解决tcp带宽利用的问题呀? -dennis2000(dennis2000); 2005-10-26 (#2575260@0)

老大，我的目标是充分利用新的带宽实现文件高速传输,而不是解决TCP带宽利用的问题。传统的文件传输程序都是基于FTP的,几乎没有基于UDP的。在high latency的网络环境中，TCP就是扶不起的阿斗，大家都使用其他方法,例如Parallel FTP, Multicast FTP和TCP over UDP。参见链接
-ready4u(就等你了); 2005-10-27 (#2575327@0)

哦! 还有为什么你说tftp不能传大文件哪?用tftp传1G的文件会有什么结果? -dennis2000(dennis2000); 2005-10-27 (#2576745@0)

Here is an old post: #1872461. Read it and you will understand that guy more. -iwantcar(EnjoyStudying); 2005-10-27 (#2575517@0)

@Florida

恭喜，自己找到答案，相信又进步了不少。我接触WAN时间不长，目前有个类似的issue，不知在座各位能否给些意见。

Replies, comments and Discussions:

More Topics