The internet is not a single wire between two computers.
Data travels through many routers, networks, and paths before reaching its destination.

If data were sent without rules:

• some parts could get lost

• some could arrive late

• some could arrive out of order

• some could get corrupted

Yet applications like websites, emails, and file downloads need correct and complete data.

TCP (Transmission Control Protocol) exists to solve this problem.

TCP is a transport protocol that ensures data is delivered:

• reliably

• in the correct order

• without corruption

Problems TCP is designed to solve

TCP is designed to handle the natural unreliability of networks.

It solves these key problems:

• Packet loss
  Some data may never arrive.

• Out-of-order delivery
  Data may arrive in the wrong sequence.

• Data corruption
  Data may get damaged during transmission.

• Network congestion
  Sending too fast can overwhelm receivers.

TCP does not assume the network is reliable.
It actively checks, corrects, and controls communication.

What is the TCP 3-Way Handshake

Before sending real data, TCP first establishes a connection between two computers.

This setup process is called the 3-Way Handshake.

Its purpose is to:

• confirm both sides are reachable

• synchronize communication

• prepare for reliable data transfer

Think of it as starting a phone call before having a conversation.

Step-by-step working of SYN, SYN-ACK, and ACK

Step 1: SYN – “Can we talk?”

The client sends a message asking to start a connection.

Meaning:

• “I want to communicate”

• “Here is my starting point”

This message is called SYN (synchronize).

No application data is sent yet.

Step 2: SYN-ACK – “Yes, I hear you”

The server replies back.

Meaning:

• “I received your request”

• “I am ready to communicate too”

This response is called SYN-ACK.

Now both sides know the other is reachable.

Step 3: ACK – “Great, let’s start”

The client sends a final confirmation.

Meaning:

• “I know you’re ready”

• “Let’s begin data transfer”

This message is called ACK (acknowledgement).

After this step, the TCP connection is established.

How data transfer works in TCP

Once the connection is open:

• data is broken into small pieces

• each piece is numbered

• pieces are sent across the network

The receiver:

• checks which pieces arrived

• confirms successful delivery

• waits for missing pieces if needed

Applications only see complete and ordered data.

How TCP ensures reliability, order, and correctness

Reliability

If a piece of data is lost:

• TCP notices it was not acknowledged

• TCP resends the missing piece

Nothing is silently dropped.

Order

Each piece of data has a position number.

Even if data arrives out of order:

• TCP rearranges it correctly

• applications receive data in sequence

Correctness

TCP checks data for errors.

If corrupted data is detected:

• it is discarded

• it is sent again

This prevents broken files and incorrect messages.

Flow control

TCP adjusts speed based on the receiver’s ability to handle data.

This prevents fast senders from overwhelming slower receivers.

How a TCP connection is closed

Just like a connection is opened carefully, it is also closed cleanly.

When communication is finished:

• one side signals it is done sending data

• the other side acknowledges

• the connection is closed only after both agree

This prevents:

• half-open connections

• wasted system resources

When two computers talk over the internet, they don’t send thoughts — they send data.

That data:

• travels long distances

• passes through many networks

• can arrive late, out of order, or not at all

So the internet needs rules to decide how data should be sent and received.
These rules are called protocols.

Two of the most important ones are TCP and UDP.

What are TCP and UDP (very high level)

TCP and UDP are transport protocols.

That means:

• they decide how data moves between two computers

• they sit below applications like browsers and APIs

Think of them as delivery methods, not messages themselves.

TCP: safe and reliable

TCP (Transmission Control Protocol) focuses on correctness.

What TCP cares about:

• data arrives completely

• data arrives in the correct order

• lost data is resent

Analogy:
A courier service with tracking and signature required.

If something goes wrong, TCP slows down and fixes it.

UDP: fast but risky

UDP (User Datagram Protocol) focuses on speed.

What UDP cares about:

• sending data as fast as possible

• no waiting, no checking

What UDP does not guarantee:

• delivery

• order

• retries

Analogy:
A live announcement over a loudspeaker — if you miss it, it’s gone.

Key differences between TCP and UDP

Simple rule:

• TCP = correctness first

• UDP = speed first

When to use TCP

Use TCP when:

• data must not be lost

• order matters

• correctness is more important than speed

Examples:

• loading a website

• sending emails

• file downloads

• database communication

If even one byte is missing, TCP makes sure it’s resent.

When to use UDP

Use UDP when:

• speed matters more than perfection

• small losses are acceptable

• real-time experience is important

Examples:

• video calls

• online gaming

• live streaming

• voice communication

If a packet is lost, UDP moves on instead of slowing everything down.

