Hacker News Reader

Comment by manigandham | Hacker News Reader

HTTP/3 is HTTP/2 with minor updates and running on QUIC instead of TCP.

QUIC is basically rebuilding the stateful connection abilities of TCP on top of UDP with optimizations.

Multiplexed streams with packets that can arrive out of order, removing the head of line blocking issue with TCP. There is also forward error-correction to reconstruct lost packets instead of retransmitting. Better packet sizing and congestion algorithms to reduce round-trips. There are also updates to include all the TLS 1.3 stuff for 0-RTT setup.

All of this reduces latency and makes connections more reliable, especially with changing networks on mobile devices. Not many downsides other than that TCP is far more open and optimized than UDP so it may take a while to effectively get this protocol out there.

View on HN

> especially with changing networks like mobile

In particular QUIC contains everything necessary to continue connections after the client's IP address (any one side really, but the other side has to find it) changes, which is helpful when devices change between networks without needing a Mobile IP-style bouncer.

Except no mobile devices use this yet :(

Plenty of mobile devices use QUIC. The OS only needs to support UDP (which I believe all do) and applications that use QUIC will work.

My Pixel 2 running the Hangouts app transparently switches between home WiFi, LTE and xfinity WiFi (Comcast's attempt to make every one of their customers into a WiFi hotspot).

The Hangout connection doesn't drop. It may go fuzzy/staticy before the WiFi drops in favor of LTE but that's all.

Doesn't Multipath TCP already exist as a solution for this?

Indeed. I’m not sure why adoption is so poor on that.

It's only available on apple iOS and maybe Mac OS out of the box. Android is probably not going to support it; if Android does support it, it will be a long time before there's critical mass and early versions may claim to support it, but not work well, and it may be hard to selectively enable it, and we know many devices won't get the updates to fix it.

It's expensive to support on servers because (to my knowledge) there's not a good way to ensure related sub flows arrive at the same nic rx queue on the same server in real world load balancing situations, which is critical for performance.

Nobody else is doing it (other than Apple for Siri), so it's not clear what the benefits are.

It's weird that Android wouldn't support it, it was developed for linux first.

That's very inefficient as it is essentially creating backup TCP connections to get around the fact that TCP might not behave well in certain situations.

On mobile, it is meant to use an entirely separate network backbone (wifi vs LTE) so doesn't offer much benefits when you're limited to a single type.

In practice I’ve seen poor handling in Chrome on desktop when the router changes WAN IP. Chrome reports ERR_NETWORK_CHANGED rather than do something sensible — this problem doesn’t exist in HTTP/1.x. I assume it should just be reconnecting — or the server should be using the connection ID field properly.

Very interesting. It sounds like the people behind it have learned a lot about networking in the current era. Is there any work toward making this a peer protocol to TCP and UDP?

Obviously that doesn't solve any immediate problems, in that I'm sure it would take a decade to get something like that in widespread use. But if the theory is that TCP isn't so great given what we know now, I'm wondering if it's worth making those capabilities available to other protocols.

How will negotiation work? If my work say blocks UDP 80 outbound will I have to wait for a timeout every single time I try to go to a site?

Chrome's implementation solves this by racing a TCP connection with the QUIC connection.

Ah now that's clever.

Apple supports this with iOS, albeit with multiple TCP connections over both wifi and cellular for user experience concerns.

https://support.apple.com/en-us/HT201373

So the server now sends a TCP ACK to SYN that is never followed up on? That is, the actual server software will wake up from a listen(), go through the motions of setting up a session for nothing for 50% of the time with this hack? Nice waste of other people's resources right there!

Well, presumably, the client with close the TCP connection once QUIC is established, and cache the result of the race for some period of time.

Okay, I had to do some extra digging. And I was a bit off in my original comment: accept returns a socket only when a connection is fully established, that is, after the ACK from the client. Until then, the application is oblivious to the connection attempt. So sending SYNs by themselves is it too hard on the servers.

The bigger boss will see his favourite website does not work over HTTP/1 and needs to open UDP 80 to access.

Reply on news.ycombinator.com