Network Packet Journey

Overview

Loading a web page is a chain of steps across several systems, and knowing the chain helps you find where a slow or failing request is stuck. This simulator follows a request from the browser to the database and back. It starts with DNS resolution to find the address, then the TCP handshake, then, for HTTPS, the TLS handshake. The request may stop at a CDN edge, pass through a load balancer, reach a web server, be handled by the application and trigger a database query, and the response travels back the same way. Four scenarios compare the paths: plain HTTP, HTTPS, HTTPS through a CDN, and HTTPS with the response already cached at the CDN, where the request never reaches your servers at all. Seeing the steps one after another shows where the time goes, why TLS adds round trips, and why a CDN cache hit is so much faster than a full trip to the origin. It is a useful mental model for the classic interview question about what happens when you type a URL.

Try this

1. Run "Basic HTTP" and then "HTTPS" to see the extra TLS handshake step.
2. Run "HTTPS + CDN" and follow the request from the edge to the origin and back.
3. Compare it with "HTTPS + CDN (Cached)", where the edge answers without contacting the origin.

Frequently asked questions

What happens when you type a URL into a browser?

The browser resolves the domain with DNS, opens a TCP connection, negotiates TLS for HTTPS, sends the HTTP request, which may pass through a CDN and load balancer to an application, and renders the response.

How does a CDN make a site faster?

It serves cached copies from edge locations close to users, which shortens the network distance and spares the origin. On a cache miss the edge fetches from the origin and may keep the result for later requests.

Why is HTTPS slower to connect than HTTP?

A new TLS connection adds a handshake before the request can be sent: one round trip with TLS 1.3, two with TLS 1.2. Connection reuse and TLS 1.3 resumption keep that cost small.