The network delivers request bytes by forwarding packets across connected networks toward the destination address, often through routers, proxies, load balancers, or CDN infrastructure before anything reaches the server-side application path.
Learning Question
What happens between the client machine sending bytes and the server machine receiving them?
The request does not travel through a single direct wire from browser code to server code.
It moves as network traffic across intermediate systems. Those systems generally operate at transport, network, or proxy layers. They do not know the user’s button click or the server route handler as application concepts.
The first mental model is:
The network forwards deliverable units of traffic toward an address. It does not execute the web request’s application meaning.
The Network Carries Packets, Not Intent
At the application level, the client has an HTTP request.
At lower levels, the network carries packets or datagrams with addressing and transport information.
Those packets may contain encrypted pieces of HTTP data. They may also contain transport control information, retransmissions, acknowledgments, or connection-management data.
The network does not carry a high-level instruction such as:
call createItem on the backendIt carries traffic that lower layers can route and deliver.
Application intent exists inside the HTTP message and server-side interpretation, not in the network’s forwarding decisions.
Routers Forward Toward Destinations
Routers move packets between networks.
At a simplified level, each router asks:
For this destination address, where should I send the packet next?The router does not need to know the final application route, database query, or user interface behavior.
It uses routing information to choose a next hop.
Across the internet, traffic may pass through several networks:
client network
-> internet service provider
-> transit networks
-> destination provider network
-> server-side infrastructureThe exact path may vary over time. Packets for the same connection are usually expected to reach the destination consistently, but the internet is still a network of forwarding decisions, not a single fixed tunnel from application to application.
Middleboxes May Participate
Between client and application server, traffic may pass through systems such as:
- NAT devices
- firewalls
- corporate proxies
- VPN gateways
- CDN edge servers
- reverse proxies
- load balancers
- API gateways
These systems have different roles.
A NAT device may translate private local addresses to public addresses.
A firewall may allow or block traffic.
A CDN may serve cached content or forward the request.
A reverse proxy may terminate TLS and pass the request to an internal server.
A load balancer may choose one backend server from a pool.
These are still not the same thing as the application handler. They are infrastructure participants that may deliver, reject, transform, terminate, forward, or answer traffic before the application code sees it.
Server Address May Point to Infrastructure
The IP address returned for a hostname may not belong directly to the application server process.
It may belong to:
- a CDN edge
- a load balancer
- a reverse proxy
- a cloud ingress gateway
- a network appliance
- a virtual IP that fronts many server instances
This means the visible destination in the browser is not necessarily the final machine where application code runs.
The request may first arrive at infrastructure that decides what to do next.
For example:
client
-> CDN edge or load balancer
-> reverse proxy
-> application server processThe conceptual boundary remains the same: application code runs only when the request reaches a process responsible for invoking it.
TLS Termination Changes Where HTTP Becomes Visible
With HTTPS, the HTTP contents are encrypted during transport.
At some point, TLS is terminated by a system that holds the relevant certificate and private key or participates in the configured secure endpoint.
TLS may terminate:
- in the application server process
- in a reverse proxy on the same machine
- in a load balancer
- at a CDN edge
- at an ingress gateway
Where TLS terminates matters because that is where encrypted transport data becomes visible as HTTP-level request information.
After TLS termination, infrastructure may forward the request to another internal service, sometimes over another encrypted connection and sometimes over a private internal network.
The durable distinction is:
Secure transport termination is not automatically application handling. It is the point where protected bytes can be interpreted at the HTTP level by that component.
The Network Can Fail Before the Server Application
Many failures happen before application code receives the request.
Examples:
- DNS pointed to an unavailable address.
- A router or provider drops traffic.
- A firewall blocks the destination port.
- A CDN refuses the request.
- A load balancer has no healthy backend.
- TLS negotiation fails at an edge.
- A proxy times out before forwarding.
- The request body is too large for an intermediary.
In these cases, the client may see a network error or an HTTP error response from an intermediary.
That error may not come from the application code the user expected.
The Server Machine Boundary
Eventually, if delivery succeeds, traffic reaches a machine or infrastructure endpoint responsible for receiving it.
At that boundary:
network-delivered traffic
-> network interface of destination machine or edge component
-> operating system networking stackThe server-side operating system must then associate the incoming traffic with a listening socket, connection, or process.
That server-side receipt is the next step. Network delivery alone still does not mean the application handler has run.
What This Chapter Does Not Explain Yet
This chapter explains packet delivery across networks and infrastructure.
It does not explain full routing protocols, BGP, TCP internals, CDN configuration, load balancing algorithms, or firewall rule design.
It does not yet explain how the server operating system accepts traffic or how the server process parses HTTP.
Those topics come after traffic reaches the server-side receiving boundary.
Core Mental Model
Keep these levels separate:
- HTTP expresses the request’s application-level structure.
- Transport and network layers move traffic toward an address and port.
- Routers forward packets based on network information.
- Middleboxes may block, transform, terminate, forward, or answer traffic.
- Infrastructure endpoints may receive the request before the application server.
- Network delivery is not application handling.
The diagnostic question is:
Did this component forward or terminate traffic, or did it actually run the application logic for the request?
Final Summary
The network delivers request bytes by moving packets through routing and infrastructure toward a destination endpoint.
Routers, proxies, load balancers, CDNs, and gateways may participate before the request reaches application code. They help deliver or mediate traffic; they are not automatically the server-side handler that implements the request’s meaning.