The interviewer asked the TCP three-way handshake and four waves in such detail?

2022.09.01
The interviewer asked the TCP three-way handshake and four waves in such detail?
This article will focus on a series of core questions related to the three-way handshake and four-way wave, and share how to more accurately answer and respond to common interview questions. In the future, you can talk to him at will when facing the trickier interviewer.

Definition of TCP

The full name of TCP is the Transmission Control Protocol (Transmission Control Protocol), which is a connection-oriented, reliable, byte stream-based transport layer communication protocol.  TCP is a transport protocol specially designed to provide a reliable end-to-end byte stream over an unreliable internetwork.

TCP's three-way handshake and four-way wave can be said to be a classic question that is often talked about. It is usually a common interview question in major companies, with a certain level of distinction.  Deceptively simple interview questions.  If your answer does not meet the expectations of the interviewer, it may be directly cool.

This article will focus on a series of core questions related to the three-way handshake and the four-way wave, and share how to more accurately answer and respond to common interview questions. In the future, if you face the toughest interviewer, you can talk to him at will.

Answer the three-way handshake gracefully

Three-way handshake: The server creates a new socket, binds the address information and starts monitoring, and enters the LISTEN state.  After the client creates the socket binding address information, it calls connect, sends a connection request SYN, and enters the SYN_SENT state, waiting for the server's confirmation.  Once the server listens to the connection request, it will put the connection into the kernel waiting queue, and send the SYN and confirmation segment ACK to the client to enter the SYN_RECD state.  After receiving the SYN+ACK message, the client sends an acknowledgement segment ACK to the server, and enters the ESTABLISHED state to start reading and writing data. Once the server receives the confirmation message from the client, it enters the ESTABLISHED state and can read and write data.

picture

1. Why is the handshake three times instead of two or four?

A: Two times is not safe, four times is unnecessary.  In tcp communication, it is necessary to ensure that both parties have the ability to send and receive data. If an ACK response is received, it is considered that the other party has the ability to send and receive data. Therefore, both parties must send SYN to ensure that the other party has the ability to communicate.

  • The first handshake is that the client sends SYN, the server receives it, and the server concludes that both the sending capability of the client and the receiving capability of the server are normal;
  • The second handshake is that the server sends SYN+ACK, the client receives it, and the client concludes that the client's sending and receiving capabilities are normal, and the server's sending and receiving capabilities are also normal, but the server cannot confirm whether the client's receiving capabilities are normal at this time;
  • In the third handshake, the client sends ACK and the server receives it. Only then can the server conclude that the client's sending and receiving capabilities are normal, and the server's own sending and receiving capabilities are also normal.

2. Can the three-way handshake carry data?

A: The first and second handshakes cannot carry data, while the third handshake can carry data. Assuming that data can be carried for the first time, if someone maliciously attacks the server, a large amount of data is put into the SYN message in the first handshake every time, and a large number of SYN messages are repeatedly sent. At this time, the server will spend a lot of memory space to buffer these message, the server is more vulnerable to attack.

3. What will the server do if the TCP three-way handshake fails?

Answer: There are two reasons for the failure of the handshake. The first is that the server does not receive SYN, so it does nothing; the second is that after the server replies with SYN+ACK, it times out if it does not receive an ACK response for a long time. After that, an RST reset connection message will be sent to release resources.

4. What does ISN stand for? What's the point? Is the ISN fixed? Why is ISN Dynamically Random?

A: The full name of ISN is Initial Sequence Number, which is the origin of the byte data number of the TCP sender, telling the other party the initialization sequence number that I want to start sending data.

If the ISN is fixed, the attacker can easily guess the confirmation number of the subsequent sequence. For the sake of security, to avoid being guessed by a third party and send forged RST packets, the ISN is dynamically generated.

5. What is a semi-join queue

A: After the server receives the SYN from the client for the first time, it will be in the SYN_RECD state. At this time, the two parties have not fully established the connection. The server will put the request connection in this state in a queue, which we call a semi-connection queue. Of course, there is also a full connection queue, that is, the three-way handshake has been completed, and the connection established will be placed in the full connection queue. If the queue is full, packet loss may occur.

