[日常] 使用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上,根本就不会得到回应,因此前端就那里就会报出异常了