背景：一個短信服務，維護一個測試樁屬於服務端，正常客戶端發來了一個請求，服務端應該立即響應這個請求，但是實際是等待了2分鍾，嘗試 服務端第二次在發送重復請求，客戶端就能馬上收到響應，排查原因 原因是：由於服務端頭部長度發錯了，協議中提現指明需要30的字節長度，服務端給的確是39，導致第一次不成功，第二次在發送就成功了 修正服務端給定的客戶端的字節數長度，請求與響應正常。通過wiresharek網絡抓包分析解包查看錯誤
分析過程：
1.過濾數據包
因為我知道客戶端連接服務端和服務端向客戶端發送內容，都是通過端口7890進行過濾，所以我們通過7890就能進行過濾了，比如：
tcp.srcport ==7890 or tcp.dstport==7890
注：服務端端口為 7890 客戶端端口為50280
下圖就顯示了過濾后的內容，不過濾會有很多不屬於本次包的數據
圖1
2.分析包
三次握手包，在轉載文章中有介紹，后續還會講述三次握手和四次揮手， 在 其他篇中介紹，現在我們講解圖1，32----40序列號的數據包,這一塊就是客戶端傳輸內容到服務端，服務端返回內容給客戶端，數據交互的過程
32號包： 客戶端請求服務端，且包的長度為39，src port:資源端口 Dst port：目標端口，能確認這個包就是從客戶端請求到服務端（7890）
35號數據包：客戶端回應服務端請求，且長度為30，回應的包的協議是TCP，已經能看出一些問題
37號包：客戶端回應了，也是使用的TCP協議，因為應用回應的包是CMPP類型
38號包：服務端在次發送請求包，cmpp協議
39號包，客戶端收到了請求，回應服務端使用的cmpp協議
通過上述查看包的協議，其實我們已經大體能定位出問題了
1.在35號包發送了請求，而服務端並沒有使用cmpp協議進行回應，而是使用了最底層的TCP協議回應，說明這里與客戶端協議上有些問題，不能使用cmpp協議進行傳輸，而是在第二次服務端在次發送請求時，有才發送了cmpp協議請求 ，所以問題很明顯直接定位35號包，查看35號數據包的內容，點擊35號包，選擇追蹤TCP流
按照我們的傳輸協議，前面4個字段就是“0x00, 0x00, 0x00, 0x27” 表示傳輸的字節長度，客戶端長度正常，換算服務端就不正確，服務端長度0x27=39,明明長度是30（圖片上35號包中的len=30就是表示長度是30）為什么會是39
在代碼中查看把連接的長度寫成39了，改為30發送就正確了
思考1：為什么服務端在發次請求，客戶端能接收到數據，
猜測是這樣：第一次需要30的字節長度，但是給了39，數據部分被截取了，放到緩存中，第二次在請求一個39，數據有是一部分，然后就組合成了一個完整包，以cmpp協議傳輸 給了客戶端了
思考2：第一次服務端回應請求，為什么是使用的TCP協議
猜測：cmpp底層還是使用的TCP協議， 當服務端或者客戶端沒有按照規定的cmpp協議傳輸，默認還是會顯示發送的過程，因為服務端確實發送了，但是在應用層的客戶端中沒有收到，所以使用了TCP協議，進行發送包，客戶端在以TCP協議回應我，當我第二次能夠用CMPP協議傳輸了，也就收到了客戶端的cmpp協議的包，如果服務端沒有進行回應，就可能出現丟包，那么客戶端可能還會在重傳，所以其實服務第一次都是有傳送，只是沒有使用cmpp協議