Why a Simple GET Request Can Saturate 100Mbps: The Hidden Cost of TLS Handshake

Cause of Bandwidth Saturation

A high‑concurrency data‑collection service soon filled its 100 Mbps uplink. Since the service was the only consumer of a dedicated line, the overload could be traced to it. Although each request was a simple GET with a tiny body, packet captures showed each request consumed 1.68 KB, of which the TLS handshake alone accounted for 1.27 KB.

With 20,000 concurrent requests, the required uplink bandwidth is calculated as 1.68 KB × 20,000 / 1024 × 8 ≈ 262.5 Mbps, explaining why the 100 Mbps link was easily saturated.

What Is the TLS Handshake?

HTTPS is HTTP over TLS. Establishing a new TCP connection typically involves a full TLS handshake, during which the client and server exchange random numbers, supported cipher suites and TLS version, the server’s digital certificate (including the public key), and a pre‑master secret used to derive the symmetric session key. This exchange consumes both bandwidth and CPU cycles.

Client and server random numbers

Supported cipher suites and TLS version

Server’s digital certificate (public key)

Pre‑Master Secret for symmetric key generation

The handshake not only adds latency but also significantly increases the size of each request.

Brute‑Force Solution: Switch to HTTP

Removing the TLS handshake by using plain HTTP reduces the request size to about 0.4 KB, a 70 % reduction. The article demonstrates this with a before‑and‑after capture (see image). The smaller payload meets the bandwidth requirement and lowers server load under the same concurrency.

Therefore, in scenarios where HTTPS is not mandatory, using HTTP can save considerable bandwidth.

When HTTPS Is Required: Enable Keep‑Alive

If HTTPS must be retained, adding Connection: keep-alive to the headers allows multiple requests to reuse the same TCP connection, avoiding a full TLS handshake for each request. Only the first request incurs the handshake cost; subsequent requests benefit from reduced overhead, making this approach suitable for high‑concurrency environments.

Keep‑alive, however, has timeout limits. By default, Nginx closes idle connections after 75 seconds, while Apache’s default timeout is 5 seconds.

Important Caveats

Keep‑alive effectiveness diminishes if the client uses many proxy IPs, as each proxy may establish its own connection. In such cases, reverting to plain HTTP remains the most bandwidth‑efficient option.