Common real-world examples

TCP examples

• Web browsing

• Email (SMTP, IMAP)

• File transfer

• APIs

UDP examples

• Zoom / Google Meet

• Online multiplayer games

• Live sports streaming

• DNS lookups (often)

What is HTTP and where it fits

HTTP (Hypertext Transfer Protocol) is an application-level protocol.

It defines:

• how requests are structured

• how responses are returned

• things like URLs, headers, status codes

Important point:
HTTP does not decide how data is delivered.
It only defines what the message looks like.

Relationship between TCP and HTTP

• HTTP creates the message

• TCP delivers that message reliably

So:

• HTTP sits on top of TCP

• TCP handles delivery

• HTTP handles meaning

Think:

• HTTP = letter content

• TCP = postal system

Why HTTP does not replace TCP

HTTP assumes:

• data will arrive correctly

• data will arrive in order

It depends on TCP to guarantee this.

Without TCP:

• HTTP responses could be broken

• webpages would load incorrectly

• APIs would fail unpredictably

That’s why HTTP needs TCP, not the other way around.

Common beginner confusion: “Is HTTP the same as TCP?”

No.

They work at different layers.

• TCP = how data is transported

• HTTP = how web communication is defined

They solve different problems.

When you open a website or use an app, your data travels through multiple networking devices before reaching the internet.
Each device has one clear job. Together, they make communication fast, reliable, and secure.

Think of this setup like a city transportation system, where different roles keep traffic moving smoothly.

What is a Modem and how it connects your network to the internet?

A modem is the device that connects your home or office to your Internet Service Provider (ISP).

Its main job is translation.

• The ISP sends internet signals in a form your local network can’t understand directly.

• The modem converts those signals into data your network devices can use.

• It also converts your outgoing data back into a form the ISP understands.

Real-world analogy:
A translator at an international border converting languages so both sides understand each other.

Important point:
A modem does not manage devices or traffic inside your network. It only connects you to the outside world.

What is a Router and how it directs traffic?

A router decides where data should go.

Inside your network, multiple devices exist:

• phones

• laptops

• servers

• printers

The router:

• gives each device an internal address

• sends incoming data to the correct device

• sends outgoing data to the internet through the modem

Analogy:
A traffic police officer at an intersection directing vehicles to the right roads.

Key difference from modem:

• Modem connects to the internet

• Router manages traffic inside and outside your network

Switch vs Hub: how local networks actually work

Both hubs and switches connect devices within a local network, but they work very differently.

Hub (old and inefficient)

A hub:

• sends incoming data to every device

• does not know who the data is for

Analogy:
A person shouting a message in a room and everyone hears it.

Problems:

• slow

• insecure

• wastes bandwidth

Switch (modern and efficient)

A switch:

• sends data only to the intended device

• learns which device is connected to which port

Analogy:
A postal worker delivering letters to the correct house.

This is why modern networks use switches, not hubs.

What is a Firewall and why security lives here?

A firewall controls what is allowed in and out of a network.

It:

• blocks malicious traffic

• allows trusted traffic

• enforces security rules

A firewall can sit:

• in a router

• as a dedicated device

• in the cloud

Analogy:
A security gate that checks IDs before letting people enter.

Without a firewall:

• networks are exposed

• attacks are easy

This is why security decisions often start here.

What is a Load Balancer and why scalable systems need it?

A load balancer sits in front of multiple servers.

Its job:

• receive incoming requests

• distribute them across servers

• prevent overload on any single server

Analogy:
A toll booth manager directing cars to the shortest queue.

Why this matters:

• higher performance

• better reliability

• systems can scale as traffic grows

In production systems, load balancers are essential.

How all these devices work together in real life

In a typical setup:

• Internet comes from the ISP

• Modem connects your network to the ISP

• Router directs traffic and assigns addresses

• Firewall filters unsafe traffic

• Switch connects multiple internal devices

• Load balancer distributes traffic to servers

Each device has one responsibility, but together they form a complete system.

Connecting this to backend systems and production deployments

For software engineers:

• APIs live behind load balancers

• Firewalls protect backend services

• Routers manage internal traffic between services

• Switches connect servers inside data centers

Understanding these devices helps you:

• design scalable systems

• debug network issues

• reason about production architectures

Before understanding cURL, let’s understand what a server is.

What is a server and why do we talk to it?

A server is just another computer on the internet that:

• stores data

• runs applications

• sends responses when asked

Whenever you:

• open a website

• log in to an app

• fetch data from an API

Usually, the browser does this talking for you.
But programmers often need to talk to servers directly.

That’s where cURL comes in.

