The two layers

Free preview 3 min to read

A load balancer either understands your traffic or it doesn't, and that one distinction produces two families of product with almost nothing in common except the name.

Layer 4

It forwards packets. It sees an incoming connection with a source and destination address and port, picks a backend and pipes bytes between them.

It doesn't know whether the traffic is HTTP. It could be a database protocol, a game or a video stream, and that generality is what makes it fast.

A layer 4 balancer can handle enormous throughput on modest hardware, because it does almost nothing for each connection.

Layer 7

It reads the request: method, path, headers and cookies. Then it routes based on what it finds.

To read an HTTPS request, it must decrypt it, which means it holds the certificate and terminates TLS. That fact drives most of the differences that follow.

flowchart TB
  C["a connection arrives"] --> L{"which layer?"}
  L -->|4| P["pick a backend. pipe bytes"]
  P --> F["fast. protocol agnostic. knows nothing"]
  L -->|7| D["terminate TLS. parse the request"]
  D --> R["route on path, header, or cookie"]
  R --> S["slower. HTTP aware. can decide"]

What layer 7 buys

Path routing: /api to one fleet, everything else to another.

Real health checks. A layer 4 balancer knows whether a port accepts connections. A layer 7 balancer knows whether /up returned 200. Those are very different questions, since a Rails process that has deadlocked still accepts connections.

Retries. A failed idempotent GET can be retried against another backend. Layer 4 can't do that, because it doesn't know the request was a GET.

Response manipulation: compression, header injection, caching.

What it costs

It decrypts and parses per request, not per connection.

The certificate lives on the balancer, which is a security consideration: traffic from the balancer to your servers is decrypted unless you re-encrypt it.

And it becomes a component that understands your application, which means its understanding can drift from reality. A routing rule that matches something unintended is a whole category of trouble that layer 4 can't have.

Which one this application has

kamal-proxy is a layer 7 balancer. It terminates TLS, reads the Host header to choose a container and checks /up while a deploy brings a new container up. In front of it, Cloudflare is another layer 7 proxy: it terminates the visitor's TLS and re-encrypts the hop to the server.

kamal-proxy isn't usually described as a load balancer, because at one backend the routing is trivial. But the mechanism is the one this course is about, and recognizing it is the point.

Key takeaways

  • Layer 4 forwards packets, and it's fast because it understands nothing.
  • Layer 7 decrypts and parses, and it can route on path, header or cookie.
  • Real health checks need layer 7, because a deadlocked process still accepts connections.
  • The certificate lives on the balancer, so the hop behind it is decrypted unless it's re-encrypted.
  • kamal-proxy is a layer 7 balancer whose routing happens to be trivial today.
Lesson 1 of 7 · free

Keep going with lesson 2

Choosing a backend

Explains round robin, least connections, hashing and weighted variants, and why least connections is the usual default.

A free account also gives you the quizzes, your progress and notes, and the discussion.

Type to start searching...