3 ms·
Multiple concurrent encrypted streams with a single handshake isn’t much of a win though. N concurrent TLS connections won’t be any slower than a single TLS con
by coddle-hark 6y ago
Multiple concurrent encrypted streams with a single handshake isn’t much of a win though. N concurrent TLS connections won’t be any slower than a single TLS connection since the requests can be done in parallel.
- tick_tock_tick 6y agoIn a world with variable ping times and packet loss that is a bold lie.
- coddle-hark 6y agoHow so? Surely the variable ping times and packet loss affect both scenarios equally?
- jimmydorry 6y agoHow can that remotely be true? It's easy to forget in a world where the internet has defacto concentrated into the hands of a select few CDNs, but behind each of those CDNs are origin servers, serving the content to those CDNs. Servers can be housed in different data centres, different countries, etc. Specific servers can have hardware issues or be congested, while others remain unaffected, etc.
- coddle-hark 6y agoBut with QUIC you run the risk of all streams going to a server with hardware issues, congestion etc. It’s not clear to me that that’s any better?
- Matthias247 6y agoEven if you can achieve comparable performance on N concurrent TLS connections (which I actually think you can), you have a high additional cost of establishing those N connections. For a lot of systems the TLS handshake is the most expensive part of an operation. Reducing the amount of TLS handshakes by N can literally reduce cost by up to N in those systems.