What does the interviewer want to test us about the three-way handshake and the four-way wave?

In an interview, three handshakes and four waves are the most frequently asked knowledge points. I believe that everyone has read many articles about three handshakes and four waves. Today's article focuses on the interview. What are the more important points we should grasp and which ones are more often asked by the interviewer. I think if you can remember and understand some of the points I list below, I think that's enough.

[[262077]]

Three-way handshake

When the interviewer asks you why you need a three-way handshake, the purpose of a three-way handshake, and talk about the three-way handshake, I think many people will answer like this:

First of all, many people will talk about the handshake process:

1. First handshake: The client sends a SYN message to the server.

2. Second handshake: After receiving the SYN message, the server will respond with a SYN+ACK message.

3. The third handshake: After the client receives the SYN+ACK message, it will respond with an ACK message.

4. After the server receives the ACK message, the three-way handshake is established.

The purpose is to confirm whether the receiving and sending capabilities of both parties are normal.

Here I will explain why only three handshakes can confirm whether the receiving and sending capabilities of both parties are normal, but two handshakes cannot:

First handshake: The client sends a network packet and the server receives it. In this way, the server can conclude that the client's sending capacity and the server's receiving capacity are normal.

Second handshake: The server sends a packet and the client receives it. In this way, the client can conclude that the receiving and sending capabilities of the server and the client are normal. However, at this time, the server cannot confirm whether the receiving capabilities of the client are normal.

The third handshake: The client sends a packet, and the server receives it. In this way, the server can conclude that the client's receiving and sending capabilities are normal, and the server's own sending and receiving capabilities are also normal.

Therefore, a three-way handshake is required to confirm whether the receiving and sending capabilities of both parties are normal.

This answer is actually OK, but I think we should describe the process in more detail, because during the three-way handshake, both parties have many changes in state, and these states are also the points that the interviewer may ask. So I think when answering the three-way handshake, we should describe it in more detail, and a more detailed description means that we can talk longer. I think the description that adds points should be like this:

At first, the client is in the closed state and the server is in the listening state.

1. First handshake: The client sends a SYN message to the server and indicates the client's initialization sequence number ISN(c). At this time, the client is in the SYN_Send state.

2. Second handshake: After the server receives the SYN message from the client, it will respond with its own SYN message and specify its own initialization sequence number ISN(s). At the same time, it will use the client's ISN + 1 as the ACK value, indicating that it has received the client's SYN. ​​At this time, the server is in the SYN_REVD state.

3. The third handshake: After the client receives the SYN message, it will send an ACK message. Of course, it also uses the server's ISN + 1 as the ACK value, indicating that the SYN message from the server has been received. At this time, the client is in the established state.

4. After the server receives the ACK message, it is also in the established state. At this time, the two parties have established a link.

The role of the three-way handshake

The three-way handshake has many functions. Remember a few of them and you will never lose out. For example:

1. Confirm whether the receiving and sending capabilities of both parties are normal.

2. Specify your own initialization sequence number to prepare for subsequent reliable transmission.

3. If it is the https protocol, the three-way handshake process will also verify the digital certificate and generate the encryption key.

This alone is not enough to deal with the three-way handshake. The interviewer may also ask some other questions, such as:

1. Is (ISN) fixed?

An important function of the three-way handshake is that the client and the server exchange ISN (Initial Sequence Number) so that the other party knows how to assemble the data according to the sequence number when receiving the data next time.

If the ISN is fixed, an attacker can easily guess the subsequent confirmation number, so the ISN is dynamically generated.

2. What is a semi-connected queue?

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

Here is a supplement about the number of SYN-ACK retransmissions: After the server sends the SYN-ACK packet, if it does not receive the client's confirmation packet, the server retransmits it. After waiting for a period of time and still not receiving the client's confirmation packet, it retransmits it for the second time. If the number of retransmissions exceeds the maximum number of retransmissions specified by the system, the system deletes the connection information from the semi-connection queue. Note that the waiting time for each retransmission is not necessarily the same, and it will generally increase exponentially, such as the interval time of 1s, 2s, 4s, 8s, ....

