DEV Community

Cover image for What Really Happens When You Click a Link
Aritra Chatterjee
Aritra Chatterjee

Posted on

What Really Happens When You Click a Link

You click a link.

In under two seconds, a webpage built by someone in San Francisco loads on your phone in Delhi. No one handed it to you. Thousands of decisions happened invisibly — packets raced through cables, routers made split-second choices, servers responded in milliseconds.

Most people never think about any of this. Let's change that.


What Is a Network?

Before we get to the Internet, let's start smaller.

A network is simply a group of computers connected so they can exchange information.

Here's a concrete way to think about it: imagine everyone in an office shares a printer. Their computers are all connected to it — and to each other — through a local network. No Internet needed. Just devices talking directly.

Now imagine millions of these office networks, home networks, and data centre networks all linked together.

That's the Internet — a network of networks. In fact, the word Internet literally comes from interconnected networks.

Because these networks are all linked, a computer in Delhi can talk to one in New York almost instantly.


How Do Computers Actually Send Data?

Computers don't send data through thin air (well, sometimes they do — but even then, it's structured).

Data travels through:

  • Fiber-optic cables
  • Ethernet cables
  • Wi-Fi signals
  • Cellular networks
  • Satellites

Whatever the medium, all data gets converted into bits — the fundamental unit of digital information, represented physically as electrical signals or pulses of light.

These bits travel at speeds close to the speed of light. The more bits that can move at once, the faster your connection feels. That's the difference between a fibre connection loading a movie in two seconds and a weak signal buffering for ten.


The Two Ideas That Run the Internet

Almost everything that happens online comes down to two concepts:

  1. Packets — how data is broken up and sent
  2. Protocols — the rules that make communication possible

Let's take each one.


Packets: Think of Moving a Library

Imagine you're moving an entire library to a new building.

You wouldn't carry every book at once. You'd pack them into boxes, label each box, and transport them one by one. At the other end, you'd unpack and arrange them in order.

The Internet works exactly like this.

When you load a webpage, your browser doesn't receive the whole page in one go. The data is broken into small chunks called packets. Each packet contains:

  • A piece of the actual data
  • Where it came from
  • Where it's going
  • How to reassemble it

This extra routing information lives in the packet's header — think of it as the shipping label on a box.

Here's something most people don't know: packets from the same request can take completely different physical routes across the Internet and still arrive and reassemble correctly at the destination. One packet might go through London. Another through Singapore. They both end up at your browser, get sorted, and become the webpage you see.

That's not a bug. That's a feature — it makes the Internet resilient.


Protocols: Everyone Speaks the Same Language

Different devices — iPhones, Android phones, Windows laptops, Linux servers — all need to communicate with each other. They use different hardware, different operating systems, and different software.

So how do they understand each other?

Protocols. A protocol is just an agreed-upon set of rules for how data should be formatted, sent, received, and interpreted.

Here are the ones that matter most:

Protocol What It Does
Ethernet Handles communication between devices on the same local network
IP Delivers packets from one network to another — like a postal address for computers
TCP Guarantees packets arrive successfully, in order, with nothing missing
UDP Prioritises speed over reliability — drops packets rather than wait to resend them
HTTP/HTTPS How browsers and servers exchange website data
TLS Encrypts the connection so no one can read your data in transit

TCP vs UDP is worth pausing on because people often get confused here.

TCP is reliable but slower — if a packet gets lost, TCP notices and requests it again. That's what you want when downloading a file or loading a webpage. Missing data would corrupt the result.

UDP is fast but doesn't care about lost packets. That's fine for live video calls or gaming — if one frame drops, you don't want the video to freeze and rewind. You just want to keep going. A tiny glitch is less painful than a constant delay.


The Hardware That Makes It Physical

The Internet isn't floating in a cloud somewhere. It runs on real hardware, spread across the entire planet.

Component Job Analogy
Router Directs packets between different networks Traffic officer at an intersection
Switch Connects devices within the same network Receptionist routing calls inside an office
Server Stores and delivers content when requested The library that holds the books

The key distinction people mix up: routers connect networks; switches connect devices within a network. A router decides which road a packet takes. A switch decides which desk it lands on.

Most servers live in massive data centres — warehouses packed with thousands of machines running around the clock, with backup power, cooling systems, and redundant connections.


What Actually Happens When You Open a Webpage

Let's make this concrete. You type a URL and hit Enter.

Here's what happens next — all in under two seconds:

Step 1: DNS Lookup

Your browser knows the name example.com but has no idea what IP address that maps to. So it asks the Domain Name System (DNS) — essentially the Internet's phonebook.

DNS translates example.com93.184.216.34 (or whatever the server's IP is).

Worth knowing: DNS responses are cached. If you've visited a site recently, your browser already knows the IP and skips this step. That's one reason revisiting a site often feels faster.

Step 2: TCP Handshake

Your browser contacts the server at that IP address, and they perform a three-way handshake — SYN, SYN-ACK, ACK. Roughly: "Can we talk?" / "Yes, can we?" / "Yes." Now they're in sync and ready to communicate.

Step 3: TLS Handshake

If the site uses HTTPS (it should), your browser and the server exchange encryption keys. Everything from this point forward is encrypted. Even if someone intercepts your packets, they see gibberish.

Step 4: HTTP Request

Your browser sends a request: "Give me the content for this page."

Step 5: HTTP Response

The server responds with HTML, CSS, and JavaScript — all broken into packets and sent across the Internet.

Step 6: Browser Renders the Page

Your browser receives the packets, verifies everything arrived, reassembles them, and interprets the code. HTML builds the structure, CSS handles the styling, and JavaScript adds interactivity.

What you see on screen is the result of all of that — rendered in milliseconds.


The Big Picture

The Internet isn't magic. It's a very elegant set of agreements.

Networks connect computers. Packets carry information in manageable chunks. Protocols make sure every device on the planet can understand every other device. Routers and switches move traffic efficiently. Servers store and serve content on demand.

Every time you click a link, all of this fires at once — invisibly, reliably, and incredibly fast.

Top comments (0)