Why TLS Handshake Eats Bandwidth and How HTTP + Keep‑Alive Saves It

Cause

A high‑concurrency data‑collection service saturated its 100 Mbps upstream after launch; although each request was a simple GET with a tiny body, the full request size was 1.68 KB because the TLS handshake alone consumed 1.27 KB. The required upstream bandwidth was calculated as 1.68 KB × 20 000 requests ÷ 1024 × 8 ≈ 262.5 Mbps, explaining why the 100 Mbps link was quickly filled.

What Is TLS Handshake?

HTTPS is HTTP over TLS, and establishing a new TCP connection normally requires a complete TLS handshake. During the handshake the client and server exchange a large amount of data, including:

Client and server random numbers

Supported cipher suites and TLS version information

Server's digital certificate (containing the public key)

Pre‑Master Secret used to generate the symmetric session key

This process not only adds latency but also consumes significant bandwidth and CPU resources.

Solution: Switch to HTTP

By removing the TLS handshake and using plain HTTP, the request header shrank to about 0.4 KB, saving roughly 70 % of the data transmitted per request. The reduction in size directly alleviated the upstream bandwidth bottleneck.

When HTTPS Is Required: Keep‑Alive

If encryption cannot be dropped, adding the header Connection: keep-alive allows multiple HTTPS requests to reuse the same TCP connection, avoiding a full TLS handshake for every request. This reduces both bandwidth and server load, especially under high concurrency.

Things to Watch

Keep‑alive connections have timeout limits; Nginx defaults to 75 seconds, while Apache defaults to 5 seconds. Exceeding the timeout closes the connection, forcing a new handshake on the next request. Additionally, if a large pool of proxy IPs is used, the benefit of keep‑alive may be diminished.