- The TCP three-way handshake is essentially an exchange of serial numbers between two communicating parties
- First handshake: The client sends a request packet
SYN
Contains the initial serial number of the client - Second handshake: After receiving the request, the server returns a reply packet generated based on the initial sequence number of the client
ACK
, and the initial serial number of the serverSYN
- Third handshake: After receiving a packet from the server, the client returns a reply packet generated based on the initial serial number of the server
ACK
Two handshakes
- An old SYN packet arrived at the server earlier than the latest SYN packet.
- In this case, the server sends a SYN + ACK packet to the client.
- After receiving the packet, the client can determine whether it is a historical connection (serial number expired or timed out) based on its own context. Then, the client sends an RST packet to the server to terminate the connection.
If the connection is two shake hands, will not be able to judge whether the current connection is historical connection, to prevent the connection request failed message segment suddenly and transmitted to the server, thus produce errors, three-way handshake could be on the client side (the sender) ready to send the message for the third time, the client with sufficient context to judge whether the current connection is historical connection:
What’s the serial number
- Both sides of the TCP protocol must maintain a “serial number”. Serial number is a key factor in reliable transmission. It serves the following functions:
- The receiver can remove duplicate data;
- The receiver can receive packets in sequence according to their serial numbers.
- You can identify which packets have been received by the peer.
- When a client sends a SYN packet with the initial SEQUENCE number, the server needs to send an ACK packet to indicate that the server has received the SYN packet. When the server sends the initial sequence number to the client, the server still needs to receive an ACK packet from the client. To ensure that the initial serial numbers of both parties can be reliably synchronized
What about the four handshakes
-
In fact, the four-way handshake can reliably synchronize the initial sequence numbers of both parties. However, the server can optimize the sending of connection request packets and acknowledgement packets into one step, so it is called “three-way handshake”.
-
However, two handshakes only guarantee that the initial serial number of one party can be successfully received by the other party, but there is no guarantee that the initial serial number of both parties can be received
Four waves of the hand
- The client sends a FIN to shut down client-to-server data transfer;
- When the server receives the FIN, it sends back an ACK with the received sequence number plus one. Like the SYN, a FIN takes a sequence number;
- The server closes the connection with the client and sends a FIN to the client.
- The client sends an ACK packet for confirmation and sets the sequence number of the ACK packet to 1.
Why is it three handshakes to establish a connection, but four waves to close it?
-
When establishing a connection, the server receives a SYN packet in LISTEN state and sends the ACK and SYN packets to the client.
-
After receiving a FIN packet from the peer party, the peer party stops sending data but can still receive the receipt. The peer party may not send all data to the peer party. Therefore, we can close the connection immediately or send some data to the peer party and then send a FIN packet to the peer party to close the connection. Therefore, our ACK and FIN are generally sent separately.
How does TCP ensure reliable transmission
TCP ensures data transmission reliability in the following ways:
- Checksum: TCP keeps the checksum of its head and data. This is an end-to-end checksum to detect any changes in the data during transmission. TCP discards the segment and does not acknowledge the receipt of the segment if the segment is checked or incorrect.
- Confirmation reply + serial number (cumulative confirmation + SEQ). After receiving a packet, the receiver acknowledges it (cumulative acknowledgement: the acknowledgement of all data received in sequence). TCP numbers each packet sent. The receiver sorts the packets and sends the ordered data to the application layer. The TCP receiver discards duplicate data.
- Flow control: Each side of the TCP connection has a fixed buffer space. The TCP receiver only allows the sender to send data that the buffer of the receiver can accept. When the receiver does not have time to process the data of the sender, the sender can be prompted to reduce the sending rate to prevent packet loss. TCP uses a variable-size sliding window protocol for flow control. (TCP uses sliding Windows to achieve flow control)
- Congestion control: Reduces data transmission when the network is congested.
The stop-wait protocol is also designed to achieve reliable transmission. Its basic principle is to stop sending each packet and wait for the confirmation of the other party. Send the next packet after receiving confirmation.
- Timeout retransmission: When TCP sends a segment, it starts a timer and waits for the destination to acknowledge receipt of the segment. If an acknowledgement cannot be received in time, the packet segment is resend.