Why TLS Handshakes Consume So Much Bandwidth and How to Reduce It

A high‑concurrency data‑collection service filled a 100 Mbps uplink almost instantly. Although each request was a simple GET with a tiny payload, packet captures showed each request consumed about 1.68 KB, of which the TLS handshake alone accounted for 1.27 KB.

Calculating the required bandwidth (1.68 KB × 20,000 requests ÷ 1024 × 8) yields roughly 262.5 Mbps, explaining why the 100 Mbps link was quickly saturated.

What Is a TLS Handshake?

HTTPS is HTTP over TLS. Establishing a new TCP connection typically requires a full TLS handshake, during which the client and server exchange random numbers, supported cipher suites and TLS version, the server’s digital certificate, and the Pre‑Master Secret used to derive symmetric keys. This process consumes both bandwidth and CPU cycles.

Simple Solution: Use Plain HTTP

By switching the request protocol from HTTPS to HTTP, the TLS handshake is eliminated. After the change, a captured request was only 0.4 KB, a 70% reduction in size, confirming that in scenarios where HTTPS is not mandatory, plain HTTP can dramatically save bandwidth and reduce server load.

When HTTPS Is Required: Enable Keep‑Alive

If HTTPS must be used, enabling Keep-Alive can mitigate the overhead. Adding the header Connection: keep-alive allows multiple HTTPS requests to reuse the same TCP connection, avoiding a full TLS handshake for each request. The initial handshake still occurs, but subsequent requests benefit from reduced latency and bandwidth.

This approach is especially effective in high‑concurrency environments.

Things to Watch Out For

The keep-alive connection has a timeout. Nginx defaults to a 75‑second timeout, while Apache typically uses a 5‑second timeout. Exceeding these limits closes the connection, requiring a new handshake.

Note: If your crawler uses many proxy IPs, the benefit of keep-alive may be limited; using plain HTTP is still the most effective way to cut bandwidth.