問題描述（故障現象）

某運行商反饋一條銀行4M以太網專線存在業務卡頓現象，用戶懷疑專線業務速率達不到4M，造成業務卡頓。用戶現場對這條業務進行測速：

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

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

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

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

這種方法就會出現上下行速率不一致，某一個方向測速達不到設置的速率。

原因分析

根據測試方法出現的問題進行進一步分析：

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

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

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

解決方案

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