[平常] 使用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上,根本就不会获得回应,所以前端就那里就会报出异常了