This topic has been archived. It cannot be replied.
-
工作学习 / 专业技术讨论 / 请教专家广域网文件传输问题。
-ready4u(就等你了);
2005-10-20
{846}
(#2562693@0)
-
我来试试..1. 没有玩过MPLS (能不能发些资料我瞅瞅?). 但是既然是你所说的hi-latency网络, tcp肯定慢. 也是可以通过修改参数来提高性能的. udp是快, 但是否适合, 还不好说.
2. unix上的只要是个ftp应该都支持吧, 当然除了wuftpd. multi-session ftp应该可以了, 因为你只需要用到: 20g/4hr (11 mbps)
3. ftp不合适就用nfs吧, 它是基于udp的, 但是你是wan, 还是那句话: 是否适合?
-elife123(elife123);
2005-10-20
{356}
(#2564447@0)
-
你这个问题和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.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.
-iwantcar(EnjoyStudying);
2005-10-21
{481}
(#2565160@0)
-
能否把你的测试数据贴一下:
-iambigcat(cat);
2005-10-21
{711}
(#2565405@0)
-
谢谢答复，下面是测试数据：
-ready4u(就等你了);
2005-10-21
{1133}
(#2565488@0)
-
1. ping RTT test 是 64Bytes 包还是用的MTU size?2. window size 太大会导致TCP重传. window size 大小可依两点计算：
i: Bandwidth * delay (我之前的帖子计算过了);
ii: 是MSS 的整数倍，如 MSS * 16, MSS * 32等等。
试着调整一下window size 再试试吧.
-iambigcat(cat);
2005-10-21
{206}
(#2565790@0)
-
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:我忘记了你是单根的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 还不稳定.
-elife123(elife123);
2005-10-24
{510}
(#2570561@0)
-
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.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.
-iwantcar(EnjoyStudying);
2005-10-21
{386}
(#2565804@0)
-
可能是tcp确认机制的问题 你的mtu是多少？只改tcp window size不一定行 可以考虑使用packeeter 或者steelhead这样的设备来测试一下
-wolves(脆皮狼);
2005-10-25
(#2571444@0)
-
不知道你用的是第二层还是第三层的MPLS VPN？原理上来讲，你只要把它看成一条45M的专线就够了。但为什么UDP可以到45M而TCP只能到3M，我觉得不外乎两种可能，一是你自己的TCP测试方法有问题。
另一个就是运营商做QOS时，没有保证你的TCP流量的端到端的带宽（这种可能很小）。不知道你用的是谁的MPLS VPN，两端都是一个运营商接入吗？跨运营商做MPLS QOS难度会大些。
如果你的测试方法确实没有问题的话，你还是找运营商来看看吧，这么专业的问题你个业余选手是搞不明白的。
-septasks(SEPT.);
2005-10-25
{297}
(#2571591@0)
-
运营商才不管呢，他们只提供带宽，不管你上层应用。我觉得还是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?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.
-bugfree(BugFree);
2005-10-25
{215}
(#2573121@0)
-
衷心谢谢各位的热情回答！我已经有解了！
-ready4u(就等你了);
2005-10-25
{831}
(#2573286@0)
-
恭喜，自己找到答案，相信又进步了不少。我接触WAN时间不长，目前有个类似的issue，不知在座各位能否给些意见。
-pnpn(雁南飞);
2005-10-26
{564}
(#2574653@0)
-
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)