Computer network-TCP disconnection and precautions

TCP status: LISTEN: listening for connection request SYN-SENT from a remote TCP port: Wait for the matching connection request SYN-RECEIVED after sending the connection request again: after receiving and sending a connection request, WAIT for the other party to confirm the connection request ESTABLISHED: represents an open connection FIN-WAIT-1: waiting for the remote TCP connection to be interrupted, or previous connection interrupt request validation FIN-WAIT-2: from remote tcp wait connection interrupt request CLOSE-WA IT: WAIT connection interrupt request from local user CLOSING: WAIT for the remote TCP to confirm the connection interruption LAST-ACK: WAIT for the original send to the remote TCP connection interruption request confirmation TIME-WAIT: wait for enough time to make sure that the remote TCP receives the confirmation CLOSED of the connection interruption request: there is no connection status www.2cto.com. To analyze this cause, you have to close the four handshakes of the connection, sometimes it's a three-way handshake. As shown in:

We all know that tcp normally closes the connection after four handshakes. As follows:

In these four handshakes, there is a special note for the status TIME_WAIT. This status indicates that the active shutdown party will be in a long-term state after receiving the FIN of the disabled party (two MSL times, depending on the specific implementation, this value will be different, in RFC 1122, MSL is recommended to be 2 minutes, but the value used for Berkeley implementation is 30 s. For details, see www.rfc.net, if you don't have the patience to look at English, you can see the protocol description and the corresponding source code in the protocol analysis network. I didn't find this value in the java source code, and I can only trace PlainSocketImpl. the java class is called by the Local interface, so it depends on the implementation of the local operating system. That is, it takes about 1-4 minutes, and the operating system automatically recycles and sets the TCP connection to the initial state of CLOSED. As shown in:
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 the book, telnet login and exit are used to explain the process of establishing and suspending the TCP protocol connection. We can see that the establishment of the TCP connection can be simply called a three-way handshake, the disconnection can be called a four-way handshake.
1. when establishing a connection, the client first requests to the server to open a port (using TCP packets with SYN segments equal to 1 ), then the server sends back an ACK message 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, 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. A special concept of ending TCP is half-close, which means that the TCP connection is a full-duplex (which can be sent and received at the same time) connection. Therefore, when the connection is closed, you must disable the connection between data transmission and data transmission. 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. Www.2cto.com
3. 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. the TCP status migration graph on the P182 page shows the TCP status chart, which looks complicated, because it contains two parts: Server Status migration and client status migration, if you look at this picture from a certain perspective, it will be much clearer, the server and client here are not absolute. The client sends data, and the server receives the data.
4. 1. client application status transition diagram the client status can be expressed using the following process: CLOSED-> SYN_SENT-> ESTABLISHED-> FIN_WAIT_1-> FIN_WAIT_2-> TIME_WAIT-> the CLOSED process is the process that should be performed when the program is normal, as shown in the diagram in the book, 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. 2. server Status transition diagram the server status can be expressed in the following process: CLOSED-> LISTEN-> SYN received-> ESTABLISHED-> CLOSE_WAIT-> LAST_ACK-> when CLOSED establishes a connection, the server enters the data interaction status only after the third handshake, closing a connection is after closing the second handshake (note that it is 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. 3. the diagrams in other State Migration books also have some other State migration. These State Migration summarizes the following two aspects for the server and client: LISTEN-> SYN_SENT. This explanation is very simple, the server sometimes needs to open the connection. SYN_SENT-> SYN received. If the server and client receive SYN datagram in the SYN_SENT state, they both need to send the syn ack datagram and adjust their status to the SYN received state, prepare to enter ESTABLISHED www.2cto.com SYN_SENT-> CLOSED. When sending times out, it will return to the CLOSED status. SYN _ received-> LISTEN. If an RST packet is received, it returns to the LISTEN status. 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 There Is A TIME_WAIT wait state in the figure given in the wait state book, which is also called the 2MSL state. It indicates that after TIME_WAIT2 sends the last ACK datagram, it enters 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 ). In order to avoid this error, the server provides a concept of Calm time, which means that although the server can be restarted in 2MSL time, however, this server still needs to wait for the 2MSL time to complete the next connection.
4.5.FIN _ WAIT_2 status this is the well-known semi-closed status, which is the status after the client and server shake hands 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. Www.2cto.com
5. Opening and closing the RST at the same time is another way to close the connection. The application should be able to determine the authenticity of the RST package, that is, whether it is an exception or not. Both open and close are two special TCP states, with a low probability of occurrence.
6. TCP server design the UDP server design has previously been described. We can find that UDP servers do not need the so-called concurrency mechanism at all. It only needs 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. From the column of ODA