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 think one important mention here is that fragmentation happens at two levels: most commonly, an upper layer protocol message (such as an HTTP request) is fragmented into several TCP segments, each with one TCP header. Those TCP segments themselves can sometimes be fragmented into multiple IP packets if the TCP MSS (maximum segment size) is larger than the Ethernet MTU (maximum transmission unit).

IP fragmentation is typically avoided, and in IPv6 it is only allowed at the originator of a packet - if a router is trying to route an IPv6 packet larger than the MTU of the outgoing link's MTU, it must drop the packet and send a signal about the MTU back. An IPv4 router may fragment the packet, but this rarely works well in practice.

I suppose, if you want to squeeze it into the definition given in RFC 9293, but that same RFC only uses "fragmentation" to denote "internet fragments" or IP-level fragmentation.

You're referring to "segmentation" which is also defined in that RFC. https://www.rfc-editor.org/rfc/rfc9293.html#name-segmentatio...

Appreciate pedantry when it’s absolutely warranted. Well said!

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.

"3 shake handshake"? :)

3 hands handshake, nothing unusual here

Next TCP: Zaphod

It all started when Jon Postel obtained the Holy Hand Grenade of Antioch and reverse-engineered it...

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

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).

it's called 3-way because from the point of view of a network message diagram, there are three arrows which change direction at each step.

what it really amounts to is a three phase transaction.