[平常] 使用TCPDUMP和Ethereal抓包分析HTTP請求中的異常狀況

在測試功能的過程當中,出現這樣一種現象.前端js發起ajax請求後,在瀏覽器的審查元素網絡狀態中能夠看到status爲pending,等15秒之後js會把當前超時的請求取消掉,變成了紅色的cancel.針對這一現象,我在本地Windows電腦和遠程Linux測試機進行了網絡抓包分析.

 

因爲出現的概率很隨機,可是出現頻率挺高,我先在linux測試機中使用tcpdump進行的抓包分析,能夠看到正常的請求是能夠看獲得數據的,異常的請求根本就沒有鏈接數據,所以判定異常的數據根本就沒有請求到我當前的機器.而後在本地windows電腦中使用Ethereal進行抓包分析,才發現了緣由.

我本地有進行域名綁定測試機host,host所使用的ip是內網IP,是這種形式172.16.228.187,可是在抓到的數據包中變成了我以前綁定的host是個公網IP,因爲安全緣由,公網IP已經被禁止直接訪問了,才所以出現的異常.我猜想是在進行域名DNS解析的時候,偶爾會把我以前的緩存的host返回來,才形成的這種現象

解決這一問題的方式是清除瀏覽器的全部緩存數據,清理本身的電腦的dns緩存,使用ipconfig/flushdns

 

那麼下面這個是我正常狀況下的tcpdump抓包結果,能夠解釋下各條記錄的意義
tcpdump -i eth1 port 80
使用tcpdump必定要用-i參數指定下監聽哪一個網卡,可使用ifconfig查看當前ip的網卡,有的是eth0,有的是eth1,這樣能夠抓取到這個網卡上的數據.還要過濾一下端口號,通常就只看80端口的數據就能夠了

TCP三次握手的過程,能夠在下面的請求中看獲得.
第一次握手:10.222.128.166.60110 > 172.16.228.187.http 這裏能夠知道客戶端IP是10.222.128.166,請求來自於60110端口,目的IP是172.16.228.187的80端口.這裏的Flag是頗有意義的,Flags [S]表示的是
客戶端的SYN請求,seq序列號是1594115281.
第二次握手:服務端返回給客戶端Flags [S.],seq序列號4134215995, ack確認號是1594115282,ack是客戶端seq的+1值
第三次握手:客戶端給服務端 Flags [.],.表示標誌位均爲0 , ack是1

15:40:19.988481 IP 10.222.128.166.60110 > 172.16.228.187.http: Flags [S], seq 1594115281, win 8192, options [mss 1300,nop,wscale 8,nop,nop,sackOK], length 0
15:40:19.988528 IP 172.16.228.187.http > 10.222.128.166.60110: Flags [S.], seq 4134215995, ack 1594115282, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
15:40:19.995864 IP 10.222.128.166.60110 > 172.16.228.187.http: Flags [.], ack 1, win 260, length 0

下面就是實際的數據傳輸過程了,能夠看到tcp的分段傳輸,客戶端到服務端的數據seq 1:1180 ,長度1179,下一段是seq 1180:1221,長度41.
也能夠看到應答機制,服務端給客戶端的ack 1180,ack 1221.

15:40:19.996031 IP 10.222.128.166.60110 > 172.16.228.187.http: Flags [P.], seq 1:1180, ack 1, win 260, length 1179
15:40:19.996067 IP 172.16.228.187.http > 10.222.128.166.60110: Flags [.], ack 1180, win 137, length 0
15:40:19.997779 IP 10.222.128.166.60110 > 172.16.228.187.http: Flags [P.], seq 1180:1221, ack 1, win 260, length 41
15:40:19.997800 IP 172.16.228.187.http > 10.222.128.166.60110: Flags [.], ack 1221, win 137, length 0
15:40:20.113390 IP 172.16.228.187.http > 10.222.128.166.60110: Flags [P.], seq 1:953, ack 1221, win 137, length 952
15:40:20.114305 IP 172.16.228.187.http > 10.222.128.166.60110: Flags [F.], seq 953, ack 1221, win 137, length 0
15:40:20.122015 IP 10.222.128.166.60110 > 172.16.228.187.http: Flags [.], ack 954, win 256, length 0
15:40:20.122044 IP 10.222.128.166.60110 > 172.16.228.187.http: Flags [F.], seq 1221, ack 954, win 256, length 0
15:40:20.122057 IP 172.16.228.187.http > 10.222.128.166.60110: Flags [.], ack 1222, win 137, length 0

六個標誌位
同步SYN，在鏈接創建時用來同步序號。當SYN=1，ACK=0，代表是鏈接請求報文，若贊成鏈接，則響應報文中應該使SYN=1，ACK=1；
確認ACK，僅當ACK=1時，確認號字段纔有效。TCP規定，在鏈接創建後全部報文的傳輸都必須把ACK置1；
終止FIN，用來釋放鏈接。當FIN=1，代表此報文的發送方的數據已經發送完畢，而且要求釋放；
緊急URG，當URG=1，代表緊急指針字段有效。告訴系統此報文段中有緊急數據；
推送PSH，當兩個應用進程進行交互式通訊時，有時在一端的應用進程但願在鍵入一個命令後當即就能收到對方的響應，這時候就將PSH=1；
復位RST，當RST=1，代表TCP鏈接中出現嚴重差錯，必須釋放鏈接，而後再從新創建鏈接；

windows電腦使用Ethereal也是須要先設置捕獲的網卡,選對本身的iP網卡,可使用ipconfig來查看

這些請求跑到了以前設置的公網IP上,根本就不會獲得迴應,所以前端就那裏就會報出異常了