使用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上,根本就不會得到回應,因此前端就那裡就會報出異常了