What Happens When You Type a Website Address

Quick Answer

When you type a web address like https://thisishowitworks.in into your browser's address bar and press Enter, your computer does not simply "reach out" to the website. It initiates a coordinated chain reaction spanning all seven layers of computer networking in under 200 milliseconds:

1. URL Parsing & Security Audit: The browser breaks the string into protocol, hostname, and path. It checks its internal HSTS preload list to enforce encrypted HTTPS and checks its local DNS cache.
2. DNS Resolution (Finding the IP): If the IP address is not cached, your operating system asks a recursive DNS resolver. That resolver queries the Root servers, then the Top-Level Domain (TLD) servers (like .in), and finally the website's Authoritative DNS server to turn thisishowitworks.in into a numerical IP address (such as 104.21.48.12).
3. Local Link Discovery (ARP): Before your device can send a packet out of your room, it uses the Address Resolution Protocol (ARP) to find the physical MAC hardware address of your local Wi-Fi router.
4. TCP Connection (The 3-Way Handshake): Your browser and the remote server perform a synchronized three-way greeting (SYN → SYN-ACK → ACK) to establish a reliable, sequenced connection across the physical internet.
5. TLS 1.3 Cryptographic Handshake: Within a single round trip (1-RTT), the client and server exchange public cryptographic keys using Ephemeral Diffie-Hellman (ECDHE), authenticate the server's identity against trusted Certificate Authorities, and lock the channel with AES-256 or ChaCha20 encryption.
6. HTTP/2 Request & Response: Over this encrypted channel, the browser dispatches an HTTP GET request. The server streams back raw HTML bytes in 1,500-byte packets.
7. Browser Rendering Pipeline: As HTML bytes arrive, the browser tokenizes them into the DOM (Document Object Model), downloads and parses CSS into the CSSOM, combines them into a Render Tree, calculates pixel geometries (Layout), paints visual vectors, and delegates layer rasterization to the GPU.

[ Keystroke: Enter ]
        │
        ▼ (0–2 ms)
[ URL Parsing & HSTS Check ] ──────────► Enforces HTTPS://
        │
        ▼ (5–20 ms)
[ Recursive Anycast DNS ] ─────────────► Translates Name -> 104.21.48.12
        │
        ▼ (1–5 ms)
[ Local Link ARP Lookup ] ─────────────► Finds Home Router Gateway MAC
        │
        ▼ (15–40 ms)
[ TCP 3-Way Handshake ] ───────────────► SYN / SYN-ACK / ACK (RFC 9293)
        │
        ▼ (15–40 ms)
[ TLS 1.3 Cryptographic Handshake ] ───► ECDHE Key Exchange & Auth (RFC 8446)
        │
        ▼ (20–50 ms)
[ HTTP/2 Multiplexed Stream ] ─────────► HEADERS + DATA Frames (RFC 9113)
        │
        ▼ (10–30 ms)
[ Critical Rendering Path ] ───────────► DOM + CSSOM -> Layout -> GPU Raster
        │
        ▼ (< 200 ms Total)
[ Interactive Pixels on Screen ]

Phase 1: Keystroke to URL Parsing

The moment your finger strikes the Enter key, your browser's user-interface thread hands the raw input string to its internal URI parser, governed by the WHATWG URL Standard.

1. Dissecting the Uniform Resource Identifier

The browser checks whether the text is a search query or a valid Uniform Resource Identifier (URI). If the text lacks a scheme and top-level domain (for example, typing how internet cables work), the browser hands the string to your default search engine. If it parses as a web address:

  https://thisishowitworks.in:443/how-the-internet-works?ref=home#summary
  └──┬──┘ └──────────┬────────┘ └─┬─┘ └───────────┬──────────┘ └───┬────┘ └───┬───┘
   Scheme          Host          Port            Path            Query     Fragment

