Connection Termination at the Edge

What Termination Means

 the edge ENDS the user's connection — it does not tunnel it:

 [user] ══ connection A (user↔edge) ══► [EDGE]
                                        [edge opens fresh
 [origin] ══ connection B (edge↔origin) ══► connections from its pool]

 two independent connections; edge translates between them.
 contrast with L4 passthrough where ONE connection spans
 user→origin and every packet crosses the ocean.

The Handshake Economics

 full TLS 1.2 setup over 90ms RTT:

 TCP SYN/SYN-ACK        1 RTT     90ms
 TLS hello/cert/key     2 RTTs    180ms
 ─────────────────────────────────
 ~270ms before ANY request data flows

 per NEW CONNECTION. chatty clients opening many connections
 multiply this brutally.

 edge termination attacks it:
 - RTTs now measured to NEARBY POP (~15ms): 270ms → 45ms
 - SESSION RESUMPTION cuts TLS to 0-1 RTT for returning users
 - HTTP/2/3 MULTIPLEXING: one connection serves all streams,
   amortizing setup across hundreds of requests

Session Resumption Mechanics

 TLS 1.3 0-RTT / PSK resumption:

 first visit: full handshake; server issues SESSION TICKET
 return visit: client presents ticket + encrypted early data
               → server trusts prior identity → data in FIRST flight

 security caveat with 0-RTT:
   early data is replayable → only idempotent requests
   (GETs) should ride it; platforms enforce/advise this.

The Backend Pool Leg

 edge↔origin connections are LONG-LIVED and POOLED:

 pool per origin-host per POP:
   N warm TLS sessions kept open, requests multiplexed over them

 wins:
 - origin handshakes paid once per pool slot, not per request
 - origin sees steady connection count regardless of user storms
   (100k users → same ~50 pooled connections)
 - head-of-line managed via HTTP/2 multiplexing on the leg

 consequence for YOUR origin fleet:
 - load balancers see stable connections → better balancing
 - fewer TLS ops → CPU savings at origin
 - keep-alive timeouts must EXCEED edge pool idle settings,
   or pools churn and re-handshake constantly (classic misconfig!)

Where L7 Termination Hurts (Honesty Section)

 ✗ CLIENT CERTIFICATES / mTLS-to-origin semantics change:
   edge holds origin certs; user identity rides headers
   (must be trusted/validated carefully — header spoofing!)
 ✗ TRUE END-TO-END encryption to your servers needs extra layers
   (edge decrypts by definition)
 ✗ WebSockets: terminated too — long-lived edge↔origin leg needed;
   platform support varies; check before designing real-time

The X-Forwarded-* trust point matters most in practice: origins MUST validate that edge IPs actually sent those headers.

Interview Framing

“Why terminate TLS at the CDN instead of passing through?” scored answer: handshake RTT math (270→45ms), resumption + multiplexing effects, pooled backend legs decoupling user storms from origin connections, then the honest costs (header-trust discipline, end-to-end crypto implications). Quantifying handshakes is what separates networking literacy from vocabulary.