Respond gracefully and wave four times

Four waves:

  • When the client actively calls close, it sends the end segment FIN message to the server and enters the FIN_WAIT1 state at the same time;
  • The server will receive the FIN message of the end segment, the server will return the confirmation segment ACK and enter the CLOSE_WAIT state. At this time, if the server has data to send, the client still needs to receive it. When the client receives the confirmation of the end segment from the server, it will enter the FIN_WAIT2 state and begin to wait for the end segment of the server;
  • After the server-side data is sent, when the server actually calls close to close the connection, it will send the end segment FIN packet to the client. At this time, the server enters the LAST_ACK state and waits for the last ACK to be brought;
  • The client receives the end segment from the server, enters TIME_WAIT, and sends an ACK for the confirmation segment; the server receives the ACK for the end segment, enters the CLOSED state, and disconnects. The client has to wait for 2MSL before entering the CLOSED state.

picture

6. Why is there three handshakes and four when waving?

Answer: In fact, during the TCP handshake, the receiving end merges the SYN packet and the ACK confirmation packet into one packet and sends it, so the transmission of one packet is reduced. For the four waves, since TCP is full-duplex communication, sending a FIN request by the active closing party does not mean a complete disconnection, but only means that the active closing party no longer sends data.

The receiver may still need to send data, so the data channel from the server to the client cannot be closed immediately, so the FIN packet from the server and the ACK packet to the client cannot be combined and sent, but the ACK can only be confirmed first, and the server does not need to send data. When sending FIN packets, four packet interactions are required when waving hands four times

7. What is the function of the TIME_WAIT state, why does the active closing party not directly enter the CLOSED state to release resources?

Answer: If the active closing party enters the CLOSED state, the passive closing party does not receive an ACK confirmation after sending the FIN packet, and a FIN packet will be retransmitted after the timeout. If the client does not have the TIME_WAIT state and directly enters the CLOSED state to release resources, the next time a new client is started, it may use the same address information as the previous client. There are two hazards:

  • The first is that when the newly started new client binds the address successfully, it will receive a retransmitted FIN packet, which will affect the new connection.
  • The second is if the new client sends a SYN connection request to the same server, but the server is in the LAST_ACK state at this time, requiring an ACK instead of a SYN, so a RST re-establishment request will be sent.

8. Why does the TIME_WAIT state need to go through 2MSL to enter the CLOASE state?

A: MSL refers to the maximum lifetime of a packet in the network. After the client sends the ACK to the server for the FIN confirmation packet, the ACK packet may not arrive. If the server does not receive the ACK packet, it will resend the FIN packet.

Therefore, the client needs to set aside 2MSL time after sending the ACK (the ACK arrives at the server + the server sends the FIN retransmission packet, back and forth) to wait for the confirmation that the server has received the ACK packet. That is to say, if the client waits for 2MSL and does not receive the FIN packet retransmitted by the server, it can confirm that the server has received the ACK packet sent by the client.

9. What is the reason for a large number of TIME_WAIT on a host? How should it be handled?

Answer: TIME_WAIT is the active closing party. A large number of TIME_WAIT on a host proves that a large number of active closing connections are initiated on this host. Common in some crawler servers. At this time, we should adjust the waiting time of TIME_WAIT, or enable the socket address reuse option

10. What is the reason for a large number of CLOSE_WAITs on a host? How should it be handled?

Answer: CLOSE_WAIT is the state after the passive closing party receives the FIN request and replies, waiting for the upper-level program to further process it. If there is a large number of CLOSE_WAIT, it may be that the passive closing party’s host program forgot the last step to disconnect and then call close to release resources. This is a bug. You only need to add the corresponding close to solve the problem

11. Keep-alive mechanism in TCP connection management

A: In TCP communication, if there is no data exchange between the two ends for a long time, the server will send a keep-alive detection datagram to the client at regular intervals, asking the client to reply.  If no response is received several times in a row, the connection is considered disconnected.  The default is 7200s for a long time, 75s for every other period, and 9 times for consecutive no response.  These data can be modified in the socket, interface: Setsockopt.