Why a TLS Handshake Can Saturate 100Mbps Uplink and How to Cut Bandwidth by 70%

Origin

A high‑concurrency data‑collection service went live and immediately saturated a 100 Mbps uplink. Since the dedicated line was used only by this service, the cause was clear. Surprisingly, each simple GET request consumed 1.68 KB, mainly due to the TLS handshake.

The bandwidth required can be calculated as: 1.68*20000/1024*8=262.5mbps Thus the 100 Mbps uplink was easily filled.

What Is the TLS Handshake and Why Is It So Large?

HTTPS stands for HTTP over TLS. Establishing a new TCP connection typically requires a full TLS handshake, during which the client and server exchange certificates, public keys, supported cipher suites, TLS version, random numbers, and a pre‑master secret. These elements consume significant bytes, CPU, and time.

Client and server random numbers

Supported cipher suites and TLS version

Server's digital certificate (including public key)

Pre‑Master Secret for symmetric key generation

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

Rough Solution: Use Plain HTTP

By switching the request protocol from HTTPS to HTTP, the TLS handshake is eliminated, reducing the request size from 1.68 KB to about 0.4 KB—a 70% reduction. The screenshots show the request headers before and after the change, confirming the absence of the TLS handshake.

In scenarios where HTTPS is not mandatory, using HTTP can significantly save bandwidth and lower server load under high concurrency.

When HTTPS Is Required: Enable Keep‑Alive

If HTTPS must be used, adding the header Connection: keep-alive enables persistent connections. With Keep‑Alive, multiple HTTPS requests can reuse the same TCP connection, avoiding repeated full TLS handshakes after the first one. This is especially effective for high‑concurrency workloads.

Note that Keep‑Alive connections have timeout limits: Nginx defaults to 75 seconds, while Apache typically defaults to 5 seconds. Exceeding the timeout closes the connection, requiring a new handshake for subsequent requests.

ps: If your crawler uses many proxy IPs, Keep‑Alive may have limited effect—using plain HTTP is still the best option.