September 29th, 2024

Why TCP needs 3 handshakes

TCP establishes a reliable connection through a three-way handshake involving SYN, SYN-ACK, and ACK packets, ensuring readiness, confirming sequence numbers, preventing duplicate connections, and maintaining packet order.

Read original article

CuriosityFrustrationAgreement

The Transmission Control Protocol (TCP) employs a three-way handshake to establish a reliable connection between a client and a server. This process involves three steps: the client sends a SYN packet to initiate the connection, the server responds with a SYN-ACK packet to acknowledge the request and provide its own sequence number, and finally, the client sends an ACK packet to confirm the connection. This handshake is crucial for several reasons: it ensures that both parties are ready for data transmission, confirms the initial sequence numbers to prevent confusion with delayed packets, and allows both sides to verify their respective transmission and reception capabilities. The three-way handshake also helps avoid issues such as duplicate connections that could arise if fewer handshakes were used. The sequence numbers exchanged during this process are essential for maintaining the order of packets and ensuring reliable communication. Overall, the three-way handshake is a fundamental aspect of TCP that facilitates robust and orderly data transmission over networks.

- TCP uses a three-way handshake to establish a reliable connection.

- The handshake involves SYN, SYN-ACK, and ACK packets exchanged between client and server.

- This process confirms both parties' readiness and their initial sequence numbers.

- The three-way handshake prevents issues like duplicate connections and ensures data integrity.

- Sequence numbers are crucial for maintaining the order of packets in TCP communication.

Timeliness without datagrams using QUIC

The debate between TCP and UDP for internet applications emphasizes reliability and timeliness. UDP suits real-time scenarios like video streaming, while QUIC with congestion control mechanisms ensures efficient media delivery.

Implementing a Single-Threaded Blocking Bare Bones TCP/IP Server

The article explains creating a single-threaded TCP/IP server in Java, covering port listening, client connections, message handling, and server behavior. It discusses networking concepts and demonstrates concurrent client connections.

Comparing TCP and QUIC (2022)

Geoff Huston compares TCP and QUIC protocols in the October 2022 ISP Column. QUIC is seen as a transformative protocol with enhanced privacy, speed, and flexibility, potentially replacing TCP on the Internet. QUIC offers improved performance for encrypted traffic and independent transport control for applications.

Y'all are sleeping on HTTP/3

HTTP/3, utilizing the QUIC protocol, now accounts for over 30% of web traffic, enhancing speed and reliability while addressing TCP limitations, though challenges in tooling and support persist.

RFC: 64-Bit Sequence Numbers for TCP

The draft proposes optional 64-bit sequence numbers for TCP to improve performance on high-speed networks while ensuring backward compatibility with 32-bit implementations and addressing security concerns during the handshake.

AI: What people are saying

The comments on the TCP handshake highlight various perspectives on its necessity and efficiency.

Some commenters argue that the three-way handshake is inefficient, especially in high-latency scenarios, suggesting alternatives that eliminate repeated exchanges.
Several comments draw analogies to communication scenarios, emphasizing the importance of confirmation and acknowledgment in establishing reliable connections.
There is a discussion about the theoretical aspects of handshakes, with some suggesting that more than three handshakes do not significantly enhance reliability.
Concerns are raised about the TCP header's flexibility and the practicality of its defined states and flags.
Real-world examples, such as pilot communication, are used to illustrate the importance of clear acknowledgment in connection handovers.

15 comments

By @veblen - 7 months

Imagine two blind people who want to have a conversation. Before they start, each person needs to ensure that the other can both speak and hear. Typically, one person begins by asking, 'Can you hear me?' to check if the other can hear them. The second person responds with 'Yes,' confirming that they can hear. Then, the second person asks, 'Can you hear me?' and the first person replies, 'Yes,' completing the process.

In total, there are four exchanges (two questions and two answers). However, if you look closely, the second person's reply of 'Yes' already confirms that they can both hear and speak. Therefore, the second 'Can you hear me?' is unnecessary. With just three exchanges (one question and two answers), both people know that they can send and receive messages.

By @Pikamander2 - 7 months

> Theoretically, even more than three handshakes would not guarantee a "completely reliable" TCP connection. However, through three handshakes, it can at least be confirmed that the connection is "basically usable." Increasing the number of handshakes would merely increase the confidence level in the "connection availability."

This sounds like a variation of the Two Generals' Problem: https://en.wikipedia.org/wiki/Two_Generals%27_Problem

By @sedatk - 7 months

TL;DR: "Because if TCP handshake were 2-way only, the receiver couldn't confirm if it could send packets successfully or sender could receive them".

And that sounds bogus to me. Connection initiation isn't about testing if packets can reach or not. It's about acknowledgement, building a two peer consensus about how to handle upcoming packets from a peer, not reliability checks. In that sense, I don't even think the third step is necessary, but apparently, it's needed to handle the case of both endpoints going into a timeout loop, this article explains it perfectly: https://www.baeldung.com/cs/handshakes

By @userbinator - 7 months

I've always found the bitfields in the TCP header to be either too loosely defined or the standard insufficiently lax, since there are many combinations that make theoretical sense but don't work well or at all in practice. E.g. SYN+ACK+FIN+DATA would be perfect for a very short-lived connection that transfers a single segment. IMHO they should've either just used a "state" field that enumerates all possible states a packet is intended to have, or usefully defined all the possible combinations of the flags.

By @krackers - 7 months

There's this interesting comment by "John Day" on that page, does anyone have more context/detail?

By @gorfian_robot - 7 months

back in the day we had some chats with Vint Cerf during the development of Delay-tolerant networking (DTN) for primarily for use in space scenarios (though there are other scenarios). no way SYN, SYN-ACK, ACK type was gonna cut it. I found a light overview here: https://www.quantamagazine.org/vint-cerfs-plan-for-building-...

By @stevecalifornia - 7 months

Pilots also do a 3 handshake exchange when handing over control to the other pilot.

Pilot: "You have the plane." Co-Pilot: "I have the plane." Pilot: "You have the plane."

The third statement is the pilot acknowledging that the transfer of control has completed. Without it, the co-pilot doesn't positively know that the pilot knows that control has been handed over.

As an aside, Air France 447 was a crash where the co-pilot was pulling back on the stick without the captain knowing. The captain couldn't understand why his controls weren't having the intended effect. Both pilots were making inputs, unaware of each other.

By @geon - 7 months

Great conclusion:

3 is an arbitrary number, but one that works well in practice.

By @ali_piccioni - 7 months

The information can be compressed into a table that shows what knowledge (columns) each party gain (rows) at each stage (cells) of the connection.

            Can         Can
           Transmit  | Receive
  
 Client    SYN-ACK     SYN—ACK            
 Server    ACK         SYN

By @teleforce - 7 months

I think the more important question is why TCP only using positive acknowledgement (ACK) but not negative acknowledgement (NACK)?

By @ingen0s - 7 months

That’s commitment

By @ggm - 7 months

1RTT FTW!

By @deathanatos - 7 months

I've always considered it one handshake, with 3 packets, which are for some reason then called "3 way". But it's one 3-way-handshake.