How the Internet Actually Works

You Just Opened Swiggy. Here's Everything That Happened in 200ms.

You tapped the Swiggy icon on your phone. By the time the restaurant list loaded, that same instant, before you even processed what you're seeing, your phone had a full conversation with machines in Mumbai, Singapore, and California.

Not one conversation. Several. In parallel. Finishing before you blinked.

Here's the thing nobody explains: that "instantaneous" feeling isn't magic. It's engineering. Layers of carefully designed protocols, each one solving a specific problem, stacked on top of each other like a relay race. Understanding those layers doesn't just satisfy curiosity. It's the foundation of every distributed systems decision you'll ever make.

Why Should You Care?

1. Interviews. Every time you talk about latency, CDNs, TCP, DNS, TLS, or HTTP/2 in a system design round, you're talking about this stack. Engineers who explain why something happens get the offer. Engineers who only name buzzwords don't.
2. Real architecture decisions. CDN placement, connection pooling, regional deployments, and API gateway timeouts all sit on top of these layers. You cannot size a system without knowing what each hop costs.
3. Production pain avoided. When your app is slow, or requests fail, or CORS breaks your frontend, the answer is almost always somewhere in this stack. I have watched teams spend weeks tuning SQL when the real bug was DNS TTL set to 24 hours during an incident.

