Tcp disconnected four wave
1 client sends to the server-side FIN disconnection request, client terminal enters FIN_WAIT_1 state, waiting for the server-side ACK. At this point the client
Data can not be transmitted, but still be able to read data from the server side.
After 2 server end receives the ACK and sends FIN, the state enters close_wait can not be, but still able to transmit data to the client in the read data.
After 3 client server-side end of the ACK received, enters FIN_WAIT_2 state, waiting for the FIN server end. After entering the server side transmitted FIN
LAST_ACK state, waiting for client-side ACK.
After 4 client end receives the end of the FIN server, and then send ACk, client terminal enters the TIME_WAIT state, waiting 2MSL. The purpose is twofold
Sent to the server of choice for preventing ACK packet loss, ensure connections are closed, and the second is to allow re-read the section disappeared in the network lost them. to prevent
Excessive TIME_WAIT () status descriptor resource intensive, a method is provided under the socket in the TIME_WAIT () is a reusable state.
Four waving process
common problem:
1 Why is the time of connection is three-way handshake, when it is closed handshake?
Because when the terminal receives SYN Server Client terminal connection request message may be sent directly SYN + ACK packet. Wherein the ACK message is used for response, SYN etc is used to synchronize the packet. But the connection is closed, when the Server side FIN packet is received, probably does not close immediately SOCKET, it can only respond to a first ACK packet, told Client-side, "you send FIN messages I have received." Only until the end of all my Server messages are sent over, I can send FIN packets, and therefore can not be sent together. It requires a four-step handshake.
2 Why TIME_WAIT state need to go through 2MSL (maximum segment lifetime) CLOSE to return to the state?
Although Logically, the four packets have been sent, we can go directly to the CLOSE state, but we have the illusion of a network is unreliable, there may be the last ACK is lost. So TIME_WAIT state is used to retransmit ACK packets may be lost. Send out the final ACK reply Client, but the ACK may be lost. Server If no ACK, FIN segment sent will repeat. Client can not close it immediately, it must be confirmed Server receives the ACK. Client enters the TIME_WAIT state after sending the ACK. Client will set a timer, waiting 2MSL time. If you receive FIN again within that time, then the Client will resend ACK 2MSL and wait again. The so-called 2MSL is twice the MSL (Maximum Segment Lifetime). MSL refers to a segment of the network the maximum survival time, 2MSL is transmitted and a maximum time required for a response. If until 2MSL, Client have not received FIN again, then the Client concluded that ACK has been successfully received, the TCP connection.
And why not connect with two-way handshake?
3-way handshake to complete two important functions, both sides should make preparations to send data (both sides know each other ready), but also to allow the parties to negotiate on the initial sequence number, the serial number is sent during the handshake and confirmation.
Now put into a three-way handshake only requires two hands, a deadlock is likely to occur. As an example, consider the communication between the computer C and S, S is assumed to C transmits a connection request packet, the received packet is S, and send the acknowledgment packet. Under the agreement the two shook hands, S considers the connection has been successfully established, you can start sending data packets. However, C in the case of S reply packet is lost in transmission, and will not know if S is ready, I do not know what kind of establishment S serial number, C S even doubt whether it has received its own connection request packet. In this case, C considers the connection has not been established successfully, will ignore any data packet sent by S, just waiting for the connection confirmation response packet. After the S timeout packet sent repeatedly transmits the same packet. This creates a deadlock.
How do 4 If you have already established a connection, but the client suddenly broke down?
TCP is also a keep-alive timer, apparently, a client if a failure occurs, the server can not keep on waiting, wasted resources. Each time the server receives the client's request will reset the timer set time is usually 2 hours, if two hours has not received any data from the client, the server sends a detection message segment, then every 75 seconds to send one. If sending 10 consecutive probe packets still did not respond, the server brought out customers considered a failure, and then they close the connection.