問題描述（故障現(xiàn)象）

某運行商反饋一條銀行4M以太網(wǎng)專線存在業(yè)務(wù)卡頓現(xiàn)象，用戶懷疑專線業(yè)務(wù)速率達不到4M，造成業(yè)務(wù)卡頓。用戶現(xiàn)場對這條業(yè)務(wù)進行測速：

測試方法：將這條4M專線兩端中興ZXMP S200端口上分別接電腦A和電腦B，使用飛秋軟件傳輸文件測試。

（1）電腦A從電腦B下載文件，下載速率能達到4M;

（2）電腦A往電腦B上傳文件，上傳速率能達到4M；

（3）同時電腦A從電腦B下載文件，電腦A往電腦B上傳文件，測試結(jié)果只能保證下載速率能達到4M，上傳速率只有1M多。停止下載，上傳傳速率能恢復(fù)到4M速率。

這種方法就會出現(xiàn)上下行速率不一致，某一個方向測速達不到設(shè)置的速率。

原因分析

根據(jù)測試方法出現(xiàn)的問題進行進一步分析：

根據(jù)MSTP原理，A至B站點開通一條4M的電話，因為配置是雙向的業(yè)務(wù)，A至B的速率有4M，同樣B至A的速率也有4M。為什么會出現(xiàn)測試方法二上下行速率不一致的情況？

這就需要對使用的飛秋軟件傳輸文件原理進行分析，飛秋軟件（或者其他FTP軟件）傳輸文件都是采用TCP協(xié)議進行傳輸。TCP是一個面向連接的協(xié)議，無論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間建立一條連接。為了建立或初始化一個連接，兩個TCP通信者必須同步各自的初始序號。正是IP報文窗口機制導(dǎo)致測試方法上下行速率不一致的問題，如果是UDP報文就沒有這個問題。IP報文是建立在需要ACK的機制上的，當(dāng)單向傳輸時，方向ACK報文很?。?4字節(jié)），可以在窗口發(fā)送完成之前回送ACK。當(dāng)反向也有報文傳輸時，ACK報文需要排隊，或者和數(shù)據(jù)報文合在一起傳輸，那么就可能會出現(xiàn)發(fā)送窗口全部用完，但是ACK報文沒有收到，需要等待的情況，造成帶寬減小的感覺；真正的原因應(yīng)該是帶寬、包長和IP報文間的平衡關(guān)系。

所以使用這種測試方法測試時，因為電腦A正往電腦B傳送報文，且速率已經(jīng)達到4M，此時電腦B往電腦A傳送報文，ACK報文因為A至B的通道被占用，導(dǎo)致ACK出現(xiàn)等待情況，造成帶寬減小的感覺。

解決方案

采用SDH儀表測試，測試儀表報文采用UDP報文。儀表測試出來的速率為兩端網(wǎng)元之間真實雙向速率。A至B 或者 B至A兩個單向速率其中一個達不到設(shè)定的速率，就會出現(xiàn)丟包情況。采用SDH儀表測試才能真正反映實際傳輸速率。