Before request bytes can be exchanged, the client must identify a network endpoint by resolving names, choosing an address and port, and preparing a connection or connection-like transport path.
Learning Question
How does a request for https://example.com/api/items know where to go?
The browser cannot send bytes to the word example.com by itself.
Human-readable hostnames are not the same as network addresses. The client must use naming and addressing mechanisms to find a destination that the network can route toward.
The first mental model is:
A URL names a target for the browser, but the network needs addresses, ports, and transport state.
Hostname Is Not the Server Process
In this URL:
https://example.com/api/itemsexample.com is a hostname.
It is not the application process.
It is not a database.
It is not necessarily one physical server.
It is a name that can be resolved to one or more network addresses. Those addresses may point to a load balancer, CDN edge, reverse proxy, gateway, or directly to a server machine.
The browser’s job is not to know the final application topology. It starts with the name and asks the system how to reach it.
DNS Maps Names to Addresses
DNS, the Domain Name System, maps hostnames to records, often including IP addresses.
At a simplified level:
example.com -> 93.184.216.34Real DNS can involve:
- local browser or operating system cache
- recursive resolvers
- authoritative name servers
- records such as
A,AAAA,CNAME, and others - multiple answers for load distribution or failover
- time-to-live values that control caching
The important request-path idea is:
DNS does not run the web application. DNS helps the client find an address to send network traffic toward.
If DNS resolution fails, the HTTP request cannot reach the server because the client does not have a usable destination address.
Address Is Not Enough
An IP address identifies a network destination.
But the client also needs a port.
The port identifies a service endpoint on the destination side. For common web traffic:
- HTTP commonly uses port
80 - HTTPS commonly uses port
443
The URL scheme often implies the default port.
For:
https://example.com/api/itemsthe default port is 443 unless another port is specified.
The destination is therefore not just example.com. It becomes something like:
address: 93.184.216.34
port: 443The server process or proxy must be listening on that port, directly or through operating system and infrastructure configuration, for the connection to succeed.
Connection Setup Depends on the Transport
For many web requests, the client needs transport state before request data can be sent.
With HTTP over TCP, the client establishes a TCP connection. TCP gives the endpoints a reliable byte stream. Before application data is exchanged, TCP performs connection setup.
With HTTPS over TCP, TLS is layered over the TCP connection. TLS negotiates encryption and authenticates the server certificate before HTTP request data is protected and sent.
With HTTP/3, the transport uses QUIC over UDP. The setup details differ, but the same conceptual role remains: the client prepares a secure communication path before sending HTTP request data.
The durable point is:
HTTP describes the request. Transport setup creates the path that can carry the request bytes.
TLS Is About Secure Transport, Not Application Routing
For https, the client expects a secure connection.
TLS helps provide:
- encryption, so intermediaries cannot read the request and response contents easily
- integrity, so data cannot be silently changed without detection
- server authentication, so the client has evidence that it is talking to the holder of a certificate for the requested name
TLS does not decide which application route handles /api/items.
It protects the communication channel. Routing happens later at the HTTP server or application framework level.
The browser may fail the request before sending HTTP data if certificate validation fails.
Existing Connections May Be Reused
The client does not always create a new connection for every request.
Browsers often reuse existing connections when possible.
With HTTP/1.1, multiple requests may reuse a persistent TCP connection sequentially.
With HTTP/2, multiple request and response streams may share one connection concurrently.
With HTTP/3, multiple streams may share one QUIC connection.
This means:
“Sending a request” does not always mean “opening a brand-new connection.”
The browser may already have a suitable connection to the same origin. In that case, request bytes can be sent over existing transport state.
Origin Combines Scheme, Host, and Port
For browser security and connection behavior, the origin matters.
An origin is usually the combination of:
scheme + host + portThese are different origins:
https://example.com
http://example.com
https://example.com:8443
https://api.example.comOrigin affects browser security rules such as same-origin policy and CORS behavior. It also affects whether existing connections, credentials, and cache entries are applicable.
The path alone does not define the origin.
/api/items and /profile on the same scheme, host, and port share an origin, even if the server routes them to different handlers.
What Can Fail Before the Request Is Handled
A request can fail before any application handler sees it.
Examples:
- DNS cannot resolve the hostname.
- No network route exists to the address.
- The destination refuses the connection.
- A firewall blocks traffic.
- TCP setup fails.
- TLS certificate validation fails.
- The browser rejects the request due to security policy.
- A proxy or network intermediary fails before the origin server is reached.
In these cases, the application handler may not run at all.
This is why “the request failed” does not always mean “the server returned an error.” Sometimes the request never reached the application server.
What This Chapter Does Not Explain Yet
This chapter explains how names become destinations and how transport setup prepares communication.
It does not yet explain packet forwarding through the network.
It does not yet explain server-side socket listening.
It does not yet explain HTTP parsing or application routing.
Those topics happen after the client has a destination and a transport path for request bytes.
Core Mental Model
Keep these layers separate:
- A URL is the client’s structured identifier for the request target.
- DNS maps a hostname to address information.
- A port identifies the service endpoint.
- TCP, TLS, or QUIC prepare transport state.
- HTTP request bytes are sent only when the client has a usable transport path.
- Application routing is not decided by DNS, IP, port, TCP, or TLS.
The diagnostic question is:
Am I resolving where to send bytes, preparing how to send bytes, or interpreting what the HTTP request means?
Final Summary
Before a browser can send a web request, it must turn the URL’s hostname into a reachable network destination and prepare transport state for communicating with that destination.
DNS, addresses, ports, TCP, TLS, and QUIC help create a path for bytes. They do not directly execute server application code or decide which handler owns the request.