What do you think about HTTP/3, QUIC, WebTransport?

https://web.dev/webtransport/ (It is still a *draft*, but google is already implementing it and stuff)

Idk it feels weird for me that HTTP will be served over UDP/QUIC

Http3 as itself should be released i think.
Rfc9114

@melezorus34 yes but webtransport if i remember correctly is still a draft.

Http always had an registration on udp port 80.

@stop many other protocols/services have their port also registered on both tcp/udp. And i don't blame.

It's the sensible way forward, TCP makes a lot of silly assumptions that simply don't apply to HTTP and respecting them is wasteful. The only thing I'm not sure about is what'll happen to websockets, maybe we'll finally get a browser API to open channels with no guaranteed delivery?

I also really hate how Google is forcing their shit onto the W3C by implementing stuff first and talking about standardization later.

The central problems with TCP are:

1) Head-of-line blocking. If a packet is lost, you don't get subsequent packets until the missing one has arrived. That defeats part of HTTP/2.

2) It interprets packet loss as network overload and throttles down. That's bad for mobile where the loss cause is transient radio conditions, not overload.

3) It's not part of the browser, but of the OS and of middleboxes that will never see updates until their end-of-life. Any improvement would need 10-20 years to actually arrive in the field.

That's what the new approach is trying to resolve.

Btw., that's also why performance measurements with good, wired network conditions don't show much (if any) gain with HTTP/3. It's only under spotty mobile network conditions where it shines, and the majority of internet usage is via mobile.

It will be... Interesting.

I'm still thinking it will make a lot more pain than gain.

If anyone remembers the TLS 1.3 debacle with middle boxes, I think it will happen again....

Changing TCP to UDP is no small thing, plus the TLS changes for HTTP / Quic are problematic, too.

All in all, I think that if you really want stuff to shine and you really need latency, you won't use HTTP at all.

RPC over QUIC is made for that - be it GRPC or anything else.

Eliminate the protocol overhead - instead of trying to make the protocol smarter, which is a nice idea - but with very small benefits given that it's still the same protocol.

@IntrusionCM Browsers and web servers won't abandon HTTP, and that's what it's made for, with mobile usage in mind. Other use cases such as streaming have long been on UDP already.

@Fast-Nop Sorry was unclear...

I was in my mind at services utilizing HTTP for transport, like micro services.

Http will not be gone, of course.

Though even there I question the pain over the gain.

Especially for browser rendering cause JS. Nough said. XD