發生場景:A系統發送Http請求調用B系統提供的接口;
發生問題:A系統報錯,提示 invalid http response 錯誤信息;
問題分析:根據翻譯,無效的Http響應,初步判斷是服務提供方出現的問題,也就是回複的内容不對。那麼具體怎麼定位呢。需要慢慢排查。如果問題始終難以定位,建議安裝Wireshark抓包軟件,進行抓包分析。本案例截圖如下:
編輯
我們按照第一列序号順序梳理:
第15~19行是TCP握手過程;
第20行是上送請求報文;
第21行是确認ACK報文;
第22~24是本次發生錯誤的重點,continuation是代表打包分片的意思,也就是回複的報文太大拆成了報文塊,但是本次直接回複了這個塊是有問題的。這種報文塊的出現應該在正常回複之後,也就是說,即使有分包也應該在截圖的第29行之後;但是本次報文回複分析不應該被分包;随後對分包裡面的内容進行了分析,最終定位了是服務器偶發的一個問題;是服務器存在偶發的bug導緻将其他I/O流的部分報文段發送給了客戶端。
第26行因為收到了錯誤的回複報文,客戶端無法解析所以發送FIN報文,通知服務器要進行關閉TCP;
第29行發送了關閉請求報文後,客戶端又收到了服務器的正常回複報文;
第30~40行因為發送了關閉請求,有收到其他回複報文,所以客戶端嘗試多次發送了RST報文;
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!