TCP three-way handshake & four-way handshake (schematic)

Classic three-way handshake: (# add, "handshake" refers to the link from the left to the right in the figure)
 
The classic four-way handshake closure diagram:
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 bit code is the tcp flag bit. There are 6 types of labels: SYN (synchronous online) ACK (acknowledgement confirmation) PSH (push transfer) FIN (finish ended) RST (reset) URG (urgent) Sequence number (sequential number) acknowledge number (confirmation number) first handshake: host A sends A syn = 1 packet to the server and generates A random seqnumber = 1234567 packet. Host B is known by SYN = 1, 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 server's SYN + ACK package and sends the ACK (ack = k + 1) Confirmation package to the server. After the package is sent, the client and server enter the ESTABLISHED status, complete three handshakes. 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: S3626544836: 3626544836
IP 192.168.1.123.7788> 192.168.1.116.3337: S 1739326486: 1739326486 ack3626544837
IP 192.168.1.116.3337> 192.168.1.123.7788: ack 1739326487, ack 1 first handshake: 192.168.1.116 sends a location code syn = 1, randomly generates a data packet with seqnumber = 3626544836 to 192.168.1.123, 192.168.1.123 the SYN = 1 knows that 192.168.1.116 requires an online connection;
The second handshake: after receiving the request, 192.168.1.123 needs to confirm the online information and send acknumber = 3626544837, syn = 1, ack = 1 to 192.168.1.116. packets with seq = 1739326486 are randomly generated. The third handshake: when 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 will send ack number = 1739326487 again, ack = 1, 192.168.1.123 after receiving the message, confirm seq = seq + 1, ack = 1, 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 are two validation bits and synchronization bits 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 validation bit in the flag, that is, re-confirmation (ACK)

(Figure 5)

A complete three-way handshake, that is, request-response-confirm again
Four breakups: 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 cannot immediately close the SOCKET, that is, you may need to send some data to the other party, and then send the FIN message to the other party, indicating 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.