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.
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.
> 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."
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.
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. ;)
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.
> 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.
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
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.
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.
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.
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.
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".
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.
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.
https://www.rfc-editor.org/rfc/rfc9293.html
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.
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
"3 shake handshake"? :)
3 hands handshake, nothing unusual here
Next TCP: Zaphod
[flagged]
The information can be compressed into a table that shows what knowledge (columns) each party gain (rows) at each stage (cells) of the connection.
> 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
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.
There's this interesting comment by "John Day" on that page, does anyone have more context/detail?
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.
https://xkcd.com/927/
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
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.
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.
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.
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.
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.
That’s commitment
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".
1RTT FTW!