The Complete Journey

The Language of the Internet

Right now, as you read these words, your device is speaking a language. Not English or Hindi or Mandarin — a different kind of language. A protocol. A set of rules that every device on Earth has agreed to follow.

It's called TCP/IP.

TCP/IP isn't a single thing. It's a suite of protocols — a collection of agreements about how data should be packaged, addressed, sent, received, and verified. It's the reason your phone in Mumbai can talk to a server in Virginia. It's the reason an email sent from Tokyo arrives in London. It's the reason the internet exists at all.

Today, we're going to follow a single message — a simple HTTP request — as it travels from your browser to a server and back. Along the way, you'll see how TCP/IP actually works. Not the textbook version. The real version.

Why Layers?

Imagine you're sending a physical letter from Mumbai to New York.

You don't personally carry it across the ocean. Instead, you write the letter, put it in an envelope, write the address, drop it in a mailbox, and the postal system handles the rest. The postal system doesn't care what's in your letter. They just care about the address.

The postal system itself has layers. Local post offices handle pickup. Sorting facilities organize by destination. Airplanes carry mail across continents. Local delivery people bring it to the final address. Each layer does one job and passes the work to the next.

TCP/IP works the same way.

Instead of one massive protocol that handles everything, TCP/IP splits the work into layers. Each layer has a specific job. Each layer only talks to the layers directly above and below it. Each layer doesn't need to know how the other layers work — just how to hand off data to them.

The Four Layers

TCP/IP has four layers. From top to bottom:

Let me introduce each layer by what it cares about:

Each layer wraps the data from the layer above it, adding its own header with control information. This process is called encapsulation. We'll see it in action soon.

Where Data Begins

Priya opens her browser and types: https://github.com

She presses Enter.

The browser knows what Priya wants — she wants to see a webpage. To get it, the browser needs to send an HTTP request to GitHub's server. This request will ask: "Please send me your homepage."

The browser constructs the message:

This is pure application data. It's written in HTTP — a protocol that both the browser and the server understand. It says: "I'm requesting (GET) the root path (/) from github.com, and I want HTML back."

But this message can't travel across the internet by itself. It's just text. It doesn't have an address. It doesn't know how to reach GitHub. It doesn't know how to handle errors if something goes wrong.

The application layer has done its job. Now it hands the data down to the transport layer.

Ports: The Doors to Applications

A single computer can run many applications at once. Priya's laptop might have Chrome, Spotify, Slack, and a mail client all running simultaneously — all using the network.

When data arrives at Priya's laptop, how does the operating system know which application should receive it?

Ports.

A port is a 16-bit number (0 to 65535) that identifies a specific application or service on a machine. Think of an IP address as the street address of a building, and a port as the apartment number inside that building.

Priya's browser chooses a random source port (let's say 52431) for itself. This is how GitHub's response will find its way back to the browser specifically, not to Slack or Spotify.

So the connection will be:

TCP's Job: Reliable Delivery

The application layer handed down an HTTP request. Now the transport layer takes over. In this case, we're using TCP (Transmission Control Protocol).

TCP has three core promises:

The alternative is UDP (User Datagram Protocol), which makes none of these promises. UDP is faster but unreliable — used for video streaming, gaming, and DNS where speed matters more than perfection.

For web browsing, we need TCP. A half-loaded webpage with missing pieces is useless. We need every byte.

Segmentation: Breaking Data into Pieces

Application data can be large. An HTTP response might be megabytes — a webpage with images, scripts, styles. You can't send that as a single block.

TCP breaks the data into segments. Each segment is small enough to fit into a network packet (typically up to ~1460 bytes of data, called the Maximum Segment Size or MSS).

Each segment gets a TCP header prepended to it:

Sequence Number: Identifies where this segment's data fits in the overall stream. If I'm sending bytes 1000-2000, my sequence number is 1000.

Acknowledgment Number: Tells the other side "I've received everything up to this byte, send me the next one."

