This trace follows a fresh HTTPS request to https://api.example.com/orders, using HTTP/2 over TCP. That choice makes the boundaries easy to see. A browser with a warm connection can skip address resolution and connection setup; an HTTP/3 request uses QUIC instead of TCP. The steps below describe a common architecture, not a protocol-mandated list of appliances.
Step 1: Parse the URL and request policy
The browser extracts the scheme, host, port, and path. It checks whether browser policy, a service worker, a cache entry, or an existing connection can satisfy or change the operation. In our fresh-connection example, it needs to contact the origin.
Step 2: Resolve the hostname if necessary
The networking stack asks the operating system's configured resolver for an address when its own usable caches do not already have one. A DNS resolver can answer from cache or perform additional queries. The returned address is a candidate destination, not a promise that the service will respond.
Step 3: Open TCP
The client sends packets toward the chosen IP address and port. TCP performs its connection setup and creates an ordered byte stream. IP packets may pass through many routers; the application normally does not choose each hop itself.
Step 4: Establish TLS
The client and server negotiate TLS parameters and derive traffic keys. The client validates the certificate chain according to its trust store and checks that the certificate is valid for the requested service name. A successful handshake gives the client an authenticated encrypted channel to the TLS endpoint. If that endpoint is a CDN, a separate connection may carry the request onward.
Step 5: Send HTTP
The browser sends an HTTP request for /orders, including the method and headers, plus a body when needed. HTTP/2 frames the request on a stream, allowing multiple streams to share a connection. HTTP semantics define the request's meaning independently of this particular framing; see RFC 9110.
Step 6: Route at the edge
If the service uses an edge proxy or load balancer, that component receives the request, applies its routing or security rules, and may forward the request over another connection. It may also answer from a cache or reject the request before application code runs.
Step 7: Run application logic
The application validates the request, applies business rules, and calls dependencies as required. A database query or service-to-service call is another request journey with its own timeouts, failures, and connection choices. A slow dependency can dominate the total response time even when the client connection was fast.
Step 8: Return a response
The service sends a status code, headers, and optional content. Proxies and transport layers carry the response back. The browser exposes the response to the caller, which can then consume a streaming body or parse the complete representation.
What changes on a warm request?
The browser may reuse a connection, so DNS resolution, TCP setup, and TLS setup do not repeat. The request still has HTTP semantics and still needs server handling unless a cache or intermediary answers it. With HTTP/3, QUIC supplies transport and uses TLS handshake messages as specified in RFC 9000 and RFC 9001.