> 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
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
Thanks for the link with the correct explanation:
Particularly, the two-way handshake presents potential problems when the ACK message from the server delays too much. Thus, if a connection timeout occurs, the client sends another SYN message with a new sequence number (Z, for example) to the server. However, if the server previously sent an ACK (which is delayed), it’ll discard this new SYN message. The client, in turn, receives the delayed ACK and assumes that it refers to the last sent SYN message. Here’s where the error happens: the client will send messages with the sequence number Z, while the server expects messages following the sequence number X.
That is possibly even more wrong explanation. Hosts do not blindly assume what is getting acknowledged by ACKs
Thanks for explaining the why. I'm glad it falls somewhere between the X and the Z.
The thing the consider is who is the first to send data over the connection.
If it is the client, then a two-way handshake is enough: client sends a SYN, server sends a SYN+ACK, then the clients data which ACKs the server's SYN. These days that is the most common model. HTTP and TLS work like that.
However, what if the server sends first? For example the banner of SMTP. In that case the client sends a SYN, the server sends a SYN+ACK, the client sends an ACK and only then the server start sending data.
In general, an operating system doesn't know what is going to happen. So the client's kernel will just send the ACK immediately even if it will be followed by a data segment shortly after.
You can only reach consensus if the peers can each receive packets that the other sent.
So reaching consensus and testing for reachability in both directions are the same.
In a client/server scenario, the client knows the connection is good when it receives the SYN+ACK, but the server doesn't know until it receives the resulting ACK. So the third packet is necessary to communicate consensus to the server; it doesn't need to be a pure ACK though, it can have data, if the client's stack makes it possible to queue outgoing data before the SYN+ACK is received.
> You can only reach consensus if the peers can each receive packets that the other sent. So reaching consensus and testing for reachability in both directions are the same.
No, that's not the intent of a handshake. Assume a hypothetical Internet where every node has guaranteed connectivity to every other node that never fails. Do we suddenly lose the need to do a 3-way handshake? No. It's not about testing connectivity, that's semantically wrong. And what's the meaning of testing connectivity for a connection of an arbitrary length and with a quality of unknown degree throughout? It doesn't make any sense.
There is no "knowing the connection is good", there is a process of building up consensus. The peers are only interested in an answer to this question: "Does the other party assume a connection?".
If we knew the answer to that question beforehand, we wouldn't need a handshake at all. Reachability, transmissibility are all irrelevant. And, UDP actually works like that. Both endpoints assume willingness to connect. That's why you don't need a handshake with UDP.
TCP-FO worked liked that too, removing the need for a TCP handshake completely, because it could persist the consensus information.
UDP doesn't include a protocol handshake, and there is no consensus on if the peers are communicating, unless the application adds that.
Lack of consensus/lack of handshake on UDP is why protocols with large responses become tools for DDoS reflection, and TCP protocols with large responses don't. TCP protocols with large responses can still be used for DDoS, but only when the target takes an active part --- either filling its outbound bandwidth to serve the large response to distributed requestors or being induced into making a request with a large response that fills its inbound bandwidth.
TCP Fast Open is interesting, but didn't seem to go anywhere. Speculatively including one MSS worth of data in the handshake process seems like it could be useful in some circumstances, but the server side implications of processing a request without an expectation that the client will receive the response are hard. (Of course, TCP can't and doesn't guarantee the client will receive the response, but when you have recent consensus on communication, you can expect it will). The crypto context shows evidence of past communication, but does not show evidence of current communication.
Yeah, as a proof it is dubious as it doesn't really define what "established" means in this context.
The baeldung article is just wrong
> The client, in turn, receives the delayed ACK and assumes that it refers to the last sent SYN message
ACKs have acknowledgement numbers, so this sort of confusion can not happen.
without a 3-way handshake, wouldn't it be easier to do spoofing? or a man-in-the-middle attack?
I think now there are ways to do the 3-way handshake in hardware at hardware speeds, and only involve software if the connection has been vetted. This can protect against Denial-Of-Service attacks.
> I think now there are ways to do the 3-way handshake in hardware at hardware speeds, and only involve software if the connection has been vetted. This can protect against Denial-Of-Service attacks.
Do we need hardware for this? Syncookies have provided a software method to handle large volumes of inbound syn without memory restrictions since the late 90s, and it's been in all major platforms except Mac since the late 2000s; Apple forked FreeBSD's tcp months before FreeBSD added syncookies, and last I checked, Apple never pulled them in. My testing is a bit old, but I had more trouble generating line rate syns at 2x10g than handling them several years ago. Are syncookies in software enough at 100g? I'm not sure, but I'd assume so. There's plenty of things to hardware accelerate on a NIC, but syn handling doesn't seem worthwhile IMHO.
No and no. IP spoofing was already trivial with 3-way handshake. That's why random TCP sequence numbers were introduced. It's now harder, but for some scenarios, SYN cookies might also be needed.
There's this interesting comment by "John Day" on that page, does anyone have more context/detail?
No, but I found the comment more interesting after learning what his background is (based on the name/email left in the comment):
> John Day has been involved in research and development of computer networks since 1970, when his group at the University of Illinois was the 12th node on ARPANet (precursor to the Internet) and has developed and designed protocols for everything from the data link layer to the application layer. Also making fundamental contributions to research on distributed databases. He managed the development of the OSI reference model, naming and addressing, and a major contributor to the upper-layer architecture. He was a major contributor to the development of network management architecture, working in the area since 1984 and building and deploying LAN products and a network management system, a decade ahead of comparable systems. Mr. Day has published Patterns in Network Architecture: A Return to Fundamentals (Prentice Hall, 2008), which has been characterized (embarrassingly) as “the most important book on network protocols in general and the Internet in particular ever written.” The book analyzes the fundamental flaws in the Internet and proposes what appears to be the only path forward. Today Mr. Day splits his time between making this new path a reality and teaching at Boston University. Mr. Day is also a recognized scholar in the history of cartography focusing on 17thC China, and is past President of the Boston Map Society.
You can find the original paper by Watson online which explains it in more detail. The 3 way handshake is in fact not necessary. I believe the delta-t protocol was one of the available protocols in OSI as well. TCP/IP being the standard now is not due to the fact that it was technically the best. In fact, there are multiple shortcomings.
The delta-t protocol is also used in RINA, which was invented by John Day. It is also used in Ouroboros (https://arxiv.org/pdf/2001.09707), and I can confirm it works. ;)
The actual delta-t protocol spec has historically been quite hard to find, but is freely available from here: https://www.osti.gov/biblio/5542785
Also related and of interest in this connexion: CurveCP and its handshake, https://curvecp.org/packets.html
There were several competing standards on the early networks, and almost every ambitious commercial entity wanted to embed their licensed IP into the webs core transport layer or lower on the OSI stack.
We take for granted the inter-connectivity of most modern equipment, but to this day companies still try to create synthetic technology monopolies to cash-in. i.e. to sustain a tenuous service commodity out of something that has essentially been free since the mid 1990s.
Philosophically it doesn't matter TCP is imperfect, but rather that the inter-connectivity is compatible with the inertia of the installed infrastructure.
One can indeed optimistically ignore the TCP connection drop and syn part of standards to tunnel/reverse-proxy though certain censorship firewalls... but it still does not make it safe for the people that live under such regimes.
Does this make it more or less clear? =3
> We take for granted the inter-connectivity of most modern equipment, but to this day companies still try to create synthetic technology monopolies to cash-in. i.e. to sustain a tenuous service commodity out of something that has essentially been free since the mid 1990s.
This is why as a network engineer I always advocate for open standards everywhere I can to avoid vendor lock-in. The classic one is using OSPF instead of EIGRP on Cisco routers (or their other proprietary protocols). Nowadays this is much tricker with cloud computing and black box stuff like SDN/SDWAN.
Most good engineers I've met follow the same open standards prioritization recommendation.
The drama that goes on inside Cisco could fill a soap opera season. =3
Great conclusion:
> 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."
3 is an arbitrary number, but one that works well in practice.
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 SYNIs your bottom row backwards? Surely the server learns that the client can transmit when it receives a SYN and that it must have received the SYN-ACK when the ACK comes back.
I think the more important question is why TCP only using positive acknowledgement (ACK) but not negative acknowledgement (NACK)?
Selective acknowledgement (SACK) effectively indicates which sequence numbers are missing when there's packet loss. It's optional, but afaik, used by nearly everything on today's internet.
What would a NACK add? TCP can already send an ACK for the last successful sequence number, telling the sender to retransmit packets after that sequence number. Due to latency and large window sizes, it's far more efficient to just resend all the data than NACK individual packets.
Perhaps GP considers a NACK more semantically easier to understand on an intuitive level, instead of the implicit NACK with "I know you sent 8, but we're really at 4 so resume from that". But I do agree that it's more efficient for the remote host to just immediately establish "4 was the last point we are ok at".
It is not possible to distinguish between the absence of negative ACK and the loss of it.
That’s commitment
1RTT FTW!
TFO has unfortunately been ruined by middleboxes meddling. Maybe once IPv6 becomes more popular and NATs (that also mangle) fall out of favor we'll have more luck enabling it.
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.
It is only one handshake, with 3 packets.
The author made a mistake in the title, but the content is mostly correct (fails at "First Handshake", "Second Handshake" and "Third Handshake").
He should call them stages, phases or something like that.
To be really specific, they are not "packets" but at the TCP protocol level, they are "segments"
TFA appears to use both terms sort of interchangeably, which is uncool when describing a formalized protocol standard!
Segments are encapsulated in IP datagrams, or packets, which are, in turn, encapsulated in other PDU types, such as Ethernet frames.
Appreciate pedantry when it’s absolutely warranted. Well said!
And one could ask are segments without well data segment a segments? As mostly 2 first PDUs in exchange do not contain data...
Yes they are. I don't know what "well data segment" is, but perhaps you mean a payload. TCP streams consist of segments, and the fragmentation or collection of those logical segments into packets is a function of the lower-layer protocols which are not TCP.
I've consider it to be 4 handshakes but the middle 2 are merged.
There is a scenario called “simultaneous open”, which has 4 packets handshake and is a wonderful source of corner cases and debugging. Mostly doesn’t happen these days, but is possible by standard and is explicitly described.
It has been used for NAT traversal when both parties are behind NAT, but sadly it doesn't work with all routers.
The reason it’s considered a “3-way” handshake is mostly latency related. If the delay sending a packet between the client and server is k, there are 3 hops involved in establishing a connection so the time is 3k. Confusingly, this has nothing to do with how many devices are involved.
> The reason it’s considered a “3-way” handshake is mostly latency relate
Its not latency related. Its because there 3 packets involved in completing the handshake.
> If the delay sending a packet between the client and server is k, there are 3 hops involved in establishing a connection so the time is 3k.
Also I think calling it "hops" is not correct. A hop occurs when a packet passes through a router.
> Confusingly, this has nothing to do with how many devices are involved.
In a TCP handshake there are only two devices involved (disregarding any middleboxes that meddle with the connection).
Its just 1 packet: an RST with a data field containing a swear word.
Jokes like that make me realize I understand the matter more than I want to :'D
I did not know RST packets had a data field lol
"3 shake handshake"? :)
You, the server and the NSA Collection.
3 hands handshake, nothing unusual here
Next TCP: Zaphod
[flagged]
Kind of, but not exactly. The article treats the channels as immutable, ie you can tell whether a channel is working or not by sending one packet. In this assumption, you'd have to send three packets for both sides to discover if all four ways work (server send, server receive, client send, client receive), but after that you'd need no more assurance.
In the two generals problem, the channel can fail at any time (which is what happens in real life), so no amount of handshakes can assure you. Because of the above, I don't agree with their conclusion that more handshakes is better. Either you assume immutable channels, so you only need three, or mutable channels that can fail any time, so you need infinite.