·某運營商Boss系統向服務器提交訂單，每天會有600個左右不成功的訂單，不成功的訂單需手工錄入，極大的影響工作效率；該情況已持續2-3個月；

·持續ping服務器和boss，未出現任何的丟包現象；

·應用部門和應用廠商檢查應用程序和規則說一切正常；

·網管人員檢查網絡設備的性能，設置（MTU、MSS等）一切正常；

·管理人員在boss系統上抓取的同步數據包大于在PIX之前抓取的數據包，懷疑有丟包，但其它應用和ping都正常，網絡丟包沒有說服力。

 

 

圖 1 網絡拓撲圖

 

 

訂單提交不成功有兩種情況，一是服務端未收到boss的請求，二是服務端收到請求后未響應，由于用戶反映在boss和pix上抓包不一致，遂選擇在boss和pix上進行抓包（將便攜式和回溯系統的時間同步）。

 

分別提取回溯系統和便攜式上的數據包，進行對比分析。

 

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

 

如圖2：

 

圖 2 boss端TCP會話

 

再來看在PIX前抓取的數據：

 

圖 3 pix端TCP會話

 

服務端沒有收到boss系統的請求包，是不是因為包被丟棄了？從拓撲上看，數據經過的都是路由、交換設備，該數據包并未到達防火墻，且該鏈路上的其它應用一切正常，網絡丟包沒有說服力。

 

進一步分析發現網絡中存在大量的FIN數據包，4452個數據包就有2498個包帶FIN標記。

 

過濾FIN數據包，發現絕大部份FIN數據包都是由boss服務器發出來的。

 

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

 

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

 

簡單的說，在通訊過程中，客戶端和服務端的TCP狀態遷移如下：

 

·客戶端TCP狀態遷移：

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

·

服務器TCP狀態遷移：

CLOSED->LISTEN->SYN

 

·收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED登錄10.238.230.50后臺，通過netstat查看主機的會話狀態。

 

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

 

 

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

 

10.238.230.50在與server關閉連接的過程中，window為0，可能是系統忙于處理colse_wait會話所致，從而導致boss與server的通訊異常。

 

訂單提交不成功的原因是boss系統隊列已滿或繁忙，沒有資源對連接請求進行處理，問題出在boss系統。

 

檢查10.238.230.50與10.254.126.227和10.238.159.90的應用通訊和應用程序（因為colse_wait的會話大部分與這兩個IP有關，而10.238.230.50 與server的連接狀態是正常的）。

 

修改tcp_keepalive_*的相關參數。