Concepts: Networks, IP, DNS, Packets

What Is a Network?

A network is any group of devices that are connected so they can share data. Your phone, your router at home, and your ISP’s equipment are all part of a network. The internet is just a very large network of networks — millions of them, all connected and talking to each other using agreed-upon rules.

When you log into your bank’s website and transfer money, your browser is sending data to the bank’s server. That data travels through your Wi-Fi or mobile connection, through cables, through data centres, and back again — all in under two seconds.

IP Addresses — The Postal Address of the Internet

Every device that connects to the internet needs an address so data knows where to go. This is called an IP address (Internet Protocol address).

Think of it this way: your home has a postal address. Without it, no parcel can find you. Every device on the internet has an IP address. Without it, no data packet can find you.

IP addresses look like this: 142.250.192.46. Four numbers separated by dots, each between 0 and 255. That particular address belongs to Google.

Public vs. Private IP

Your router has a public IP address — this is the address the rest of the internet sees. All the devices in your home (your phone, laptop, smart TV) share this one public IP.

Inside your home network, each device gets a private IP address — something like 192.168.1.5. Your router keeps track of which private device gets which data from the outside world.

Internet ← Public IP: 103.21.58.10 → Your Router → Private IPs:
                                                      Phone: 192.168.1.2
                                                      Laptop: 192.168.1.3
                                                      Smart TV: 192.168.1.4

DNS — The Internet’s Phone Book

When you type sbi.co.in into your browser, your computer does not know where that is. It only knows addresses — numbers like 203.197.166.60. So how does it find SBI’s server?

This is where DNS (Domain Name System) comes in.

Imagine you know someone as “Priya from Haldwani.” You don’t know her phone number. But you have a phone book that can look up “Priya from Haldwani” and return her number. DNS is exactly that phone book — except it converts domain names into IP addresses, and it works in milliseconds.

How a DNS lookup works, step by step:

1. You type sbi.co.in into your browser
2. Your phone checks its own memory first — “Have I looked this up recently?” (This is called the DNS cache)
3. If not, it asks your ISP’s DNS server: “What is the IP for sbi.co.in?”
4. The ISP’s DNS server may ask other DNS servers higher up the chain
5. Eventually the answer comes back: 203.197.166.60
6. Your browser now connects to that IP address

The whole process takes milliseconds. You never see it happen.

Packets — Breaking Data into Pieces

Here is something surprising: when you send a WhatsApp photo to a friend, that photo does not travel as a single chunk. It gets broken into hundreds or thousands of small pieces called packets.

Why? Because the internet was designed for resilience. If one route is congested, individual packets can take different paths. If one packet gets lost, only that piece needs to be resent — not the whole photo. This is much more efficient than sending one giant chunk that would need to be completely re-sent if anything went wrong.

Pandey sir’s postal analogy: Imagine writing a very long letter — 20 pages. You could put it in one giant envelope and hope it arrives. Or you could number each page, put each in its own envelope addressed to the same destination, and send them separately. Some might go through Lucknow, some through Delhi. All arrive at the destination and are reassembled in order.

Each packet contains:

• A piece of the actual data (the “payload”)
• The destination IP address
• The source IP address
• A sequence number (so packets can be reassembled in order)
• Error-checking information

Routing — Finding the Path

Once data is broken into packets, each packet needs to find its way across the internet. This is done by routers — devices whose entire job is to receive packets and decide where to send them next.

Imagine a packet travelling from your phone in Bhopal to a server in Mumbai. It might pass through:

Your phone → Mobile tower → ISP network → City router →
Backbone router → Maharashtra network → Mumbai data centre

Each router along the way looks at the destination IP address and makes a decision: “Which direction should I send this next?” This is called routing, and there are sophisticated algorithms that make these decisions in microseconds, accounting for congestion and failures on the network.

Protocols — The Agreed Rules

None of this works unless every device agrees on the same rules. These rules are called protocols.

