Analyze TCP three-way handshake using tcpdump

In the past, the three-way handshake of TCP stayed at the level of three arrows. now, with the help of tcpdump, we can clearly see how TCP established connections and transmitted data. I first ran the TCP bounce server program on the UNP book, asked it to listen on port 9889, and then used the tcpdump program to intercept the communication packet of port 9889 of the local machine.

In the past, TCP three-way handshakes have stuck to know how many arrows there are.TcpdumpThis tool clearly shows how the TCP protocol establishes a connection and transmits data.
I first ran the TCP bounce server program on the UNP book, asked it to listen on port 9889, and then used the tcpdump program to intercept the communication packet of port 9889 of the local machine. The command line is as follows:

$ Sudo tcpdump-I Lo' port 9889 and tcp '-X-s 0-S

The command parameters of the specific tcpdump can be known through man tcpdump. However, the most important commands here are-X and-S.-X indicates that when analysis and printing are performed, tcpdump prints the header data of each package, and prints the data of each package in hexadecimal and ASCII code format (excluding the header of the connection layer ).

-S indicates that when printing the sequence number of a TCP packet, the absolute sequence number is used instead of the relative sequence number. for example, when I use tcpdump to view tcp's three-way handshake for the first time, I find that the ack of the third handshake is 1, because tcpdump only displays the absolute sequence number in the SYN packet, non-SYN packets show relative values. to facilitate observation, absolute sequence numbers are used when packets are captured.

To understand the output format of tcpdump, you must first understand the data encapsulation of TCP/IP, as shown in:

The preceding command-X parameter specifies that only the last and second data packets in the screenshot are intercepted, that is, only the IP Header, TCP Header, and ApplicationData are included.

First, let's look at the structure of the IP Header:

I have not studied the structure of the IP Header. The simple fields are described as follows:

Version: <4 bits> indicates the IP Version, which is generally 4 or 6.

IHL: <4bit>, Internet HeaderLength, indicates the length of the IP header, a unit length is 32bit, the Options field in is not mandatory, so the minimum length of IPHeader is 5x32bits. therefore, the minimum value of this field is 5.

Total Length: <16 bits>. This field indicates the Length of the entire IP package, including IP Header, TCPHeader, and Application Data.

IP SourceAddress: <32 bits>, source IP Address. the Adresse in the figure is the Address of German. the diagram of this IPHeader and the diagram of the TCP Header below are all taken from the German website.

IP Destionation Address: <32 bits>, the destination IP Address.

Options: optional field. Padding indicates that 32 bits is not enough to be filled with 0.

For example, I caught such a package with tcpdump:

00:05:36. 631501 IP localhost.54504> localhost.9889:
Flags [P.], seq 4289908547: 4289908560, ack 2355231328,
Win 2050, options [nop, nop, TS val 28499978 ecr 28495907], length13
0 × 0000: 4500 0041 1f63 4000 4006 1d52 7f00 0001 E... A. c @. @. R ....
0 × 0010: 7f00 0001 d4e8 26a1 ffb2 cf43 8c61 fa60 ...... &.... C. .'
0x0020: 8018 0802 fe35 0000 0101 080a 01b2 e00a ..... 5 ..........
0 × 0030: 01b2 d023 6865 6c6c 6f20 776f 127C 647e... # Hello. world ~
0 × 0040: 0a

We can see that the data of the first 32bits is 4500. according to the definition of the IP Header above, the length of this IPHeader is 5, that is, 5 x32bits, which is organized as follows:

+- +-+
| Ver: 4 | IHL: 5 | ToS: 00 | Total Length: 0041 |
+- +-+
| Identification: 1f63 | F: 4 | Fragment Offset: 000 |
+- +-+
| TTL: 40 | Protocol: 06 | Header Checksum: 1d52 |
+- +-+
| Source Address: 7f00 0001 |
+- +-+
| Destination Address: 7f00 0001 |
+- +-+

The structure of TCP Header is as follows:

Source Port: <16 bits>, Source Port

Destination Port: <16 bits>, the Destination Port.

