Understanding TCP Server Behavior: Analyzing TCP Handshake and Connection Management with Wireshark

Let’s use Wireshark today to analyze some principles of TCP. First, let’s establish a TCP server.

Code Language: JavaScript

Next, let’s establish a TCP client.

Code language: JavaScript

We will analyze each case.1 Do not start the server, start the client.Let’s see how TCP behaves in this situation. First, let’s look at the overview.

TCP server />

We see that TCP first sends a SYN packet.

TCP server />

Since the server is not started, the client does not receive a SYN+ACK packet, and then retransmits twice. Finally, it reports an error.

2 Start the server, start the client.Let’s see how a complete TCP handshake works.

Firstly, the client sends a SYN packet with seq equal to 0, then the server returns a SYN+ACK TCP packet. The acknowledgment number is 1, meaning the previous sequence numbers have been received. Finally, the client sends an ACK packet again, where seq equals 1, indicating the handshake takes up a sequence number. ACK equals 1 also. The client informs the server that the sequences before 1 are received. This completes the three-way handshake. What does the three-way handshake mean? How is it implemented? The essence of the three-way handshake is that some context is recorded on both ends. For instance, the server records which IP and port have established a connection. So, when the server next receives a packet from this client, it checks if a record exists; if there is, it means a connection is established and it’s a legitimate request. Otherwise, it sends a reset packet to the client (we can use C language to construct a TCP message).

3 The client crashes (or the server crashes)Let’s see what TCP does if the client directly crashes.

We see that TCP will send a reset packet to the server.

4 The client (or server) closes the connection normallyLet’s modify the client code first

Code Language: JavaScript

The above code makes the client immediately begin the four-way handshake to close the connection after completing the three-way handshake. Let’s see how TCP behaves.

We only look at the last four lines (four-way handshake). First, the client sends a FIN packet, but we find that seq equals 1, indicating that the FIN packet does not consume a sequence number. Similarly, the server first returns an ACK packet, then sends a FIN packet, and waits for an ACK from the client. The last time the client sends an ACK, it must wait for 2 MSL. This IP and port can be reused unless port reuse is set.

5 Both ends close simultaneouslyLet’s also modify the server code.

Code Language: JavaScript

When the server completes the three-way handshake, it immediately sends a FIN packet in the callback. What does TCP do then? Because in the three-way handshake, the third handshake is sent by the client, when the client sends the third handshake, it enters the established state. However, the server has not yet received the data packet from the third handshake. So, the client will send a FIN packet first. So, the problem arises. The order of the FIN packet and the third handshake’s ACK packet reaching the server affects the subsequent process. Below are the two scenarios.

The ACK of the third handshake arrives first

The FIN packet arrives first6 Keep-aliveBy default, TCP does not automatically disconnect; it requires the caller to control it. However, TCP has done some optimization, which is if there is no data transmission after a period of time, it will send a probe packet. If there is still no data transmission or no ACK of the probe packet is received, it will send another probe packet every interval (these two intervals seem to be the same in Windows; they can be different in Linux). If no response is received after several attempts, it sends a reset packet to the opposite side to disconnect.

We see that after the three-way handshake, without data transmission, TCP will continuously send probe packets.

Summary: That’s all for today. TCP is very complex, and this article provides some examples, analyzing certain principles of TCP.