How the Internet Really Works: From Packets to TCP, UDP, HTTP, and CDNs

When we say “the internet is down”, what we usually mean is that one device or rule in a long global chain stopped doing its job.

The internet is not a single system.
It is a massive network of networks, spread across countries, oceans, and data centers—held together by cables, routers, and most importantly, rules.

This article is a complete mental model of:

• How data travels across the world

• Why TCP and UDP exist

• How HTTP fits on top

• Why CDNs make things fast

• How everything connects end-to-end

No deep protocol internals.
Just behavior, purpose, and real-world understanding.

The Internet Is a Network of Networks

Before any backend service receives a request, data does not move as a single piece.

It is broken into small packets.

These packets may travel through:

• Local ISP networks

• National networks

• International backbone cables

• Routers owned by different organizations

• Data center networks

All of this can happen in milliseconds.

How a Request Travels Across the World

Imagine a client in one country requesting data from a server in another country.

The request:

1. Leaves the client device

2. Goes to the local ISP

3. Enters national networks

4. Travels via international backbone cables

5. Reaches the destination country

6. Passes through regional networks

7. Reaches the server hosting the domain

The response follows a similar path back.

No device knows the full journey.

Routers: The Toll Booths of the Internet

Each router acts like a toll booth.

• It receives a packet

• Reads the destination IP

• Decides where to send it next

That’s it.

A router does not know:

• Where the packet started

• The full path

• The final application logic

It only knows the next best hop.

Bandwidth, Latency, and Congestion

How fast data moves depends on:

• Bandwidth – how much data can flow at once

• Latency – how long a packet takes to travel

• Congestion – how busy the network is

Even high bandwidth cannot fix high latency caused by distance.

From ISP to Your Device

When the response reaches your location:

1. Your ISP delivers the data

2. The modem converts signals into digital data

3. The router checks its routing/NAT table

4. The data is forwarded to the correct device using a private IP

At this point, packets reach your machine.

But moving packets alone is not enough.

Why the Internet Needs Rules

Packets can:

• Get lost

• Arrive out of order

• Arrive duplicated

• Arrive corrupted

So the internet needs rules to decide:

• Should we retry?

• Should we wait?

• Should we ignore missing data?

These rules are implemented using transport protocols.

The two most important ones are:

• TCP

• UDP

What Is TCP? (Transmission Control Protocol)

TCP is about reliability.

Its goal is to make sure:

• Data arrives

• Data arrives in order

• Missing data is retransmitted

• Both sides agree before communication starts

Mental Model

TCP is like a courier service with tracking and confirmation.

• “Did you receive this?”

• “Yes.”

• “Okay, sending the next one.”

Key Characteristics

• Connection-based (3-way handshake)

• Reliable

• Ordered

• Slower (because of checks)

If data is important, TCP waits.

What Is UDP? (User Datagram Protocol)

UDP is about speed.

It sends data without:

• Confirmations

• Retries

• Ordering guarantees

Mental Model

UDP is like a live broadcast or announcement.

• Data is sent

• No one checks if it arrived

• If you miss it, you miss it

Key Characteristics

• Connectionless

• Fast

• Best-effort delivery

• No retransmission

UDP does not care about loss.

TCP vs UDP

When to Use TCP

Use TCP when:

• Data correctness matters

• Order matters

• Loss is unacceptable

Examples

• HTTP / HTTPS

• APIs

• File downloads

• Emails

• Database connections

Even 1 missing byte can break things.

When to Use UDP

Use UDP when:

• Speed matters more than perfection

• Real-time delivery is required

• Small losses are acceptable

Examples

• Live cricket match streaming

• Video calls

• Voice calls

• Online gaming

• DNS queries

Losing an old packet is better than waiting for it.

TCP vs UDP Communication Flow

TCP (Reliable, Ordered)
----------------------
Client                     Server
  | -------- SYN --------> |
  | <----- SYN-ACK ------- |
  | -------- ACK --------> |
  |                        |
  | --- Data (Packet 1) -->|
  | <----- ACK ------------|
  | --- Data (Packet 2) -->|
  | <----- ACK ------------|
  |                        |
  | ---- FIN ------------> |
  | <---- FIN-ACK -------- |

UDP (Fast, Unreliable)
---------------------
Client                     Server
  | --- Data (Packet 1) -->|
  | --- Data (Packet 2) -->|
  | --- Data (Packet 3) -->|
  |                        |
(No acknowledgments, no retries)

Why Live Streaming Uses UDP

In a live match:

• Old frames are useless

• Waiting causes lag

• Speed matters more than accuracy

That’s why:

• Video may skip

• Audio may glitch

• But the stream stays live

What Is “Local Caching”?

Local caching means:

Keeping a copy of data closer to the user so it doesn’t have to be fetched from far away every time.

Instead of requesting the same data again and again from a central server (which may be in another country), the system stores a temporary copy somewhere closer.

Simple example

• First user requests a movie

• The movie is fetched from the main server

• A copy is stored nearby

• Next user gets the movie from the nearby location

Result:

• Faster response

• Less internet travel

• Lower latency

What Exactly Is a CDN?

A CDN (Content Delivery Network) is a globally distributed network of servers whose job is to serve content from the closest possible location to the user.

Instead of one server serving the whole world, a CDN has hundreds or thousands of servers placed in different geographic locations.

These servers are called edge servers.

Key idea:
A CDN moves data closer to users, not users closer to data.

How a CDN Works

Let’s say you open Netflix or any website using a CDN.

1. User Makes a Request

• You request a movie or a web page

• Your request goes to the nearest CDN edge server (not the main server)

This routing usually happens using DNS-based routing or Anycast IPs.

2. Cache Hit vs Cache Miss

Case 1: Cache Hit (Most Common)

• The content is already stored on the edge server