• Scheme (https): Tells the networking engine to use the Transport Layer Security protocol over TCP.
• Host (thisishowitworks.in): The human-readable name of the target entity.
• Port (443): The standard network port for encrypted web traffic (defaulting to 80 for plaintext HTTP and 443 for HTTPS).
• Path (/how-the-internet-works): The hierarchical resource identifier on the destination host.
• Query String (?ref=home): Parameters passed to the application.
• Fragment (#summary): A client-side anchor that scrolls the viewport; the fragment is never transmitted over the network wire.

2. The HSTS Preload Check

Before establishing any network socket, the browser inspects its compiled HSTS (HTTP Strict Transport Security) database.

If you typed thisishowitworks.in without specifying https://, a naive browser might first attempt an unencrypted http:// connection on port 80, allowing an attacker on public Wi-Fi to intercept or alter the traffic before a redirect occurs (a SSL-stripping attack).

Because modern security standards mandate HSTS, modern browsers ship with a hardcoded preload list. If the domain is on the list, the browser automatically transforms the URL to https:// client-side before a single photon leaves your Wi-Fi antenna.

Phase 2: The Domain Name System (DNS) & Anycast

Computers and optical routers do not understand human names like thisishowitworks.in. Routers only understand numerical IP addresses—specifically IPv4 (32-bit addresses like 104.21.48.12) or IPv6 (128-bit addresses like 2606:4700:3037::6815:300c).

The Domain Name System (DNS), standardized in IETF RFC 1035, is the planetary distributed telephone directory that maps names to IP addresses.

                        [ Browser DNS Cache ]
                                │ (Cache Miss)
                                ▼
                         [ OS DNS Cache ]
                                │ (Cache Miss)
                                ▼
                    [ Local hosts File (/etc/hosts) ]
                                │ (Cache Miss)
                                ▼
┌────────────────────────────────────────────────────────────────────────┐
│                      RECURSIVE DNS RESOLVER                            │
│           (Operated by your ISP, Cloudflare 1.1.1.1, or Google 8.8.8.8)│
└──────────────┬───────────────────┬───────────────────┬─────────────────┘
               │ 1. "Where is .in?"│ 3. "Where is      │ 5. "What is IP of
               │                   │    thisishow...?" │    thisishowitworks.in?"
               ▼                   ▼                   ▼
      ┌─────────────────┐ ┌─────────────────┐ ┌──────────────────────────┐
      │   ROOT SERVERS  │ │   TLD SERVERS   │ │    AUTHORITATIVE DNS     │
      │   13 Anycast IP │ │   (.in Registry)│ │   (Cloudflare / NS1)     │
      │   Identities    │ │   Run by NIXI   │ │   Holds Zone A/AAAA Data │
      └─────────────────┘ └─────────────────┘ └──────────────────────────┘
               │ 2. "Ask TLD"      │ 4. "Ask Auth"     │ 6. "104.21.48.12"
               └───────────────────┴───────────────────┴──────────┐
                                                                  ▼
                                                       [ Returns Resolved IP ]

The Hierarchical Lookup Chain

When your browser needs an IP address, it searches a hierarchical cascade of memory caches:

1. Browser Cache: Chrome, Safari, and Firefox store hundreds of recently resolved domain names in high-speed RAM for a few minutes.
2. Operating System Cache: If the browser misses, it issues a system call (such as getaddrinfo on Linux/macOS or DnsQuery on Windows) to the OS resolver daemon.
3. Local Hosts File: The OS checks its local override file (/etc/hosts or C:\Windows\System32\drivers\etc\hosts). If no static mapping exists, the request leaves your computer.

The Recursive Resolver's Journey

Your computer transmits a UDP packet on port 53 (or an encrypted DNS-over-HTTPS packet on port 443) to a Recursive DNS Resolver (usually assigned by your router via DHCP, or configured to public resolvers like Cloudflare 1.1.1.1 or Google 8.8.8.8).

If the resolver does not have the record in its cache, it performs a top-down tree traversal across the global root structure:

1. The Root Zone (. Name Servers): The resolver queries one of the 13 root server IP identities (named a.root-servers.net through m.root-servers.net). These 13 IP addresses do not represent 13 physical computers; they are broadcast worldwide across thousands of servers using BGP Anycast routing. The root server responds: "I do not know the IP of thisishowitworks.in, but here are the name servers for the .in Top-Level Domain."
2. The TLD Zone Servers (.in): The resolver queries the .in registry servers (operated by NIXI in India). The TLD server responds: "I do not have the specific website IP, but here are the Authoritative Name Servers designated by the domain owner."
3. The Authoritative Name Server: The resolver finally contacts the domain's authoritative name server (e.g., ns1.cloudflare.com). Because this server hosts the master DNS zone file, it returns the definitive A record (IPv4) or AAAA record (IPv6), accompanied by a TTL (Time to Live) value in seconds specifying how long the resolver can safely cache the answer.

The recursive resolver stores the answer in memory and returns the IP address to your operating system, which hands it back to your browser. Total elapsed time: 5 to 25 milliseconds.

The Step-by-Step Sequence Lifecycle

The diagram below maps the precise sequence of operations across your computer, local networking hardware, the global DNS hierarchy, remote edge servers, and your display graphics engine:

Phase 3: The Link Layer Handshake — ARP (Address Resolution Protocol)

Your browser now has an IP address: 104.21.48.12. However, your computer's Wi-Fi card or Ethernet chip cannot put an IP address directly onto a radio wave or copper wire.

Local network cards communicate strictly through 48-bit Media Access Control (MAC) hardware addresses at Layer 2 of the OSI model.

Because 104.21.48.12 is not on your home subnet (which typically uses private IP space like 192.168.1.0/24), your computer knows it must route the packet through your local Default Gateway (your home Wi-Fi router, e.g., 192.168.1.1). But what is your router's physical MAC address?

The ARP Broadcast Query

Your operating system consults its local ARP cache table:

• If the MAC address is cached, it encapsulates the IP packet into an Ethernet frame immediately.
• If the entry is missing, the OS broadcasts an ARP Request frame (IETF RFC 826) to the broadcast MAC address FF:FF:FF:FF:FF:FF:

"Attention all devices on this Wi-Fi network: Who has IP address 192.168.1.1? Tell MAC address 3c:22:fb:a4:89

."

Every device connected to your home Wi-Fi hears the broadcast. Devices whose IP does not match discard the frame. Your home Wi-Fi router recognizes its own IP and transmits a unicast ARP Reply:

"192.168.1.1 is at MAC address 74:83:c2:11:5a

."

Your operating system caches this hardware address in RAM and wraps the outbound IP packet inside a Layer-2 Ethernet frame stamped with your router's MAC as the destination. The Wi-Fi radio transmits the modulated radio burst to your router, which strips the Ethernet header, reads the IP packet, and forwards it into the optical fiber backbone.

Phase 4: The Transport Layer — TCP 3-Way Handshake

Now that packets can reach the destination server across the global fiber lattice (as detailed in our foundational guide on How the Internet Actually Works), your browser must establish an orderly, reliable connection.

Websites run on the Transmission Control Protocol (TCP), standardized in IETF RFC 9293. TCP guarantees that no bytes are lost, duplicated, or delivered out of sequence.

Client (Browser)                                         Server (Web Host)
       │                                                         │
       │── 1. SYN (Seq = X) ────────────────────────────────────►│  LISTEN
       │   "I want to connect. My starting byte sequence is X"   │
       │                                                         │
SYN_   │◄─ 2. SYN-ACK (Seq = Y, Ack = X + 1) ────────────────────│  SYN_RCVD
SENT   │   "Acknowledged! My starting sequence is Y. Send X+1"   │
       │                                                         │
       │── 3. ACK (Seq = X + 1, Ack = Y + 1) ───────────────────►│  ESTABLISHED
       │   "Acknowledged! Socket is officially open."            │
       ▼                                                         ▼
ESTABLISHED                                                 ESTABLISHED

Why a Three-Way Handshake?

A two-way exchange is mathematically insufficient to synchronize both sides reliably over an asynchronous network where packets can be delayed:

1. Packet 1 (SYN): The client generates a cryptographically random Initial Sequence Number (ISN), e.g., $X = 1000$, and sets the SYN flag bit in the TCP header.
2. Packet 2 (SYN-ACK): The server receives the request, stores the client's sequence number, generates its own random sequence number $Y = 5000$, and sets both SYN and ACK flags. The acknowledgment number is set to $X + 1$ ($1001$), confirming receipt of the client's SYN.
3. Packet 3 (ACK): The client confirms receipt of the server's sequence by sending an acknowledgment with $Y + 1$ ($5001$).

Both machines now have synchronized byte counters and allocated memory buffers. This exchange takes exactly one Round-Trip Time (1 RTT)—typically 15 to 60 milliseconds depending on geographic distance.

Phase 5: The Cryptographic Layer — TLS 1.3 Handshake (1-RTT)

A raw TCP connection is completely plaintext. Anyone tapping a fiber cable, operating an ISP router, or monitoring public Wi-Fi could read every password, cookie, and article you view.

To secure the connection, the browser immediately initiates a Transport Layer Security (TLS 1.3) handshake, governed by IETF RFC 8446. While older TLS 1.2 required two full round-trips to negotiate encryption, TLS 1.3 completes the entire cryptographic setup in a single round-trip (1-RTT).

Client (Browser)                                         Server (Edge CDN)
       │                                                         │
       │── 1. ClientHello ──────────────────────────────────────►│
       │   • Supported Cipher Suites (e.g. TLS_AES_256_GCM_SHA384)│
       │   • Server Name Indication (SNI: thisishowitworks.in)   │
       │   • Key Share: Client ECDHE Public Key (g^a mod p)     │
       │                                                         │
       │◄─ 2. ServerHello + EncryptedExtensions ─────────────────│
       │   • Selected Cipher Suite                               │
       │   • Key Share: Server ECDHE Public Key (g^b mod p)     │
       │   • Certificate Chain (Signed by trusted CA)            │
       │   • CertificateVerify (Digital signature over handshake)│
       │   • Finished (HMAC verifying handshake integrity)       │
       │                                                         │
═══════╪═════════════════════════════════════════════════════════╪═══════
       │    BOTH PARTIES INDEPENDENTLY COMPUTE SYMMETRIC KEY     │
       │           Session Key = (g^a)^b = (g^b)^a               │
═══════╪═════════════════════════════════════════════════════════╪═══════
       │                                                         │
       │── 3. First Encrypted Application Data (HTTP/2 GET) ────►│

1. Ephemeral Diffie-Hellman Key Exchange (ECDHE)

In TLS 1.3, the client does not wait for the server to reply before generating keys. In its very first ClientHello packet, the browser:

• Speculatively assumes modern elliptic curve cryptography (such as Curve25519 or NIST P-256).
• Generates an ephemeral private key $a$ and calculates a public key share $g^a$.
• Packs this public key share directly into the ClientHello.

When the server receives the packet, it generates its own private key $b$, calculates its public key share $g^b$, and combines the client's share with its private key to compute the master shared secret:

$$\text{Shared Secret} = (g^a)^b \pmod p = (g^b)^a \pmod p$$

Neither party ever transmits the shared secret across the wire. Even an adversary recording all optical internet traffic on ocean cables can never reconstruct the session key because deriving the private exponent from the public share is computationally intractable (the Discrete Logarithm Problem).

2. Server Identity Authentication

How does the browser know the server is truly thisishowitworks.in and not an imposter?

The server sends its X.509 Digital Certificate, signed by a recognized Certificate Authority (such as Let's Encrypt or DigiCert). The browser verifies the signature using the public keys of root Certificate Authorities pre-installed in your operating system's trust store. If the cryptographic signature matches and the domain name on the certificate matches the URL host, identity is verified.

At this exact instant, a secure symmetric channel locked with AES-GCM-256 is established.

Phase 6: Application Layer — HTTP/2 Multiplexing & Request

With encryption established, the browser dispatches the actual application request using HTTP/2 (IETF RFC 9113) or HTTP/3 (over QUIC/UDP).

Unlike legacy HTTP/1.1, which sent plaintext text strings like GET /index.html HTTP/1.1\r\n and suffered from head-of-line blocking (where only one file could be requested per TCP connection at a time), HTTP/2 operates on binary frames:

┌────────────────────────────────────────────────────────────┐
│                    HTTP/2 BINARY FRAME                     │
├──────────────┬──────────────┬──────────────┬───────────────┤
│ Length (24b) │  Type (8b)   │  Flags (8b)  │ Stream ID(31b)│
├──────────────┴──────────────┴──────────────┴───────────────┤
│ Frame Payload (Compressed Headers via HPACK or Data Bytes) │
└────────────────────────────────────────────────────────────┘

Multiplexing over a Single Socket

HTTP/2 splits traffic into independent bidirectional streams identified by an integer Stream ID:

• Stream 1: The initial HTML document request.
• Stream 3: An essential CSS stylesheet.
• Stream 5: A critical JavaScript bundle.
• Stream 7: An SVG diagram or WebP image.

All streams are interleaved simultaneously across the single TCP socket without waiting for preceding responses to finish.

TCP Slow Start & The First 14 KB

When the server begins transmitting the HTML response, it does not immediately blast the full webpage at maximum line speed. Because it does not know how congested intermediate routers are, TCP enforces Slow Start:

• The server initializes its Congestion Window (cwnd) to approximately 10 to 14 packets (roughly 14,600 bytes, or ~14 KB).
• The server transmits this first 14 KB chunk and stops, waiting for the browser to send an ACK packet.
• Once acknowledged, the server doubles its sending rate to 28 packets, then 56 packets, scaling exponentially until it detects network saturation.

This physical constraint is why frontend performance engineers optimize their critical rendering code to fit inside the initial 14 KB payload—allowing the browser to start rendering before the first round-trip pause.

Phase 7: The Browser Rendering Engine (Pixels on Screen)

As raw HTML bytes stream into the browser's networking process, they are piped directly into the Rendering Engine (such as Google Blink in Chrome and Edge, or Mozilla Gecko in Firefox).

The browser does not wait for the entire HTML document to download. It parses the document incrementally through the Critical Rendering Path:

[ Raw Bytes from Network: 3c 21 44 4f 43 ... ]
                      │
                      ▼
[ Characters: <!DOCTYPE html><html>... ]
                      │
                      ▼
[ Tokens: StartTag 'html', StartTag 'body', StartTag 'h1' ]
                      │
                      ▼
[ DOM Nodes: HTMLHtmlElement, HTMLHeadingElement ]
                      │
                      ▼
┌───────────────────────────────────────┐      ┌────────────────────────┐
│      DOCUMENT OBJECT MODEL (DOM)      │      │ CSS OBJECT MODEL (CSSOM)│
│  Hierarchical tree of HTML elements   │  +   │ Rules & computed styles│
└───────────────────┬───────────────────┘      └───────────┬────────────┘
                    │                                      │
                    └──────────────────┬───────────────────┘
                                       ▼
                             [ RENDER TREE ]
                 Only visible nodes (excludes <head>, display:none)
                                       │
                                       ▼
                                [ LAYOUT / REFLOW ]
                 Calculates exact coordinates & pixel bounding boxes
                                       │
                                       ▼
                                [ PAINT ENGINE ]
                 Generates display lists (vectors, text, colors, shadows)
                                       │
                                       ▼
                            [ COMPOSITING & GPU ]
                 Uploads bitmap textures to GPU VRAM -> Display 60/120Hz

1. Tokenization and DOM Tree Construction

The browser's HTML tokenizer implements a state machine defined by the WHATWG HTML Living Standard:

• Raw bytes are decoded into UTF-8 characters.
• Characters are converted into tokens (StartTag, EndTag, Character, Comment).
• Tokens are instantiated as DOM node objects and linked into a parent-child tree hierarchy: the Document Object Model (DOM).

2. The CSSOM and the Render Tree

Whenever the parser encounters a <link rel="stylesheet"> tag or <style> block, it pauses DOM construction if the style is render-blocking. It downloads and parses the CSS into the CSS Object Model (CSSOM)—a tree mapping CSS selectors to computed cascaded properties (font-size, margin, display).

Once both trees are ready, the engine merges them into the Render Tree:

• The Render Tree only includes nodes that actually produce visual output on screen.
• Elements inside <head>, <script>, and elements styled with display: none are stripped out completely.
• Elements styled with visibility: hidden are retained because they still occupy physical spatial volume.

3. Layout (Reflow): Calculating Geometry

With the visual hierarchy established, the browser begins Layout:

• Traversing the Render Tree starting from the root viewport.
• Computing the exact physical geometry of every box: width, height, margins, padding, and (x, y) Cartesian coordinates relative to the viewport.
• Resolving percentage widths (e.g., width: 50%) and flexbox/grid alignments into absolute device pixels.

4. Paint and GPU Compositing

Once coordinates are calculated, the browser executes the final visual stages:

• Paint: The browser converts layout boxes into a sequence of drawing commands (e.g., "draw a black rectangle at $(0, 0, 800, 60)$", "render text glyphs in Inter 16px").
• Tiling & Rasterization: The paint commands are divided into tiles (typically $256 \times 256$ pixels). The browser's raster worker threads convert these mathematical vectors into raw RGB pixel bitmaps.
• Compositing: Modern browsers separate elements into independent GPU layers (for example, fixed headers, video elements, or transform animations). The Compositor Thread uploads these layer textures to the graphics card's VRAM.
• GPU Display: The GPU composites the layers together into the hardware frame buffer, and the physical monitor refreshes its liquid crystal or OLED pixels at 60 Hz or 120 Hz.

The page is now visually complete and interactive. The entire journey—from keystroke, across ocean beds, through cryptography, down to graphics hardware—concluded in less than the blink of a human eye.

Why This Architecture Matters

Every layer in this sequence was designed under a single architectural philosophy: separation of concerns through layered abstraction.

Because each layer operates independently:

• The DNS system does not need to know whether you are using Wi-Fi, 5G, or Ethernet.
• The TCP and IP protocols do not need to know whether you are transferring an HTML document, a video stream, or a cryptographic bank transfer.
• The Browser Rendering Engine does not need to care which submarine fiber cable transported the packets across the Atlantic or Indian Oceans.

When modern engineers optimize web applications, they are navigating the physical laws of this stack:

• Content Delivery Networks (CDNs) move Anycast DNS and TLS termination geographically closer to the user to compress the TCP and TLS round-trip latencies.
• HTTP/3 (QUIC) replaces TCP with encrypted UDP streams, collapsing the TCP handshake and TLS handshake into a single 0-RTT connection.
• Critical CSS Inlining allows the rendering engine to paint the initial viewport within the first 14 KB TCP window before external stylesheets arrive.

The planetary internet is not a single technology; it is a synchronized choreography of decentralized protocols, converting physical optical pulses into human knowledge at the speed of light.

To understand how global networks route packets across transoceanic optical cables and commercial Autonomous Systems, read our foundational guide on How the Internet Actually Works. You can also discover how banking networks leverage secure message switching in How Money Moves Between Indian Banks or explore how contactless cards execute cryptographic challenges in How Credit Cards Actually Work.