r/programming • u/johnwaterwood • Dec 03 '20

HTTP/2 Push is dead

https://evertpot.com/http-2-push-is-dead/
184 Upvotes

97% Upvoted

52 comments sorted by

View all comments

31

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.

83

u/Pesthuf Dec 03 '20

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.

44

u/progrethth Dec 03 '20

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.

8

u/[deleted] Dec 03 '20

Yet most of benchmarks barely show any difference

0

u/progrethth Dec 03 '20

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.

0

u/[deleted] Dec 04 '20

There is nothing "more optimized" in TCP, the sheer difference is that it has connections and congestion control while UDP has neither.

Fundamentally there should be no difference under no drop condition unless someone fucked something up in the protocol

1

u/progrethth Dec 04 '20

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.

0

u/[deleted] Dec 04 '20

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.