A server machine receives a request when incoming network traffic reaches its network interface, the operating system processes that traffic, and the data becomes available to a process listening for the relevant address, port, and protocol.
Learning Question
When request traffic reaches the server side, how does it become something a server process can read?
The server application does not receive a browser event.
The server machine receives network traffic. The operating system networking stack processes that traffic and associates it with a socket or transport endpoint. A server process can then accept or read from that endpoint.
The first mental model is:
The server machine receives bytes through the operating system before application code can see an HTTP request.
Server Machine vs. Server Process
The server machine is the environment that receives network traffic.
It may be:
- a physical machine
- a virtual machine
- a container host
- a cloud instance
- a serverless or platform-managed runtime environment
The server process is a running program that handles network communication.
Examples include:
- Nginx
- Apache
- Caddy
- Node.js server
- Python ASGI or WSGI server
- Java application server
- Go HTTP server
- reverse proxy or application runtime
The machine can receive packets only because its operating system and network interface exist. The process can handle requests only if it is running and listening through the server-side networking stack.
The machine and the process are distinct.
Listening on an Address and Port
A server process must be listening for incoming traffic.
At a simplified level, a process asks the operating system:
I want to listen for connections on this address and port.For example:
0.0.0.0:443
127.0.0.1:3000
10.0.1.25:8080The address controls which local interfaces or addresses the process listens on. The port identifies the service endpoint.
If no process or proxy is listening on the destination port, the request cannot be handed to application code.
It may fail with a connection error, be refused, or be handled by another infrastructure component depending on the environment.
Operating System Receives Incoming Traffic
When traffic reaches the server machine:
network interface
-> operating system network stack
-> transport handling
-> socket buffers
-> listening or connected processFor TCP-based HTTP, the operating system manages connection state. It handles incoming segments, acknowledgments, ordering, retransmission behavior, and buffers data for the process.
The process does not receive raw internet packets as its normal application interface. It reads from sockets or server abstractions built on sockets.
The operating system turns network events into process-readable data streams or datagrams.
Accepting a Connection Is Not Handling a Request
For TCP-based servers, a listening socket accepts connections.
Accepting a connection means the server process or server stack now has a connection endpoint for communicating with a client.
It does not yet mean an application route has handled a request.
On one connection, there may be:
- no complete HTTP request yet
- one HTTP request
- multiple sequential requests
- multiple concurrent streams, depending on protocol
Therefore:
Connection acceptance is a transport-level server event. Request handling is an application-level event.
This distinction matters for HTTP/2 and HTTP/3 especially, where a single connection can carry multiple request and response streams.
TLS Termination on the Server Side
If the server endpoint receives HTTPS traffic, TLS must be terminated before HTTP request details are visible to the component handling HTTP.
TLS termination may happen in:
- the same application process
- a reverse proxy on the machine
- a sidecar proxy
- a load balancer or ingress component before the application server
After TLS termination, the receiving component can interpret HTTP information such as method, path, headers, and body.
Before termination, the HTTP contents are encrypted transport data.
Request Data Becomes Available in Buffers
The server process usually does not read one whole request magically in a single step.
Incoming data may arrive in chunks and be buffered by the operating system, TLS layer, server library, or framework.
The server stack reads data, parses enough to recognize the HTTP message structure, and makes request information available to higher-level code.
For example, it may need to determine:
- where the headers end
- whether there is a request body
- how large the body is
- whether the request uses streaming or chunked transfer
- whether the request is valid
- whether limits have been exceeded
Only after enough protocol information is available can the server create a useful request representation for the application layer.
Different Processes May Own Different Steps
The process that first receives traffic may not be the process that runs application code.
Common arrangements include:
Nginx receives public traffic
-> forwards HTTP request to app process on localhostload balancer receives TLS traffic
-> forwards request to reverse proxy
-> reverse proxy forwards request to app serverplatform ingress receives request
-> invokes container or function runtimeIn each case, there is still a receiving boundary where network traffic becomes process-readable data.
There may be several server-side hops before the final application handler runs.
What the Application Has Not Done Yet
At the server-receipt stage:
- the request may not be fully parsed yet
- no route may have been matched yet
- no controller or handler may have run yet
- no database query may have happened yet
- the server may still reject the request for protocol, size, timeout, or security reasons
Receiving traffic is necessary for application handling, but it is not the same as application handling.
What This Chapter Does Not Explain Yet
This chapter explains the server machine and operating-system receipt boundary.
It does not explain full kernel networking internals.
It does not explain every web server architecture.
It does not yet explain framework routing, middleware, controllers, handlers, or business logic.
Those are the next stage: turning a parsed request into application execution.
Core Mental Model
Keep these boundaries separate:
- The server machine receives network traffic.
- The operating system processes transport data and manages sockets.
- A server process listens on an address and port.
- Accepting a connection is not the same as handling an HTTP request.
- TLS termination makes HTTP contents visible to the terminating component.
- Request parsing must happen before application code gets a useful request object.
The diagnostic question is:
Has the server only received transport data, or has the request reached application dispatch?
Final Summary
The server side begins with network traffic reaching a machine or endpoint and being processed by the operating system and server stack.
Only after that data is associated with a listening process, decrypted if needed, and parsed as HTTP can it move toward application routing and handler execution.