Packet Capture analysis

The TCP protocol specifies a server port number for the HTTP process , typically a request by an HTTP client to establish a TCP connection to the server-specified port (by default, port 80). (Note that this refers to port 80 for server development) The HTTP server listens on that port for requests sent by the client.

Open the Wireshark grab packet, filter the HTTP protocol, File–export objects–http Select the package that needs to be exported, and then click the Save As button to view the files uploaded and downloaded in the background: Wireshark export the HTTP download or post upload file

Wireshark Export Data:

Export the decoded message content, including detailed message and simple data information, "Save as Type" is "Plain Text"

Export only a summary of the specified data information, export as CSV (Comma separated Values) File

Access to the www.baidu.com process

For machines that are connected directly through the Ethernet, theWireshark Capture filter is "hostwww.baidu.com" and for over Ethernet through PPP ( PPPoE) networked machines,Wireshark Capture filter for "pppoes and hostwww.baidu.com".

Three handshake the process for establishing a TCP connection is as follows:

   C (Browser)                                    S (www.baidu.com)  CLOSED                                             LISTEN syn-sent    →<seq=0><ctl=syn>              → Syn-received established←<seq=0><ack=1><ctl=syn,ack>←syn-received established→<seq=1> <ACK=1><CTL=ACK>      →established

s call the Listen function of the socket to enter the listening state; C calls the Connect function connection S:[syn],s Call the Accept function to accept C's connection and initiate a connection to the C direction: [Syn,ack]. C sends [ACK] to complete three handshake, the Connect function returns; s receives the [ACK] sent by C, and the Accept function returns.

About SEQ and ACK

Seq is the sequence number, which is the sending sequence numbers for the source end, and theAck is acknowledgment, which is the destination (destination) receive the confirmation serial number. In Wireshark Display filter, you can use TCP.SEQ or tcp.ack filtering.

In Packet1, c:5672 sends a SYN handshake packet to the s:80, seq=0, Packet2 sends an ACK handshake response packet to s:80, c:5672, and sends a SYN handshake packet, ack=1; in Seq=0, Packet3 to S : 80 Send Ack handshake response packet, seq=1,ack=1.

At this point, Seq=1 is the C's isn, later a moment of Seq=ISN+ Cumulative Send volume (cumulative sent); Ack=1 is IAN of C. , the Ackat a later time =IAN+ cumulative receive . For S, seq and ack are the same reason.

2. TCP get web site data flow

After the connection is established, the next step is to send ("get/http/1.1") the request HTML page, where "/" represents the default homepage of S, "GET" is the HTTP Request Method; "/" is Request-uri, here is the relative address http/1.1 indicates that the HTTP protocol version number used is 1.1.

The following is an HTTP GET Request packet (PACKET4).

4  192.168.89.125:5672→220.181.6.175:80 HTTP 417get/http/1.1

The HTTP get message has a length of =417-54=363 bytes, where next sequence number:364 (relative sequence number) indicates that the message was sent successfully if it received a s response ack=364 within the specified time. The next message (seq=364) can be sent, otherwise retransmission (TCP retransmitssion). The serial number confirmation mechanism is the guarantee of TCP reliability transmission .

S (HTTP) receives an HTTP GET message (a total of 363 bytes) and sends a TCP acknowledgment message (PACKET5) to C (AMQP).

5   220.181.6.175:80→192.168.89.125:5672 TCP 60http > AMQP [ACK] seq=1 ack=364 win=6432 len=0

Here Seq=1, for S's isn, meaning has been sent over Syn. Packet2, Ack=1 is Ian of S. The ack-ian=364-1=363 here indicates that s has received 363 bytes from C, an HTTP GET message. At the same time, ack=364 is also the next TCP message sequence number that s expects c to send (next sequence numbers analyzed above).

Next, S sends the HTTP Response to C, according to the HTTP protocol, first sends the response header (Response header), then sends the Baidu homepage HTML file.

The Http Response header message (PACKET6) is as follows.

6  220.181.6.175:80→192.168.89.125:5672 TCP 465[tcp segment of a reassembled PDU]

Some of the contents are as follows:

http/1.1 OK ... Content-length:2139content-type:text/html;charset=gb2312content-encoding:gzip

s in response to the "get/http/1.1" request of C, first sends a 411-byte HTTP Response Header (Packet 6) with the identity of [PSH].

The TCP header [PSH] identifies the bit and urges C to push the cached data to the application, which is to process the HTTP Response Header first, which is actually a "interception" notification. The corresponding C socket call to send when the IPPROTO_TCP option level is set Tcp_nodelay to True disables the Nagle algorithm to "preserve the send boundary" to prevent adhesion.

When a get condition is requested, the client provides a if-modified-since request header to the server with a value of the date value in the last-modified response header that was last returned by the server, and a The If-none-match request Header value is the value of the ETag response header that the server last returned:

The server reads the values in both request headers to determine if the client caches the resource is up-to-date, and if so, the server returns a http/304 not Modified response , but no response body. when the client receives a 304 response, the corresponding resource is read from the cache.

Alternatively, if the server considers that the client cache resource has expired, the server returns the http/200 OK response, which is the most current content of the resource. After the client receives a 200 response, it overwrites the old cache resource with the new response body.

A conditional request can be sent only if the client has cached the corresponding resource and the resource's response header contains a last-modified or ETag . If none of the two headers exist, you must unconditionally ( Unconditionally) requests the resource, the server must also return the full resource data.

　Although the MSS negotiated by the handshake is 1460, the server or proxy balancing server has a maximum of 1420 bytes of TCP data sent over each time . You can use the Ping-f-l size target_name command to send ICMP packets of the specified byte amount to the specified target target_name, where-l size specifies the size of the send buffer, and-F indicates that no Shard DF is set in the IP datagram (Don ' t Fragment) so that the MTU on the target path can be detected.

The result of executing "ping-f-L 1452 www.baidu.com" is as follows:

Ping statistics for 220.181.6.18:

Packet: Sent = 4, received = 4, lost = 0 (0% missing)

The result of executing "ping-f-L 1453 www.baidu.com" is as follows:

The packet needs to be split but DF is set.

Ping statistics for 220.181.6.18:

Packet: Sent = 4, received = 0, lost = 4 (100% missing)

From the above ping results can be seen, in the non-sharding, from the local to Baidu route to the maximum amount of data to pass the 1452, which deduced the mtu{local,baidu}=sizeof (IP header) + sizeof (ICMP header ) +sizeof (ICMP Data portion) =20+8+1452=1480.

s calls the socket's send function to send 2,139 bytes of http Response Content (Packet 7, Packet 9), and then sends out after the TCP layer is decomposed into two segments (segment).

7  220.181.6.175:80→192.168.89.125:5672 TCP 1474    [TCP segment of a reassembled PDU]

By "content-length:2139", the HTML file also has 2139-(1474-54) = 719 bytes. But at this point, C has sent a confirmation message (PACKET8).

8  192.168.89.125:5672→  220.181.6.175:80 TCP 54amqp > http [ACK] seq=364 ack=1832 win=65535 len=0

seq-isn=364-1=363, which indicates that C has sent 363 bytes, has received an acknowledgment of s from the top. Ack-ian=1832-1= (465-54) + (1474-54) indicates that C has received 1831 bytes from S.

Next, C receives the remaining 719 bytes of the HTML file, and the message (PACKET9) is as follows.

9  220.181.6.175:80→192.168.89.125:5672 HTTP  773http/1.1 OK

At this point, C received S sent over all the HTTP response message , that is, Baidu home HTML content (text/html).

the ACK for PACKET6, PACKET7, and Packet9 are all 364because these three segment are TCP responses to Packet4 . S will Baidu homepage HTML file (a complete HTTP message) according to the MSS fragment submitted to the TCP layer. In Wireshark, you can see the following reassemble information in the PACKET9 message:

[Reassembled TCP segments (2555 bytes): #6 (411), #7 (1420), #9 (719)] [Frame:6, payload:0-410 (411 bytes)] [Frame:7, payload:411-1830 (1420 bytes)] [Frame:9, payload:1831-2549 (719 bytes)]

C (AMQP) after receiving the HTML file on the homepage of Baidu, start parsing rendering . In the parsing process, found that the page contains Baidu's logo resources baidu_logo.gif, and need to bdsug.js script .

{d.write (' <script src=http://www.baidu.com/js/bdsug.js?v=1.0.3.0><//script> ')}

So the above connection (c:5672) continues to request the Logo icon resource for S , the message (PACKET10) is as follows.

10 192.168.89.125:5672→  220.181.6.175:80 HTTP 492get/img/baidu_logo.gif http/1.1

At the same time, C (JMS) creates a new connection (TCP 5673) to the S request JS script file. The message (PACKET11) is as follows.

11 192.168.89.125:5673→  220.181.6.175:80 TCP 62jms > http [SYN] seq=0 win=65535 len=0 mss=1460 sack_perm=1

(Packet) Packet,Packet, Packetand Packet For TCP responses to Packet10 (their ack=802), they are logically a complete TCP message . Its HTTP Response content is a picture file baidu_logo.gif. We can see the following reassemble information in the Packet17 message in Wireshark:

[Reassembled TCP segments (1801 bytes): #13 (312), #14 (1420), #16 (, #17 (41)] [Frame:13, payload:0-311 (312 bytes)] [Frame:14, payload:312-1731 (1420 bytes)] [Frame:16, payload:1732-1759 (bytes)] [Frame:17, payload:1760-1800 (bytes)]

packet11-packet19-packet20 Three handshake to complete the new connection. C (JMS) then sends a "get/js/bdsug.js?v=1.0.3.0 http/1.1" message (Packet21) to obtain the Bdsug.js script file.

21 192.168.89.125:5673→  220.181.6.175:80 HTTP 465get/js/bdsug.js?v=1.0.3.0 http/1.1

(Packet) Packet,Packet, Packetand Packet For TCP responses to Packet21 (their ack=412), they are logically a complete TCP message. Its HTTP Response content is the script file bdsug.js. We can see the following reassemble information in the PACKET27 message in Wireshark:

[Reassembled TCP segments (3897 bytes): #23 (310), #24 (1420), #26 (1420), #27 (747)] [Frame:23, payload:0-309 (310 bytes)] [Frame:24, payload:310-1729 (1420 bytes)] [Frame:26, payload:1730-3149 (1420 bytes)] [Frame:27, payload:3150-3896 (747 bytes)]

Usually, the browser will automatically search the root of the site, as long as it found favicon.ico this file, download it down as the website Address bar icon . Thus, C (AMQP) will also launch "Get/favicon.ico http/1.1" request site Address bar icon, the text Packet29.

3. TCP four times wave close connection

After Packet28 confirms receipt of the complete japplication/javascript file , link 1 (Local port 5673) ends the mission, s closes the link and enters four times to wave off the bidirectional connection.

(Packet30) Packet31 and Packet32 are TCP responses to Packet29 (their ack=1201). After Packet33 confirms receipt of the complete Image/x-icon file , Link 2 (Local port 5672) ends the mission , s closes the link and enters four times to wave off the bidirectional connection.

Why is the handshake three times, and the wave is four times? This is because when a handshake occurs, the server often establishes a connection with the client when it agrees to establish a connection, known as a two-way connection . Therefore, in Packet2, the server sends ACK and SYN packages. Waving, that is, closing the connection, often just indicates that the wave is no longer sending data (no data can be sent), and the receiving channel is still valid (can still accept data). When the other side also waved, it indicates that the other side also no data can be sent, when the two-way connection is really closed.

Packet Capture analysis