Not sure Tim Berners-Lee’s vision was to have 148 requests transfer 5.3 MB of assets to deliver 15 KB of text
@urlyman
*148 requests carried over UDP 🤦
To me this is one of the most bizarre parts!
@m0xee can you expand? I’m not well-versed on networking protocols ( I’m more of a front-end bloke)
@urlyman
HTTP/3 is UDP-based — a strong departure from TCP-based HTTP1.1
Not without a few advantages — mainly parallelism, and it's a further development of HTTP/2, which was still TCP-based, but multiplexed.
Yet, dealing with datagrams on application level to work with streams of data seems a little controversial to me. Last, but not least: it mostly makes sense when in addition to 15 kB of main text content you have to carry large number of scripts, stylesheets, auxilary data fragments, etc
@unsaturated
TBH, I'm not knowledgeable enough myself about how QUIC, which HTTP/3 is based on, handles that. To me the idea of introducing congestion control into application level (and the implied added complexity of client implementation) seem bad enough, but you might be right, there might be even more to it than that.
@urlyman
@unsaturated
Maybe network engineers who had to deal with it in practice can shed some light. My "solution" is disabling it in clients where it is optional (it is in Firefox) and building software such as curl without support for it 😅
@urlyman
@m0xee @urlyman does HTTP/3 have back off logic built in? A big part of TCP is making sure that normal clients don’t cause a storm when packets are being dropped