Sequence Number: <32 bits>. this is still to be studied. I think so now. if The SYN (Synchronize sequence numbers) in the TCPHeader is 0, indicates the sequence number of the first byte of the data carried by the TCPHeader. if The SYN mark in the TCP Header is 1, the sequence number represents ISN (initialsequencenumber ), that is, the initial serial number when both parties establish a TCP connection. the first byte number transmitted in this direction after this TCP connection should be ISN + 1.

Acknowledge Number: <32 bits>. This field is valid only when the ACK mark in TCPHeader is 1, representing the serial Number of the next data expected by the sending end of the TCP Header, used with the SequenceNumber mentioned above. Once the two ends are connected over TCP, this field should always be valid.

Data Offset: <4 bits>. similar to IHL in the IP Header, the unit length is also 32 bits, representing the length of TCPHeader. TCP Options are optional, but generally exist, therefore, the minimum value of this field is 5, but generally it is greater than 5.

Options: The length is not fixed. each option starts with a 1-byte kind field, indicating the option type. Kind = 0: option table end (1 byte), Kind = 1: No operation (1 byte), Kind = 2: maximum packet segment length (4 bytes), Kind = 3: window expansion factor (4 bytes), Kind = 8: timestamp (10 bytes)

Data: Finally, this field is Application Data. The Data we want to send is here.

The preceding packet, the TCP segment and the subsequent Data segment are sorted as follows:

+- +-+
| Source Port: d4e8 | Destination Port: 26a1 |
+- +-+
| Sequence Number: ffb2 cf43 |
+- +-+
| Acknowledgment Number: 8c61 fa60 |
+- +-+
| DO: 8 | Reserved: 0 | Flags: 18 | Window: 0802 |
+- +-+
| Checksum: fe35 | Urgent Pointer: 0000 |
+- +-+
| TCP Options: 0101 080a |
+- +-+
| TCP Options: 01b2 e00a |
+- +-+
| TCP Options: 01b2 d023 |
+- +-+
| Data: 6865 6c6c 6f20 776f RJC 647e 0a |
+- +-+

The ascii value of the above Data segment is: "hello world ~ \ N"

The packets I intercepted on the local machine are as follows. here, I use a yellow background to represent the IP segment, a green background to represent the TCP segment, and a data segment without a background. The blue font is my comment.

