WireShark是一个非常准确和稳定的tcp抓包工具,但看其40多m的安装包就可以想象其功能的强大,借助其功能强大的表达式筛选器,可以迅速的筛选出来我们所需要报文和记录,最近我就通过WireShark推断网络性能问题的故障点,收获颇丰。
最近客户提出app端load慢,尤其是在网络不好的地方,得好几分钟才能加载出数据,于是打算用抓包软件WireShark 看看http请求就用用了多长时间才传回来的,首先我用火狐浏览器访问了一下一个GET接口,监听结果如下
(我本机的端口是61281,但是抓包软件又抓出一个61282的端口,应该不是我的火狐浏览器的结果,下文忽略61282端口的消息)
从抓包结果来看,本次HTTP请求大体分为以下步骤
三次握手-->发送GET请求--->收到服务器返回json--->获取浏览器favicon.ico--->KEEP-ALIVE--->四次挥手
在介绍每个步骤的返回值之前,先介绍一下WireShark这个软件的简单用法
首先是我的过滤器设置:ip.addr == 122.248.245.191 含义是仅保留源ip地址和目标主机ip地址至少有一个为122.248.245.191,也就是项目服务器的地址,这样就可以筛选出所有的本机和122.248.245.191的收发报文
如果更改过滤器描述,比如ip.dst==122.248.245.191 andip.src==192.168.1.109(192.168.1.109是本机的ip)就可以查看所有从本机发往服务器的报文,如果把两个ip对换一下,就可以查看所有服务器发给本机的报文
如果写成ip.addr == 122.248.245.191 and tcp.srcport==61281(其中61281是本机的对外端口)就是查找所有源ip的端口为61281的报文,换句话说就是只显示本机发给服务器的报文,不同的条件可以用and连接,灵活处理。
再来说一下报文里面的基本信息
(一) 、ACK,FIN,PSH这三个是TCP请求的标志,本身并不是一个数,而是和另外五个这样的标志组成了一个长度为1字节(8位)的标志,用于标示出当前请求报文的类型,可以在WireShark 底下的FLAGS目录下查看,如果某一位设置为1则为Set,置0为Not set,一般我们只看置1的位,其中Acknowledgement = ACK,FIN = Fin,Push = Psh
(二)、seq,ack的含义,其中seq是Sequence number的简写,即序列号。Ack是 Acknowledge number的简写,即应答码,用这两个数字可以观察相邻的几条报文的顺序。
好了现在我们可以开始按照步骤逐一分析了
第一阶段:三次握手
(本机ip是192.168.1.109:61281,服务器ip是:122.248.245.191:7033)
首先来回顾一下三次握手的过程
下面这幅图标示出了三次握手的报文这里面的第三条因为端口不是火狐的端口号,所以是另一次三次握手
从这里面我们可以看出完全符合标准TCP三次握手的流程,第二次握手的ack为第一次的seq+1
三次握手耗时102.605103-102.354383 = 0.2572秒,看起来很快,说明三次握手上没有浪费很多时间
第二阶段:发送GET请求并接收返回json
从这里可以看出,服务器发送三波数据,每个报文的长度为都为1514,然后返回了一个200 OK来结束发送,其中在第二次发送完毕之后客户端发送了一个数据接收确认报文,在200 OK之后,客户端有发送了一个数据接收确认报文
从这里可以看出整个服务器向客户端发送数据的耗时:103.862232-102.858066 = 1.004166
那么从三次握手成功到成功客户端成功收到json的时间是103.862232-102.354383 = 1.507849
那么我们可以算出来服务器的响应时间是1.507849-1.004166(数据回传)-0.2572(三次握手)= 0.246483秒
可以看出,无论是网络还是服务器,都是相当快。
本部分的几个报文都已经粘贴在本文的最底部,有兴趣可以看看
第三阶段:请求favicon.ico
从图中可以看出,一共请求了两次图片,每次请求都没有成功(因为服务器根本就没有这个图)每次请求大约1秒左右的时间,其中第一次105.605757-104.393820 = 1.211937,第二次106.025472-105.608105= 0.417367,第二次比第一次时间用的短好多。
第四阶段:KEEP-ALIVE
这个KEEP-ALIVE的请求是由火狐浏览器发出的,我估计目的在于减少三次握手建立和销毁连接的开销,并且每隔10秒左右就发出一个KEEP-ALIVE请求,总共发送了6次,服务器应答了5次,总共保活的时间是158.373788-115.817623=42.556165秒,看来火狐浏览器对http优化的很好,同时我们也知道了用火狐在大约1分钟内是不会重建http连接的
第五阶段:四次挥手
首先我们来回顾一下四次挥手的过程下面我们来看一下四次挥手的报文
从这里抓取的报文可以看出,这里和标准的TCP四次挥手是一致的,而且从抓包结果来看,这次挥手是由服务器先发起的,估计是服务器受不了客户端没完没了的保活请求,要释放一下连接。从数据来看,整个四次挥手耗时,166.387505-166.162996 = 0.224509
ok了从这里可以看出,整个http请求过程一气呵成,速度极快,几乎用了不到两秒就完成了全部数据的请求,至于UI绘制以毫秒计数,所以可以看出在代码层面无论服务器还是客户端都没什么性能上的问题,不过刚刚的测试是使用电脑浏览器通过宽带网络进行http请求,没有考虑到超时重传和丢包的情况,也没有模拟手机在wifi或者无线网络下的情况,下文将着重考虑网络条件不好的时候丢包情况。
使用WireShark抓包分析Android网络请求时间(二)
附:http回传数据的几条报文
No. Time Source Destination Protocol Length Info 3632 102.858066 122.248.245.191 192.168.1.109 TCP 60 7033 → 61281 [ACK] Seq=1 Ack=413 Win=19200 Len=0 Frame 3632: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 Ethernet II, Src: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2), Dst: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, Src: 122.248.245.191, Dst: 192.168.1.109 Transmission Control Protocol, Src Port: 7033 (7033), Dst Port: 61281 (61281), Seq: 1, Ack: 413, Len: 0 Source Port: 7033 Destination Port: 61281 [Stream index: 29] [TCP Segment Len: 0] Sequence number: 1 (relative sequence number) Acknowledgment number: 413 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 75 [Calculated window size: 19200] [Window size scaling factor: 256] Checksum: 0x6f29 [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] No. Time Source Destination Protocol Length Info 3675 103.861417 122.248.245.191 192.168.1.109 TCP 1514 [TCP segment of a reassembled PDU] Frame 3675: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0 Ethernet II, Src: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2), Dst: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, Src: 122.248.245.191, Dst: 192.168.1.109 Transmission Control Protocol, Src Port: 7033 (7033), Dst Port: 61281 (61281), Seq: 1, Ack: 413, Len: 1460 Source Port: 7033 Destination Port: 61281 [Stream index: 29] [TCP Segment Len: 1460] Sequence number: 1 (relative sequence number) [Next sequence number: 1461 (relative sequence number)] Acknowledgment number: 413 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 75 [Calculated window size: 19200] [Window size scaling factor: 256] Checksum: 0xdba5 [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] TCP segment data (1460 bytes) No. Time Source Destination Protocol Length Info 3676 103.861630 122.248.245.191 192.168.1.109 TCP 1514 [TCP segment of a reassembled PDU] Frame 3676: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0 Ethernet II, Src: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2), Dst: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, Src: 122.248.245.191, Dst: 192.168.1.109 Transmission Control Protocol, Src Port: 7033 (7033), Dst Port: 61281 (61281), Seq: 1461, Ack: 413, Len: 1460 Source Port: 7033 Destination Port: 61281 [Stream index: 29] [TCP Segment Len: 1460] Sequence number: 1461 (relative sequence number) [Next sequence number: 2921 (relative sequence number)] Acknowledgment number: 413 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 75 [Calculated window size: 19200] [Window size scaling factor: 256] Checksum: 0xb2fa [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] [Reassembled PDU in frame: 3679] TCP segment data (1460 bytes) No. Time Source Destination Protocol Length Info 3677 103.861655 192.168.1.109 122.248.245.191 TCP 54 61281 → 7033 [ACK] Seq=413 Ack=2921 Win=65700 Len=0 Frame 3677: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface 0 Ethernet II, Src: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c), Dst: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2) Internet Protocol Version 4, Src: 192.168.1.109, Dst: 122.248.245.191 Transmission Control Protocol, Src Port: 61281 (61281), Dst Port: 7033 (7033), Seq: 413, Ack: 2921, Len: 0 Source Port: 61281 Destination Port: 7033 [Stream index: 29] [TCP Segment Len: 0] Sequence number: 413 (relative sequence number) Acknowledgment number: 2921 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 16425 [Calculated window size: 65700] [Window size scaling factor: 4] Checksum: 0x23e3 [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] No. Time Source Destination Protocol Length Info 3678 103.861773 122.248.245.191 192.168.1.109 TCP 1514 [TCP segment of a reassembled PDU] Frame 3678: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0 Ethernet II, Src: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2), Dst: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, Src: 122.248.245.191, Dst: 192.168.1.109 Transmission Control Protocol, Src Port: 7033 (7033), Dst Port: 61281 (61281), Seq: 2921, Ack: 413, Len: 1460 Source Port: 7033 Destination Port: 61281 [Stream index: 29] [TCP Segment Len: 1460] Sequence number: 2921 (relative sequence number) [Next sequence number: 4381 (relative sequence number)] Acknowledgment number: 413 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 75 [Calculated window size: 19200] [Window size scaling factor: 256] Checksum: 0x6d9d [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] [Reassembled PDU in frame: 3679] TCP segment data (1460 bytes) No. Time Source Destination Protocol Length Info 3679 103.862209 122.248.245.191 192.168.1.109 HTTP 288 HTTP/1.1 200 OK (application/json) Frame 3679: 288 bytes on wire (2304 bits), 288 bytes captured (2304 bits) on interface 0 Ethernet II, Src: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2), Dst: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, Src: 122.248.245.191, Dst: 192.168.1.109 Transmission Control Protocol, Src Port: 7033 (7033), Dst Port: 61281 (61281), Seq: 4381, Ack: 413, Len: 234 Source Port: 7033 Destination Port: 61281 [Stream index: 29] [TCP Segment Len: 234] Sequence number: 4381 (relative sequence number) [Next sequence number: 4615 (relative sequence number)] Acknowledgment number: 413 (relative ack number) Header Length: 20 bytes Flags: 0x018 (PSH, ACK) Window size value: 75 [Calculated window size: 19200] [Window size scaling factor: 256] Checksum: 0x46b6 [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] TCP segment data (234 bytes) [4 Reassembled TCP Segments (4614 bytes): #3675(1460), #3676(1460), #3678(1460), #3679(234)] Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Content-Encoding: gzip\r\n Content-Type: application/json;charset=UTF-8\r\n Date: Wed, 11 May 2016 05:37:22 GMT\r\n Server: nginx\r\n Vary: Accept-Encoding\r\n Content-Length: 4404\r\n Connection: keep-alive\r\n \r\n [HTTP response 1/3] [Time since request: 1.256983000 seconds] [Request in frame: 3615] [Next request in frame: 3705] [Next response in frame: 3779] Content-encoded entity body (gzip): 4404 bytes -> 17029 bytes JavaScript Object Notation: application/json No. Time Source Destination Protocol Length Info 3680 103.862232 192.168.1.109 122.248.245.191 TCP 54 61281 → 7033 [ACK] Seq=413 Ack=4615 Win=65700 Len=0 Frame 3680: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface 0 Ethernet II, Src: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c), Dst: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2) Internet Protocol Version 4, Src: 192.168.1.109, Dst: 122.248.245.191 Transmission Control Protocol, Src Port: 61281 (61281), Dst Port: 7033 (7033), Seq: 413, Ack: 4615, Len: 0 Source Port: 61281 Destination Port: 7033 [Stream index: 29] [TCP Segment Len: 0] Sequence number: 413 (relative sequence number) Acknowledgment number: 4615 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 16425 [Calculated window size: 65700] [Window size scaling factor: 4] Checksum: 0x1d45 [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis]