How TLS Handshake Makes a Tiny GET Request Eat 1.68KB and How to Cut Bandwidth

Origin

A high‑concurrency data‑collection service quickly saturated a 100 Mbps uplink. Although each request was a simple GET with no body, packet captures showed each request occupied 1.68 KB, of which the TLS handshake alone accounted for 1.27 KB.

Bandwidth required for 20,000 concurrent requests can be estimated as:

1.68*20000/1024*8=262.5mbps

This explains why a 100 Mbps uplink was easily saturated.

What Is TLS Handshake?

HTTPS (HTTP over TLS) requires a full TLS handshake when establishing a new TCP connection. During the handshake the client and server exchange:

Random numbers

Supported cipher suites and TLS version

Server’s digital certificate (public key)

Pre‑Master Secret for symmetric key generation

The process consumes both time and bandwidth.

Reducing Overhead by Using HTTP

Switching the request protocol to plain HTTP removes the TLS handshake entirely. After the change the request size dropped to 0.4 KB, a reduction of about 70%.

Consequently, bandwidth usage decreased and server load was noticeably lower under the same concurrency.

When HTTPS Is Required: Keep‑Alive

If HTTPS cannot be dropped, enabling

keep-alive

(by adding

Connection: keep-alive

to headers) allows multiple HTTPS requests over a single TCP connection, avoiding repeated full handshakes after the first one.

This approach is effective for high‑concurrency scenarios, though keep‑alive connections have timeout limits (e.g., Nginx defaults to 75 seconds, Apache to 5 seconds).

Important Notes

Keep‑alive may be less effective when a large pool of proxy IPs is used, as connections are frequently re‑established.