• IP (Internet Protocol) — how packets are addressed and routed
• TCP — how reliable delivery is guaranteed
• HTTP — how browsers and web servers communicate
• HTTPS — encrypted HTTP (the padlock you see in the browser)

Think of protocols like railway track gauge — all trains in India are built to the same track width. Different manufacturers, different trains, but they all run on the same tracks. Protocols are the agreed-upon “gauge” of the internet.

Ports & Server Processes — You Are Talking to Software

Here is something that surprises most people: when you connect to google.com, you are not connecting to a building. You are connecting to a specific piece of software — a server process — running on a computer inside Google’s data centre.

An IP address gets your request to the right machine. But a single machine runs many different services simultaneously. How does your request find the right one? That is what ports are for.

A port is a number — from 0 to 65535 — that identifies a specific service on a machine. Think of an IP address as the address of a large apartment building, and the port as the flat number inside it. The building address gets you to the right building; the flat number gets you to the right door.

The most important ports you will encounter:

When your browser connects to https://google.com, it automatically connects to port 443 — because HTTPS always uses port 443 by convention. You never type the port number; your browser adds it for you.

Sometimes you will see a port number explicitly in a URL, like http://192.168.1.1:8080. The :8080 means “connect to port 8080 on this address.” This is common for internal tools, routers, and test servers that run on non-standard ports.

On the other end of that port sits a server process — software like Nginx or Apache — that is permanently running, listening on port 443, and waiting to answer requests. When your browser connects, this software wakes up, reads your request, and sends back a response.

The TCP/IP Stack — Four Layers, Each with One Job

Everything we have described — your browser making a request, packets being routed, DNS resolving names — fits into a four-layer model called the TCP/IP stack. Each layer handles one part of the job, hands its output to the layer above or below, and does not care about the rest.

┌─────────────────────────────────────────────┐
│  Application Layer  (HTTP, HTTPS, DNS)       │
│  "What are we saying?"                       │
├─────────────────────────────────────────────┤
│  Transport Layer    (TCP, ports)             │
│  "How do we deliver it reliably?"            │
├─────────────────────────────────────────────┤
│  Network Layer      (IP addresses, routing)  │
│  "Which path do we take?"                   │
├─────────────────────────────────────────────┤
│  Physical Layer     (cables, Wi-Fi, 4G)      │
│  "How do we move bits from A to B?"         │
└─────────────────────────────────────────────┘

Application Layer — This is where your browser lives. It constructs an HTTP or HTTPS request: “GET the homepage of google.com.” It does not know or care how the request travels.

Transport Layer — TCP takes the request, breaks it into packets, assigns port numbers, and guarantees that every packet arrives and arrives in order. This is the layer that handles reliability.

Network Layer — IP takes each packet and handles routing — figuring out the path from your device’s IP address to Google’s IP address, hop by hop across the internet.

Physical Layer — At the bottom, bits become electrical signals on cables, radio waves on Wi-Fi, or light pulses through fibre optics. This layer just moves energy from one place to another.

When your response comes back, it travels up the stack in reverse: physical signals become bits, bits become packets, packets become a complete message, and your browser renders the page.

What Happens When You Type google.com

Now you can answer the session’s opening question. When you type google.com and press Enter, four things happen in sequence:

Step 1 — DNS Resolution
  Your browser asks: "What is the IP address of google.com?"
  DNS resolver answers: "142.250.192.46"

Step 2 — TCP Connection to Port 443
  Your browser connects to 142.250.192.46:443
  TCP establishes a reliable connection
  (Port 443 because you typed https://)

Step 3 — Server Process Answers
  Nginx (or a similar server) is listening on port 443
  It reads your request: "GET the homepage"
  It sends back the HTML, CSS, images

Step 4 — Browser Renders
  Your browser assembles the response
  Page appears on screen

Four steps. Less than half a second. Every time.

The same sequence happens when you open a banking app, send a WhatsApp message, or stream a video. The application changes. The four steps do not.