What is cURL (very simple)?

cURL is a tool that lets you send messages to a server from the terminal.

Think of cURL as:

“A browser without buttons or visuals”

Instead of clicking links, you type commands.

Why do programmers need cURL?

Programmers use cURL to:

• Test APIs

• Check if a server is working

• See raw responses from servers

• Debug backend issues

cURL is useful because:

• It’s fast

• It works everywhere

• It shows exactly what the server sends back

Your first cURL command (simplest possible)

curl https://example.com

What this does:

• Sends a request to the server

• Fetches the webpage content

• Prints the response in the terminal

This is similar to opening a website — just without the browser UI.

Understanding request and response

Every server communication has two parts:

Request (what you ask)

• “Give me this page”

• “Send me this data”

Response (what server replies)

• Status (success or error)

• Data (HTML, JSON, text, etc.)

GET and POST (only the basics)

GET – asking for data

Used when you want to read something.

curl https://api.example.com/users

Meaning:

“Server, give me the users”

POST – sending data

Used when you want to send something.

curl -X POST https://api.example.com/users

Meaning:

“Server, I want to send data to you”

(Details can come later — this is enough for now.)

Using cURL to talk to APIs

APIs are servers that expect requests and return data, usually in JSON.

With cURL, you can:

• Call APIs

• See exact responses

• Test endpoints without writing code

This makes cURL a backend developer’s best friend.

DNS (Domain Name System) is the internet’s phonebook.

• Humans type names → google.com

• Computers need numbers → IP addresses

• Name resolution is the process of converting a name into an IP

Without DNS, you’d have to remember numeric IPs for every website — impossible at scale.

What is the dig command and when it is used

dig (Domain Information Groper) is a DNS debugging and inspection tool.

You use it to:

• See how DNS answers are found

• Check NS, A, MX, TXT records

• Debug DNS issues (wrong IP, missing record)

Think of dig as show me what dns is actually doing behind the scenes

DNS resolution happens in layers

DNS works top-down, not all at once:

Root servers → TLD servers (.com, .org) → Authoritative servers (google.com)

Understanding dig . NS — Root name servers

dig . NS

It asks Who is responsible for DNS root

Ans: Root name servers

Very simple words → Root is the top level directory of the internet

Understanding dig com NS — TLD name servers

What it asks: Who manages all .com domains?”

Ans : .com TLD name servers

Key idea:

• TLD servers know where each domain’s authoritative servers are

• They still don’t know the website’s IP

Understanding dig google.com NS — Authoritative name servers

as the command suggest google is authoritative name servers.

Key idea:

• These servers hold the real DNS records

• A, AAAA, MX, TXT live here

Understanding dig google.com — Full DNS resolution

What happens (simplified):

1. Recursive resolver starts at root

2. Root points to .com

3. .com points to google.com NS

4. Authoritative server returns IP address

5. Resolver gives IP to browser

Your browser:

• Doesn’t talk to root/TLD directly

• Uses a recursive resolver (ISP, Google DNS, Cloudflare)

Why NS records matter

NS records define authority.

They tell DNS:

• Who is allowed to answer for a domain

• Where the truth lives

Without correct NS records:

• No website

• No email

• No verification

How this connects to real browser requests

When you open a website:

• Browser → Recursive resolver

• Resolver uses the same steps you saw with dig

• dig just lets you see it manually

So:

DNS- Domain Name System

In very simple words DNS is the phonebook/phone directory of the Internet.

Why are DNS records needed?

One domains need answer to many questions like:

• Who manages it?

• Where is the website?

• Where should emails go?

• Is this domain verified?

Each DNS record solves one problem.

NS - Name System

NS controls the domains.

It tells which company is responsible for this domain’s DNS?

Eg. We have CloudFlare, GoDaddy, AWS\

They are the main authority office for the domain.

A Record – Domain → IPv4 address

A record maps a domain name to an IPv4 address.

example.com → 93.184.216.34

Like House name → Street address

AAAA Record – Domain → IPv6 address

Same as A record, but for IPv6 (newer IP format).

• A = IPv4

• AAAA = IPv6

CNAME Record – One name pointing to another name

CNAME points a domain to another domain name, not an IP.

www.example.com → example.com

Think of it as Nickname → Real name

MX Record – How emails reach you

MX (Mail Exchange) record tells:

Where emails for this domain should be delivered

example.com → Google mail servers

Like you have post offices for your address that handles the your letters.

TXT Record – Extra info & verification

TXT records store text for:

• Email security (SPF, DKIM)

• Domain ownership verification

It is a notice board message for the internet

Together these make the website and email work properly.