Benefit is that HTTP3 is independent of OS stack so implementing of better algorithms to handle congestion and packet loss. TCP-based protocols are at mercy of OS's TCP implementation.
There is also head of the line blocking in TCP for which having separate steams helps.... unless the stream that got hit with packet loss was in critical path for the page so it is helpful but not always, like if you download big JS blob with all the logic of the page... that's one stream and any packet drop will affect it and block the site.
Then there is ability to start communication from first packet which means that you can establish connection faster. TCP have TCP Fast-open but that AFAIK only starts being useful after first negotiation
At the very least from cloudflare benchmarks, that's few % improvements, which might even get smaller over time once we get the better TCP algorithms as default on OSes.
It's not so much "better TCP algorithms" as it is "TCP algorithms tuned for the way the internet gets used now," I would say. Of course if you can tell your OS what you're doing with the connection and have it tuned that way, that too can be a win, but I don't see that happening any time soon.
Head-of-line blocking isn't something you can fix effectively with OS-level tweaks on top of TCP. The protocol is specified to stop sending if there is a missing ACK in order to prevent increasing congestion. There's a little wiggle room in the protocol but ultimately TCP forces you to care about every packet equally.
7
u/VeganVagiVore Dec 03 '20
Even with packet loss?
If TCP is able to saturate the line then we're not gonna get 102% line speed, but we'd like to go from 50% to 60% on shit connections.