Hacker News Reader

Comment by Wohlf | Hacker News Reader

Removes the overhead and blocking of TCP while providing redundancy for the packet loss of UDP.

It also allows for multiple concurrent encrypted streams while just doing one handshake.

HTTP/2 also allowed this, but suffered from head-of-line blocking between those multiplexed connections. Quic streams are independent. One Stream can still make progress if datagrams which contained data for another stream got lost.

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.

In a world with variable ping times and packet loss that is a bold lie.

How so? Surely the variable ping times and packet loss affect both scenarios equally?

How 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.

But 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?

Even 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.

That’s not quite right. It greatly reduces the handshake time for new connections, but it adds more network overhead (more bytes sent) than TCP. TCP doesn’t “block” any more than QUIC.

Reply on news.ycombinator.com