A Connection Is Not Yet an HTTP Request

Why modern edge platforms begin much earlier than many architecture diagrams suggest.

There is a remarkable characteristic of modern platform architectures. Although almost every public application today runs behind a load balancer, API gateway, or web application firewall, we surprisingly rarely talk about what actually happens between the first TCP packet and the first byte of an HTTP request. The reason is obvious. For developers, this infrastructure usually disappears completely behind a URL. The browser establishes a connection, the reverse proxy accepts it, and a few milliseconds later the application is already processing the request. From the platform's point of view, however, the real work starts much earlier. Perhaps this is one of the biggest misconceptions in modern infrastructure. We often treat an HTTP request as if it were the beginning of a connection. In reality, it is one of its final steps.

Let us look at how an HTTPS connection is established. Not from the browser's perspective. From the perspective of an edge platform.

Browser
    │
    ▼
TCP Three-Way Handshake
    │
    ▼
TLS Handshake
    │
    ▼
HTTP Request
    │
    ▼
Layer 7 Processing
    │
    ▼
Backend Selection
    │
    ▼
Compute

Interestingly, HTTP does not exist at all during a significant part of this communication. Before the browser can send the first header, a TCP connection must first be established. Both peers negotiate sequence numbers, confirm reachability, and establish a reliable transport channel. Only then does TLS begin exchanging cryptographic parameters, negotiating supported cipher suites, and validating the server certificate. Only after that process has completed successfully does the platform gain access to application data for the first time. The order seems obvious. Its consequences are often underestimated.

As long as a connection consists only of TCP segments, a platform has surprisingly little information. It knows the source and destination addresses. It knows the source and destination ports. It knows sequence numbers. It may already know TCP options or ECN markings. But not much more. It does not yet know which URL will be requested, which host domain will be addressed, or which user is behind the connection. That information simply does not exist yet. Nevertheless, the platform already has to make decisions. Should this connection be accepted at all? Is there enough capacity? Could this be a volumetric attack? Are SYN cookies required? Does traffic need to be distributed at Layer 4 already? All of these decisions arise independently of the actual application protocol.

Only when the TLS handshake begins does the picture change. For the first time, the platform receives information beyond pure transport parameters. The ClientHello may include supported protocol versions, cipher suites, and extensions such as Server Name Indication (SNI), allowing a client to indicate during the handshake which hostname it wants to reach. For the first time, context appears. Not much. But enough to make additional decisions. Should this certificate be used? Is HTTP/2 possible? Is HTTP/3 offered? Should the connection already be terminated here because of cryptographic policy? SNI in particular has fundamentally changed the architecture of modern platforms. In the past, one public IP address often meant exactly one application. Today, hundreds or even thousands of applications may share the same address. It is not DNS that ultimately determines which application is meant. Not routing. Often it is only the TLS negotiation.

Only after the TLS handshake has completed successfully does what we commonly call an HTTP request finally emerge. Now, for the first time, there are headers. Cookies. Methods. URLs. Query parameters. JWTs. Host headers. And with them begins a completely different class of decisions.

TCP

↓

TLS

↓

HTTP

↓

GET /api/v1/users

Host: api.example.de

Authorization: Bearer …

Only now does a platform have enough information to perform meaningful Layer 7 routing. Only now can a web application firewall apply rules to specific URLs. Only now do rate limits per user or API key become possible. Only now can the platform decide whether /api and /dashboard should even reach the same application. This may explain why Layer 4 and Layer 7 load balancing, despite their similar names, solve fundamentally different problems.

Layer 4 looks only at transport information.

Source IP
Destination IP
Source Port
Destination Port
TCP/UDP

Layer 7, by contrast, looks at the actual application protocol.

HTTP Method
Host
URL
Headers
Cookies
Body

At first glance, this distinction seems technical. Architecturally, however, it has major consequences. A Layer 4 load balancer can forward millions of connections per second without ever knowing which application is behind them. A Layer 7 proxy, by contrast, knows the complete HTTP communication, but pays for that flexibility with additional processing, TLS termination, and significantly more context. There is therefore no universal answer as to which approach is better. They answer different questions.

Perhaps this is one of the most important architectural decisions in modern edge platforms. Not every connection needs the same processing. Not every service needs Layer 7. Not every application benefits from complete HTTP analysis. TCP databases. gRPC. MQTT. DNS. HTTP. Each of these protocols has different requirements. A platform should therefore be able to decide as early as possible which information is actually needed and which processing steps can be skipped. That is why an edge platform does not begin with HTTP. It begins with a connection. And it expands its knowledge step by step as that same connection reveals more context.

Perhaps this gradual emergence of information is one reason modern platform architecture can no longer be described meaningfully as a simple chain of products. TCP knows no HTTP headers. TLS knows no Kubernetes services. Layer 4 knows no URLs. Layer 7 knows no BGP routes. And yet each of these layers builds directly on the decisions of the previous ones. Not as a loose sequence of technical components. But as a continuous processing flow in which each layer uses exactly the information available to it at that point in time. That may also explain why we increasingly talk about platforms rather than individual products. A request does not emerge in a single moment. It emerges step by step. With every packet. With every handshake. With every piece of information the network reveals. And that is the real task of modern edge platforms: Not to provide as many features as possible. But to make exactly those decisions for which enough information already exists at each point in time.