Analysis of TCP three-way handshake and four-way handshake

TCP (Transmission Control Protocol) Transmission Control Protocol

TCP is the transmission control protocol used by the host to control the host layer. It provides reliable connection services and uses three handshakes to establish a connection:

The location code is the TCP flag. There are 6 types of tags: SYN (synchronous established online) ack (acknowledgement confirmation) Psh (push transfer) Fin (finish ended) RST (reset) URG (Urgent urgent)

Sequence Number acknowledge number (confirmation number)

The first handshake: host a sends a packet with a SYN = 1 and generates a random seq number = 1234567 packet to the server. Host B is known as SYN = 1, and host a requires online connection;

The second handshake: after receiving the request, host B needs to confirm the online information and send ACK number = (SEQ + 1 of host a), SYN = 1, ACK = 1, generate a random seq = 7654321 Packet

The third handshake: After receiving the handshake, host a checks whether the ACK number is correct, that is, the seq number + 1 sent for the first time, and whether the Ack is 1. If yes, host a will send ACK number = (SEQ + 1 of host B), ACK = 1 again. After host B receives the message, confirm that the seq value is set to ACK = 1, and the connection is established successfully.

After three handshakes are completed, data is transmitted between host a and host B.

 

In TCP/IP, TCP provides reliable connection services and uses three handshakes to establish a connection.
First handshake: when a connection is established, the client sends the SYN Packet (SYN = J) to the server and enters the syn_send status. Wait for the server to confirm;
The second handshake: when the server receives the SYN packet, it must confirm the customer's Syn (ACK = J + 1) and send a SYN Packet (SYN = K), that is, the SYN + ACK packet, the server enters the syn_recv status. The third handshake: the client receives the SYN + ACK packet from the server and sends the ACK (ACK = k + 1) Confirmation packet to the server, the client and server enter the established status and complete the three-way handshake. After three handshakes are completed, the client and the server start to transmit data.

Instance:

IP 192.168.1.116.3337> 192.168.1.123.7788: s 3626544836: 3626544836
IP 192.168.1.123.7788> 192.168.1.116.3337: s 1739326486: 1739326486 ack 3626544837
IP 192.168.1.116.3337> 192.168.1.123.7788: ACK 1739326487, Ack 1

The first handshake: 192.168.1.116 sends a location code SYN = 1, and generates a random seq number = 3626544836 packet to 192.168.1.123, 192.168.1.123 by SYN = 1 knowing 192.168.1.116 requires online connection;

The second handshake: after receiving the request, 192.168.1.123 needs to confirm the online information and send ACK number = 3626544837, SYN = 1, ACK = 1 to 192.168.1.116. packets with seq = 1739326486 are randomly generated;

The third handshake: After 192.168.1.116 is received, check whether the ACK number is correct, that is, the seq number + 1 sent for the first time, and whether the Ack is 1. If yes, 192.168.1.116 then sends ack number = 1739326487, ACK = 1, 192.168.1.123 receives the message and confirms that seq = seq + 1, ACK = 1, and the connection is established successfully.

 

Illustration:
A three-way handshake process (Figure 1, Figure 2)

(Figure 1)

(Figure 2)

The flag of the first handshake (figure 3)
We can see that there is only one synchronization bit in the flag, that is, the request (SYN)

(Figure 3)

The flag of the second handshake (Figure 4)
We can see that there is a confirmation and synchronization bit in the flag, that is, the response (SYN + ACK)

(Figure 4)

The flag of the third handshake (figure 5)
We can see that there is only one confirmation bit in the flag, that is, re-confirmation (ACK)

(Figure 5)

A complete three-way handshake, that is, request-response-confirm again

Four breaking up:

Because the TCP connection is full-duplex, each direction must be closed separately. This 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 between the two parties. a tcp connection can still send data after receiving a fin. First, the party that closes the service will take the initiative to close the service, and the other party will passively close the service.

(1) Client A sends a fin to disable data transmission from client a to server B (packet segment 4 ).

(2) When server B receives the fin, it sends back an ACK and confirms that the serial number is 1 (packet segment 5 ). Like SYN, a fin occupies a sequence number.

(3) server B Closes the connection with client a and sends a fin to Client A (packet segment 6 ).

(4) Client A sends back the ACK message for confirmation, and sets the confirmation sequence number to receive the serial number plus 1 (packet segment 7 ).

 

 

1. Why is the three-way handshake while the four-way handshake when the connection is closed?

This is because the socket in the listen status of the server can respond to ack and SYN after receiving the SYN Packet connection request) it is sent in a message. However, when the connection is closed, when the other party receives the fin Message notification, it only indicates that the other party has no data to send to you; but not all your data may have been sent to the other party, therefore, you may not close the socket immediately, that is, you may need to send some data to the other party, and then send the fin message to the other party to indicate that you agree to close the connection now, therefore, the ACK messages and fin messages are sent separately in most cases.

2. Why does the time_wait status still need to be 2 MSL before it can be returned to the closed status?

This is because both parties have agreed to close the connection, and the four handshake packets are also coordinated and sent, it can be directly returned to the closed state (just like from syn_send to establish State), but because we must assume that the network is unreliable, you cannot guarantee that the last ACK message you sent will be received by the other party. Therefore, the socket in the last_ack status of the other party may fail to receive the ACK message due to timeout, but resend the fin message, therefore, the time_wait status is used to resend potentially lost ACK packets.