End of the year, everyone is recapping something or the other so I decided to build a little something too.
Make your own WhatsApp Wrapped and preserve 'some' of your memories with your pals, using just the transcript.
Link in the replies
Meet my friend Kinshuk
Kinshuk scored 99.37 %ile in CAT preparing in stealth, not even his pet cat knew he was appearing for the test, let alone his friends.
Everyone say congats to Mr Kin.(@maiwonahihu)
Ever built a real-time chat app using WebSockets?
It is rarely just about code optimization.
It is about the plumbing underneath in the OSI model.
The Transport Layer.
If you want to understand how it works under the hood, you have to understand the war between TCP (reliability) and UDP (speed).
Here is a deep dive from basics to HTTP/3 and by extension the QUIC protocol.
The foundation first.
Before we even get to data delivery, we have IP at the
Network Layer.
Think of IP as the postal service of the internet.
It knows where to send data using IP addresses, but it does not care if the data arrives intact or in order.
To actually make applications work, we need a Transport Layer on top of IP.
This is where our two contenders enter.
___________________________________________________
- TCP (Transmission Control Protocol): the perfectionist.
For decades, the web lived on TCP because reliability mattered more than speed.
TCP is connection-oriented.
Before sending a single byte, it forces a 3-way handshake (SYN, SYN-ACK, ACK).
It is like calling someone and waiting for them to say hello before you start talking.
TCP is ordered.
If you send packets A, B, and C, the receiver processes them as A, B, C.
TCP is reliable.
If packet B gets lost, TCP stops everything and asks for a re-send.
__________________________________________________
- UDP (User Datagram Protocol): the speed demon.
UDP is the rebel.
It strips away safety features for raw performance.
Sort of like the cooler Ultimatrix (cloned by Albedo from the safer and more 'dull' Omnitrix made by his mentor Azmuth and in case you had a very boring childhood, you should know it is a Ben10 reference).
UDP is connectionless.
No handshake. It fires datagrams immediately.
UDP is unreliable and unordered.
Packet C can arrive before packet A. Or not arrive at all.
Why use it?
Because checking for errors takes time.
For video streaming or gaming, a lost frame is better than a buffering wheel.
__________________________________________________
Now comes the part most developers actually touch.
WebSockets and HTTP : When you build a chat app, you use WebSockets.
A WebSocket starts as a standard HTTP request running on TCP.
It sends an Upgrade header.
If the server agrees, the TCP connection stays open permanently.
This removes the overhead of opening new connections, but it is still bound by TCP rules.
If one packet drops, the stream stalls.
HTTP/1.1 and HTTP/2 - Both run on TCP.
This exposed a nasty flaw : Head-of-Line blocking.
Because TCP enforces strict ordering, if one packet is lost, everything behind it waits.
In HTTP/2, even multiplexed streams still suffer because they share a single TCP connection.
_________________________________________________
Now the modern era.
HTTP/3 and the QUIC protocol.
Google and the IETF realized that TCP semantics were ill-suited for multiplexed modern web traffic.
So they built HTTP/3 on top of UDP using a protocol called QUIC.
And yes, QUIC is not an acronym in IETF usage(while its initial name was proposed to be an acronym for Quick UDP Internet Connections).
QUIC adds reliability back on top of UDP, but does it intelligently.
If one stream like an image fails, others like text keep loading.
No global stall. No head-of-line blocking across streams.
__________________________________________________
Why does this matter?
Most of us use high-level libraries that hide all of this.
But if you want to optimize real-time systems, you need to see the difference, not just read about it.
__________________________________________________
I am building a Go-based visualization engine that pits raw TCP streams against UDP and QUIC in real time.
It includes a chaos engine that injects packet loss and latency so you can actually see head-of-line blocking happen.
Dropping soon. Code and benchmarks.