The same HTTPS request crosses a hub, a switch, a router, a stateful firewall, a layer 4 load balancer and a layer 7 proxy; what can each read, and why can only the proxy route on the URL path?
answer
- progressively deeper wrappers
- firewall and L4 read alike
- decision made at the first segment
- path inside encrypted payload
- terminate to read
basics
~20 sThey read progressively deeper: hub nothing, switch the MAC, router the IP, firewall and layer 4 balancer the IP and TCP headers. The path is encrypted HTTP inside TLS, so only a proxy that terminates TCP and TLS can read it.
solid answer
~50 sThe **hub** repeats bits and reads nothing. The **switch** reads the Ethernet header and forwards on the destination MAC. The **router** reads the IP header, forwards on the destination address and decrements the TTL or `Hop Limit`. The **stateful firewall** reads IP and TCP headers (addresses, ports, flags) and matches the segment to a tracked flow. The **layer 4 load balancer** reads the same headers and picks a backend when the connection's first segment arrives, keyed on addresses and ports. The URL path lives in the HTTP request, which travels as TCP payload after the handshake, encrypted inside TLS and possibly split across segments. To read it a device must accept the TCP connection itself, terminate TLS and parse HTTP, which is exactly what a **layer 7 proxy** does and what would turn a layer 4 balancer into one.
go deeper
Walk the ladder in order and say which header each device reads: nothing, MAC, IP, then IP plus ports. Know that the URL path is application data that only the last device reads.
Explain the nesting: frame, packet, segment, TLS records, HTTP request. Show why the firewall and layer 4 balancer read the same headers yet do different jobs with them.
Argue the path limitation from three facts: the backend is chosen at the first segment, the path is encrypted, and HTTP is a byte stream. Conclude that reading it requires terminating TCP and TLS, which makes the device a proxy.
Frame the choice of device depth as a trust and placement decision: every layer you read deeper means holding keys, owning connections and becoming an endpoint in the path, with the operational weight that brings.
## The request, wrapped Take one HTTPS request, `GET /invoices/42`, from a laptop to a web service. On the wire it is nested like this: 1. an **Ethernet frame** (source and destination MAC) carrying 2. an **IP packet** (source and destination address, TTL or Hop Limit) carrying 3. a **TCP segment** (source and destination port, flags, sequence and window fields) carrying 4. **TLS records** (encrypted) carrying 5. the **HTTP request**: method, host, **path**, headers. The path is in the innermost layer, and it is **encrypted**. Every device the request crosses reads some outer part of this stack and stops. The question is how far in each one reads. ## What each device reads | Device | Reads | Decides on | Cannot see | |---|---|---|---| | Hub | nothing | repeats bits to every port | any address | | Switch | Ethernet header | destination MAC | IP, ports, payload | | Router | IP header | destination IP; decrements TTL / Hop Limit | ports (for forwarding), payload | | Stateful firewall | IP + TCP headers, flow table | five-tuple, TCP state | anything inside TLS | | Layer 4 load balancer | IP + TCP headers | backend chosen per connection from addresses and ports | anything inside TLS | | Layer 7 proxy | everything, after terminating TCP and TLS | host, path, headers, cookies | nothing in the request | Each row reads at least as far in as the one above it, and the firewall and the layer 4 balancer read the **same** headers. They differ in what they do with them (allow or drop versus choose a backend), not in how far they see. ## Why a layer 4 balancer cannot see the path A layer 4 balancer is built to pick a backend when a new connection's **first segment** arrives and then to forward the whole connection there. RFC 9000 §5.2.3, discussing QUIC deployments, calls this kind of balancing, on source and destination IP addresses and ports only, "simple" load balancing. Three facts keep the path out of reach: 1. **Timing.** The first segment is the client's SYN. The HTTP request is sent only after the TCP handshake, and for HTTPS after the TLS handshake too, so the path does not exist when the choice is made. 2. **Encryption.** When the request does arrive, it is inside TLS records. Without the service's keys the balancer sees ciphertext. 3. **Segmentation.** Even plain-text HTTP is a byte stream. A request can span several TCP segments, and only an endpoint that reassembles the stream can parse it. TCP Fast Open (RFC 7413, an Experimental RFC) lets a client carry data in the SYN, but for HTTPS those bytes are TLS handshake or encrypted early data, never a readable path. To route on the path, a balancer must **complete the TCP handshake itself**, **terminate TLS** and **parse HTTP**. At that point it is no longer forwarding someone else's connection; it is an endpoint, which is the definition of a layer 7 proxy. ## What the layer 7 proxy does differently A layer 7 proxy is the TCP and TLS endpoint for the client. It holds the service's certificate and private key, decrypts the request, reads host, path and headers, chooses a backend and sends the request over **its own** connection. Every per-request decision (path routing, header rewriting, cookie affinity) follows from that one fact. The cost and operational tradeoffs of doing so are a separate subject. ## Forwarding layer versus what is visible Two subtleties separate a strong answer from a memorised one: - **Devices can read deeper than they forward.** A router forwards on the destination IP, yet its access lists may match TCP ports. The layer label names the forwarding decision. - **Some things leak without decryption.** RFC 9293 notes that TCP's cleartext headers expose more metadata than routing strictly needs: addresses, ports, flags, sizes and timing. An on-path device can usually also read the server name the client sends unencrypted at the start of the TLS handshake (the TLS handshake is a subject of its own). That gives a hostname, never a path. QUIC shifts the picture again. It runs over UDP and protects most of its header, so a firewall or balancer sees UDP ports plus a visible connection ID. RFC 9000 notes that a balancer hashing only addresses and ports can send packets to the wrong server when a client's address changes, and lets deployments route on the connection ID instead. ## The model behind the answer RFC 1958 states the Internet's architectural bias: the network's job is to move datagrams "as efficiently and flexibly as possible", and "everything else should be done at the fringes". Each device up this list moves toward being a fringe: the layer 7 proxy has become an endpoint. That is why only it can make a decision based on the path.
- How does QUIC change what a layer 4 balancer can key on?QUIC runs over UDP, and a balancer hashing only addresses and ports can send packets to the wrong server when the client's address or port changes, for example after NAT rebinding. RFC 9000 §5.2.3 describes this simple balancing and says a deployment that cannot keep continuity SHOULD send the `disable_active_migration` transport parameter. The connection ID is visible in the header, so a balancer can route on it instead, while the rest of the packet stays protected.
- Without decrypting anything, what can an on-path device still learn from an HTTPS connection?Everything in the cleartext headers: IP addresses, protocol, ports, TCP flags, sequence and window fields, plus packet sizes and timing. RFC 9293 notes that TCP's cleartext headers expose more metadata than routing needs. It can usually also read the server name the client sends unencrypted at the start of the TLS handshake, which gives the hostname but never the path, method or headers.
- Does TCP Fast Open let a layer 4 balancer read the path from the first segment?No. RFC 7413, an Experimental RFC, lets a client carry data in the SYN, but for HTTPS those bytes are the start of the TLS handshake or encrypted early data, never a readable path. Even for plain HTTP, reading the path means parsing application bytes and buffering a request that may span segments, which is the work of a proxy, not a connection-level forwarder.
A sealed letter passing through a building. The loudspeaker in the lobby (hub) repeats everything to everyone. The mailroom (switch) reads only the floor label, the city sorting office (router) only the street address, and the gate guard (stateful firewall) checks sender, recipient and whether this answers earlier post. The receptionist who hands letters to clerks (layer 4 balancer) sees the same envelope. What the letter asks for is sealed inside; to send it to the right clerk by its content, someone must be entitled to open it, read it and write a new letter onward: the layer 7 proxy.
saying these in an interview costs you the question
- A layer 4 load balancer can read the URL path because every byte passes through it.
- A stateful firewall sees the URL path because it tracks the TCP connection.
- Turning TLS off alone lets a layer 4 balancer route on the path with no other change.
- A router's ordinary forwarding decision depends on the TCP destination port.
- The server name in the TLS handshake gives an on-path device the full URL.