TCP connection establishment and Termination

TCP connection establishment and termination three handshakes the server side is ready to receive external links, through the socket, bind, listen3 functions, for passive open client through the connect function to actively establish a connection, send a SYN (with serial number) server to confirm (ACK) the customer's SYN, confirm that the serial number is the number of the Service SYN plus 1, and send a SYN (with serial number) client to confirm (ACK) the SYn of the service. confirm that the serial number is the serial number of the Service SYN plus 1. the above is what we usually call three-way handshake TCP connection termination four-way handshake Client call close to actively close (usually Client, or server ). Send a FIN (with serial number ). In the FI_WAIT1 status, the Peer of the received FIN is passively disabled. Send ACK confirmation. Then go to CLOSE_WAIT. The peer receives ACK and enters FIN_WAIT_2. In this case, the unit is closed. The peer calls close to close the execution. Send FIN (with serial number ). Enter the LAST_ACK status. The client that receives the FIN sends ACK confirmation and enters the TIME_WAIT status. The Server enters the CLOSED status after receiving the ACK. Closes the connection. The preceding figure shows the four handshakes for closed connections. The CLOSE_WAIT Server receives the FIN reply ACK from the Client and enters the CLOSE_WAIT status. The connection from the Client to the Server is closed. The Client cannot send data to the Server. At this time, the Server can still send data to the Client. That is, one-way connection is closed. The Server must also close to the status after the transfer. Sometimes we find that the server has a lot of close_wait, because the other party closes the connection, and the server is not closed due to busy reading/writing or other reasons. The TIME_WAIT Client enters the TIME_WAIT status after receiving the corresponding ACK from the Server FIN. The duration of this status is twice the maximum MSL (maximum segment lifetime), that is, 2MSL. The recommended RFC1122 value is 2 minutes, while the traditional implementation of Berkeley is 30 seconds. Therefore, the duration ranges from 1 minute to 4 minutes. It exists to ensure that the last ACK can be successfully achieved. Otherwise, the Server resends the FIN after MSL to trigger ACK resending. The maximum time is 2MSL. This is the main reason. Another reason is to allow the old repeated segment to disappear in the Network: In the next scenario, a tcp connection is established between Port 1 of A and port port2 of port B, and then the connection is closed. To ensure A period of time, we can also establish A connection between Port 1 of A and Port 2 of port B. We should avoid the previous old groups on the connection from appearing again. To do this, TCP does not initiate a new connection for a connection in the TIME_WAIT status. The TIME_WAIT state duration is 2MSL, so that the maximum data survival time in each direction is MSL. In this way, when a TCP connection is successfully established, the old repeat groups from the connection are all lost in the network.