🎙️ Introduction
Hey Reader — welcome back
Okay, that did sound like an NPC. Let’s fix that.
In last blog, we really had an intense discussions about the internet rules.
If you’ve been following along, you should already have a rough mental map of:
- how devices connect,
- how DNS finds servers,
- and how TCP and UDP choose how data moves.
If not, quick catch-up here:
Blog 1: Understanding Network Devices - DEV Community
Blog 2: How DNS Resolution Works - DEV Community
Blog 3: DNS Record Types Explained - DEV Community
Blog 4: TCP vs UDP: When to Use What, and How TCP Relates to HTTP - DEV Community
The more I learn about this stuff, the more I understand why the internet is considered one of humanity’s greatest inventions.
Sometimes it honestly feels like I’m debugging packets with Iron Man holograms floating around me.
Anyway — before I drift again — let’s talk TCP.
🧨 When Data has no Rules
🤔 Internet with & without rules
Imagine a highway.
No traffic lights.
No lanes.
No signs.
Just vibes.
Every car rushes forward trying to win. Very GTA energy. Fun for chaos — terrible for reaching a destination.
That’s what the internet looks like without rules.
On the internet, cars are data packets.
And the “rules” are called protocols.
With protocols:
- Data arrives reliably
- Packets stay in order
- No duplication
- Errors are detected and corrected
Without protocols:
- Packets get lost
- Order breaks
- Duplicates appear
- Corrupted data slips through
Chaos. Every time.
🚫 Why Internet cannot rely on “best effort” alone
The internet’s core design is best effort delivery.
That means:
- The network tries to deliver packets
- But it makes zero promises
If a packet is lost, delayed, duplicated, or reordered — the network shrugs and moves on.
That’s fine for:
- video streaming
- voice calls
- casual browsing
But it’s disastrous for:
- file downloads
- emails
- online payments
When correctness matters, best effort isn’t enough.
That’s where TCP enters.
📌 TCP and 3-way handshake
As we have seen TCP in the last blog and discussed its meaning and full-form and where to use TCP , I won’t be able to repeat myself.
Don’t worry I will explain TCP here but in short…
You are always welcomed to checkout the last blog as well the series
🌐 TCP: Reliable Connections
TCP (Transmission Control Protocol) sits at the transport layer and is the backbone of reliable internet communication.
Key traits:
- Connection-oriented
- Reliable delivery
- Ordered data transfer
- No duplication
TCP doesn’t just send data.
It builds trust first.
🤝 Why a handshake is Needed
Before sending data, TCP asks one simple question:
“Are you there — and are you ready?”
The handshake:
- Confirms both sides are reachable
- Synchronizes sequence numbers
- Establishes reliability rules
Only after this agreement does data flow.
🔄️ TCP 3-Way Handshake
The TCP 3-way handshake establishes a reliable connection before data transfer begins.
The three steps:
-
SYN
Client: “I want to connect. Here’s my starting sequence number.”
-
SYN-ACK
Server: “I hear you. Here’s mine — and I acknowledge yours.”
-
ACK
Client: “Acknowledged. Let’s begin.”
After this, the connection is live.
Why three steps?
- Both sides confirm readiness
- Both sides acknowledge each other
- No assumptions, no guessing
That’s reliability by design.
- This guarantees both devices are fully ready and “in sync”
🗣️ Conversation Analogy:
- Client: “Hey, can we talk? My first word will be number 100.” (SYN)
- Server: “Sure! I heard you. My first word will be number 300.” (SYN-ACK)
- Client: “Got it, I’ll listen starting at 300.” (ACK)
📦 Reliable Data Transfer and Connection Closure:
Data Transfer After Handshake
- Once the handshake is established, data flows in segments
- Each segments has a unique number known as sequence number, receiver acknowledges receipt.
Role of Sequence Numbers and Ack’s
- Sequence number ensure data arrives in order
- Acks confirms successful delivery
- If an ACK is missing, the sender knows something is wrong
Detecting Packet Loss & prevention
- TCP uses timeouts and duplicates ACK’s to detect lost packets
- If a packet is lost, TCP retransmits it to maintain reliability
Ensuring Correctness
- TCP checks data integrity using checksums.
- If corrupted data is detected, it is discarded and retransmitted.
😁 Ending Thought
I’m trying my best to stay consistent with this series, but time management is starting to hit hard.
So for the next few blogs, the long introductions and ending thoughts might take a back seat.
The focus will stay the same though:
understanding how the internet actually works — clearly, honestly, and without magic.
Humor may go quiet for a bit, but the learning won’t.
Top comments (7)
Nice write-up 👏
I liked how you moved past definitions and focused on why TCP’s guarantees matter in real systems — especially around ordering, retransmissions, and correctness. The handshake + sequence number explanation ties in well with how HTTP and API reliability actually work in production.
Thank you for your feedback!!! 😁
This is awesome!! TCP finally makes sense with your analogy… love the SYN/SYN-ACK/ACK breakdown 😁 Tip: using real-life conversation examples like you did makes these network concepts stick way faster… keep them coming!!
This is what I was writing for.
Tech is super easy, if you filter you the hard words.
I'm glad this blog helped you. 💖
A well written article !
The visuals are very good too.
Thank you for posting these fundamentals and helping the community grow and learn.
That's great to hear!!
Getting support from the dev community means a lot. 💖
I've always read blogs of others, so writing my own for others is my way of thanking them.
Glad you like it 😁 Thank you
Yeah I liked it. I hope other do too. The community welcomed me with open arms. They will do the same for you too.
Keep writing