@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

@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

@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 it looks like quic and http/3 have congestion control RFC’s. I totally agree with you wrt doing this at the app layer.