3. Can data be carried during the three-way handshake?

Many people may think that the three handshakes cannot carry data, but in fact, the third handshake can carry data. In other words, the first and second handshakes cannot carry data, but the third handshake can carry data.

Why is this so? You can think about this question. If the first handshake can carry data, if someone wants to maliciously attack the server, then he will put a lot of data in the SYN message in the first handshake every time, because the attacker does not care whether the server's receiving and sending capabilities are normal, and then frantically repeats the SYN message, which will make the server spend a lot of time and memory space to receive these messages. In other words, if the first handshake can carry data, one of the simple reasons is that it will make the server more vulnerable to attack.

As for the third time, the client is already in the established state, that is, for the client, it has established a connection and already knows that the server's receiving and sending capabilities are normal, so there is nothing wrong with carrying the data page.

Regarding the three-way handshake, you can know about the https authentication process, but I won’t talk about it. I will save it for when I write an article related to http interviews.

Four waves

The same applies to the four waves. Don't send a FIN message from the other party, an ACK message from us, then a FIN message from us, and an ACK message from us. Then end it. Explain it in more detail. For example, the following is enough. Remember the status of each stage. I was asked several of these questions in my last interview. Haha. I answered them wrong, but I thought I answered them correctly. I explained them clearly at the time. Haha.

At the beginning, both parties are in the established state. If the client initiates the close request first, then:

1. First wave: The client sends a FIN message, which specifies a sequence number. At this time, the client is in the CLOSED_WAIT1 state.

2. Second handshake: After receiving FIN, the server will send an ACK message and use the client's sequence number value + 1 as the sequence number value of the ACK message, indicating that the client's message has been received. At this time, the server is in CLOSE_WAIT2 state.

3. Third handshake: If the server also wants to disconnect, it sends a FIN message and specifies a sequence number, just like the first handshake of the client. At this time, the server is in the LAST_ACK state.

4. The fourth wave: After receiving the FIN, the client also sends an ACK message as a response, and uses the server's sequence number value + 1 as the sequence number value of its own ACK message. At this time, the client is in the TIME_WAIT state. It takes a while to ensure that the server receives its own ACK message before entering the CLOSED state.

5. After the server receives the ACK message, it closes the connection and is in the CLOSED state.

The TIME_WAIT state is particularly important here. This is a high-frequency test point in the interview. You need to understand why the client does not close directly after sending ACK, but waits for a while before closing. The reason is to ensure that the server has received our ACK message. If not, the server will resend the FIN message to the client. After the client receives the FIN message again, it knows that the previous ACK message is lost, and then sends the ACK message again.

As for the duration of TIME_WAIT, it is at least the round trip time of a message. Generally, a timer is set. If no FIN message is received after this timer, it means that the other party succeeded, that is, the ACK message, and it is in the CLOSED state.

Here I give the meaning of each status, you can take a look if you are interested.

LISTEN - listen for connection requests from remote TCP ports;

SYN-SENT - waits for a matching connection request after sending a connection request;

SYN-RECEIVED - Waiting for confirmation of a connection request after receiving and sending one;

ESTABLISHED - represents an open connection and data can be transferred to the user;

FIN-WAIT-1 - Waiting for a connection interruption request from the remote TCP, or confirmation of a previous connection interruption request;

FIN-WAIT-2 - Waiting for a connection interruption request from the remote TCP;

CLOSE-WAIT - Waiting for a connection termination request from a local user;

CLOSING - waiting for confirmation from the remote TCP that the connection is broken;

LAST-ACK - Waiting for the acknowledgment of the original connection termination request sent to the remote TCP;

TIME-WAIT - Waits for enough time to ensure that the remote TCP receives acknowledgment of the connection termination request;

CLOSED - no connection status;

Finally, in the diagram of the three-way handshake and the four-way wave