5 ms·

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

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.

IB885588 7y ago
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.
sebazzz 7y ago
> 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?
- adequateness 7y ago
  HTTP/3 is using QUIC which is UDP based.
- SmooL 7y ago
  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.
- afiori 7y ago
  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.
- georgyo 7y ago
  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_Protocol https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...
  - cb22 7y ago
    > 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 https://webrtcglossary.com
    - ajrw 7y ago
      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.
    - ignoramous 7y ago
      > ...when you use a WebRTC data channel, you're using SCTP over DTLS over UDP! https://orchid.com https://orchid.com VPN does tunnel the traffic over webrtc. Ref: https://news.ycombinator.com/item?id=21952887 https://news.ycombinator.com/item?id=21952887
- deleted 7y ago
  [deleted]
- jeltz 7y ago
  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.
- toast0 7y ago
  You can't get promoted at Google by making TCP on Android better, but you can for releasing HTTP over TCP over UDP.
  - jeltz 7y ago
    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.
yencabulator 7y ago
> 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/cronet https://developer.android.com/guide/topics/connectivity/cron...

IB885588 7y ago

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.

sebazzz 7y ago

> 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?

adequateness 7y ago
HTTP/3 is using QUIC which is UDP based.
SmooL 7y ago
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.
afiori 7y ago
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.
georgyo 7y ago
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_Protocol https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...
- cb22 7y ago
  > 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 https://webrtcglossary.com
  - ajrw 7y ago
    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.
  - ignoramous 7y ago
    > ...when you use a WebRTC data channel, you're using SCTP over DTLS over UDP! https://orchid.com https://orchid.com VPN does tunnel the traffic over webrtc. Ref: https://news.ycombinator.com/item?id=21952887 https://news.ycombinator.com/item?id=21952887
deleted 7y ago
[deleted]
jeltz 7y ago
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.
toast0 7y ago
You can't get promoted at Google by making TCP on Android better, but you can for releasing HTTP over TCP over UDP.
- jeltz 7y ago
  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.

yencabulator 7y ago

> 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/cronet https://developer.android.com/guide/topics/connectivity/cron...