When you type an address like `https://shubhajitnotes.com` into your browser address bar and press Enter, your computer performs an astonishing series of coordinated physical and cryptographic steps within milliseconds. Most explanations stop at a high-level summary: *"DNS finds the IP, then your browser downloads HTML."* But understanding the precise mechanics underneath reveals why distributed systems behave the way they do, where latency actually originates, and how modern protocols overcome physical constraints. Bandwidth can always be bought and scaled by laying down thicker pipes; latency is fundamentally bounded by the speed of light in glass (~200,000 km/s). Every network optimization is ultimately a fight to reduce round trips (RTT). ## The Physical Substrate: Cables, Photons, and Autonomous Systems The internet is not a cloud. It is a vast physical web of fiber-optic cables running beneath ocean beds, buried under highways, and terminated in carrier-neutral data centers known as Internet Exchange Points (IXPs). Every major network on earth — whether an ISP, a cloud provider like Google or AWS, or a university — is registered as an **Autonomous System (AS)** with an assigned Autonomous System Number (ASN). Communication between disparate Autonomous Systems relies on the **Border Gateway Protocol (BGP)**. BGP does not measure link speed or quality; it calculates paths based on routing policies and commercial peering agreements: ``` [Your Laptop] │ (Local Wi-Fi / Ethernet) ▼ [ISP Local Gateway] ── (ASN 7018) │ ▼ (BGP Peering via IXP) [Tier 1 Transit / Backbone] ── (ASN 174) │ ▼ (Subsea Fiber Cable) [Cloudflare Edge / Vercel Edge Server] ── (ASN 13335) ``` ## The Logical Journey: What Happens When You Press Enter When you strike the Enter key, the operating system triggers a hardware interrupt. The browser receives the keystroke, parses the URL string, checks for special characters, and validates whether the protocol is explicitly defined or defaults to HTTPS. Before any packet leaves your network interface, your operating system must discover the destination's IP address. ## DNS Resolution: The Global Recursive Directory Domain names are human conveniences; IP routing operates strictly on binary addresses (IPv4 32-bit or IPv6 128-bit). Resolving a hostname follows a strict hierarchical cache lookup: 1. **Browser Cache**: Your browser inspects its internal DNS table. 2. **OS Resolver Cache**: If missing, it queries the local OS resolver (`/etc/hosts` and system cache). 3. **Local Router Cache**: The request checks your home or office router. 4. **Recursive Resolver**: If un-cached, the request reaches your configured recursive resolver (such as `1.1.1.1` or your ISP's resolver). If the recursive resolver does not have the record cached in its TTL window, it walks the DNS tree: ```bash # Tracing recursive root-to-authoritative lookup dig +trace shubhajitnotes.com A ``` | Step | Server Queried | Answer Returned | | :--- | :--- | :--- | | 1 | Root DNS Server (`a.root-servers.net`) | Points to `.com` TLD Name Server | | 2 | TLD Server (`a.gtld-servers.net`) | Points to Authoritative NS for domain | | 3 | Authoritative Name Server | Returns `A` / `AAAA` record (`104.21.54.12`) | Traditional DNS queries over UDP port 53 are unencrypted, allowing eavesdropping by upstream ISPs. Modern clients increasingly use DoH (DNS over HTTPS) or DoT (DNS over TLS) on port 443/853 to encrypt name resolution. ## The Transport Layer: TCP Handshakes and Congestion Control Once the IP address is known, the client initiates a transport session. For traditional HTTP/1.1 and HTTP/2, this requires a **Transmission Control Protocol (TCP)** three-way handshake: During this handshake, both endpoints negotiate parameters including: - **Maximum Segment Size (MSS)**: Preventing packet fragmentation. - **Selective Acknowledgments (SACK)**: Allowing retransmission of only dropped packets. - **TCP Window Scaling**: Enabling high-bandwidth throughput over high-latency links. ## Cryptographic Guarantees: TLS 1.3 Key Exchange Immediately after TCP establishes byte reliability, the Transport Layer Security (TLS) protocol negotiates encryption and identity verification. In TLS 1.2, this negotiation required two full round trips. TLS 1.3 optimized this down to a single round trip (1-RTT) using **Ephemeral Diffie-Hellman (ECDHE)**: ```typescript // Conceptual TLS 1.3 1-RTT Handshake flow interface ClientHello { cipherSuites: string[]; supportedKeyShares: Array<{ curve: "x25519"; publicKey: Uint8Array }>; serverNameIndication: string; // "shubhajitnotes.com" } interface ServerHello { chosenCipher: "TLS_AES_256_GCM_SHA384"; keyShare: { curve: "x25519"; publicKey: Uint8Array }; certificate: Uint8Array; // X.509 Certificate Chain signedVerify: Uint8Array; // Signature proving private key ownership } ``` Both sides derive shared cryptographic session keys without ever transmitting the secret over the wire. Once established, symmetric encryption (`AES-GCM` or `ChaCha20-Poly1305`) encrypts all further communication. ## HTTP/2, HTTP/3, and QUIC Multiplexing Historically, HTTP/1.1 suffered from **Head-of-Line (HoL) Blocking**: only one HTTP request could occupy a single TCP connection at a time. Browsers worked around this by opening up to 6 parallel TCP connections per host. HTTP/2 introduced **binary framing and multiplexing**, allowing hundreds of concurrent requests over a single TCP stream. However, if a single packet dropped at the TCP layer, the entire connection stalled while the missing packet was retransmitted. HTTP/3 solves this by replacing TCP with **QUIC** over UDP: ``` [ HTTP/3 Application Layer ] │ [ QUIC Layer ] ── Handles stream multiplexing, packet loss, and encryption │ [ UDP Layer ] ── Stateless, lightweight datagram delivery │ [ IP Layer ] ``` With QUIC, packet loss on Stream A has zero impact on Stream B. Furthermore, connection migration allows your mobile device to switch from Wi-Fi to cellular data without dropping active downloads. ## The Browser Rendering Pipeline Once the encrypted response payload streams back into your browser engine (such as Chromium or WebKit), the rendering engine springs into action: ``` HTML Bytes ──> Characters ──> Tokens ──> DOM Tree ──┐ ├──> Render Tree ──> Layout ──> Paint ──> Composite CSS Bytes ──> Characters ──> Tokens ──> CSSOM Tree ┘ ``` 1. **Incremental Parsing**: The browser does not wait for the entire HTML document to download. It streams chunks and constructs the DOM node by node. 2. **Preload Scanner**: A background thread scouts ahead for external resources (``, `

How the Internet Actually Works