<1> 00:05:20. 346307 IP localhost.54504> localhost.9889:
Flags [S], seq 4289908546 (client ISN), win 32792,
Options [mss 16396, sackOK, TS val 28495907 ecr 0, nop, wscale 4], length 0
0 × 0000: 4500 003c 1f61 4000 4006 1d59 7f00 0001 E... <. a @. @... Y ....
0 × 0010: 7f00 0001 d4e8 26a1 ffb2 cf42 0000 0000 ...... &.... B ....
0 × 0020: a002 8018 fe30 0000 0204 400c 0402 080a ..... 0 .... @.....
0 × 0030: 01b2 d023 0000 0000 01030304... #........
<2> 00:05:20. 346333 IP localhost.9889> localhost.54504: Flags [S.],
Seq 2355231327 (server ISN), ack 4289908547 (ack = client ISN + 1), win 32768,
Options [mss 16396, sackOK, TS val 28495907 ecr 28495907, nop, wscale4],
Length 0
0 × 0000: 4500 003c 0000 4000 4006 3cba 7f00 0001 E... <.....
0 × 0010: 7f00 0001 26a1 d4e8 8c61 fa5f ffb2 cf43 .... &.... A ._... C
0 × 0020: a012 8000 fe30 0000 0204 400c 0402 080a ..... 0 .... @.....
0 × 0030: 01b2 d023 01b2 d023 01030304... #... #....
<3> 00:05:20. 346347 IP localhost.54504> localhost.9889: Flags [.],
Ack 2355231328 (ack = server ISN + 1), win 2050,
Options [nop, nop, TS val 28495907 ecr 28495907], length 0
0 × 0000: 4500 0034 1f62 4000 4006 1d60 7f00 0001 E .. 4. B @.@..'....
0 × 0010: 7f00 0001 d4e8 26a1 ffb2 cf43 8c61 fa60 ...... &.... C. .'
0x0020: 8010 0802 fe28 0000 0101 080a 01b2 d023 ..... (......... #
0 × 0030: 01b2d023... #
# Tcp 3 wayhandshake, we can see that none of the three packages contain data. since the first and second handshakes contain the maximum packet length and the third handshake only contains the timestamp, the length of the TCPHeader is different.

<4> 00:05:36. 631501 IP localhost.54504> localhost.9889: Flags [P.],
Seq 4289908547: 4289908560, ack 2355231328,
Win 2050, options [nop, nop, TS val 28499978 ecr 28495907], length13
0 × 0000: 4500 0041 1f63 4000 4006 1d52 7f00 0001 E... A. c @. @. R ....
0 × 0010: 7f00 0001 d4e8 26a1 ffb2 cf43 8c61 fa60 ...... &.... C. .'
0x0020: 8018 0802 fe35 0000 0101 080a 01b2 e00a ..... 5 ..........
0 × 0030: 01b2 d023 6865 6c6c 6f20 776f 127C 647e... # Hello. world ~
0 × 0040: 0a.
<5> 00:05:36. 631964 IP localhost.9889> localhost.54504: Flags [.],
Ack 4289908560, win 2048, options [nop, nop, TS val 28499979 ecr28499978],
Length 0
0x0000: 4500 0034 2a43 4000 4006 running f 7f00 0001 E .. 4 * C @.@.......
0 × 0010: 7f00 0001 26a1 d4e8 8c61 fa60 ffb2 cf50 .... &.... A .'... P
0x0020: 8010 0800 fe28 0000 0101 080a 01b2 e00b ..... (..........
0 × 0030: 01b2e00a ....
<6> 00:05:36. 632024 IP localhost.9889> localhost.54504: Flags [P.],
Seq 2355231328: 2355231341, ack 4289908560, win 2048,
Options [nop, nop, TS val 28499979 ecr 28499978], length 13
0 × 0000: 4500 0041 2a44 4000 4006 1271 7f00 0001 E .. A * D @. @... q ....
0 × 0010: 7f00 0001 26a1 d4e8 8c61 fa60 ffb2 cf50 .... &.... A .'... P
0x0020: 8018 0800 fe35 0000 0101 080a 01b2 e00b ..... 5 ..........
0 × 0030: 01b2 e00a 6865 6c6c 6f20 776f 450C 647e .... Hello. world ~
0 × 0040: 0a.
<7> 00:05:36. 632078 IP localhost.54504> localhost.9889: Flags [.],
Ack 2355231341, win 2050, options [nop, nop, TS val 28499979 ecr28499979],
Length 0
0 × 0000: 4500 0034 1f64 4000 4006 0001 1d5e 7f00 E .. 4. d @... ^ ....
0 × 0010: 7f00 0001 d4e8 26a1 ffb2 cf50 8c61 fa6d ...... &.... P.A.M
0x0020: 8010 0802 fe28 0000 0101 080a 01b2 e00b ..... (..........
0 × 0030: 01b2e00b ....
#4, 5, 6, and 7 packets indicate that the client sends "helloworld ~" to the server ~ \ N ", then the server returns to the client

<8> 00:06:11. 448332 IP localhost.54504> localhost.9889: Flags [P.],
Seq 4289908560: 4289908587, ack 2355231341, win 2050,
Options [nop, nop, TS val 28508683 ecr 28499979], length 27
0 × 0000: 4500 004f 1f65 4000 4006 1d42 7f00 0001 E. O. e @. @. B ....
0 × 0010: 7f00 0001 d4e8 26a1 ffb2 cf50 8c61 fa6d ...... &.... P.A.M
0x0020: 8018 0802 fe43 0000 0101 080a 01b3 020b ..... C ..........
0 × 0030: 01b2 e00b 6162 6364 6566 6768 696a 6b6c .... Abcdefghijkl
0 × 0040: 6d6e 6f70 7172 7374 7576 7778 797a0a mnopqrstuvwxyz.
<9> 00:06:11. 448524 IP localhost.9889> localhost.54504: Flags [P.],
Seq 2355231341: 2355231368, ack 4289908587, win 2048,
Options [nop, nop, TS val 28508683 ecr 28508683], length 27
0 × 0000: 4500 004f 2a45 4000 4006 1262 7f00 0001 E. O * E @. @... B ....
0 × 0010: 7f00 0001 26a1 d4e8 8c61 fa6d ffb2 cf6b .... &.... A. m... K
0x0020: 8018 0800 fe43 0000 0101 080a 01b3 020b ..... C ..........
0 × 0030: 01b3 020b 6162 6364 6566 6768 696a 6b6c .... Abcdefghijkl
0 × 0040: 6d6e 6f70 7172 7374 7576 7778 797a0a mnopqrstuvwxyz.
<10> 00:06:11. 448578 IP localhost.54504> localhost.9889: Flags [.],
Ack 2355231368, win 2050, options [nop, nop, TS val 28508683 ecr28508683],
Length 0
0x0000: 4500 0034 1f66 4000 4006 1d5c 7f00 0001 E. 4. f @.@..\....
0 × 0010: 7f00 0001 d4e8 26a1 ffb2 cf6b 8c61 fa88 ...... &.... K. ..
0x0020: 8010 0802 fe28 0000 0101 080a 01b3 020b ..... (..........
0 × 0030: 01b3020b ....
# The functions of packages 8, 9 and 10 are similar to those of packages 4, 5, 6, and 7, indicating that the client sends "abcdefghijklmnopqrstuvwxyz \ n" to the server, and then the server returns to the client, however, the functions of the 9th packages are equivalent to the merging of 5 or 6 packages. why is this happening? To be verified.
<11> 00:06:14. 752733 IP localhost.54504> localhost.9889: Flags [F.],
Seq 4289908587, ack 2355231368, win 2050,
Options [nop, nop, TS val 28509509 ecr 28508683], length 0
0x0000: 4500 0034 1f67 4000 4006 1d5b 7f00 0001 E... 4.g @.@..[....
0x0010: 7f00 0001 d4e8 26a1 ffb2 cf6b 8c61 fa88 ..
0x0020: 8011 0802 fe28 0000 0101 080a 01b3 0545 ...... (...... E
0x0030: 01b3020b ....
<12> 00:06:14. 753693 IP localhost.9889> localhost.54504: Flags [F.],
Seq 2355231368, ack 4289908588, win 2048,
Options [nop, nop, TS val 28509509 ecr 28509509], length 0
0x0000: 4500 0034 2a46 4000 4006 running C 7f00 0001 E .. 4 * F @. @... | ....
0 × 0010: 7f00 0001 26a1 d4e8 8c61 fa88 ffb2 cf6c .... &.... A ..... L
0x0020: 8011 0800 fe28 0000 0101 080a 01b3 0545 ..... (......... E
0 × 0030: 01b30545... E
<13> 00:06:14. 753727 IP localhost.54504> localhost.9889: Flags [.],
Ack 2355231369, win 2050, options [nop, nop, TS val 28509509 ecr28509509],
Length 0
0x0000: 4500 0034 1f68 4000 4006 1d5a 7f00 0001 E .. 4. h @. @. Z ....
0 × 0010: 7f00 0001 d4e8 26a1 ffb2 cf6c 8c61 fa89 ...... &.... L. ..
0x0020: 8010 0802 fe28 0000 0101 080a 01b3 0545 ..... (......... E
0 × 0030: 01b30545... E

# Packages 11, 12, and 13 are TCP connections. Theoretically, there should be four packages, because four handshakes are required to close the TCP connections between the two parties. Here I understand it as follows: the reason for the four handshakes is that when the client sends FIN to the server, it means that the client will not send any more data, but the server may also send data to the client, for example, telnet to a bbs. when you exit, you may say Goodbye before the server is disconnected. at this time, the packet captured should be four times, but after the client is disconnected, the server is immediately disconnected, so the server ack and FIN are sent together. This is just my guess and remains to be further verified.
It can be seen from here that tcpdump is powerful.