TCP establishes a connection 3 handshake and 4 waves to close the connection

#.3-time handshake process status

First handshake: When a connection is established, the client sends a SYN packet (SYN=J) to the server and enters the Syn_send state, waiting for the server to confirm;

Second handshake: The server receives the SYN packet, it must confirm the customer's SYN (ACK=J+1), and also send itself a SYN packet (syn=k), that is, the Syn+ack packet, when the server enters the SYN_RECV state;

Third handshake: The client receives the server's Syn+ack packet, sends the acknowledgment packet ack (ACK=K+1) to the server, the packet is sent, the client and the server enter the established state, and the handshake is completed three times.

With such a three-time handshake, the client establishes a reliable duplex connection with the server to begin transmitting data.

The main purpose of the three-time handshake is to ensure that the connection is duplex, and that more reliable is ensured by the retransmission mechanism.

# Why do I need to shake 3 times?

1. To ensure full-duplex communication is possible.
For example, party a wrote a letter to party B (the first handshake), if you receive a reply from party B (the second handshake), that party B can both receive the letter can also reply. If party B receives a reply from party A (the third handshake), it indicates that party a can also reply by receiving the letter.

2. An error occurs in order to prevent a failed connection request message segment from suddenly being transmitted to the server (that is, the problem of a deferred repeating packet in the network).
A "Failed connection request message segment" was generated in a situation where the first connection request message segment of the client was not lost, but it was stuck in a network node for a long time, so that it was delayed until a certain time after the connection was released before it reached the server. Originally this is a message segment that has already expired. However, after the server receives this failed connection request message segment, it is mistaken for a new connection request from the client. The client is then sent a confirmation message segment, agreeing to establish a connection. Assuming that the "three-time handshake" is not used, the new connection is established as soon as the server issues a confirmation. Because the client is now not making a connection request, the server acknowledgement is ignored and data is not sent to the server. But the server thought the new transport connection had been established and waited for the client to send the data. In this way, many of the server's resources are wasted. The use of "three-time handshake" method can prevent the above phenomenon. For example, in that case, the client does not issue confirmation to the server's confirmation. The server knows that the client does not require a connection because it cannot receive a confirmation.

#.4 Wave process Status (reference)

fin_wait_1: The true meaning of the fin_wait_1 and Fin_wait_2 states is the FIN message that waits for each other. The difference between the two states is: The fin_wait_1 state is actually when the socket in the established state, it would like to actively close the connection, send a FIN message to the other side, when the socket is entered into the fin_wait_1 state. And when the other party responds to the ACK message, then into the fin_wait_2 state, of course, under the actual normal circumstances, regardless of the circumstances of each other, should immediately respond to the ACK message, so fin_wait_1 state is generally more difficult to see, and Fin_wait_ 2 states can also sometimes be seen with netstat. (Active side)
fin_wait_2: This state is explained in detail above, in fact, the socket in the fin_wait_2 state, that is, a half connection, that is, one side requires close connection, but the other party tells the other side, I temporarily have some data to send you (ACK message), and then close the connection later. (Active side)
time_wait: It received the fin message from the other side, and sent out the ACK message, so 2MSL can return to the closed available state. If the fin_wait_1 state, received the other side with the FIN flag and the ACK flag message, you can directly into the time_wait state, without having to go through the fin_wait_2 state. (Active side)
CLOSING(relatively rare): This state is special, the actual situation should be very rare, belonging to a relatively rare exception state. Normally, when you send a fin message, it is supposed to receive (or receive) the other's ACK message before receiving the other's fin message. But closing status indicates that you send fin message, and did not receive the other's ACK message, but also received the other side of the fin message. Under what circumstances will this happen? In fact, it is not difficult to come to a conclusion: that is, if the two sides close a socket at the same time, then there is a situation where both sides send the fin message, there will be a closing state, indicating that both sides are shutting down the socket connection.
close_wait: The meaning of this state is actually expressed in waiting to be closed. How do you understand it? When the other side close a socket to send fin message to yourself, you will undoubtedly respond to an ACK message to each other, then enter into the close_wait state. Next, the real thing you really need to consider is whether or not you have the data sent to the other person, if not, then you can close the socket, send fin messages to each other, that is, close the connection. So what you need to accomplish in the close_wait state is waiting for you to close the connection. (Passive side)
Last_ack: This state is still relatively easy to understand, it is the passive close side after sending fin messages, and finally wait for each other's ACK message. When an ACK message is received, it is also possible to enter the closed available state. (Passive side)
CLOSED: Indicates a connection interruption.

# Why do I need to wave 4 times?

The reason is that TCP is a full-duplex mode, and when it receives fin it means no data is sent again, but the data can continue to be sent.

#. TCP state diagram

#. Reference

http://blog.csdn.net/xifeijian/article/details/12777187

TCP establishes a connection 3 handshake and 4 waves to close the connection