Flags: Control bits like SYN (start connection), ACK (acknowledgment), FIN (end connection), PSH (push data to application immediately).

Window Size: How much more data I can receive before you need to wait. Flow control.

Checksum: A mathematical fingerprint of the segment. If even one bit is corrupted in transit, the checksum won't match, and the segment is discarded.

How TCP Achieves Reliability

The internet is unreliable. Packets get lost. Routers drop them when they're congested. Cables get damaged. Radio signals interfere. Yet TCP promises reliable delivery. How?

Acknowledgments and Retransmission.

When Priya's laptop sends a TCP segment, it starts a timer. It expects to receive an acknowledgment (ACK) from GitHub saying "I received that segment." If the timer expires and no ACK has arrived, TCP assumes the segment was lost and retransmits it.

This is why TCP is "reliable" — not because the network is reliable, but because TCP detects and fixes unreliability.

Ordering is handled by sequence numbers. If segment 3 arrives before segment 2, the receiver holds segment 3 in a buffer and waits for segment 2. Only when all pieces are present does TCP pass the complete, ordered data up to the application.

Flow Control: Don't Overwhelm Me

What if Priya's laptop can send data faster than GitHub's server can process it? The server's receive buffer would fill up, and new packets would be dropped.

TCP solves this with flow control using the window size field.

Each side advertises how much buffer space it has available. "My window is 65535 bytes" means "you can send me up to 64KB before waiting for me to catch up."

If the receiver is getting overwhelmed, it shrinks its advertised window. If the window goes to zero, the sender stops completely until the receiver says "okay, I have room now."

TCP also has congestion control — it monitors the network for signs of congestion (lost packets, delays) and slows down to avoid making things worse. This is why your downloads start slow and speed up — TCP is probing the network capacity.

IP's Job: Getting Packets Across Networks

The transport layer created a TCP segment. But the segment only has port numbers — it doesn't have addresses. It doesn't know that Priya is in Mumbai and GitHub is in Virginia.

The Internet Layer adds addressing and routing. Its main protocol is IP — the Internet Protocol.

IP takes the TCP segment and wraps it in an IP packet, adding a header with source and destination IP addresses.

Version: IPv4 (4) or IPv6 (6). Most of the internet still runs on IPv4.

TTL (Time to Live): A counter that decrements at each router. When it hits zero, the packet is dropped. This prevents packets from looping forever if there's a routing error. Usually starts at 64 or 128.

Protocol: What's inside this packet? 6 means TCP. 17 means UDP. 1 means ICMP (ping).

Source/Destination IP: The global addresses. Priya's public IP is 103.21.45.78. GitHub's server is at 140.82.121.3.

IP Addresses: The Global Postal System

An IP address is a unique identifier for a device on a network. In IPv4, it's a 32-bit number, usually written as four octets (bytes) separated by dots:

Each octet ranges from 0 to 255. That gives us about 4.3 billion possible addresses — which seemed like plenty in 1981, but isn't enough today. That's why IPv6 exists (128 bits, virtually unlimited addresses), but IPv4 is still dominant.

Routing: How Packets Find Their Way

IP doesn't plan the entire journey. It just makes one hop at a time.

When Priya's laptop sends a packet to 140.82.121.3, it doesn't know the route to Virginia. It just knows: "that's not on my local network, so I'll send it to my default gateway (my router)."

The router receives the packet. It looks at the destination IP. It checks its routing table — a list of rules that say "for addresses in this range, send to this next hop." It forwards the packet to the next router.

Each router does the same thing. No router knows the full path. Each just knows the next step.

This decentralized approach is what makes the internet resilient. If one path fails, routers can find alternative routes. The packet might take a different path tomorrow, and that's fine.

The Final Mile: Physical Transmission

We have an IP packet. It knows where it wants to go (140.82.121.3). But IP addresses are logical — they exist in software. The packet needs to become electrical signals on a wire, or radio waves in the air, or pulses of light in fiber.

