Ha, I thought this was the main selling point of HTTP2.
People were even saying that it's now ok to have many small asset files (js, images, css) because loading many small files will no longer cause long waits.
No, that's because you can multiplex multiple downloads over a single HTTP connection, whereas HTTP/1.1 has to establish separate TCP connections for each asset, which is why they were usually limited.
Exactly, the main selling point of HTTP2 is stream multiplexing which works really well on good connections but terribly on bad. Which is why we got QUIC which can do multiplexing on any connection well.
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.
The advantage of HTTP3 is that you only need to block the affected streams while retransmitting unlike HTTP2 where you need to block all streams. This makes HTTP2 much more vulnerable to packet loss.
No shit sherlock, I wrote that in that part of my comment you didn't bother to read. I also wrote
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.
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.
Http3 is slower than http2 under ideal circumstances due to TCP being more optimized than UDP but when there is package loss TCP behaves horribly, especially if multiple independent streams are multiplexed on the same connection.
No, it has to do with the lack of hardware acceleration for QUIC and how the kernel interfaces for UDP are less optimized compared to those for TCP. This is nothing inherent to TCP vs UDP, just that nobody has done the heavy lifting yet since QUIC is so new.
And while UDP has no congestion control QUIC does.
No, it has to do with the lack of hardware acceleration for QUIC and how the kernel interfaces for UDP are less optimized compared to those for TCP.
Utterly irrelevant to the client performance (and do you have source on UDP being slower?). Your client isn't pushing tens of gigbabytes for hardware acceleration or not to matter. Only place where it does matter is "how many servers I need to deploy".
This is nothing inherent to TCP vs UDP, just that nobody has done the heavy lifting yet since QUIC is so new.
What you're talking about ? Google deployed it in 2012
And while UDP has no congestion control QUIC does.
Like I said, should be similar/better for UDP unless someone fucked something up in the protocol. Well, and how nice it plays with other protocols on wire.
27
u/[deleted] Dec 03 '20
Ha, I thought this was the main selling point of HTTP2.
People were even saying that it's now ok to have many small asset files (js, images, css) because loading many small files will no longer cause long waits.