@urlyman HTTP/3 is UDP-based — a strong departure...

@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

Like 15 August at 15:21 | Wall-to-wall | Open on social.librem.one

4 comments

Mark Pauley

@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

15 August at 17:46 | Open on discuss.systems

m0xEE

@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

15 August at 18:09 | Open on social.librem.one

m0xEE

@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

15 August at 18:10 | Open on social.librem.one

Mark Pauley

@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.

15 August at 18:15 | Open on discuss.systems