Analyze Android Network request time using Wireshark capture packet

Wireshark is a very accurate and stable TCP capture tool, but look at its more than 40 m of the installation package can imagine its powerful, with its powerful expression filter, can quickly filter out the messages and records we need, Recently, I have been using Wireshark to infer the fault point of network performance problem, harvest quite abundant.

Recently the customer put forward the app side load slow, especially in the network bad Place, it takes several minutes to load the data, so it is intended to use the capture software Wireshark to see how long the HTTP request is used to send back, first I use the Firefox browser to access a get interface, the monitoring results are as follows

(my local port is 61281, but the capture software also grabbed a 61282 port, should not be the result of my Firefox browser, the following ignore 61282 port messages)

From the capture results, this HTTP request is broadly divided into the following steps

Three-time handshake-Send GET request---> Receive server return JSON---> Get browser favicon.ico--->keep-alive---> Four waves

Before introducing the return value of each step, let's introduce the simple usage of the Wireshark software.

First of all, my filter settings: ip.addr = = 122.248.245.191 The implication is that only the source IP address and the destination host IP address have at least one of 122.248.245.191, which is the address of the Project Server, so that all native and 122.248.245.191 messages can be filtered out.

If you change the filter description, such as ip.dst==122.248.245.191 andip.src==192.168.1.109(192.168.1.109 Is the IP of the machine can see all the messages from the local to the server, if you swap two IP, you can view all the server sent to the local message

if written as Ip.addr = = 122.248.245.191 and tcp.srcport==61281 ( where 61281 is the external port of the machine) is to find all the source IP port 61281 of the message, in other words, only show the message sent to the server, different conditions can be connected with and, flexible processing.

Let's take a look at the basic information inside the message.

(i) , ACK, FIN,PSH These three are flags of the TCP request, which is not a number in itself, but a flag of 1 bytes (8 bits) for the other five such flags to indicate the type of the current request message, which can be Wireshark Under the Flags directory to view, if one is set to 1 is set, 0 is not set, generally we only look at the bit 1, where acknowledgement = Ack,fin = Fin,push = Psh

(ii), Seq,ack meaning, where seq is a shorthand for Sequence number, which is the serial numbers. The Ack is a shorthand for the acknowledge number, which is the answer code, which can be used to observe the order of several adjacent messages with these two numbers.

Okay, so now we can start by analyzing the steps individually.

First stage: three handshake

(The native IP is 192.168.1.109:61281, the server IP is: 122.248.245.191:7033)

First, let's review the three-time handshake process.

The picture below shows the three handshake messages.

This is the third one. Because the port is not the end number of Firefox, it's another three-time handshake.

From here we can see that the process of fully conforming to the standard TCP three handshake, the second handshake ACK is the first time the seq+1

Three handshake takes 102.605103-102.354383 = 0.2572 seconds, looks fast, shows that the three-time handshake didn't waste a lot of time

Phase two: Send a GET request and receive a return JSON

From here, it can be seen that the server sends three waves of data, each message length is 1514, and then return a number OK to end the send, where after the completion of the second send the client sent a data receive acknowledgement message, after the OK, the client sent a data receive acknowledgement message

From here you can see how long it takes the entire server to send data to the client: 103.862232-102.858066 = 1.004166

Then the time from three handshake success to successful client received JSON is 103.862232-102.354383 = 1.507849

Then we can figure out the response time of the server is 1.507849-1.004166 (data callback)-0.2572 (three handshake) = 0.246483 seconds

As you can see, both the network and the server are pretty fast.

Several of the messages in this section have been pasted at the very bottom of this article and are interested to see

Phase III: Request Favicon.ico

As can be seen, a total of two pictures requested, each request did not succeed (because the server does not have this graph) each request about 1 seconds or so, the first time 105.605757-104.393820 = 1.211937, the second time 106.025472-105.608105= 0.417367, the second time is much shorter than the first times.

Stage four: Keep-alive

This keep-alive request is issued by Firefox, I estimate the purpose is to reduce the three handshake build and destroy the connection overhead, and every 10 seconds or so to send a keep-alive request, a total of 6 times, the server answered 5 times, The total keepalive time is 158.373788-115.817623=42.556165 seconds, it seems that Firefox is optimized for HTTP, and we also know that with Firefox in about 1 minutes will not rebuild the HTTP connection

Fifth stage: Wave four times

First, let's review the process of waving four times.

Let's take a look at four waves of messages.

From here to capture the message can be seen here and the standard TCP four wave is consistent, and from the packet capture results, this wave is initiated by the server, it is estimated that the server can not stand the client's endless keepalive request, to release a connection. Judging from the data, the entire four waves are time consuming, 166.387505-166.162996 = 0.224509

OK from here, it can be seen that the entire HTTP request process one go, very fast, almost in less than two seconds to complete the entire data request, as for UI drawing in milliseconds, so you can see at the code level regardless of the server or the client has no performance problems, However, just the test is to use a computer browser through the broadband network for HTTP requests, do not take into account the time-out retransmission and packet loss situation, there is no simulation of the mobile phone in WiFi or wireless network situation, the following will focus on the network conditions when the bad when the packet loss situation.

Attached: Several messages for HTTP callback data

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=0frame 3632:60 bytes on wire (480 BITS), bytes captured (480 bits) on interface 0Ethernet II, SRC:CHENGDUV_08:D6:C2 (EC:6C:9F:08:D6:C2), dst:wistroni_a 3:C8:2C (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, src:122.248.245.191, Dst:192.168.1.109transmission Control Protocol, SRC port:7033 (7033), Dst port:61281 (61281), Seq:1, ack:413, len:0 Source port:7033 Destination Por t:61281 [Stream index:29] [TCP Segment len:0] Sequence number:1 (relative Sequence number) Acknowledgme NT number:413 (relative ACK number) Header length:20 bytes flags:0x010 (ACK) Window size value:75 [Calc ulated window size:19200] [window size scaling factor:256] checksum:0x6f29 [validation disabled] Urgent Pointe r: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), 151 4 bytes captured (12112 bits) on interface 0Ethernet II, SRC:CHENGDUV_08:D6:C2 (EC:6C:9F:08:D6:C2), Dst:wistroni_a3:c8:2 C (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, src:122.248.245.191, Dst:192.168.1.109transmission Control Protocol, SRC port:7033 (7033), Dst port:61281 (61281), Seq:1, ack:413, len:1460 Source port:7033 Destination port:6128 1 [Stream index:29] [TCP Segment len:1460] Sequence number:1 (relative Sequence number) [Next Sequence N umber:1461 (relative sequence number)] acknowledgment number:413 (relative ACK number) Header length:20 byt    Es 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), 151 4 bytes captured (12112 bits) on interface 0Ethernet II, SRC:CHENGDUV_08:D6:C2 (EC:6C:9F:08:D6:C2), Dst:wistroni_a3:c8:2 C (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, src:122.248.245.191, Dst:192.168.1.109transmission Control Protocol, SRC port:7033 (7033), Dst port:61281 (61281), seq:1461, ack:413, len:1460 Source port:7033 Destination port:6 1281 [Stream index:29] [TCP Segment len:1460] Sequence number:1461 (relative Sequence number) [Next sequ ence number:2921 (relative sequence number)] acknowledgment number:413 (relative ACK number) Header Length:    Bytes flags:0x010 (ACK)Window size value:75 [calculated window size:19200] [window size scaling factor:256] CHECKSUM:0XB2FA [Validat Ion disabled] Urgent pointer:0 [seq/ack analysis] [reassembled PDUs in frame:3679] TCP segment data (1460 BYT     ES) 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=0frame 3677:54 bytes on wire (4 -bits), bytes captured (432 bits) on interface 0Ethernet II, src:wistroni_a3:c8:2c (3c:97:0e:a3:c8:2c), Dst:chengdu V_08:D6:C2 (EC:6C:9F:08:D6:C2) Internet Protocol Version 4, src:192.168.1.109, Dst:122.248.245.191transmission 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) Acknowl Edgment 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), 151 4 bytes captured (12112 bits) on interface 0Ethernet II, SRC:CHENGDUV_08:D6:C2 (EC:6C:9F:08:D6:C2), Dst:wistroni_a3:c8:2 C (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, src:122.248.245.191, Dst:192.168.1.109transmission Control Protocol, SRC port:7033 (7033), Dst port:61281 (61281), seq:2921, ack:413, len:1460 Source port:7033 Destination port:6 1281 [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: Bytes flags:0x010 (ACK) Window size value:75 [Calculated window size:19200] [window size scaling factor : checksum:0x6d9d [validation disabled] Urgent pointer:0 [seq/ack analysis] [reassembled PDUs 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 OK (application/json) Frame 3679:288 bytes on wire (2304 bits), 288 Bytes captured (2304 bits) on interface 0Ethernet 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.109transmission 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 Numbe    R) [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 seg  ment data (234 bytes) [4 reassembled TCP segments (4614 bytes): #3675 (1460), #3676 (1460), #3678 (1460), #3679 (234)]hypertext Transfer Protocol http/1.1 ok\r\n content-encoding:gzip\r\n content-type:application/json;charset=utf-8\r\     n date:wed, 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 byte     Sjavascript Object Notation:application/jsonno.         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=0frame 3680:54 bytes on wire (4 -bits), bytes captured (432 bits) on interface 0Ethernet II, src:wistroni_a3:c8:2c (3c:97:0e:a3:c8:2c), Dst:chengdu V_08:D6:C2 (EC:6C:9F:08:D6:C2) Internet Protocol Version 4, src:192.168.1.109, Dst:122.248.245.191transmission 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) Acknowl Edgment 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 [val Idation disabled] Urgent pointer:0 [seq/ack analysis]

Analyze Android Network request time using Wireshark capture packet