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

A high‑concurrency crawling service quickly saturated a 100 Mbps upstream link, even though each request was a simple GET with a small payload.

Network capture revealed that each request consumed about 1.68 KB , of which the TLS Handshake alone accounted for 1.27 KB .

With 20,000 concurrent requests, the required upstream bandwidth is calculated as 1.68 * 20000 / 1024 * 8 = 262.5 Mbps , explaining why the 100 Mbps link was easily saturated.

HTTPS is essentially HTTP over TLS . Every new TCP connection performs a full TLS handshake, exchanging random numbers, supported cipher suites, TLS version, the server’s digital certificate (including the public key), and the Pre‑Master Secret . This process consumes additional bytes, bandwidth, and CPU resources.

One straightforward mitigation is to switch to plain HTTP, eliminating the TLS handshake. After the change, the request size dropped to 0.4 KB , a 70 % reduction, saving bandwidth and noticeably lowering server load under the same concurrency.

If HTTPS is mandatory, adding the Connection: keep-alive header enables the Keep‑Alive mechanism. This allows multiple HTTPS requests to reuse the same TCP connection, avoiding a full TLS handshake for each request after the initial one.

Keep‑Alive connections have timeout settings: Nginx defaults to 75 seconds, while Apache’s default is 5 seconds. In environments with many proxy IPs, the benefit of Keep‑Alive may be limited.

In summary, for scenarios where HTTPS is not required, using HTTP can substantially reduce bandwidth usage; when HTTPS is needed, enabling Keep‑Alive helps mitigate handshake overhead in high‑concurrency situations.