[move-on-by]

I'm certainly no network engineer, but my understanding is that HTTP/3 really shines in poor networking conditions. HTTP/2 was a massive improvement on HTTP/1.2 that had some really impressive stats to back it up. HTTP/3 isn't going to have that. Being on-par with HTTP/2 in excellent conditions is expected. The little game animation backs that up - if all the data arrives in both HTTP/2 & HTTP/3 then its a wash. I'm certainly not aware of any HTTP/3 browser implementations on mobile. I believe that is when you'll see the improvements. Although, I've also read that without kernel and NIC-level support for HTTP/3, its supposed to be a large CPU and battery drain. So it might be awhile before the real benefits of HTTP/3 are fully realized. Regardless, its fascinating to watch.

[sebazzz]

> I'm certainly no network engineer, but my understanding is that HTTP/3 really shines in poor networking conditions.

Doesn't that mean we need to rethink TCP instead of pulling all these transfer concerns to the application layer?

[georgyo]

The application layer is the only place these changes can go anymore. IPv6 is a good example that protocol layer changes are really slow to roll out.

You may also be interested in SCTP, which is awesome on paper and works well across the internet. But since most firewalls only understand TCP, UDP, and ICMP other protocols get auto dropped.

SCTP could have been amazing. https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...

[cb22]

> SCTP could have been amazing

It still is, it's part of the WebRTC spec, and when you use a WebRTC data channel, you're using SCTP over DTLS over UDP! (or TCP, possibly with a TURN relay, which may end up tunneling the whole thing over TLS over TCP :))

There are a lot of acronyms in WebRTC, thankfully there's https://webrtcglossary.com

[ignoramous]

> ...when you use a WebRTC data channel, you're using SCTP over DTLS over UDP!

https://orchid.com VPN does tunnel the traffic over webrtc.

Ref: https://news.ycombinator.com/item?id=21952887

[ajrw]

Wow, I knew it was using SCTP but I didn't know that was inside the DTLS channel. That seems like a lot of overhead.

[SmooL]

In theory, yes. In practice, TCP has "ossified". That is to say; all the routers and networking equipment, around the world, would have to be upgraded to support changes to TCP, which in practice will never happen. Look at IPv6 adaption rates as an example.

[adequateness]

HTTP/3 is using QUIC which is UDP based.

[jeltz]

Yes, but that is essentially what QUIC is, a new transport layer protocol andHTTP/3 is then ran over QUIC. QUIC is right now implemented in user space but nothing prevents it from being implemented in the kernel.

[afiori]

That is for sure true, TCP is also know for having lots of weird and quirky implementations in the wild.

On the other hand, there will never be a time when TCP could possibly be "update", it is too entrenched and fossilized.

[toast0]

You can't get promoted at Google by making TCP on Android better, but you can for releasing HTTP over TCP over UDP.

[jeltz]

Maybe not but IETF took over the development from Google and now Quic is a generic and widely useful transport protocol. What is needed is kernel support and hardware accelerators.

[IB885588]

Indeed, the part that they illustrated with Pong does show that in environments where you lose packets or have to reconnect there should be a more noticeable advantage.

[yencabulator]

> I'm certainly not aware of any HTTP/3 browser implementations on mobile.

Chrome is happily using QUIC, also on Android. And for non-browser apps, every Android app that links against the recommended network client library will do QUIC transparently.

https://developer.android.com/guide/topics/connectivity/cron...