Re:LiteSpeed QUIC (LSQUIC) is an open-source implementation ...
by nicoburns on Monday February 15, 2021 @02:26PM
(#26146185)
Head of line blocking in http/2, and performance/reliability on dodgy mobile connections. It's definitely getting to the point of diminishing returns, but given how widely http is used it does seem to justify the effort.
[ Parent
| on HN ]
Re:LiteSpeed QUIC (LSQUIC) is an open-source implementation ...
by chrismorgan on Monday February 15, 2021 @03:26PM
(#26146891)
TCP HOLB is hardly diminishing returns; it’s the defining way in which HTTP/2 is not uniformly superior to HTTP/1.1—because of it, for a meaningful fraction of users, single-connection HTTP/2 behaves visibly worse than its primary competition, up-to-six-connection HTTP/1.1. (Lack of WebSockets support used to be another point, but that got fixed a year or two back.)
Some of the other benefits of HTTP/3 over HTTP/2, like the bypassing of TCP’s outmoded congestion control, are definitely more like diminishing returns.
Re:LiteSpeed QUIC (LSQUIC) is an open-source implementation ...
by cogman10 on Monday February 15, 2021 @07:57PM
(#26149738)
HTTP2 always seemed like a great idea for the backend and a "meh" idea for the front end. On backend systems where networks and lines are mostly reliable and fast, HOLB is generally not a problem.
It's only when you start talking about connections outside a backend network that HTTP2's weaknesses start to show (specifically mobile networks).
Re:LiteSpeed QUIC (LSQUIC) is an open-source implementation ...
by chrismorgan on Tuesday February 16, 2021 @09:56AM
(#26154389)
I wouldn’t call it “meh”. For almost all sites, it’s at least a slight win for the significant majority of users; for most sites, it’s a moderately significant improvement for most users; for some sites, it’s a huge improvement for most users. Certainly high-latency, high-loss networks undermine its benefits, but it’s still generally a definite improvement over HTTP/1.1.