Understanding TLS Handshake Overhead and Bandwidth Impact in High‑Concurrency Services

A high‑concurrency data‑collection service quickly filled a 100 Mbps uplink because each GET request consumed about 1.68 KB, with the TLS handshake alone accounting for 1.27 KB.

Bandwidth calculation: 1.68 KB × 20,000 requests ÷ 1024 × 8 ≈ 262.5 Mbps, explaining the saturation.

The TLS handshake (HTTPS) involves exchanging client/server random numbers, supported cipher suites and TLS version, the server's digital certificate, and the pre‑master secret, which together consume significant bytes, CPU, and time.

To reduce overhead, the author switched the request protocol to plain HTTP, removing the TLS handshake entirely; the request size dropped to 0.4 KB, a 70 % reduction, confirming that HTTP can save bandwidth when encryption is not mandatory.

When HTTPS is required, enabling Connection: keep-alive allows multiple HTTPS requests over the same TCP connection, avoiding repeated full handshakes after the initial one, which is beneficial for high‑concurrency scenarios.

However, keep‑alive connections have timeout limits (default 75 seconds in Nginx, 5 seconds in Apache), after which the connection closes and a new handshake is needed.

In summary, avoiding unnecessary TLS handshakes—by using HTTP where possible or by leveraging keep‑alive—significantly reduces bandwidth consumption and server load in high‑traffic environments.