UNDER PRESSURE

Level 1 · Multiplying Machines

Session 10: Layer 4 and Layer 7: The Blind Guard vs the Smart Guard

What if the security guard at the entrance could only look at the color of a visitor's shirt, and wasn't allowed to ask why they came? What would get much faster, and what would become impossible?

Session 10 / 344 min read

1. The Decision Layer: Connection vs Message Content

When a request enters the system, the Load Balancer has to decide where it goes. Which OSI layer that decision happens at determines the speed, resource consumption, and routing flexibility.

   OSI MODEL               LOAD BALANCING
┌──────────────┐
│ 7. APPLICATION│ ──► L7: Reads HTTP/HTTPS, Headers, Path, Cookie, Payload
├──────────────┤
│ 6. PRESENTATION│
├──────────────┤
│  5. SESSION  │
├──────────────┤
│  4. TRANSPORT│ ──► L4: Only sees Source IP, Destination IP, & Port (TCP/UDP)
├──────────────┤
│  3. NETWORK  │
└──────────────┘

2. Layer 4: TCP Passthrough (Fast but Blind)

How It Works:

  • An L4 Load Balancer only inspects packets at the transport level (IP address and TCP/UDP port, for example :443 or :80).
  • As soon as the TCP handshake is established (SYN, SYN-ACK, ACK), the LB forwards the binary data packets straight to the backend server without opening the TLS encryption or reading the HTTP request contents.

Advantages:

  1. Maximum Speed & High Throughput: The LB doesn't need expensive CPU to parse HTTP text or decrypt SSL.
  2. Lightweight on Resources: A single L4 machine (for example HAProxy in TCP mode, or IPVS/LVS) can handle hundreds of thousands to millions of packets per second.
  3. Protocol Agnostic: Works for databases (PostgreSQL :5432, MySQL :3306), Redis (:6379), video streaming (RTSP/RTMP), or game servers (UDP).

Disadvantages:

  • Blind to Content: It can't see the URL path (/api/v1/payment vs /static/img.png), can't read HTTP Headers, can't read cookies.
  • All traffic goes uniformly into the same server pool.

3. Layer 7: Application Routing & TLS Termination (Smart but Heavy)

How It Works:

  • An L7 Load Balancer acts as a full reverse proxy.
  • The LB completes the TCP connection and performs TLS Termination (decrypting SSL/HTTPS using the certificate on the LB).
  • The LB reads the HTTP method (GET, POST), headers, cookies, and URL path before choosing a backend server.

Key L7 Features:

  1. Path-Based Routing: - /api/checkout ──► routed to Cluster Backend Payment - /images/* ──► routed to Cluster Storage / CDN Origin - /ws ──► routed to Cluster WebSocket Server
  2. Header & Host Routing: - Host mobile.tokomu.com vs desktop.tokomu.com are routed to different backends.
  3. SSL/TLS Offloading: - Backend servers on the private network (LAN) don't have to burn CPU on HTTPS encryption/decryption; traffic between the LB and the backends runs over fast plain HTTP.
  4. WAF & Security Inspection: - Filters out SQL Injection and XSS, and applies rate-limiting per API endpoint.

The Consequence:

  • High CPU Cost: TLS decryption and HTTP string parsing consume hundreds of times more CPU than L4.

4. L4 vs L7 Comparison

Aspect Layer 4 (Transport) Layer 7 (Application)
Data It Sees TCP/UDP IP & Port HTTP URL, Path, Headers, Cookies
TLS Encryption Passthrough (Not opened) Termination (Decrypted at the LB)
Performance / Throughput Extremely fast (Millions of pps) Lower (CPU-intensive)
Routing Flexibility Low (Only to 1 backend pool) Very high (Microservices routing)
Protocols TCP, UDP, MySQL, Redis, gRPC HTTP, HTTPS, WebSocket, gRPC

5. Sticky Session: Today's Lifesaver, Tomorrow's Killer

Sticky Session (Session Affinity) is an L7 mechanism where the load balancer injects a cookie, or reads the user's session cookie, so that a given user is always routed to the same backend server.

       ┌────────────────────────┐
       │   L7 Load Balancer     │
       └───────────┬────────────┘
         Cookie:   │   Cookie:
         SRV=A     │   SRV=B
     ┌─────────────┴─────────────┐
     ▼                           ▼
┌─────────────┐             ┌─────────────┐
│  Server A   │             │  Server B   │
│ Session User│             │ Session User│
│    #123     │             │    #456     │
└─────────────┘             └─────────────┘

Why Is It Used?

  • It's used when a legacy application stores session data in the server's local RAM (in-memory session).

Why Is It Dangerous? (The Long-Term Trap):

  1. Load Imbalance: If a few highly active super-users are stuck to Server A, Server A will fall over while Server B sits idle.
  2. Downtime Wrecks the User Experience: The moment Server A crashes or is drained for an update, every user session on Server A vanishes instantly (users get forcibly logged out).
  3. Blocks Autoscaling: Servers can't be safely shut down during quiet periods because there are still "sticky" connections on them.

The Real Solution: Make the application Stateless and store sessions in a centralized Redis cluster (covered fully in Session 12).

6. Key Terms

  • Layer 4 (L4): Transport-level routing (TCP/UDP, IP & Port).
  • Layer 7 (L7): Application-level routing (HTTP, URL path, headers).
  • TCP Passthrough: Forwarding a binary connection without decrypting or inspecting the payload.
  • TLS Termination: Opening HTTPS encryption at the load balancer.
  • Path-Based Routing: Routing traffic to different clusters based on the URL path.
  • Sticky Session / Session Affinity: Pinning a user to a specific server via a cookie.