一、故障描述
某二級政府單位網絡，網絡管理人員經常接到用戶反映業務系統訪問比較慢，而此時網絡運行良好，並不存在網絡問題。基於這種情況，我們對網絡進行了數據流分析。網絡及部署情況大致如下：
如上圖，該網絡爲省級單位的應用服務器區，通過各下級單位通過廣域網訪問應用服務器，科來回溯分析系統部署在覈心交換的鏡像端口。
二、故障分析
2.1 分析方法簡介
通過流量、數據包、利用率、TCP Flags關鍵參數的圖形化顯示，快速瞭解網絡運行狀況；並通過網絡協議，物理端點、IP端點、物理會話、IP會話、TCP會話、UDP會話等多角度、深層次的對數據進行關聯挖掘，直觀地展現各網絡對象間的關聯關係和數據統計結果，從而全面展現網絡的工作狀態，是否存在風險和隱患等問題。
最後通過提取數據包(Packets)，通過解碼、會話分析等驗證結論過解碼驗證分析結果。數據包分析將按照以下兩種方法進行：
1. 數據包分析法
對捕獲下來的數據包進行統計分析，解碼分析（關鍵字段），專家分析。
2. 同步對比分析法
在不同的位置同時捕包，並採用數據包分析方法對數據進行對比分析的方法。
整個測試分析過程嚴格遵循以上流程，即“全局—>節點（會話）—>數據包”的分析方法。
2.2 詳細分析
本次分析仍然使用診斷-->定位地址-->定位數據包---〉分析這個傳統的分析思路。
1.下載數據包
根據用戶反饋的時間，定位到相關時間段，如下圖：
選中相關數據包，調用專家分析進行診斷
科來回溯分析系統提供了專家分析功能，可以智能的對網絡中的一些安全、性能、故障問題進行快速的定位。
2、診斷分析
專家分析系統提供了快捷的分析體系，可通過診斷三步曲，來實現對異常現象的快速定位、識別分析。
第一步，先找出網絡中存在的異常現象，本次發現了TCP慢應答報錯，關於TCP慢應答的相關解釋信息，可在診斷條目中雙擊該條目獲取，如下圖：
第二步，定位診斷髮生的地址，如上圖中詳細的提供了發生TCP慢應答的主機，並提供了各主機出現慢應答的次數，並支持對次數排名，如下圖：
其中服務器16.205出現的次數最多，達到了402個，接下來需要對該主機的TCP會話信息進行深入分析。
第三步，選中該主機，定位到診斷事件，快速調去相關數據包，如下圖：
通過如上三步曲，我們選中了25.157:1304<--->16.205:1521這個會話進行詳細分析，通過對TCP會話交互信息，確定應用慢具體慢在什麼地方。
如上圖，在TCP會話中顯示該會話條目，雙擊進入TCP流分析界面，如下圖：
選中的該會話持續了29.45s，傳輸了139.714K字節，共522個數據包。
打開TCP交易列表，對TCP會話包括的所有交易情況進行分析，如下圖：
選取請求3與響應3的的時間差值來簡單評估服務器的響應時間，我們可以看到在該服務器響應中，只用了0.815ms，可以說服務器性能良好。
而在後續的交易中，服務器響應時間也相對較快，其中下圖中的紅色標示部分爲服務器響應時間：
在上圖中，我們可以清晰的看到響應時間一般在0.3ms左右，最高也不過0.5ms。
繼續分析該會話的交易信息，發現在序列號193、194、195這三個數據包之間出現了比較大地超時，如下圖：
而在序列號爲193的數據包解碼中，看到ORA-01403: no data found字樣。
結合上下文，該no data found響應，是由於客戶端進行如下操作時造成：
select count ( *) from xxx*ba where xx* =:1 and xxbz ='Y' and q_q <= :2 and ( xxx) ，（一條select語句）如下圖所示：
由於這樣一個操作導致了將近2.5s的時間停頓，如下圖：
繼續分析該會話，又在序列號230、231、232這三個數據包之間出現了一個長達8.9s的傳輸停頓，如下圖：
同樣這個停頓也是由於客戶端收到了一個no data found的報錯，如下圖：
而本次客戶端上一個操作爲：Select Max （xx） From xx Where x =:1 and xx_xx =:2 and
接下來在序列號爲244、245、246這三個數據包之間又出現了10.4s的時間停頓，如下圖：
同樣這個停頓了也伴隨了no data found，而這次客戶端的操作爲：Select MBFS from xx where xx =:1，
綜合本次會話中的3次no data found停頓，共造成了2.5+8.9+10.4=21.8s的延時，而整個會話總共爲29.4s。也就是在這個29.4s的會話中只有7.6s的時間用於傳輸有效數據，其中21.8s的時間用於時間停頓，也就造成了該應用的用戶體驗較差。
三、結論
業務訪問慢問題，主要由於客戶端的查詢錯誤導致長時間停頓造成。其中在截取的29.4s會話中，只有不足三分之一的時間用於有效的請求、響應及數據傳輸，大量時間用於停頓。
關於造成該停頓的原因可能跟該應用的客戶端程序設計有關，需進一步跟相關應用開發人員協商，準確定位問題原因。
此次分析的入手點是診斷信息定位到的TCP慢反應，需註明此信息與最終的診斷原因並無明顯的必然聯繫，希望大家不要誤解。而之所以從此特徵能成功找到故障根源，跟網絡中該業務數據流較大，且更多會話中都存在該查詢等錯誤有關。