DEV Community: Aritra Chatterjee

What Really Happens When You Click a Link

Aritra Chatterjee — Wed, 10 Jun 2026 05:39:05 +0000

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:

Packets — how data is broken up and sent
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.com → 93.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.

Git & GitHub 101: A Beginner's Guide to Version Control

Aritra Chatterjee — Wed, 13 May 2026 12:18:52 +0000

Your friend leans over and says, "Just push it to GitHub." You smile. You nod. You have absolutely no idea what that means.

By the end of this blog, you won't just understand what it means — you'll be able to say it yourself, and explain it to someone else. Let's start from the very beginning.

First Things First: What is a Version Control System?

Before we talk about Git or GitHub, we need to understand the problem they solve.

Imagine you're building a website. You make some changes, something breaks, and now you can't remember what your code looked like before. Sound familiar?

A Version Control System (VCS) is a tool that tracks and manages changes to your files over time. Think of it as a time machine for your code — one that remembers every version of your project, so you can always go back.

With a VCS, you can:

Save different versions of your code
Revert to a previous version if something breaks
Collaborate with other developers without overwriting each other's work
Track who changed what, and when

The Three Types of Version Control Systems

Not all VCS tools work the same way. Here's how they've evolved:

Type	How It Works	Examples	Key Trade-off
Local VCS	Store versions only on your computer	—	Simple, but zero collaboration support
Centralised VCS (CVCS)	All versions live on one central server	SVN, CVS	Easy collaboration, but if the server goes down, everyone's stuck
Distributed VCS (DVCS)	Every developer has a full copy of the project	Git, Mercurial	Fast, offline-friendly, and more secure — the modern standard

Git is a distributed VCS, which is exactly why it became the industry standard.

Meet Git

"Git is like Microsoft Word's Track Changes — but for your entire codebase, and about 100x more powerful."

Git is a distributed version control system created by Linus Torvalds in 2005 (yes, the same person who built the Linux kernel). It runs locally on your computer and takes snapshots of your project every time you save your progress.

Here's what makes Git special:

Fast — most operations happen on your own machine, no internet needed
Branching — you can create separate "versions" of your project to experiment freely
Backup built-in — every copy of a Git project is a full backup
Free and open source — used by millions of developers worldwide

So when someone says "commit your changes" — they mean Git just saved a snapshot of your code at that moment. Like a save point in a video game.

👉 Git Official Website

Meet GitHub

"Git is the tool. GitHub is where you put your work so the world can see it."

GitHub is a cloud-based platform that hosts your Git repositories online. While Git works on your computer, GitHub lets you:

Store your project in the cloud
Collaborate with a team
Review each other's code via Pull Requests
Track bugs and features with Issues
Connect to deployment pipelines with CI/CD integrations

The simplest way to remember the difference:

	Git	GitHub
What it is	A version control tool	A platform to host repositories
Where it runs	Your local computer	Online (browser/app)
Works offline?	✅ Yes	❌ Mostly no
Made by	Linus Torvalds	GitHub Inc.

So when someone says "push it to GitHub” — they mean: upload your Git snapshots to the cloud so others can see and access them.

👉 GitHub Official Website

The Core Concepts (With Real-World Analogies)

This is the part most beginner guides skip. Let's make sure the key ideas actually stick.

📁 Repository (Repo)

A repository is your project folder — but one that has a memory. It remembers every single change ever made to every file inside it.

"It's your project folder if your project folder kept a journal."

A repo can be local (on your computer) or remote (on GitHub).

📸 Commit

A commit is a saved snapshot of your project at a specific moment in time.

"Think of commits like save points in a video game. Git doesn't just save where you are — it remembers every save point you've ever made. Died at level 5? Roll back to level 3 and try again."

Every commit has a message describing what changed, like: "Added login page" or "Fixed the navbar bug".

🎭 Staging Area

Before you commit, you first decide what you want to include in the save.

"Imagine packing for a trip. You don't throw everything straight into the suitcase. First, you lay things out on the bed and decide what makes the cut. The bed is your staging area. git add is you deciding what goes in."

🌿 Branch

A branch is a parallel version of your project where you can experiment freely.

"Branches are like a parallel universe for your code. The main branch is your real, working world. You create a new branch to experiment — and whatever chaos happens there, stays there. It doesn't touch the main world until you decide to merge it back."

Common example:

main → your stable, live code
feature-login → new login feature being built separately

The Basic Git Workflow

Here's what a typical day with Git looks like. Let's walk through it step by step, so nothing feels like magic.

Step 1: Write or edit your code

Just work normally in your project folder. Nothing Git-specific yet.

Step 2: Stage your changes

git add .

The . means "everything." You're telling Git: "Hey, watch all these files — I'm about to save them." Nothing is saved yet. You're just raising your hand.

Step 3: Commit your changes

git commit -m "Added login page"

Now you're actually saving. The -m flag lets you write a message — a note to your future self (or teammates) explaining what changed. Think of it like adding a caption to a photo: "Here's the project on day 12, with the login page added."

Step 4: Push to GitHub

git push origin main

Two things to know here:

origin — Git's nickname for your GitHub repository (the remote/online version of your project)

main — the branch you're pushing to (the primary, stable version)

So this line says: "Upload my saved changes to the main branch of my GitHub project."

Common Git Commands Cheat Sheet

Command	What It Does
`git init`	Start a new Git repository in your folder
`git clone <URL>`	Download a repository from GitHub
`git status`	See what's changed and what's staged
`git add .`	Stage all changes
`git commit -m "msg"`	Save a snapshot with a description
`git push`	Upload your commits to GitHub
`git pull`	Download the latest changes from GitHub
`git branch`	View or create branches
`git checkout -b <name>`	Create and switch to a new branch
`git merge <branch>`	Merge a branch into your current one

Pro tip: Run git status constantly. It tells you exactly what state your files are in — which are untracked (red), which are staged (green), and whether you're ahead of GitHub.

Working With Branches

Creating a branch is one of the most powerful things you can do in Git. Here's how:

# Create a new branch
git branch feature-login

# Switch to it
git checkout feature-login

# Or do both in one command
git checkout -b feature-login

Once your feature is ready, you merge it back into main:

git checkout main
git merge feature-login

No chaos. No broken main code. Just clean, parallel development.

Conclusion

So — next time someone says "just push it to GitHub" — you've got them.

You now know that Git is the tool that tracks your changes locally, and GitHub is the platform that hosts your work online. You know what a commit is (a save point), what a branch is (a parallel universe for your code), and what staging means (packing your suitcase before the trip).

Git isn't just another tool you learn for fun. It's the tool every software team on the planet already uses. Mastering it doesn't just make you a better developer — it makes you a hireable one.

Now go initialise a repo. You've earned it.

git init