• The CDN serves it immediately

Fast, low latency, no long-distance travel

Case 2: Cache Miss

• The content is not present on the edge server

• The CDN fetches it from the origin server

• Stores (caches) it locally

• Sends it to the user

Slightly slower the first time, fast afterwards

Why Netflix Feels Instant

Netflix knows:

• Which movies are popular

• Which regions watch what content

So it:

• Pre-loads (pre-warms) popular content into edge servers

• Places servers inside or very close to ISPs

That’s why:

• New popular releases load instantly

• Rare or old content may take longer the first time

What Kind of Data Is Served via CDN?

CDNs usually serve:

• Videos (Netflix, YouTube)

• Images, CSS, JS (websites)

• Static APIs

• Software downloads

Some advanced CDNs also cache:

• API responses

• Dynamic content (with rules)

CDN vs Normal Server

Why CDNs Matter in System Design

From a system-design perspective, CDNs:

• Reduce latency

• Reduce bandwidth costs

• Protect origin servers

• Improve availability

• Handle traffic spikes easily

In cloud terms:

• AWS → CloudFront

• GCP → Cloud CDN

• Azure → Front Door

One-Line Mental Model

A CDN is a global cache sitting between users and your servers.

DNS vs CDN

DNS / Name Server

• Converts domain → IP

• Does not serve data

“Here is the address.”

CDN

• Serves the actual content

• Sends video, images, responses

“Here is the data.”

How They Work Together

1. User requests domain

2. DNS returns IP (often CDN IP)

3. Request goes to CDN edge

4. CDN serves content or fetches from origin

DNS tells where to go

CDN delivers what you asked for

Real-World Use Cases: TCP vs UDP

TCP Use Cases (Accuracy First)
------------------------------
- Web pages (HTTP/HTTPS)
- APIs
- Emails
- File downloads
- Database connections

UDP Use Cases (Speed First)
---------------------------
- Live video streaming
- Voice calls
- Online multiplayer games
- DNS queries
- Real-time telemetry

What HTTP Really Is

HTTP is a conversation format.

It defines:

• How a client asks for something

• How a server replies

• How errors are described

• How metadata (headers) is attached

HTTP does NOT:

• Send packets

• Guarantee delivery

• Handle retransmission

• Handle ordering

That’s TCP’s job.

Think of it like this:

TCP is the delivery truck

HTTP is the letter inside the envelope

Why HTTP Needs TCP

HTTP assumes:

• Data arrives complete

• Data arrives in order

• Data arrives once

TCP guarantees all three.

If HTTP were sent over UDP:

• Headers could be lost

• Body could be corrupted

• Responses could arrive incomplete

That’s why classic HTTP runs only on TCP*.*

HTTP Is Stateless

Each HTTP request:

• Knows nothing about previous requests

• Is independent

That’s why we need:

• Cookies

• Sessions

• Tokens

• Authorization headers

Statelessness makes HTTP scalable*, but shifts state handling to apps.*

HTTP Request–Response Mental Model

1. Client opens TCP connection

2. Client sends HTTP request

3. Server processes it

4. Server sends HTTP response

5. TCP ensures safe delivery

6. Connection may close or stay alive

HTTP Is NOT TCP

This is critical.

• TCP = transport protocol

• HTTP = application protocol

HTTP:

• Does not handle packet loss

• Does not handle retransmission

• Does not manage delivery

It relies on TCP.

Relationship Between HTTP and TCP

Simple layering:

HTTP → Application rules
TCP  → Reliable delivery
IP   → Addressing & routing

1. HTTP runs on top of TCP

2. TCP does not know about HTTP

HTTP Request Flowing Over TCP

Browser
  |
  |  HTTP GET /index.html
  |----------------------------->
  |        (via TCP)
  |
  |  HTTP/1.1 200 OK
  |  <html>...</html>
  |<-----------------------------
  |
TCP ensures:
✔ delivery
✔ order
✔ completeness

Layered view:

HTTP  → Request / Response
TCP   → Reliable transport
IP    → Routing
Link  → Local delivery

OSI Model vs TCP/IP Model

First: Why Models Exist

Networking is complex.

Models:

• Break complexity into layers

• Give us shared vocabulary

• Help debugging (“Where is the problem?”)

Models are learning tools, not physical systems.

OSI Model

OSI has 7 layers.

You don’t “use” OSI — you think with it.

OSI Layers (Top → Bottom)

1. Upper layers = data meaning

2. Lower layers = data movement

TCP/IP Model (What Actually Runs the Internet)

TCP/IP is the practical implementation.

It compresses OSI into 4 layers.

Real protocols map here.

OSI vs TCP/IP Layer Mapping

OSI Model                 TCP/IP Model
--------------------------------------
Application  (7)  ┐
Presentation (6)  ├──► Application
Session      (5)  ┘

Transport    (4)  ───► Transport

Network      (3)  ───► Internet

Data Link    (2)  ┐
Physical     (1)  ┘──► Network Access

Why People Get Confused

• OSI is theoretical

• TCP/IP is practical

• HTTP lives in Application

• TCP lives in Transport

They are not competing, just different abstractions.

One End-to-End Mental Flow

1. User opens a website

2. DNS resolves domain

3. CDN edge is selected

4. TCP connection is established

5. HTTP request is sent

6. Response is delivered

7. CDN may cache it

8. Browser renders content

Everything fits together.

One End-to-End Stack View

User clicks link
      |
      ▼
HTTP  (What to say)
      |
TCP   (Reliable delivery)
      |
IP    (Where to go)
      |
Router → Router → Router
      |
Server

Finally :

• IP → where to go

• TCP/UDP → how to send

• HTTP → what to say

• CDN → how to be fast

The internet works not because it is fast, but because each layer has one responsibility.