How the Internet Actually Works

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.

#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:

# Tracing recursive root-to-authoritative lookup
dig +trace shubhajitnotes.com A

#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):

// 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 (<link rel="stylesheet">, <script src="...">, <img>) to initiate network fetches early.
3. Layout (Reflow): Computing exact pixel coordinates and dimensions for every visible box on the screen.
4. Paint & Composite: Translating layout geometry into pixel bitmaps on raster threads, then handing GPU layers to the compositor for hardware-accelerated drawing.

#Key Takeaways

The web is an intricate, multi-layered machine built on decades of foundational engineering:

• Fiber and BGP route your packets across physical borders.
• DNS translates human abstractions to machine coordinates.
• TCP and QUIC provide reliability over unreliable physical links.
• TLS 1.3 guarantees confidentiality and integrity in an adversarial world.
• Browser engines assemble raw bytes into interactive human interfaces.

When you respect how these layers work in harmony, you build faster, more resilient, and more enduring software.