TCP Connection closed

The workflow for closing the mechanism is: ApplicationProgramCall the close method or shutdownoutput method of the socket to indicate that the data has been sent. At this moment, the underlying TCP implementation first transfers data stored in the sendq Queue (it also depends on the remaining space of the recvq queue at the other end ), then, send a handshake message to the other end that closes the TCP connection. The closed handshake message can be seen as a stream termination flag: It tells that no new data is transmitted to the recvq queue after receiving TCP. (Note: The closed handshake message itself is not passed to the received application, but is returned to indicate its position in the byte stream through the read method .) TCP that is being closed will wait for confirmation of its handshake closed information, which indicates that all data transmitted on the connection has been completely transmitted to recvq. As long as a confirmation message is received, the connection becomes "semi-closed (half
Closed) "status. The connection is completely closed until the symmetric handshake information is received in the other direction of the connection -- that is, the two ends of the connection indicate that there is no data to be sent.

 

The closing event sequence of TCP connections may occur in two ways: one is to call the close () method (or the shutdownoutput () method) by an application first ), then, the handshake message is closed before the other end calls the close () method. The other method is to call the close () method at the same time, and their close handshake messages are transmitted across the network.

 

Shows the event sequence in the underlying implementation when the connection is closed in the first way:

The closed handshake message has been sent, and the data structure of the socket has been set to "Closing" (fin_wait_1). Then, the close () call will return. After these operations are completed, any read/write operations on the socket will be prohibited (an exception will be thrown ). After receiving the close handshake confirmation message, the status of the socket Data Structure Changes to "semi-closed" (fin_wait_2), which will continue until the other end receives the close handshake message.

Note: If the remote terminal has left when the connection is semi-closed, the local underlying data structure will remain in this status indefinitely. When the close handshake message at the other end arrives, a confirmation message is sent back and the status is changed to "time-Wait ". Although the corresponding socket instance in the application may have disappeared, the underlying data structure associated with it will remain in the underlying implementation for several minutes.

 

 

 

It shows the sequence of events on the terminal that did not initiate or close first:

 

When a closed message arrives, it immediately sends back a confirmation message and changes the connection status to "Close-Wait ".
In this case, you only need to wait for the application to call the close () method of socket. After this method is called, the final closed handshake message will be initiated and the underlying socket data structure will be released, although the reference to the original socket strength is still stored in the Java program.

Note: neither the close () method nor the shutdownoutput () method waits for the completion of the close handshake, but returns immediately after the call.

Socket. setsolinger () is used to control whether the close () method waits until the handshake is closed before the return result. The setsolinger () method does not provide any extra guarantee for the referenced program currently implemented.

Because the message transmission delay occurs in the network, the TCP specification requires that at least one socket must be in the Time-Wait status for a period of time after both ends of the handshake are closed when the connection is terminated. If the handshake is closed at both ends of the connection, the underlying data structure is removed, and a new connection is established between the same socket address, the delayed message of the previous connection may arrive after the new connection is established. Because it contains the same source address and destination address, the old message is incorrectly considered as a new connection, and the data contained in the old message may be mistakenly allocated to the application.

The time-Wait Status is used to ensure that each TCP connection ends in a period of calm, during which no data is sent. The length of the calm time should be twice the maximum retention time of the packet on the network.

The most important role of the Time-Wait Status is that as long as the underlying socket data structure still exists, it is not allowed to associate other sockets on the same local port. In particular, an ioexception is thrown when you try to use this port to create a new socket instance.

 

 

Sequence diagram of the first case:

The sequence diagram of the second case: