5 ms·
But it doesn’t say what TLS cipher suite it is using, making it a pointless benchmarks
by thecompilr 4y ago
But it doesn’t say what TLS cipher suite it is using, making it a pointless benchmarks
- tialaramex 4y agoI'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.
- thecompilr 4y agoMaybe, 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.
- Matthias247 4y agoChaCha20 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 https://github.com/rustls/rustls/issues/509).
- secure 4y agoI’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
- thecompilr 4y agoThanks, you should use AES-128-GCM, it is about 40% faster and is much more common on the internet.