Interview frequently questions-tcp three times handshake and four times handshake

http://blog.csdn.net/dotnetpig/article/details/6776999

Recently interviewed a lot of companies, in addition to Baidu, other companies Taobao etc will ask you TCP three handshake in the end is what, why is three times shaking hands instead of four times shaking hands.

After reading this article, I am sure I will find the answer. 1, establish the Connection agreement (three times handshake)
(1) The client sends a TCP message with a SYN flag to the server. This is message 1 in the three handshake process.
(2) server-side response to the client, this is the three handshake in the 2nd message, this message with both ACK and SYN logo. It therefore represents a response to a client-side SYN message, while labeling SYN to the client and asking the client if it is ready for data communication.
(3) The customer must again respond to the service segment an ACK message, this is the message segment 3. Note: Because TCP is Full-duplex, in fact, the normal time, it is necessary to test whether the two channels to open the success of the line, however, because the second handshake, the server not only sent a confirmation message, but also sent to the client-related message SYN, asking the client whether to prepare data communications, This saves the sending of a message.
2. Connection termination agreement (four waves)
Because the TCP connection is Full-duplex, each direction must be closed separately. The principle is that when one party completes its data sending task, it can send a fin to terminate the connection in this direction. Receiving a fin only means that there is no data flow in this direction, and a TCP connection can still send data after receiving a fin. The side that first closes will perform the active shutdown while the other side performs the passive shutdown.
(1) The TCP client sends a FIN, which is used to turn off client to server data transfer (message segment 4).
(2) The server receives this fin, it sends back an ACK, confirming that the serial number is the received number plus 1 (message Segment 5). Like Syn, a fin will occupy an ordinal number.
(3) The server shuts down the client's connection and sends a FIN to the client (message segment 6).
(4) The customer segment sends back ACK message confirmation, and the confirmation serial number is set to receive the serial number plus 1 (message paragraph 7). 3. Process analysis of calling function

Function:
Socket ()--Creates a socket that creates a struct and a buffer for sending and receiving. This does not specify which IP and port port the socket is on.
Bind ()--used to bind a socket to a specific ip/port
Listen ()--to create two queues for the listening port (see above) SYN Request for receiving clients
Accept ()--Remove those connections from the established queue in the listening port
Connect ()--Client connection request

Client process: Socket ()-> bind (optional)-> Connect ()
Server procedure: Socket ()-> bind (mandatory)-> listen ()-> accept ()

>>>> clients must call the BIND function.

The purpose of BIND is to bind the socket to a specific Ip/port port, where the client usually uses a temporary allocation when connect PORT,IP will select the appropriate local IP based on the routing table, which, in general, may not be specified by the client.
The service side must specify that bind be invoked to bind to a specific port, but IP may not be specified. Otherwise, if the system is temporarily allocated, the client's connection request may be unknown. For IP, of course, the local IP, if deliberately binding, you must specify one of the local.

>>>> Listen's real purpose ...

The Listen function creates two queues for the listening port: the unfinished queue (SYN_RCV state) and the completed queue. If listen is not invoked, the client-side SYN request cannot be queued for further processing. Therefore, listen is a necessary process for the server.

4. Questions and Answers:

>>>> Listen if the client reaches the maximum allowable number, how to handle the new SYN request.

For af_inet communication domains, the underlying use of the retransmission SYN message, if the maximum number of retransmissions can still not join the team, then return timeout error.
For Af_unix communication domains, the Connect () function returns the Erefuse error message.

>>>> TCP set three handshake, and release requires four handshake, why can not be released three times to complete it.
CLOSED: There's nothing to say about this, the initial state.
LISTEN: This is also very easy to understand a state, indicating that a server side of the socket is in the listening state, you can accept the connection.
SYN_RCVD: This state is accepted to the SYN packet, under normal circumstances, this state is a server-side socket in the establishment of TCP connections during the three handshake session in the process of a middle state, very short, basically with netstat you are very difficult to see this state, Unless you deliberately write a client test program, intentionally three times TCP handshake process of the last ACK message is not sent. Therefore, when the client's ACK message is received, it will enter the established state.
Syn_sent: This state echoes with SYN_RCVD, when the client socket performs connect connection, it first sends the SYN message, so it then enters the syn_sent state and waits for the 2nd message in the service side to send a handshake of three times. The Syn_sent state indicates that the client has sent a SYN message.
Established: This is easy to understand, indicating that the connection has been established.
Fin_wait_1: This state to explain, in fact, the real meaning of fin_wait_1 and fin_wait_2 state is to represent the fin message waiting for each other. And the difference between the two states is: fin_wait_1 state is actually when the socket in the established state, it wants to actively shut down the connection, sent the FIN message to the other side, when the socket is entered into the fin_wait_1 state. And when the other side response ACK message, then into the fin_wait_2 state, of course, in the actual normal circumstances, regardless of what the other side of the case, should immediately respond 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.
Fin_wait_2: This state is explained in detail above, in fact, the socket in the state of fin_wait_2, which means that a half connection, that is, one side requires a close connection, but also told the other side, I have some data to be sent to you, and then close the connection.
Time_wait: said that received the other side fin message, and sent an ACK message, and so on 2MSL can return to the closed available state. If the fin_wait_1 state, received the other side with the FIN flag and ACK sign message, you can go directly to the TIME_WAIT state, without the fin_wait_2 state.
CLOSING: This state is more special, the actual situation should be very rare, belong to a relatively rare exception state. Normally, when you send a fin message, it is supposed to receive (or simultaneously receive) the other's ACK message, and then receive the other's fin message. But the closing state means that after you send the FIN message, you do not receive an ACK message from the other side, but you also receive a fin message from the other side. Under what circumstances would such a situation arise? In fact, it is not difficult to draw a conclusion: that is, if the two sides close at the same time a socket, then there are both sides send fin message, also will appear closing state, that both sides are closing the socket connection.
Close_wait: The meaning of this state is actually that it is waiting to be closed. How to understand it. When the other side close a socket and send fin message to yourself, your system will undoubtedly respond to an ACK message to the other side, then into the close_wait state. The next thing you really need to consider is whether you still have data to send to each other, and if not, then you can close the socket, send a FIN message to the other, or turn off the connection. So what you need to do in the close_wait state is to wait for you to close the connection.
Last_ack: This state is relatively easy to understand, it is a passive closed side in the sending fin message, the last wait for the other ACK message. When the ACK message is received, it can be entered into the closed available state.
Finally there are 2 questions to answer, my own analysis after the conclusion (not necessarily guaranteed 100% correct)
1, why the establishment of the Connection Agreement is three times handshake, and closed the connection is four times handshake.
This is because the socket in the listen state of the server when the SYN message is received, it can send ack and SYN (ACK to respond, and SYN to sync) in a message. But when you close the connection, when receiving a fin message from each other, it simply means that the other party has no data to send to you, but not all of your data is sent to each other, so you may not be able to immediately close the socket, that is, you may also need to send some data to each other after the Send fin message to each other to indicate that you agree that the connection can now be closed, so it's ACK and fin messages are sent in most cases separately.
2, why the TIME_WAIT state also need to wait 2MSL before return to the closed state.
This is because: although both sides agreed to close the connection, and the handshake of the 4 messages are also coordinated and sent over, can reasonably be directly back to the closed state (as from the Syn_send state to the establish state), but because we have to pretend that the network is unreliable, You can not guarantee that your final ACK message will be received by the other side, so the other side in the Last_ack state of the socket may be due to timeout did not receive an ACK message, and resend the fin message, so the role of this time_wait state is to resend the likely loss of the ACK message.