This picture is more intuitive. Compare the picture below with
TIME_WAIT .
Generally speaking, four packets are required for tcp to shut down normally. For example, a and b close the connection, a first sends a fin to b, b will confirm the ack, and then b will also send the fin, when a receives the fin and sends the last ack, it will be in the time_wait state, usually 2 times the estimated maximum segment usage period (called 2MSL, usually 2 minutes),
although both parties agree to close the connection, and the 4 packets of the handshake have also been coordinated and sent, it is reasonable to return to the CLOSED state directly (Just like from the SYN_SEND state to the ESTABLISH state); but because we have to assume that the network is unreliable, you cannot guarantee that the ACK message you send last will be received by the other party, so the SOCKET in the LAST_ACK state of the other party may be The FIN message will be retransmitted because the ACK message is not received over time, so the function of this TIME_WAIT state is to retransmit the ACK message that may be lost, and this is guaranteed.
So here comes the question:
I wrote a test program that calls a certain http interface cyclically, and does not enable keep-alive. If there is a time_wait state, in theory, it takes at least 2MSL time between the two requests? Isn't that so?
Use org.apache.httpcomponents:httpclient, write a simple test program, initiate http calls in a loop, and use wiresharp to capture, the results are as follows:
Conclusion : The party that actively initiates the closing of the connection enters the time_wait state, and the port number occupied by the process cannot be used by the process. Release, but when disconnected and reconnected, SOCKET will use a different port, and after a few minutes, the original port will be automatically closed