案例背景

  1、故障描述

  某運營商Boss系統(tǒng)向服務(wù)器提交訂單,每天會有600個左右不成功的訂單,不成功的訂單需手工錄入,極大的影響工作效率;該情況已持續(xù)2-3個月;

  持續(xù)ping服務(wù)器和boss,未出現(xiàn)任何的丟包現(xiàn)象;

  應(yīng)用部門和應(yīng)用廠商檢查應(yīng)用程序和規(guī)則說一切正常;

  網(wǎng)管人員檢查網(wǎng)絡(luò)設(shè)備的性能,設(shè)置(MTU、MSS等)一切正常;

  管理人員在boss系統(tǒng)上抓取的同步數(shù)據(jù)包大于在PIX之前抓取的數(shù)據(jù)包,懷疑有丟包,但其它應(yīng)用和ping都正常,網(wǎng)絡(luò)丟包沒有說服力。

  2、網(wǎng)絡(luò)拓?fù)?/strong>


圖 1 網(wǎng)絡(luò)拓?fù)鋱D

  案例分析

  訂單提交不成功有兩種情況,一是服務(wù)端未收到boss的請求,二是服務(wù)端收到請求后未響應(yīng),由于用戶反映在boss和pix上抓包不一致,遂選擇在boss和pix上進(jìn)行抓包(將便攜式和回溯系統(tǒng)的時間同步)。

  分別提取回溯系統(tǒng)和便攜式上的數(shù)據(jù)包,進(jìn)行對比分析。

  在6503上捕獲到10.238.230.50和10.238.103.86的會話中,存在多個syn包無響應(yīng)的會話,從而證實確實存在訂單提成不成功的問題,而在PIX的入口并沒有捕獲到該會話,也就是說服務(wù)端并未收到boss的應(yīng)用請求,所以該現(xiàn)像與服務(wù)器端無關(guān)。

  如圖2:


圖 2 boss端TCP會話

  再來看在PIX前抓取的數(shù)據(jù):


圖 3 pix端TCP會話

  服務(wù)端沒有收到boss系統(tǒng)的請求包,是不是因為包被丟棄了?從拓?fù)渖峡?,?shù)據(jù)經(jīng)過的都是路由、交換設(shè)備,該數(shù)據(jù)包并未到達(dá)防火墻,且該鏈路上的其它應(yīng)用一切正常,網(wǎng)絡(luò)丟包沒有說服力。

  進(jìn)一步分析發(fā)現(xiàn)網(wǎng)絡(luò)中存在大量的FIN數(shù)據(jù)包,4452個數(shù)據(jù)包就有2498個包帶FIN標(biāo)記。

  過濾FIN數(shù)據(jù)包,發(fā)現(xiàn)絕大部份FIN數(shù)據(jù)包都是由boss服務(wù)器發(fā)出來的。

  再定位到TCP會話,通過時序圖查看會話中FIN包的情況,可以看到在一個會話中存在多個FIN位置1的數(shù)據(jù)包,而且沒收到對端的確認(rèn),這表示該會話沒有正常關(guān)閉。

  網(wǎng)絡(luò)中存在大量的在一個會話中發(fā)送大量FIN+ACK置1且window為0的數(shù)據(jù)包的情況(我們知道,在數(shù)據(jù)傳輸過程窗口為0表示不能接受任何數(shù)據(jù),至于關(guān)閉連接的window為0是否表示不能接收任何數(shù)據(jù)包有待驗證,但可以肯定是不正常的),且這些會話都與10.238.230.50有關(guān),這就表示在10.238.230.50上有很多未關(guān)閉的TCP會話,這是不正常的,需要進(jìn)一步分析原因。

  簡單的說,在通訊過程中,客戶端和服務(wù)端的TCP狀態(tài)遷移如下:

  客戶端TCP狀態(tài)遷移:

  CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

  服務(wù)器TCP狀態(tài)遷移:

  CLOSED->LISTEN->SYN

  收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED登錄10.238.230.50后臺,通過netstat查看主機(jī)的會話狀態(tài)。

  10.238.230.50上存在近5000個狀態(tài)為colse_wait的連接,會話處于Colse_wait表示該連接還沒有發(fā)FIN+ACK數(shù)據(jù)包。通常情況下,一個colse_wait會維持至少2個小時的時間,這樣,隨著時間的增加就會導(dǎo)致不能釋放的會話越來越多,直到系統(tǒng)沒有資源處理新的連接請求。

  分析結(jié)論

  10.238.230.50上存在大量未釋放的TCP連接,TCP是有隊列限制的,當(dāng)隊列已滿時,TCP將不會處理傳入的SYN,也不會發(fā)RST應(yīng)答,因為隊列已滿是由應(yīng)用程序和操作系統(tǒng)繁忙造成的(詳見TCP/IP卷1第18章),這也能解釋為什么服務(wù)端沒有收到boss的SYN包了,實際上這些數(shù)據(jù)包是boss系統(tǒng)收到的營業(yè)廳的SYN包,但由于boss系統(tǒng)隊列已滿或繁忙,則對其不做處理。

  10.238.230.50在與server關(guān)閉連接的過程中,window為0,可能是系統(tǒng)忙于處理colse_wait會話所致,從而導(dǎo)致boss與server的通訊異常。

  訂單提交不成功的原因是boss系統(tǒng)隊列已滿或繁忙,沒有資源對連接請求進(jìn)行處理,問題出在boss系統(tǒng)。

  分析建議

  檢查10.238.230.50與10.254.126.227和10.238.159.90的應(yīng)用通訊和應(yīng)用程序(因為colse_wait的會話大部分與這兩個IP有關(guān),而10.238.230.50 與server的連接狀態(tài)是正常的)。

  修改tcp_keepalive_*的相關(guān)參數(shù)。

責(zé)任編輯:admin