不像重大網絡故障總讓人猝不及防，不重要的故障總是會發生在風和日麗的日子，但刺類似故障網絡工程師不可避免，拿來與大家分享。

某天接到公司新上業務系統SA的反饋，該應用基於HTTP打開主界面反應遲緩，疑似網絡質量有問題，希望排查鏈路。由於其他應用都沒有出現類似問題，大概判斷是業務本什麼問題。但是推斷不能TrobleShooting的絕對依據，實實在在的數據更有說服力。

該應用是基於Web登錄，打開頁面首，先進入sso的用戶認證。認證通過後，會返回包含各功能模塊的主頁面；

由於所有Client端訪問該應用地址都有類似現象，顧在本機直接抓包，用以分析網頁緩慢的問題點，本次使用wireshark分析：

1、TCP三次握手

TCP三次握手

通過時間戳之間的絕對時間可以清楚發現交互的時間非常短，可以斷定，網絡質量沒有問題；

2、用戶認證登錄：

Client-Server用戶認證交互

378行Client顯示server端的登錄信息回顯，並使用瀏覽器的cookie來驗證登錄信息，可見上圖紅框；

以上抓包內容與實際使用中的狀況完全一致：打開網頁-跳轉認證-輸入用戶名密碼，相應速度都比較快速。接下來就是最重要的：Server認證完用戶名密碼後Client獲取的index主頁相應時間：

3、回顯Web主頁：

Index請求及響應

521行Cliet請求主頁：使用Seq 8505 + Length長度947，因此522行Server Ack確認9394數據長度0，時間戳間的絕對時間非常短，網絡交互沒有任何問題，如下圖：

Server確認主頁請求

但是在522-564間，也就是Server確認Client的index請求，並將主頁信息返回給Client端用了將近10s（30.269-20.4808），並且此過程不涉及Client-Server的網絡交互，完全是Server在Ack+len0後，處理返回的數據，問題點完全在Server處理數據的能力：如下圖：

Server返回主頁內容

儘管在565行TCP使用了PSH置位（簡單說一下TCP的PSH置位TCP的發送方在數據包過大時會使用分片技術，接受方收到數據後會緩存起來，直到整個數據傳完再上傳給應用層處理，而PSH位可以讓接收方收到該數據片後，立即上交應用層）但是Server本身處理過程過久，無關Client如果處理收到的數據。

Flags：PSH

根據以上對數據包的分析：

1 無關網絡問題；

2 Server處理該應用能力不足；

3 該應用對主頁的設計不足；

甩鍋是一種技術，但是找到根本原因，解決問題才是關鍵。通過數據包的底層分析，不但有理有據更能深刻的理解TCP/IP各層協議。歡迎大家討論交流。