> ## Content Index > Fetch the complete content index at: https://blog.greyhatguy007.win/llms.txt > Use this file to discover other available public pages before exploring further. # Networking 201 - URL: https://blog.greyhatguy007.win/networking-201/ - Published: 2026-09-20T08:52:27.000Z - Updated: 2026-09-20T08:52:27.000Z - Author: Ritvik Prasad > 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: graph TD Root\["Root Name Server (.)"\] --> Com\["TLD Name Server (.com)"\] Root --> Org\["TLD Name Server (.org)"\] Root --> In\["TLD Name Server (.in)"\] Com --> GoogleAuth\["Authoritative Name Server (ns.google.com)"\] Org --> GhostAuth\["Authoritative Name Server (ns1.ghost.org)"\] In --> LocalAuth\["Authoritative Name Server (ns.gov.in)"\] GoogleAuth --> GoogleIP\["IP Address 142.250.190.46"\] GhostAuth --> GhostIP\["IP Address 151.101.2.194"\] LocalAuth --> LocalIP\["IP Address 164.100.x.x"\] ###### 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. sequenceDiagram autonumber participant Client participant Server Note over Client,Server: TLS 1.3 Handshake Flow Client->>Server: Client Hello (keyshare, supported cipher suites) Server->>Client: Server Hello, keyshare, certificate, finish Note over Client: Gets keyshare, derives handshake secret, validates cert Client->>Server: Finished (Encrypted communication starts!) graph LR Client\["Client TLS Request
SNI: other.com"\] --> Ingress\["Nginx Ingress Controller"\] Ingress --> S1\["anything.com
(Cert A)"\] Ingress --> S2\["other.com
(Cert B)"\] style S2 fill:#d4edda,stroke:#28a745 ###### 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? graph LR Client\["Client TLS Request
SNI: other.com"\] --> Ingress\["Nginx Ingress Controller"\] Ingress --> S1\["anything.com
(Cert A)"\] Ingress --> S2\["other.com
(Cert B)"\] style S2 fill:#d4edda,stroke:#28a745 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. sequenceDiagram autonumber rect rgb(240, 240, 240) note right of Client: 1\. DNS Resolution Client->>Resolvers: DNS Request (google.com) Resolvers->>Client: DNS Response (IP: 142.250.190.46) end rect rgb(230, 242, 255) note right of Client: 2\. TCP Handshake Client->>Server: SYN Server->>Client: SYN-ACK Client->>Server: ACK end rect rgb(255, 235, 230) note right of Client: 3\. TLS 1.2/1.3 Handshake Client->>Server: Client Hello Server->>Client: Server Hello, Certificate, Server Hello Done Client->>Server: Client Key Exchange, Change Cipher Suite, Finish Server->>Client: Change Cipher Suite, Finish end rect rgb(235, 255, 235) note right of Client: 4\. Secure HTTP/2 Communication Client->>Server: GET /index.html (Encrypted) Server->>Client: 200 OK + Payload (Encrypted) end #####