1. Why does TCP have three handshakes instead of two

1. Prevent invalid connection requests from being sent to the server and causing errors.

Unfortunately, this explanation is inaccurate, and the reason for TCP’s three-way handshake is much simpler than most blogs suggest. To ensure reliable data transmission, both parties of the TCP protocol must maintain a serial number to identify which packets have been received. The three-way handshake is a necessary step for communication parties to inform each other of the start sequence number and confirm that the other party has received the start sequence number. In the case of two handshakes, at most only the initial sequence number of the connection initiator can be confirmed, and the sequence number selected by the other party cannot be confirmed.

The bit code is the TCP flag bit, which has the following six identifiers:

① SYN(synchronous establishing online);

② Acknowledgement

③ PSH(Push transmission)

④ FIN(Finish)

⑤ RST(reset)

⑥ URGENT (URG)

4) Sequence number //Acknowledge number

First handshake: Host A sends A packet with bit code SYN=1 and randomly generates A packet with SEQ number=1234567 to the server. Host B knows from SYN=1 that host A requires to establish an online connection.

For the second handshake, host B confirms the online information after receiving the request and sends A packet with ACK number=(SeQ +1 of host A), SYN=1,ACK=1, randomly generating A packet with SEQ number=7654321.

Third handshake: After receiving the packet, host A checks whether the ACK number is correct, that is, the seQ number+1 sent for the first time and the bit code ACK is 1. If yes, host A will send ack number= (SeQ +1 of host B),ACK=1. If host B receives the seQ value and ACK=1, the connection is established successfully.

Sequence number: indicates the position of the first digit of the data part of this packet in the whole data stream on our side (sender). (Note the use of “should.” Because for a transfer without data, such as ACK, although it has a SEQ, the transfer does not take place in the entire data stream. So the next actual data transmission will still start from the seQ that sent the last ACK packet.

Acknowledge number: What is the expected next sequence number of the other person (receiver)? Note that a SYN/FIN transmission without data increases the seq of the next packet by one, but an ACK transmission does not increase the seQ of the next packet.

Why in the last handshake of the three handshakes, the reply seq = x+1 in the diagram above.

The acknowledgement number serves to indicate to the other party that I am looking forward to receiving the next serial number. If you reply with ACK = 31, it means that you have received data numbered up to 30, and that the expected next data point is 31.

The last handshake, which carries no data by default, does not consume the sequence number because the SYN is not 1. Therefore, after the three-way handshake, the seQ in the next packet sent by the client is still X +1.

1. Why is establishing a connection protocol a three-way handshake, but closing a connection a four-way handshake?

When establishing a connection, ACK and SYN can be sent in a single message. When closing a connection, the passive closing party may need to send some data before sending a FIN packet to indicate that it agrees to close the connection. Therefore, ACK packets and FIN packets are sent separately in most cases.

2. Why does TIME_WAIT wait 2MSL before returning to CLOSED?

Two reasons exist: 1. The last ACK packet cannot be received by the peer. Therefore, you need to resend the ACK packet that may be lost. 2. After the connection is closed for a period of time, a new connection may be established with the same IP address and port. To prevent the repeated grouping of the old connection from reoccurring after the new connection has been terminated. 2MSL is sufficient for groups to survive up to MSL seconds before being discarded.

3. Why must it be a three-way handshake instead of a two-way handshake?

Remember that server resources are too valuable to waste! If after disconnection, the first handshake request packet will cause the server to open the connection, occupy resources and vulnerable to malicious attacks! Methods to prevent attacks and shorten server waiting time. Two handshakes tend to deadlock. If the reply group of the server is lost in transmission, it does not know what serial number S establishes. C considers that the connection has not been established successfully, and ignores any data groups sent by S and only waits for the connection to confirm the reply group. S repeatedly sends the same packet after the sent packet times out. This creates a deadlock.