The establishment of a TCP connection can be simply referred to as a three-way handshake, while the termination of the connection can be called a four-way handshake.
TCP is a connection-oriented protocol, so both parties need to establish a connection before sending data. This is completely different from the protocols discussed earlier. All the previous protocols only send data and most do not care whether the data is delivered, especially UDP; from a programming perspective, UDP programming is much simpler—UDP does not require consideration of data fragmentation. The book uses telnet login and logout to explain the process of establishing and terminating a TCP connection, where it can be seen that the establishment of a TCP connection can be simply referred to as a three-way handshake, while the termination can be called a four-way handshake.
Establishing a Connection
When establishing a connection, the client first requests to open a specific port (using a TCP packet with SYN equal to 1), and then the server sends back an ACK packet to notify the client that the request packet has been received. After the client receives the confirmation packet, it sends another confirmation packet to acknowledge the confirmation packet sent by the server (a bit convoluted), and thus, the connection is established. This is called a three-way handshake. If both parties are to be adequately prepared, three packets must be sent, and only three packets are needed.
It can be imagined that if we add TCP’s timeout retransmission mechanism, TCP can fully guarantee that a data packet is delivered to its destination.
Ending a Connection
TCP has a special concept called half-close, which means that TCP connections are full-duplex (can send and receive simultaneously). Therefore, when closing a connection, both directions of the connection must be closed. The client sends a TCP packet with FIN equal to 1 to the server, then the server returns a confirmation ACK packet to the client and sends a FIN packet. When the client replies with an ACK packet (the four-way handshake), the connection is terminated.
Maximum Segment Size
When establishing a connection, both parties must confirm each other’s Maximum Segment Size (MSS) for communication. Generally, this SYN length is the MTU minus the fixed lengths of the IP and TCP headers. For Ethernet, this can generally reach 1460 bytes. Of course, for non-local IPs, this MSS may only be 536 bytes, and if the MSS of the intermediate transmission network is even smaller, this value will become smaller.
TCP State Transition Diagram
As shown in the figure, this is a relatively complex state transition diagram because it contains two parts—the server’s state transitions and the client’s state transitions. From a certain perspective, this diagram becomes much clearer; the server and client are not absolute; the one sending data is the client, and the one receiving data is the server.
Client Application State Transition Diagram
The client’s state can be represented by the following process:
-
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
The above process is what should occur under normal program conditions. From the diagram in the book, it can be seen that when the client receives the ACK of the SYN packet, it opens the data exchange connection. The termination of the connection is usually initiated by the client; after the client ends the application, it needs to go through states like FIN_WAIT_1, FIN_WAIT_2, etc. These state transitions are the four-way handshake mentioned earlier to end the connection.
Server State Transition Diagram
The server’s state can be represented by the following process:
-
CLOSED->LISTEN->SYN_RECEIVED->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
When establishing a connection, the server enters the data exchange state only after the third handshake, while the closure of the connection occurs after the second handshake of the closing connection (note that this is not the fourth). After closing, it must wait for the client to send the final ACK packet to return to the initial state.
Other State Transitions
There are also some other state transitions, which summarize the transitions for both the server and client as follows:
-
LISTEN->SYN_SENT, this explanation is simple; the server sometimes also needs to open a connection.
-
SYN_SENT->SYN_RECEIVED, when the server and client are in the SYN_SENT state and receive a SYN packet, they need to send a SYN ACK packet and adjust their states to SYN_RECEIVED to prepare to enter ESTABLISHED.
-
SYN_SENT->CLOSED, in the case of a timeout, it will return to the CLOSED state.
-
SYN_RECEIVED->LISTEN, if an RST packet is received, it will return to the LISTEN state.
-
SYN_RECEIVED->FIN_WAIT_1, this transition indicates that it can skip the ESTABLISHED state and directly jump to FIN_WAIT_1 and wait for closure.
TIME_WAIT State
The TIME_WAIT state, also known as the 2MSL state, indicates that after the last ACK packet is sent in TIME_WAIT2, it enters the TIME_WAIT state. This state is prepared to prevent the last handshake’s data packet from not being delivered to the other party (note that this is not the four-way handshake, but a safety state for the fourth handshake). This state largely ensures that both parties can end normally, but problems arise.
Due to the 2MSL state of the socket (socket refers to the combination of IP and port), applications cannot reuse the same socket within the 2MSL time. This is somewhat manageable for client programs, but for server programs, such as httpd, which always need to use the same port for service, starting httpd during the 2MSL time will result in an error (the socket is in use). To avoid this error, the server provides the concept of a quiet time, which means that during the 2MSL time, although the server can be restarted, it must still wait quietly for the 2MSL time to pass before proceeding to the next connection.
FIN_WAIT_2 State
This is the famous half-closed state, which occurs after two handshakes when closing a connection. In this state, the application can still receive data but cannot send data. However, it is also possible that the client remains in the FIN_WAIT_2 state while the server remains in the WAIT_CLOSE state until the application layer decides to close this state.
RST, Simultaneous Open and Simultaneous Close
RST is another way to close a connection, and applications should be able to determine the authenticity of the RST packet, i.e., whether it is an abnormal termination. Simultaneous open and simultaneous close are two special TCP states that occur with very low probability.
TCP Server Design
Previously, the design of a UDP server was discussed, revealing that a UDP server does not need a concurrency mechanism; it only needs to establish a data input queue. However, TCP is different; a TCP server needs to establish an independent process (or lightweight thread) for each connection to ensure the independence of the dialogue. Thus, a TCP server is concurrent. Moreover, TCP requires a queue for incoming connection requests (which UDP servers do not need) to establish dialogue processes for each connection request. This is why various TCP servers have a maximum number of connections. Based on the source host’s IP and port number, the server can easily distinguish different sessions for data distribution.
“Learning Linux This Way” is a technical book written based on the latest Linux system, aimed at zero-based readers. It starts with basic Linux knowledge and gradually increases the difficulty of content, detailing the working principles and configuration methods of various services in the Linux system to match the requirements of operations and maintenance personnel in real production environments, highlighting the practicality of the content. Readers who want to learn the Linux system can click the “Read Original” button to learn more about this book. This book is also suitable for professional operations and maintenance personnel as a very valuable reference tool!