↓Skip to main content

What happens when you access a webpage?

·6 mins
Tech Tidbits
Table of Contents

Going to a website is something pretty much everyone does everyday. It just works and we don’t think about it much.

So what actually happens behind the scenes?

First you type in a URL or click on a link, and then the adventure begins!

Let’s suppose we typed in anuragdulapalli.com

Parsing the URL #

First, the browser will parse the URL. In our case, it will assume the protocol is HTTP by default and convert the URL into: http://anuragdulapalli.com. Some browsers will then upgrade that to HTTPS as well so it becomes https://anuragdulapalli.com

URL example

Resolving the URL #

The browser needs to translate the URL into an IP address. It will perform a Domain Name Resolution (DNS) query using a DNS “resolver”–this is a reusable intermediary.

The request will go to the Internet Service Provider (ISP) which will then contact its own managed DNS server.

There are a few sub-steps here.

Root nameserver #

There are thirteen root nameservers that every DNS resolver knows about. Any of these nameservers will accept the initial DNS request and tell the resolver to to seek a particular TLD nameserver.

TLD nameserver #

A TLD nameserver is responsible for information on all the domains matching a specific top-level domain (TLD). These can be .com, .org, and so forth.

The TLD nameserver will point the resolver to the authoritative nameserver for a domain.

Authoritative nameserver #

This is generally the last step in the DNS lookup. This nameserver knows the specific DNS record information for the domain.

If the DNS record is an “A record”, the resolver will now get a specific IP address.

Otherwise, if there is a CNAME record, then the resolver will get an alias domain… and have to perform a fresh DNS lookup for that domain.

%%{ init: { "mirrorActors": false } }%% sequenceDiagram participant Client as Browser participant DNSResolver as DNS Resolver participant RootNS as Root Nameserver participant TLDNS as TLD Nameserver participant AuthNS as Authoritative Nameserver Client->>DNSResolver: Query anuragdulapalli.com DNSResolver->>RootNS: Which server knows about .com domains? RootNS-->>DNSResolver: Use .com TLD nameserver DNSResolver->>TLDNS: Which server knows about anuragdulapalli.com? TLDNS-->>DNSResolver: Use Authoritative nameserver DNSResolver->>AuthNS: Where can I find anuragdulapalli.com? AuthNS-->>DNSResolver: Here's the IP address DNSResolver-->>Client: IP address for anuragdulapalli.com

Making a connection #

Now that we have the site address, the browser needs to connect to the site. The site could be hosted on a standard server or on a content delivery network (CDN).

TCP handshake #

Assuming we have a standard HTTP or HTTPS URL, the browser will try to connect using the Transmission Control Protocol (TCP) over IP.

This requires a handshake between the client (browser) and server:

  1. The client initiates the connection by sending a SYN (synchronize) packet to the server. It also includes a random sequence number x.
  2. The server responds with a SYN-ACK (synchronize-acknowledge) packet. It acknowledges the client’s request by sending back x + 1 and sends its own random sequence number y.
  3. The client confirms the connection with an ACK packet by sending back y + 1. The client is ready at this point.
  4. Once the server receives the last ACK packet, the server is also ready.
%%{ init: { "mirrorActors": false } }%% sequenceDiagram participant Client participant Server Note over Client,Server: TCP Three-Way Handshake Client->>Server: SYN (Synchronize) Note right of Client: Sequence Number = x Server->>Client: SYN-ACK (Synchronize-Acknowledge) Note left of Server: Sequence Number = y
Acknowledgment Number = x+1 Client->>Server: ACK (Acknowledge) Note right of Client: Acknowledgment Number = y+1 Note over Client,Server: Connection Established

TLS handshake #

If we have an HTTPS URL, a Transport Layer Security (TLS) handshake is required after the TCP connection is established. This secures the connection through encryption:

  1. The client sends a Client Hello message with supported TLS versions, cipher suites, and a random value.
  2. The server responds with a Server Hello message selecting the TLS version and cipher suite, plus its own random value.
  3. The server sends its digital certificate for the client to verify.
  4. The client verifies the certificate and generates a pre-master secret, encrypting it with the server’s public key.
  5. Both client and server independently generate the same session keys from the pre-master secret.
  6. The client and server exchange Finished messages to confirm the handshake was successful.
%%{ init: { "mirrorActors": false } }%% sequenceDiagram participant Client participant Server Note over Client,Server: TLS Handshake Client->>Server: Client Hello Note right of Client: TLS version, cipher suites, random Server->>Client: Server Hello Note left of Server: Selected TLS version, cipher, random Server->>Client: Certificate Note left of Server: Server's digital certificate Server->>Client: Server Hello Done Client->>Server: Client Key Exchange Note right of Client: Pre-master secret (encrypted) Client->>Server: Change Cipher Spec Client->>Server: Finished Server->>Client: Change Cipher Spec Server->>Client: Finished Note over Client,Server: Secure Connection Established

Fetching the site content #

Once the TCP connection is established. The browser will send an HTTP request to fetch the site content from the server. This is typically done via an HTTP GET method.

The server will then process the request and respond back with the HTML/CSS/JS and other assets that represent the web page.

%%{ init: { "mirrorActors": false } }%% sequenceDiagram participant Client as Browser participant Server as Web server Client->>Server: HTTP GET /index.html Note right of Client: Request headers (Host, User-Agent, Accept, etc.) Server->>Client: 200 OK Note left of Server: Response headers (Content-Type, Content-Length, etc.) Server->>Client: Content payload (HTML, CSS, JS)

Rendering the site #

After the browser has access to the site content, it will attempt to render it for display.

HTML and CSS #

First, the browser will parse and convert any received HTML into a Document Object Model (DOM). This represents the structure of the page.

Next, the browser similarly parses any CSS files into a CSS Object Model (CSSOM), which describe how to style the page.

These two representations are combined into a “render tree”.

JavaScript #

The browser content may include JavaScript (JS) code. Any JS that is declared to be executed immediately (vs. conditionally or async) will be executed. Depending on what the code does, running it may affect what the current render tree looks like.

Layout and painting #

Finally, the browser will calculate the actual sizes and positions of page elements. It will then paint the elements, add coloring, and include media (images and so forth).

flowchart TD A[HTML Content] --> B[Document Object Model] C[CSS Content] --> D[CSS Object Model] B --> E[Build render tree] D --> E F[JavaScript] --> G{Manipulate DOM?} G -.-> B E --> H[Calculate layout] H --> I[Paint] I --> J[✨ Display page ✨] %% Distinct coloring for HTML, CSS, and JS style A fill:#D62728,stroke:#333,stroke-width:2px,color:white style C fill:#1F77B4,stroke:#333,stroke-width:2px,color:white style F fill:#FF8C00,stroke:#333,stroke-width:2px,color:white %% Processing elements style B fill:#f9f,stroke:#333,stroke-width:2px style D fill:#bbf,stroke:#333,stroke-width:2px style E fill:#ff9,stroke:#333,stroke-width:2px style G fill:#ffe6cc,stroke:#333,stroke-width:2px style H fill:#d5e8d4,stroke:#333,stroke-width:2px style I fill:#9f9,stroke:#333,stroke-width:2px %% Final display with simple but attractive styling style J fill:#845EC2,stroke:#333,stroke-width:3px,color:white

🎉 Success! 🎉 #

Congratulations! The webpage is ready to use.