🟢 The Simple Version (Start Here If You're New)

The Internet Is Like Mailing a Letter to Bangalore

Imagine you want to mail a letter to your friend in Bangalore. You need three things:

1. Their address, so the post office knows where to deliver it
2. A reliable delivery system, so your letter doesn't get lost at a sorting center
3. A shared language, so your friend can actually read what you wrote

The internet has exactly these three things. The complexity is just in how each layer works.

Finding the Address: IP and DNS

Every device on the internet (your phone, your laptop, Swiggy's servers, the Netflix server in Mumbai) has a unique address called an IP address.

It looks like this: 142.250.190.46

That's Google. Not google.com, but Google's actual address.

Humans can't remember numbers like that. So we built the Domain Name System (DNS), essentially the phonebook of the internet. When you type swiggy.com, your phone secretly calls a DNS server and asks: "What's the IP address for swiggy.com?" The DNS server replies with something like 103.248.128.1, and now your phone knows where to connect.

The whole lookup takes 20-50 milliseconds. Often less if the answer was already cached.

Sending the Letter: Packets

Here's the first surprising thing: the internet doesn't send your data in one big chunk. It tears it into small pieces called packets, typically 1,500 bytes each.

A 1MB image becomes ~700 packets. Each packet travels independently, possibly through different cities, different undersea cables, different routers. They arrive out of order. Some get dropped entirely. They get reassembled at the destination.

This sounds chaotic. It kind of is. And it works beautifully.

Making It Reliable: TCP

TCP (Transmission Control Protocol) is what guarantees your data arrives complete and in order. It:

• Numbers every packet
• Tracks which ones arrived
• Re-requests any that got lost
• Reassembles them in the right order

Before TCP sends a single byte of your data, it runs a three-way handshake with the server: SYN, SYN-ACK, ACK. Basically "hello, I'm ready to talk" and confirming the other side is listening. That handshake adds latency. Every new HTTPS connection from your app to a server costs you one round trip before any data flows. For a server in Mumbai, that's maybe 10ms. For a server in the US, it's 150ms+. This is why connection pooling, keep-alive headers, and HTTP/2 exist.

Speaking the Language: HTTP

Once the connection is established, your browser needs to actually ask for something. It does this using HTTP (HyperText Transfer Protocol), a simple text-based format for requests and responses.

When you open swiggy.com, your browser sends something like:

GET / HTTP/1.1
Host: swiggy.com
User-Agent: Chrome/120

And Swiggy's server replies:

HTTP/1.1 200 OK
Content-Type: text/html

<html>...the Swiggy homepage...</html>

The number 200 means "everything worked." Other numbers you'll see constantly as an engineer:

• 301/302: Redirect (the page moved)
• 400: Bad request (you sent something malformed)
• 401: Unauthorized (log in first)
• 403: Forbidden (you logged in, but you can't access this)
• 404: Not found
• 500: Server error (the backend crashed)
• 503: Service unavailable (server is down or overloaded)

That's the basic picture. DNS → TCP → HTTP. Three layers, one request.

🟡 Going Deeper: The Full Path, HTTPS, and When Speed Is Never Free

Mumbai to Your Screen: Six Hops

Let's trace what actually happens when you open Swiggy from your phone in Delhi:

Notice the CDN edge node. Swiggy's restaurant images, JS bundles, and CSS files often don't come from Mumbai. They're cached at a Cloudflare or AWS CloudFront edge node physically close to you. That's why static content loads fast even from Delhi. It's not traveling to Mumbai at all. API calls for live menu prices still hit origin.

HTTPS: The Lock Icon Isn't Just Decoration

When your browser shows a padlock icon, it means the connection is encrypted using TLS (Transport Layer Security). Without TLS, anyone on the same Wi-Fi network as you, in a coffee shop, on a train, can read your HTTP requests in plain text. Your cookies, your login tokens, everything.

TLS adds a handshake on top of the TCP handshake:

1. Your browser says: "I support these encryption methods"
2. Server picks one and sends its certificate (proves it's really Swiggy, not a hacker)
3. Browser verifies the certificate against a trusted authority (like DigiCert or Let's Encrypt)
4. Both sides derive a shared encryption key
5. Every message from here is encrypted with that key

This adds another round trip before you send your first byte of actual data. That's latency. That's why engineers obsess over TLS session resumption. If your device has connected to Swiggy's servers before, it can skip most of this handshake using a cached session.

HTTP/2 vs HTTP/1.1: The Multiplexing Breakthrough

HTTP/1.1 (which is what most of the web used until ~2016) has a painful limitation: one request per connection at a time. Your browser wants to load a page that has 30 resources (HTML, CSS, JS, 20 images, fonts). It has to queue them up and fetch them one by one per connection, or open multiple parallel connections.

HTTP/2 solved this with multiplexing: multiple requests can fly over a single connection simultaneously. The browser sends requests for all 30 resources at once, and the server processes and returns them in any order, interleaved over the same TCP connection.

The difference in practice: a page with 30 resources might take 1.5 seconds over HTTP/1.1 and 400ms over HTTP/2. Same server, same content, different protocol.

UDP: When "Good Enough" Beats "Perfect"

Remember how TCP guarantees delivery by resending lost packets? That's great for loading a webpage, terrible for live streaming.

Imagine watching an IPL match on Hotstar. A packet drops. TCP's approach: stop, wait for the retransmission, which arrives 100ms later. Now every subsequent packet is delayed. The stream stutters.

UDP doesn't do any of that. It fires packets and forgets. If one drops, the decoder moves on, you see a brief pixelation and then the next frame. Zero buffering, zero retransmission delays.

DNS actually uses UDP by default (with a fallback to TCP for large responses). It's one request, one response, and the overhead of a TCP connection would be larger than the actual DNS answer.

🔴 Architect's Corner: The Internet's Invisible Infrastructure

BGP: The Protocol That Accidentally Breaks the Internet

When you talk about "routing," you're eventually talking about BGP (Border Gateway Protocol), the protocol that lets internet service providers announce which IP ranges they're responsible for.

Here's what makes BGP terrifying: it's based on trust. Every ISP and cloud provider broadcasts "I can reach these IPs." Other routers believe them. No cryptographic verification.

This has caused real outages: a misconfigured ISP once accidentally announced ownership of a major video platform's IP range, and within minutes, global traffic rerouted into that ISP's network, where it died. The platform went unreachable worldwide for hours, caused entirely by a bad routing announcement from a single operator. This is called a BGP hijack.

It still happens. In 2022, Cloudflare and other providers were briefly affected by a BGP route leak from a small ISP. The fix (RPKI, cryptographic signing of route announcements) exists but adoption is slow.

As a system architect, understanding BGP explains why:

• Cloud providers have presence in multiple Internet Exchange Points (IXPs) in each region
• Indian apps prefer to route traffic through NIXI (the National Internet Exchange of India) to keep Indian traffic on Indian networks
• "Anycast" routing (multiple servers sharing the same IP address, traffic routed to the nearest one) works: Cloudflare's DNS at 1.1.1.1 is served by thousands of machines globally, all announcing the same IP

Latency Is Physics

Speed of light through fiber: ~200,000 km/second. The one-way trip between Mumbai and Singapore (via undersea cable): ~2,700km, ~13ms minimum. Round-trip: ~27ms. That's physics. You can't beat it.

In practice, Mumbai to Singapore round-trip is 40-60ms (fiber isn't perfectly straight, routing isn't optimal). Mumbai to London is 120ms+. Mumbai to California is 180ms+.

Implications for Indian system design:

• Most Indian startups serve users from AWS ap-south-1 (Mumbai), and that's the right call for Indian users
• For a startup going global: you need either a multi-region deployment or a CDN that caches your responses at edge nodes near users
• Real-time features (live scores, trading, chat) need servers close to users. A 180ms round-trip to the US feels sluggish for interactive UI

The Physical Internet

The internet isn't wireless. 99% of intercontinental traffic travels through undersea fiber optic cables, literal cables on the ocean floor, the thickness of a garden hose, running from Mumbai to Fujairah to Marseille to London.

India has major cable landing stations in Mumbai and Chennai (SEACOM, SMW-4, SMW-5 cables). When a ship's anchor accidentally cuts a cable near Egypt (this has happened multiple times), Indian internet traffic to Europe reroutes via the Pacific, adding 50-100ms latency, which users definitely notice.

This physical reality is why multi-region architecture isn't just a "nice to have" for global companies. It's risk management against physical infrastructure failures.

DNS as a Security Attack Surface

DNS was designed in 1983 when the internet had ~500 hosts and everyone trusted each other. It was never designed for security.

DNS cache poisoning: An attacker can inject a fake DNS response into a resolver's cache, causing users to be redirected to a malicious IP that looks like the real site.

DNS over HTTPS (DoH): Modern browsers increasingly use HTTPS for DNS queries, so your ISP can't see (or tamper with) your DNS lookups.

Split-horizon DNS: Large companies run two DNS systems: an internal one for employees (routes api.company.internal to the real internal IP) and an external one (routes api.company.com to the public-facing IP). Mixing these up causes interesting production incidents.

How India-Scale Systems Do It

Swiggy serves static assets from CDN edges in Delhi, Bangalore, and Mumbai while API calls hit ap-south-1. A Delhi user loading restaurant photos might never touch Mumbai. A live ETA call always does. That split is deliberate: images are cacheable, ETAs are not.

Hotstar during an IPL match pushes video over UDP-based delivery stacks while the app shell and auth stay on TCP+TLS. If you tried TCP for every video frame, the retransmit stalls would make the stream unwatchable at 10 crore concurrent viewers.

UPI (NPCI) cannot tolerate "eventually consistent" routing. Payment rails run over encrypted TCP connections to known endpoints. DNS misconfiguration during a bank migration once routed a slice of traffic to a stale IP. Transactions failed for 40 minutes. The fix was DNS TTL and health checks, not more app servers.

IRCTC tatkal opens at 10 AM with millions of users hitting the same origin. Without CDN for static assets and aggressive connection reuse (HTTP/2), the TCP+TLS handshake storm alone would saturate load balancers before a single seat query runs.

Flipkart Big Billion Days pre-warms CDN caches and uses anycast DNS so users in Chennai and Jaipur hit different edge nodes with the same hostname. The tradeoff: cache invalidation during a price change is harder. They accept stale product images for 30 seconds rather than melt origin.

The Decision Matrix

What you give up: TCP reliability costs handshakes and head-of-line blocking. UDP speed costs guaranteed delivery. HTTP/2 multiplexing still shares one TCP pipe, so one slow stream can block others. TLS adds RTT unless you invest in session resumption. There is no free lunch, only the right tool for the workload.

Common Mistakes

1. "HTTPS means the site is safe."
HTTPS means the connection is encrypted. It says nothing about whether the site is malicious, the server is secure, or the certificate is legitimate. Phishing sites use HTTPS all the time. The padlock icon just means "your connection to this site is private," not "this site is trustworthy."

2. "DNS is just a lookup; it can't be the bottleneck."
DNS can absolutely be a bottleneck. Slow DNS resolvers add 50-200ms to every cold request. Misconfigured TTLs (time-to-live) can mean your DNS change takes hours to propagate when you're in the middle of an incident. Always test your DNS performance and set appropriate TTLs (short for changing records, longer for stable ones).

3. "More TCP connections = faster loading."
HTTP/1.1 encouraged browsers to open 6 parallel connections per domain to work around the one-request-per-connection limitation. But opening 6 TCP connections means 6 handshakes, 6 TLS negotiations. That's wasteful. HTTP/2's multiplexing is strictly better. If you're still serving HTTP/1.1 in production, upgrade.

4. "Our app is slow, must be the database."
Before you blame the database, run a network trace. I've seen teams spend weeks optimizing SQL queries when the real issue was a missing CDN (static assets loading from the US instead of India) or DNS misconfiguration causing 300ms lookup times. Always profile the full request path before assuming.

🧠 Key Takeaways

• DNS is the phonebook: translates swiggy.com to an IP. Takes 20-50ms on a cold request, near-zero if cached.
• TCP guarantees reliable delivery with a handshake. UDP is faster but unreliable, the right choice for live media.
• HTTP is the text-based language of the web. Status codes (200, 404, 500) are vocabulary every engineer must know cold.
• HTTPS = HTTP + TLS encryption. Adds a round trip but is non-negotiable for any real application.
• HTTP/2 multiplexes multiple requests over one connection, a major performance improvement over HTTP/1.1.
• The physical internet (undersea cables, routing, BGP) creates latency floors that no amount of software optimization can overcome. Architecture must account for physics.

Think About It

1. Swiggy serves users in Delhi, Mumbai, Hyderabad, Kolkata. If all their servers are in Mumbai, what's the latency difference between a Delhi user and a Mumbai user making the same API call? What would you do architecturally to reduce that gap?

2. WhatsApp uses TCP for messages but not for voice/video calls. Why? And why does WhatsApp video still feel smooth even when your network is patchy, what engineering trick makes that work?

3. India has ~800 million internet users, many on 4G with 100-200ms latency to any server. How would that constraint change how you design an app like Google Pay versus how Silicon Valley designs apps for US users on broadband?

Further Reading

• How DNS Works (comic): Beautiful visual walkthrough of DNS resolution
• High Performance Browser Networking, Ilya Grigorik: Free book, the best deep dive on HTTP/2, WebSockets, WebRTC
• BGP Explained, Cloudflare Blog: Real incidents and how BGP routing breaks things
• Submarine Cable Map: See the actual physical cables your data travels through
• The Illustrated TLS Connection: Step-by-step breakdown of every byte in a TLS handshake