Consider a browser running:
const response = await fetch("https://api.example.com/orders");The code describes an HTTP request. It does not say how the browser will reach the service. That journey depends on what the browser already knows, which HTTP version the peers support, and how the service is deployed. Here is one useful baseline: a new connection to an HTTPS service using HTTP/2 over TCP.
1. The client prepares the request
The browser parses the URL into a scheme (https), host (api.example.com), port (443 by default), path (/orders), and any query. It also applies browser rules such as cookies, cache policy, and security checks. A service worker, cache, or already-open connection may change what happens next. If a suitable connection is already available, the browser can reuse it and skip new DNS, TCP, and TLS setup.
2. The hostname is resolved when needed
The client needs an IP address to contact. It first checks its own available name and connection caches; if it still needs an address, the operating system's resolver asks a configured DNS resolver. That resolver may answer from cache or query other DNS servers before returning an address.
DNS gives the client an address to try. It does not guarantee that the address will be reachable, that the service is healthy, or that a particular server will handle the request. A hostname may resolve to several addresses, and deployments can use DNS, anycast, or an edge network to direct clients.
3. The client establishes a transport
In this baseline, the browser opens a TCP connection to the selected address on port 443. TCP establishes an ordered byte stream and handles retransmission when packets are lost. Routers forward packets toward the destination; the exact route is chosen by the network and can change over time.
This is not the only HTTPS transport. HTTP/3 uses QUIC, which runs over UDP and incorporates transport and security setup differently. If HTTP/3 is available and selected, the browser does not first perform the TCP connection described above. See the QUIC transport specification and TLS for QUIC.
4. TLS protects the connection
For HTTP/2 over TCP, the client and server perform a TLS handshake. They agree on cryptographic parameters, establish shared traffic keys, and authenticate the service identity using its certificate and the client's trust rules. After setup, TLS protects application data in transit against reading or modification by parties that cannot break the cryptography or control an endpoint.
TLS protects the connection between its endpoints. A CDN or reverse proxy may terminate TLS at the edge and create a separate protected connection to an application server. The browser's connection is then secure to the edge, while the service operator is responsible for protecting the next leg too. The TLS 1.3 specification defines the handshake; RFC 9525 describes service identity checks.
5. HTTP carries the request
Once the connection is ready, the browser sends an HTTP request with a method, target, headers, and possibly a body. For this example, the method might be GET and the target /orders. HTTP defines the meaning of these messages; the protocol version determines their wire framing and some connection behavior. HTTP/2 can carry multiple concurrent streams on a connection, while HTTP/1.1 and HTTP/3 have different framing rules.
An HTTP request can cross intermediaries such as a CDN, web application firewall, or load balancer. An intermediary may reject it, serve a cached response, route it to an available service instance, or forward it to another proxy. The architecture decides which of these components exist.
6. The service handles the request
The selected server accepts the request and passes it through its HTTP stack to application code. The application checks authentication and authorization, validates inputs, and performs the requested operation. It may read from a database, call another service, or return a result from memory. Each downstream dependency can add latency or fail independently.
The HTTP server turns the outcome into a response: a status code, headers, and possibly content. A 200 response can carry the requested representation; a 4xx or 5xx response still follows the same request/response model. HTTP semantics are shared across protocol versions and described in RFC 9110.
7. The response returns to the client
The response travels back over the established connection. The browser's networking stack processes the transport and TLS data, then makes the HTTP response available to JavaScript. fetch() resolves when response headers are available; reading the body is a separate operation, so a large response may continue streaming afterward.
The browser may keep the connection alive for another request. A later call to the same origin can therefore avoid repeating setup. Retries also need care: a client can often safely retry a read, but repeating a state-changing request may duplicate work unless the API defines an idempotency strategy.
The useful mental model
Separate the request into layers: the application chooses what it wants; HTTP expresses that intent; TLS may protect application bytes; TCP or QUIC transports them; IP routing moves packets; DNS helps find an address. Proxies and caches can participate between the client and the application. A real request may skip or add steps, so use this sequence as a map for asking which layer is doing the work.
Continue with the step-by-step HTTPS trace or explore the interactive request flow.