See figure:
Serial number SEQ: 4 bytes, used to mark the sequence of data segments. TCP encodes a serial number for all data bytes sent in the connection. The number of the first byte is randomly generated locally. After the bytes are numbered, each message segment is assigned a number; The serial number seQ is the data number of the first byte in the packet segment.
Ack number: a 4-byte sequence number of the first data byte of the next packet segment expected to be received. Serial number indicates the number of the first byte of data carried in the message segment. The acknowledgment number refers to the number expected to receive the next byte; Therefore, the number of the last byte of the current packet segment +1 is the confirmation number.
ACK: Contains 1 bit. The ACK number field is valid only when ACK=1. When ACK=0, the confirmation number is invalid
SYN: Synchronizes the sequence number when the connection is established. When SYN=1 and ACK=0, it indicates that this is a connection request packet segment. If the connection is agreed, SYN=1 and ACK=1 are set in the response packet segment. Therefore, SYN=1 indicates that this is a connection request, or a connection accept message. The SYN bit is set to 1 only when TCP establishes a production connection. After the handshake is complete, the SYN bit is set to 0.
Terminate FIN: Used to release a connection. FIN=1 indicates that the sender of the packet has finished sending data and wants to release the transport connection
PS: ACK, SYN, and FIN are capitalized words representing flag bits that are either 1 or 0. Ack and seq are lowercase words for serial numbers.
Understand the three-way handshake process
First handshake: When establishing a connection, the client sends a SYN packet (SYN = J) to the server and enters the SYN_SENT state, waiting for confirmation from the server. SYN: Indicates the Synchronize Sequence number.
Second handshake: After receiving a SYN packet, the server must acknowledge the client’s SYN (ACK = J +1) and send a SYN packet (ACK = K). In this case, the server enters the SYN_RECV state.
Third handshake: After receiving the SYN+ACK packet from the server, the client sends an ACK packet (ACK = K +1) to the server. After the packet is sent, the client and the server enter the ESTABLISHED state (TCP connection is successful) and complete the three-way handshake.
Four wave process understanding
1) The client process sends a connection release packet and stops sending data. Release the header of the data packet, FIN=1, whose sequence number is SEq = U (equal to the sequence number of the last byte of the previously transmitted data plus 1). At this point, the client enters the fin-WaIT-1 state. According to TCP, FIN packets consume a sequence number even if they do not carry data.
2) After receiving the connection release packet, the server sends an acknowledgement packet with ACK=1, ACK= U +1 and its serial number seq= V. Then, the server enters the close-wait state. The TCP server notifies the higher-level application process that the client is released from the direction of the server. This state is half-closed, that is, the client has no data to send, but if the server sends data, the client still accepts it. This state also lasts for a period of time, i.e. the duration of the close-wait state.
3) After receiving the acknowledgement request from the server, the client enters the fin-WaIT-2 state and waits for the server to send the connection release message (before receiving the final data from the server).
4) After sending the final data, the server sends a connection release packet to the client, FIN=1, ACK = U +1. Because the server is in the semi-closed state, it is likely to send some more data. Assume that the serial number is SEQ = W, then the server enters the last-ACK state, waiting for the confirmation of the client.
5) After receiving the connection release packet from the server, the client must send an acknowledgement with ACK=1, ACK= W +1 and its serial number is SEq = U +1. In this case, the client enters the time-wait state. Notice That the TCP connection is not released at this time, and the client can enter the CLOSED state only after 2∗∗MSL (maximum packet segment life) and the corresponding TCB is revoked.
6) As long as the server receives the confirmation from the client, it will enter the CLOSED state immediately. Similarly, revoking the TCB terminates the TCP connection. As you can see, the server ends the TCP connection earlier than the client.
Frequently seen exam
Why is there a three-way handshake when you connect and a four-way handshake when you close?
A: After receiving a SYN request packet from the Client, the Server sends a SYN+ACK packet. ACK packets are used for reply, and SYN packets are used for synchronization. However, when the Server receives a FIN packet, the SOCKET may not be closed immediately. Therefore, the Server can only reply with an ACK packet to tell the Client, “I received the FIN packet you sent.” I can send FIN packets only after all packets on the Server are sent. Therefore, THE FIN packets cannot be sent together. Therefore, a four-step handshake is required.
Why does the TIME_WAIT state take 2MSL to return to CLOSE?
A: Although it is reasonable that all four packets are sent and we can directly enter the CLOSE state, we must pretend that the network is unreliable and the last ACK can be lost. Therefore, the TIME_WAIT state is used to resend ACK packets that may be lost. The Client sends the last ACK reply, but the ACK may be lost. If the Server does not receive an ACK, it repeatedly sends FIN fragments. Therefore, the Client cannot shut down immediately. It must confirm that the Server received the ACK. The Client enters the TIME_WAIT state after sending an ACK.
The Client sets a timer and waits for 2MSL of time. If a FIN is received again within that time, the Client resends the ACK and waits for another 2MSL. The so-called 2MSL is twice the MSL(Maximum Segment Lifetime). MSL refers to the maximum lifetime of a fragment in the network. 2MSL refers to the maximum time required for a send and a reply. If the Client does not receive a FIN again until 2MSL, the Client concludes that the ACK has been successfully received and terminates the TCP connection.
Why can’t we connect with two handshakes?
A: The 3-way handshake performs two important functions, both by preparing the parties to send the data (both parties know that they are ready) and by allowing the parties to negotiate the initial serial number, which is sent and confirmed during the handshake.
Now instead of three handshakes requiring only two handshakes, deadlocks can occur. As an example, consider the communication between computers S and C. Suppose C sends A connection request packet to S, which receives the packet and sends an acknowledgement reply packet. Following the two-handshake protocol, S considers that the connection has been successfully established and can start sending packets of data.
However, in the case that THE reply packet of S is lost in transmission, C will not know whether S is ready, do not know what sequence number S establishes, and C even doubts whether S has received its connection request packet. In this case, 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.
What if the connection has been established, but the client suddenly fails?
A: TCP also has a keepalive timer, so obviously if the client fails, the server can’t wait forever and waste resources. The server resets this timer every time it receives a request from the client, usually for two hours. If it does not receive any data from the client within two hours, the server sends a probe segment, which is then sent every 75 minutes. If there is no response after 10 probe packets are sent, the server assumes that the client is faulty and closes the connection.