Networking 201

The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made.

So today we'd be touching upon few of the core concepts in networking that is enabling you to view this write-up comfortably (and securely) at your place right now.

So, let's start with a basic question.

What happens when you enter google.com in your browser ?

Sounds simple right, but the things that happen is far beyond fascinating.

To grasp the true engineering marvel that happens behind the scenes, we first need to lay down a few groundwork.

Numbers or Names ?

Before a single packet can travel across the globe, we run into a fundamental mismatch: computers love numbers, but humans love names.

Under the hood, every device connected to the internet is identified by an IP address - a numerical label like 142.250.190.46 (IPv4) or 2607:f8b0:4004:c08::64 (IPv6). While routers and network interface cards route traffic effortlessly using these numeric identifiers, expecting humans to memorize a string of numbers for every single website we visit would be completely impractical.

This is where hostnames come in.

A hostname is a human-readable label assigned to a device connected to a computer network. It acts as an alias, masking the raw numeric complexity of an IP address behind a structured, memorable name.

Anatomy of a Hostname

When you look at a fully qualified domain name (FQDN) or a hostname like www.google.com, it isn't just a random string. It is structured hierarchically from right to left:

• Root Domain (.): The invisible dot at the very end of the hierarchy, managed by root name servers.
• Top-Level Domain (TLD): The rightmost segment (e.g., .com, .org, .io, .in). It categorizes the type of organization or geographic region.
• Second-Level Domain (SLD): The primary identifier chosen by the organization (e.g., google).
• Subdomain: The leftmost segment (e.g., www, mail, docs) that points to a specific server or service within that organization's infrastructure.

Why Hostnames Matter

1. Abstraction: They decouple the identity of a service from its underlying infrastructure. If Google needs to migrate google.com to a completely new data center with a brand-new set of IP addresses, the hostname remains unchanged. Only the underlying mapping updates.
2. Virtual Hosting: A single physical server holding a single IP address can host hundreds of different websites. Hostnames allow the server to figure out which specific site your browser is actually asking for. (we'd come back to this later)

Now that we have a human-readable label, our browser faces an immediate roadblock: the local operating system doesn't inherently know which IP address google.com points to.

So how do we know what's the IP address of google.com ? This is where DNS comes in.

"The" DNS

So, DNS is Domain Name System. It is responsible for converting hostnames into their corresponding IP addresses.

There are billions of websites on the internet, and each one of them have an IP address associated to them. Now if you need to lookup a website, you could have its corresponding IP mapped to its hostname on your computer. But can you do it for every single website ? A billion of them ? Your system would run out of space storing the hostname-IP mapping.

So what do we do now ? This is where DNS comes in.

The DNS is actually a protocol. It runs on top of UDP, usually port 53.

Instead of a single bloated database, the Domain Name System is organized as a distributed, hierarchical database spread across millions of servers worldwide.

When your computer needs to resolve a hostname like google.com, it doesn't just guess or query the entire internet at once. It climbs down a structured tree of name servers step-by-step until it finds the exact server holding the final answer.

Here is how that hierarchical lookup flows across different branches of the internet:

Anatomy of a DNS Packet & The OSI Model Check

Before we watch the browser pack its bags, let’s look closely at how a DNS request is actually structured on the wire. DNS runs over UDP port 53. When your computer's stub resolver kicks off a query, it structures the packet into distinct sections:

• Header: Contains critical administrative metadata, including num_questions, num_answers, num_authority, num_additional, and tracking flags.
• Question Section: Holds the target domain name you are trying to resolve (e.g., mail.google.com), along with the query type (like A or AAAA for IPv4/IPv6 addresses, or CNAME for canonical names).
• Answer Section: The payload returned by the nameserver containing the resolved IP.
• Authority Section: Points to the authoritative nameservers if the domain isn't fully resolved yet.
• Additional Section: Contains extra helpful data, such as the IP addresses of those nameservers.

Taking a Step Back: The OSI Model

Now that the domain name is resolved into an IP address, it is a great time to map out where we are across the OSI model:

• Application Layer: Where protocols like HTTP, DNS, and SSH live.
• Presentation Layer: We honestly don't care about it here.
• Session Layer: Also bypassed for this flow.
• Transport Layer: SSL/TLS encryption layers.
• Network Layer: TCP/UDP connection management and IP addresses.
• Data Link Layer: The local MAC address routing.
• Physical Layer: Let's not go this deep into the copper wires and optical fiber.

Evolution of HTTP

Once we have our IP address, we need to fetch the actual web page using HTTP. HTTP has grown up a lot over the years:

• HTTP/0.9: A long while back, this opened a TCP connection, sent a basic response, and immediately closed it. Highly inefficient, and no headers whatsoever.
• HTTP/1.0 & 1.1: Brought in proper headers and connection pipelining.
• HTTP/2.0: Brought in full multiplexing and streaming capabilities.
• HTTP/3.0: Ditched TCP entirely in favor of QUIC (Quick UDP Internet Connection) to completely eliminate head-of-line blocking.

For HTTP versions 1 through 2, we rely on TCP underneath.

The TCP Handshake

Before any application data flows, TCP establishes a reliable connection using the classic 3-way handshake.:

1. SYN: The client initiates synchronization.
2. SYN-ACK: The server acknowledges and sends its own synchronization.
3. ACK: The client acknowledges back, and the connection is live.

TLS Negotiation & SNI

Between TCP and HTTP comes TLS (Transport Layer Security). TLS encrypts the connection so anyone listening on the physical wire can't read your sensitive messages. Like HTTP, TLS has evolved significantly.

TLS 1.2 vs TLS 1.3 Handshake

TLS 1.2 takes two full round trips to negotiate keys and verify certificates, whereas TLS 1.3 streamlines this down to a single round trip by guessing client keyshares upfront.

SNI (Server Name Indication) and Virtual Host Routing

Imagine a Kubernetes cluster running an Nginx Ingress controller. That single controller manages dozens of microservices, each with its own independent SSL certificate (other.com, anything.com, etc.).

When your browser connects to port 443 on an IP address hosting multiple domains, how does the server know which certificate to hand back?

For this, we use SNI (Server Name Indication). The domain name is attached right inside the plaintext Client Hello message so the proxy knows which virtual host and certificate to route to. (Modern TLS 1.3 even introduces Encrypted Client Hello (ECH) to encrypt the SNI itself!)

Putting Everything Together

Let's visualize how a complete GET google.com request flows from top to bottom across every layer we just unpacked

I believe most of you would think of your web browsers as a simple application that you use to view websites, and that's a surface level description of what it does. The browser does many behind-the-scenes work, more than what you think the browser is doing.