一 問題描述：
通(tong)過(guo)25G交換機(ji)下服(fu)務器(qi)向10G交換機(ji)下服(fu)務器(qi)，通(tong)過(guo)iperf3壓測帶寬只有1/2G。另外，通(tong)過(guo)測試服(fu)務器(qi)多次驗證(zheng)，不(bu)是每(mei)次測試都上不(bu)去，多數情況還(huan)是能打到接近10G的，只有碰到中間網絡(luo)丟包嚴(yan)重時(shi)才(cai)這樣(yang)。
二 問題分析
通過多次測試發(fa)現，當網絡(luo)環境不穩定時，如上圖所示，丟包比較嚴重，需要較長時間才可以把擁塞窗(chuang)口調整(zheng)下來。懷疑擁塞控制算法cubic啟(qi)動過程異(yi)常，啟(qi)動參數異(yi)常。
通過stap跟蹤內核cwnd變化情況(kuang)(kuang)，發現異常(chang)(chang)和(he)正常(chang)(chang)情況(kuang)(kuang)下變化不大，可以確定，iperf顯示的(de)cwnd與(yu)內核中計(ji)算的(de)不是(shi)一個(ge)概念(nian)，iperf顯示應該(gai)是(shi)包含了重傳數據(ju)包后自己計(ji)算的(de)。
異常情況(kuang)下cwdn變(bian)化
; 正(zheng)常(chang)情(qing)況下cwnd變化
對比(bi)上(shang)(shang)述兩幅圖，分(fen)別為(wei)丟包嚴重和丟包很(hen)少(shao)情況，cwnd變(bian)化情況，其中(zhong)圖右側為(wei)iperf統計信(xin)息，相差很(hen)大；而左側為(wei)probe跟(gen)蹤的(de)(de)(de)內(nei)核中(zhong)對應sock的(de)(de)(de)cwnd變(bian)化情況，可以看(kan)到兩幅圖上(shang)(shang)，內(nei)核中(zhong)cwnd是一(yi)致的(de)(de)(de)，都是從10開始(shi)的(de)(de)(de)慢啟(qi)動(dong)過程。
另外，對比下圖，為壓測過程中，帶寬(kuan)帶寬(kuan)上(shang)不去時(shi)，內(nei)核(he)統計(ji)(ji)到的tcpRetrans統計(ji)(ji)（重傳包(bao)(bao)統計(ji)(ji)）信息，與(yu)ipef統計(ji)(ji)是可以(yi)對應起(qi)來，而帶寬(kuan)正常時(shi)該項統計(ji)(ji)計(ji)(ji)數為零(ling)（不顯示），可以(yi)確認是有(you)用網(wang)絡丟(diu)包(bao)(bao)較嚴重，恢(hui)復不及時(shi)導(dao)致。
三 問題結論
對比其他服務(wu)器發現，server端(duan)沒(mei)有啟(qi)動sack功能，開啟(qi)后對比結果如下：
上圖為(wei)通過iperf3連續(xu)打壓52次(ci)，帶(dai)寬平均值對比(bi)(bi)。其中，左邊為(wei)tcp_sack == 0， 可以明(ming)顯看到10次(ci)帶(dai)寬只(zhi)有2-3G左右(you)，且重傳(chuan)數據包非(fei)常多（中間列數字(zi)）；對比(bi)(bi)右(you)邊tcp_sack==1 時(shi)的情(qing)況，可明(ming)顯看到帶(dai)寬很(hen)穩(wen)定，都是再9.8G以上，且重傳(chuan)報文很(hen)少。
