Before we start the article, here’s an interesting article I’ve read recently. Click here for more details: AI Madness! Introducing some interesting AI algorithms.
This article introduces several interesting AI algorithms and their applications, covering areas like video generation, code generation, and game AI, showcasing the charm of the latest AI technologies and the unlimited potential for the future.
1. Introduction
According to the plan, today we will explain and share the TCP protocol’s three-way handshake and four-way wave, as well as the skills of capturing TCP/IP protocol data packets using Wireshark. This allows for in-depth analysis of TCP frame formats and the “TCP three-way handshake.” By capturing and analyzing data packets, we can understand the TCP/IP protocol, further deepening our understanding of TCP packets.
2. Establishing a TCP Connection (Three-Way Handshake)
2.1 Easy-to-Understand Version
First, here’s a common example from our daily work: remote meetings, video, or phone calls. Here’s the diagram:
The TCP three-way handshake is a bit like when we have a remote meeting (most of us have experienced this during the pandemic);
1) Colleague A: Hello! Can you hear me? (First handshake A–>B);
2) Colleague B: I can hear you, can you hear me? (Second handshake B–>A);
3) Colleague A: I can hear you, let’s start the meeting (Third handshake A–>B).
That’s a complete flow of a remote meeting.
The process of the three-way handshake, here’s the diagram again:
Initially, both the client and server are in a CLOSED state. The client initiates the connection and the server passively opens the connection.
- First handshake: The Client sets the SYN flag to 1, randomly generates a value seq=J, and sends the data packet to the Server. The Client enters the SYN_SENT state, waiting for Server’s acknowledgment.
- Second handshake: Once the Server receives the data packet and sees the SYN=1 flag, it knows the Client is requesting to establish a connection. The Server sets both the SYN and ACK flags to 1, ack (number) = J+1, randomly generates a value seq=K, and sends the data packet to the Client to confirm the connection request. The Server enters the SYN_RCVD state.
- Third handshake: Upon receiving the acknowledgment, the Client checks if ack is J+1 and ACK is 1. If correct, it sets the ACK flag to 1, ack=K+1, and sends the data packet to the Server. The Server checks if ack is K+1 and ACK is 1. If correct, the connection is successfully established. Both Client and Server enter the ESTABLISHED state, completing the three-way handshake, after which data transmission can begin between the Client and Server.
3. Releasing a TCP Connection (Four-Way Handshake)
3.1 Easy-to-Understand Version
First, here’s a common example from our daily work: breaking up with a bad boyfriend/girlfriend or getting a divorce. Here’s the diagram:
Story summary: C and D are in a relationship, and one day C discovers that D is not genuine, so C wants to break up with D.
1) C requests a breakup from D (first wave);
2) D receives the request and, despite being unpleasant, politely tells C that the request was received but is currently busy seeing someone else (second wave);
3) D finally gets some free time and tells C, “I accept your breakup request” (third wave);
4) C tells D, “I’ve finally been released” (fourth wave).
The process of the four-way wave, here’s the diagram again:
Once data transmission is complete, either party can release the connection. Initially, both the client and server are in the ESTABLISHED state. Then, the client initiates closure, and the server closes passively.
- The client process sends a connection release message and stops sending data. The release message has a header with FIN=1, and a sequence number seq=u (equal to the number of the last byte of data transmitted plus 1). The client then enters the FIN-WAIT-1 (termination wait 1) state. According to TCP, a FIN segment consumes one sequence number, even if it doesn’t carry data.
- Upon receiving the connection release message, the server sends a confirmation message with ACK=1, ack=u+1, and a sequence number seq=v. The server enters the CLOSE-WAIT (close wait) state. TCP informs the higher-level application process that the client-to-server direction is released; it is now in a half-closed state, meaning no further data is sent from the client, but if the server sends data, the client must accept it. This state lasts for some time, the duration of the entire CLOSE-WAIT state.
- Upon receiving the server’s acknowledgment, the client enters the FIN-WAIT-2 (termination wait 2) state, waiting for the server to send a connection release message ( before this, it may need to receive the last data sent by the server ).
- When the server sends the last data, it sends a connection release message to the client with FIN=1, ack=u+1. Due to being in a half-closed state, the server might have sent some data in the interim; assuming the current sequence number is seq=w, the server then enters the LAST-ACK (last acknowledgment) state, waiting for the client’s acknowledgment.
- When the client receives the server’s connection release message, it must send an acknowledgment with ACK=1, ack=w+1, sequence number seq=u+1. The client then enters the TIME-WAIT (time wait) state. Note that TCP connection isn’t yet released until 2 ∗ MSL (maximum segment lifetime) time elapses, after which the client removes the TCB and enters the CLOSED state.
- Upon receiving the client’s acknowledgment, the server enters the CLOSED state immediately. Similarly, when TCB is removed, the TCP connection ends. It can be seen that the server’s TCP connection ends earlier than the client’s.
4. WireShark Packet Sniffing Practical
Today, using Baidu as an example, we will demonstrate using WireShark for packet sniffing.
4.1 Getting Baidu’s IP
1. First, let’s check Baidu’s IP address. There are many ways to acquire it, but I’ll show one of the simplest methods: using the ping command: ping baidu.com, as shown below:
2. From the image above, you can see that 39.156.66.10 is Baidu’s IP address, and we’ll use this IP as a filter in Wireshark to easily find the corresponding packets.
4.2 WireShark Packet Sniffing
1. Open WireShark and start capture mode. Start capturing, as shown below:
2. In the command line, use curl -I baidu.com to send an HTTP request to Baidu. As shown below:
3. Stop packet capture in Wireshark. In Wireshark’s filter, input ip.addr == 39.156.66.10 to filter the requests sent to Baidu. You will get filtered packets as shown below:
4. From the image above, we can clearly see that the first three are the packets for establishing a TCP connection through the three-way handshake. The middle three include an HTTP request, a TCP acknowledgment packet, and an HTTP response packet, with the acknowledgment packet for the response and the first wave placed in the same packet. The latter four packets are the TCP four-way handshake for disconnecting the connection.
4.3 Three-Way Handshake
4.3.1 First Handshake
The first packet of the three-way handshake: the SYN packet, which is the first handshake, as shown below:
Then check if Wireshark captured the correct packets, as shown below:
1. Based on the previous theoretical knowledge, let’s jump right in: First, look at the first packet, which is the first handshake of the three-way handshake. Click to select the first TCP to view, as shown below:
2. The entire detailed parsing of the first handshake packet message is shown on the right side of the image marked in red. Let’s look at some of the more important parts.
① It starts with a 2-byte source port number and a 2-byte destination port number.
② The next four bytes represent the initial sequence number sent by the client to the server. This is a random value intended for security purposes.
③ Note, the next four bytes are the acknowledgment number. However, in the first handshake packet, the ACK flag bit is 0, so in the first handshake, the acknowledgment number is meaningless since there is nothing to acknowledge at this point.
④ The next four bits indicate the TCP header length, which can be understood as the data offset. Note, here it is 8, and the unit of this field is 4 bytes, so the TCP header is 8*4 = 32 bytes.
⑤ Next are 4 reserved bits, and 8 special flag bits. These flags are, in order: CWR, ECE, URG, ACK, PSH, RST, SYN, FIN. Focus on ACK, SYN, and FIN. Here, SYN is 1, indicating it is a connection establishment packet; ACK is 0, indicating that the acknowledgment number of this packet is meaningless.
⑥ The next 2 bytes indicate the receive window size, which is used for flow control.
⑦ Then, there are 2 bytes of checksum and 2 bytes of urgent data pointer.
⑧ Additionally, it should be noted that this packet indicates the TCP header has 32 bytes, not the usual 20 bytes. This is because the options section includes some extra data, such as MSS (Maximum Segment Size): 1460 bytes, among other information.
4.3.2 Second Handshake
The second packet of the three-way handshake: the SYN+ACK packet, which is the second handshake, as shown below:
Then check if Wireshark captured the correct packets, as shown below:
1. The same method: Click to select the second TCP to view. As shown below:
2. In the image above, the red part on the right marks the detailed information of the second handshake packet. Most of it is similar to the first handshake. Let’s look at the important parts.
① The source port number and destination port number are just the opposite of the first handshake, indicating this is a packet the server responds to the client.
② The server provides its initial sequence number A1 7C 07 91, which corresponds to 2709260177.
③ The server’s ACK bit is 1, indicating that the acknowledgment number is meaningful, and the acknowledgment number is 15 ec 6b df, which is just the sequence number of the first handshake packet +1, indicating that all bytes before this number have been received, and expects the next sequence in the next packet to be this number.
④ Here, the TCP header is also 32 bytes, and the options section similarly explains its MSS and other information, where the MSS value given is 1412 bytes.
Overall, the difference between the second handshake packet and the first handshake packet is that the ACK bit is 1, and the acknowledgment number is the sequence number of the first handshake packet +1. In addition, both packets include extra options sections, and both headers are 32 bytes.
4.3.3 Third Handshake
The third packet of the three-way handshake: the ACK packet, which is the third handshake, as shown below:
Then check if Wireshark captured the correct packets, as shown below:
1. The same method: Click to select the third TCP to view. As shown below:
2. The red marked part on the right of the image provides the detailed information of the third handshake packet. Most of the third handshake contents are similar, focusing on the key points.
① The sequence number of the third handshake is the acknowledgment number of the second handshake. The acknowledgment number is the second handshake’s sequence number +1.
② The header length is 20 bytes, and the header has no options section.
③ The SYN field is 0. Because in the first handshake, the client requested a connection, in the second handshake, the server confirmed and accepted the connection, and by the third handshake, the connection was established. In reality, the third handshake can carry application data, although it’s not common to see that.
④ The receive window size consistently changes, which is a part of flow control. The sender sends its own window size, and the receiver adjusts the transmission rate according to the sender’s window size.
This concludes the TCP three-way handshake, and the connection is successfully established.
From the above process, it can be observed that the third handshake can carry data, while the first two handshakes cannot, which is a common interview question.
Once the three-way handshake is complete, both parties are in the ESTABLISHED state, signifying the connection has been successfully established, and the client and server can exchange data with each other.
4.4 Data Transmission
4.4.1 HTTP Request
After the client sends the third handshake packet, the connection is successfully established, and immediately data transmission information is sent. Here, it is about the HTTP request. Let’s look at the information corresponding to this request packet.
1. The same method: select the HTTP request to view. As shown below:
2. First, let’s follow along by looking at the HTTP layer protocol. When translated, this section contains the HTTP part marked in the image (left red part). It includes the request line, request header, and empty line. Note, the HTTP part here is 73 bytes, indicating the TCP data part is also 73 bytes.
In practice, the program calculates the data length by using
IP total data length - IP header length - TCP header length.
3. Now, let’s view the TCP protocol part (right red part), focusing on the following points:
① This packet’s header length is also 20 bytes.
② The acknowledgment number and sequence number of this packet are the same as in the third handshake.
③ The PSH bit is 1. Here, it indicates that this packet only has this one segment; the entire packet has been transmitted, no need to wait for other segments, and the receiver should immediately deliver the packet to the application instead of buffering it and waiting for enough data before delivering it.
Since HTTP is a protocol based on TCP, each HTTP request, even if it consists of just one segment, involves at least two TCP packets being transmitted, as the receiver will send an acknowledgment packet to the sender. Below, let’s look at the TCP acknowledgment packet corresponding to this HTTP request.
4.4.2 TCP Acknowledgment Packet
1. The same method: select the TCP acknowledgment packet after the HTTP request to view. As shown below:
This packet (right red part) has a few key points to note:
① The HTTP request from before has an HTTP portion of 73 bytes, so this acknowledgment packet’s acknowledgment number should be the previous request’s sequence number +73.
② The sender currently has not transmitted any data to the receiver, so the current sequence number is simply the initial sequence number set during connection establishment +1.
③ The PSH flag bit is not set to 1 here, which implies that only the last segment of a packet carrying data sets the PSH flag to 1.
In other words, this HTTP request packet involves an HTTP data packet and a TCP acknowledgment packet. If the data volume is large and split into segments for transmission, the transmission would involve more packets.
4.4.3 HTTP Response Packet
Next, let’s look at the HTTP response packet, i.e., the HTTP packet sent by the server to the client.
1. The same method: select the HTTP response to view. As shown below:
2. This packet is not much different from the previous ones (left and right red parts), but this time, the packet is sent by the server and carries data. Here, it carries 305 bytes of data, so the acknowledgment packet the client sends in response will have an acknowledgment number of this packet’s sequence number +305.
3. The TCP acknowledgment packet corresponding to this HTTP response is actually also the first wave packet.
4.5 Four-Way Handshake
4.5.1 First Wave
The TCP acknowledgment packet for the HTTP response is actually also the first wave packet. The first wave and the HTTP response acknowledgment are the same packet and, apart from the FIN flag bit being set to 1, it’s similar to other packets. As shown below:
1. The same method: select the first wave TCP to view. As shown below:
HTTP response’s corresponding TCP acknowledgment (left red part):
① Because the response carried 305 bytes of data, this acknowledgment packet’s acknowledgment number is the previously received packet’s sequence number +305.
② The ACK is 1, indicating that the acknowledgment number is meaningful, and the FIN is 1, indicating this is a disconnect packet, and thus the first wave packet.
4.5.2 Second Wave
1. The same method: select the second wave TCP to view. As shown below:
2. The second wave packet is sent by the server, acknowledging the first wave packet. The FIN flag is 0 here (as seen in the image above), as this packet merely acknowledges the first wave from the sender.
4.5.3 Third Wave
The server prepares for disconnection and, once ready, sends a FIN packet, which is the third wave.
1. The same method: select the third wave TCP to view. As shown below:
Note that here FIN is 1, as this is the FIN packet from the server, indicating it’s ready to disconnect. After sending this packet, the server enters the LAST_ACK stage.
4.5.4 Fourth Wave
When the client receives this packet (third wave), it sends back the last acknowledgment packet to the server, marking the fourth wave.
1. The same method: select the fourth wave TCP to view. As shown below:
2. Upon receiving this acknowledgment message, the server won’t send any more packets but instead, closes the connection and enters the CLOSED state.
5. Summary
With the preceding theory and subsequent practice, you may now have a deeper understanding of TCP packets, right? I believe you understand it well. If you want to learn more, you can look up more information. Alright, that’s it for today; it’s getting late. Thank you for your patience in reading~~