The Network Access Layer handles the physical stuff. It takes the IP packet and wraps it in a frame suitable for the local network technology — Ethernet for wired connections, Wi-Fi for wireless.

But here's the catch: the Network Access layer can only deliver frames to devices on the same physical network. Priya's laptop can't directly send a frame to GitHub — they're not on the same network. She can only send a frame to her router.

MAC Addresses: Local Identity

IP addresses are for global routing. But on a local network (like Priya's home Wi-Fi), devices use a different identifier: the MAC address.

A MAC (Media Access Control) address is a 48-bit address burned into every network interface card. It looks like: a4:83:e7:2f:1c:3b

MAC addresses are (theoretically) globally unique, but they're only used for local delivery. When a frame travels on Priya's home network, it uses MAC addresses to say "from Priya's laptop's Wi-Fi card, to the router's Wi-Fi card."

EtherType: Tells the receiver what type of payload is inside. 0x0800 means IPv4.

Frame Check Sequence (FCS): A CRC checksum to detect corruption during transmission. If the bits get corrupted, the FCS won't match, and the frame is discarded.

ARP: The Missing Link

Priya's laptop knows it needs to send the packet to her router. It knows the router's IP address (192.168.1.1). But to send a frame, it needs the router's MAC address.

How do you find a MAC address when you only know an IP address?

ARP — Address Resolution Protocol.

Priya's laptop broadcasts a message to everyone on the local network: "Who has IP 192.168.1.1? Tell me your MAC address!"

The router hears this and responds: "That's me! My MAC address is c4:91:0c:8a:2d:11."

Priya's laptop caches this mapping (IP → MAC) so it doesn't have to ask again. Now it can build the Ethernet frame with the correct destination MAC.

With the MAC address resolved, Priya's laptop can finally transmit the frame. The Wi-Fi card converts the bits into radio waves, the router's Wi-Fi card receives them, and the frame has made its first hop.

Encapsulation: Wrapping Layer by Layer

Let's visualize what we've built. Starting from Priya's HTTP request, each layer wrapped the data in its own envelope:

This is encapsulation. Each layer adds its header, wrapping the data from the layer above. The innermost layer is the application data. The outermost is the frame.

When the frame arrives at the router, the opposite happens: decapsulation. The router strips the Ethernet header (it only needed that for local delivery), examines the IP header to decide where to forward the packet, then builds a new frame with new MAC addresses for the next hop.

The Full Path

Priya's laptop:

• Application layer creates HTTP request
• Transport layer wraps it in TCP segment (port 52431 → 443)
• Internet layer wraps it in IP packet (103.21.45.78 → 140.82.121.3)
• Network layer wraps it in Ethernet frame (laptop MAC → router MAC)
• Frame is transmitted over Wi-Fi

Priya's router:

• Receives frame, strips Ethernet header
• Examines IP destination: 140.82.121.3 — not local
• Performs NAT: translates Priya's private IP to her public IP
• Looks up next hop in routing table: ISP gateway
• Builds new frame with ISP gateway's MAC address
• Transmits over WAN connection

Across the internet:

• Each router decrements TTL, checks routing table, forwards to next hop
• Packet crosses ISP networks, internet exchanges, undersea cables
• At each hop: new frame, same IP packet

GitHub's server:

• Receives frame, strips Ethernet header
• Network layer receives IP packet, strips IP header, passes segment up
• Transport layer receives TCP segment — checks sequence numbers, sends ACK
• Strips TCP header, passes HTTP data to application
• Web server processes HTTP request: "GET /"
• Builds HTTP response with HTML content
• Response travels back through all layers, all hops, to Priya

Priya sees the GitHub homepage appear in her browser.

All of this — the layering, the encapsulation, the routing, the ACKs, the MAC addresses — happened in about a third of a second.

Core Principles of TCP/IP

Technical Quick Reference