TCP/IP Study Notes (10)-TCP connection establishment and Suspension

TCP is a connection-oriented protocol. Therefore, a connection must be established before both parties send data. This is totally different from the preceding protocol. All the Protocols mentioned above only send data. Most of them do not care whether the sent data is sent or not, especially UDP. From a programming perspective, UDP programming is also much simpler-udp does not need to consider data sharding.

In this document, telnet login and exit are used to explain the process of establishing and suspending a TCP connection. We can see that the establishment of a TCP connection can be simply calledThree-way handshakeAnd the disconnection can be calledFour handshakes.

1. Establish a connection

When establishing a connection, the client first requests to the server to open a port (using a TCP packet with SYN segment equal to 1), and then the server sends back an ACK packet to notify the client to receive the request message, after receiving the confirmation message, the client sends a confirmation message again to confirm the confirmation message (bypass) sent by the server. At this point, the connection is established. This is called a three-way handshake. If you want to prepare both parties, you must send three packets, and only three packets are required.

We can imagine that if TCP's timeout retransmission mechanism is added, TCP can completely ensure that a data packet is sent to the destination.

2. End the connection.

TCP has a special concept calledHalf-closeThis concept means that the TCP connection is a full-duplex (both sending and receiving can be done at the same time) connection. Therefore, when closing the connection, you must close the connection between the transmission and sending directions. The client sends a TCP packet whose fin is 1 to the server, and then the server returns an ACK packet to the client, and sends a FIN packet. When the client replies the ACK packet (four handshakes ), the connection is over.

3. Maximum packet length

When establishing a connection, both parties must confirm the maximum message length (MSS) of each other to facilitate communication. Generally, the SYN length is MTU minus the fixed IP header and TCP Header Length. For an Ethernet, it can generally reach 1460 bytes. Of course, for non-local IP addresses, the MSS may only have 536 bytes, and the value will be smaller if the mss of the intermediate transmission network is smaller.

4. TCP status migration Diagram

The p182 page of the book provides the TCP status chart, which looks complicated because it contains two parts: Server Status migration and client status migration, from a certain point of view, this figure will be much clearer. The servers and clients here are not absolute. The clients that send data are the clients, and the servers that receive data are the servers.

4. Status migration diagram of client applications

The client status can be expressed in the following process:

Closed-> syn_sent-> established-> fin_wait_1-> fin_wait_2-> time_wait-> closed

The above process is a proper process in the normal circumstances of the program. From the figure in the book, we can see that when a connection is established, when the client receives the ACK of the SYN packet, the client opens an interactive data connection. The client ends the connection actively. After the client ends the application, it needs to go through the fin_wait_1, fin_wait_2, and other statuses. The migration of these statuses is the four handshakes mentioned above to end the connection.

4. Server Status migration Diagram

The server status can be expressed in the following process:

Closed-> listen-> SYN received-> established-> close_wait-> last_ack-> closed

When a connection is established, the server enters the data interaction status only after the third handshake, while closing the connection is after the second handshake (note not the fourth ). After the feature is disabled, you must wait for the client to provide the final ack package before entering the initial state.

4. Migration in other statuses

The diagram in the book also contains some other State migration, which summarizes the two aspects of server and client as follows:

1. Listen-> syn_sent, the explanation is very simple, and the server sometimes needs to open the connection.
2. Syn_sent-> SYN received. If the server and client receive SYN datagram in the syn_sent state, both the server and client need to send the syn ack datagram and adjust their status to the SYN receiving state to be in the established State.
3. Syn_sent-> closed: when sending times out, it will return to the closed status.
4. SYN _ received-> listen. If an RST packet is received, it returns to the listen status.
5. SYN _ received-> fin_wait_1. This migration means that you can directly jump to the fin_wait_1 status and wait to close without going to the established status.

4.4.2msl waiting status

In the figure given in the book, there is a time_wait wait state, which is also called the 2msl state. It means that after time_wait2 sends the last ack datagram, it will enter the time_wait state, this status prevents the datagram of the last handshake from being transmitted to the other party and prepared (note that this is not the four handshakes, but the fourth handshake is the insurance status ). This State ensures that both parties can end normally, but the problem also arises.

Because of the 2msl status of the plug-in port (the plug-in Port indicates the IP address and port pair, socket), the application cannot use the same plug-in again in 2msl time, which is better for the customer program, however, for a service program, such as httpd, it always needs to use the same port for service. In 2msl time, an error occurs when httpd is started (the plug is used ). To avoid this error, the server provides a concept of Calm time. This means that although the server can be restarted within 2msl, the server still needsCalmWait 2msl time before the next connection can be made.

4.5.fin _ wait_2 status

This is the famous semi-closed status, which is the status after the client and server shake hands twice when the connection is closed. In this state, the application can accept data, but data cannot be sent. However, the client is always in the fin_wait_2 state, and the server is always in the wait_close state, the Application Layer determines to close this state.

5. rst. both open and close

RST is another way to close the connection. The application should be able to determine the authenticity of the RST package, that is, whether the connection is aborted abnormally. Both open and close are two special TCP states, with a low probability of occurrence.

6. TCP Server Design

We have previously talked about UDP server design. We can find that UDP servers do not need the so-called concurrency mechanism at all, and they only need to establish a data input queue. But TCP is different. The TCP server needs to establish an independent process (or lightweight, thread) for each connection to ensure the independence of the conversation. Therefore, the TCP server is concurrent. In addition, TCP also requires an incoming connection request queue (which is not required by the UDP server) to establish a dialog process for each connection request, this is why all TCP servers have a maximum number of connections. Based on the IP address and port number of the source host, the server can easily differentiate different sessions for data distribution.

Understanding the status migration diagram in this chapter is the key to learning this chapter.