Hacker News Reader

Comment by thecompilr | Hacker News Reader

But it doesn’t say what TLS cipher suite it is using, making it a pointless benchmarks

I'd be surprised if it matters. In older TLS versions (the version is not specified either) the suite might include various handshake parameters, but they're irrelevant after the handshake completes anyway. After that, regardless of version, realistically you are doing AES or maybe ChaCha20. There are lots of options in TLS 1.2 and earlier, but you won't use any of them, since both machines know AES.

The fact it's bottlenecked somewhere but CPU is fine suggests some configuration parameter somewhere results in not as much data being in flight for HTTPS, limiting throughput over this very fast connection. If so, fixing this parameter would make the noticeable difference essentially vanish.

Maybe, maybe not, since it is a custom configuration can be anything. A coffee lake CPU should be capable of 25Gbps of AES-GCM for a single connection. Not so much for ChaCha20-Poly1305. There is a significant difference.

ChaCha20 vs AES matters a lot, because the latter is hardware accelerated on all important platforms. I did some benchmarking on this in the last year, and e.g. QUIC transfers on the same machine peaked at 520MB/s throughput per core using AES128, vs 350MB/s using ChaCha20 (see also https://github.com/rustls/rustls/issues/509).

I’m using the defaults of each server.

In practice, as you suspected, this amounts to AES, as per the curl -v output:

SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384

Thanks, you should use AES-128-GCM, it is about 40% faster and is much more common on the internet.

Reply on news.ycombinator.com