Hacker News Reader

Comment by api | Hacker News Reader

I am really happy Google and others are pushing QUIC, but for only one main reason: networks that disallow UDP will now be considered "broken."

Without something to push UDP usage its possible we could end up with a TCP-only Internet that would make P2P connectivity more or less impossible.

View on HN

Unfortunately, we may yet see networks that block or slow down QUIC, in a paradoxical attempt to improve performance.

QUIC is designed to hide a lot from the network. But some network nodes use visibility into things like round-trip time, data-in-flight and packet loss for each flow, so they can adjust queuing parameters to optimise for each user. These measurements are easy to get from monitoring TCP, but not QUIC.

The designers of those network nodes may conclude that blocking QUIC (UDP on port 443) and forcing fallback to HTTP/2 over TCP results in better ability to optimise network flows than allowing QUIC to go ahead. All browsers race TCP against QUIC, so a network blocking QUIC shouldn't significantly slow performance compared with just HTTP/2.

This is a hefty bet. The gamble is that you're very good at this, and so you'll deliver better performance with HTTP/2 than the client could have got from HTTP/3, but even if you actually are right by a slim margin you're likely to suffer the same pushback from users as if you were wrong. The only scenarios where this is a smart bet are where competitors allow HTTP/3 and have noticeably worse performance.

If it's close, regardless of which way, you'll get beaten up for disabling HTTP/3, maybe that's unjust but that's how it is.

What users are going to notice? Browsers and almost everything else is going to fallback to TCP and move on, because there are too many broken networks to bother.

Kind of like how most big sites clamp TCP MSS at 1440 instead of 1460; there's too many PPPoE or IPIP tunneled links with broken path mtu, and too many clients without working/enabler path mtu blackhole detection to bother making a fuss about it. Just move on and cry on the inside.

I think people will notice as BYOD gets more and more standard. There is already a situation in my company that everyone who is part of the BYOD initiative doesn't even use their company laptop anymore because everything is so much slower.

They might notice and complain if UDP in general is blocked, but if their webpages load, they won't complain that UDP to port 443 is degraded or blocked.

I expect HTTP/2 and HTTP/1.1 will still be with us for decades; orgs that block UDP will be able to continue to do so, and the rare HTTP/3-only website will just be inaccessible.

Even if there's a new killer app that requires QUIC, I imagine an org backward enough to disallow UDP will just not care about that app.

"Science progresses one funeral at a time."

https://en.m.wikipedia.org/wiki/Planck%27s_principle

I expect HTTP/2 to disappear completely, to the point of browsers removing support for it probably even within a decade. Everything that works over HTTP/2 should work over HTTP/1.1, even if at a slight cost, and HTTP/3 should be uniformly superior to HTTP/2, except in those rare cases of UDP-blocking firewalls, which situation I expect to improve over time. Given the complexity and maintenance burden of the protocol and more importantly the upgrade mechanism, I think browsers will be happy to remove HTTP/2 in favour of the old reliable HTTP/1.1 (which is certainly not going anywhere) and HTTP/3 once they see very little using it any more, and absolutely nothing needing to use it.

I should also write a dissenting opinion on this point—for each client, the upgrade to HTTP/2 is free, as it’s negotiated via ALPN during the TLS handshake; whereas the HTTP/3 upgrade mechanism isn’t particularly solid yet, requiring an Alt-Svc header on a response from the server, meaning you’ve already had to connect over HTTP/1 or HTTP/2 before you learn you can connect over HTTP/3. There’s also work going on to add a new type of DNS record to indicate that the server is h3-capable, which would allow you to connect over HTTP/3 immediately, but that’s opt-in, and loads of sites that support HTTP/3 will never add that record. So until browsers switch to defaulting to trying HTTP/3, HTTP-over-TCP will continue to be used regularly even when HTTP-over-QUIC is supported, and that means plenty of HTTP/2 will be used until that time. This could keep HTTP/2 alive for a lot longer than the decade I posited. I don’t know how it’ll play out, but I think it will depend on how much browsers decide they want to push HTTP/3; if they push it hard and try it more optimistically, HTTP/2 will die more quickly.

I'm totally on board with having more than one protocol available (especially since UDP is so much more flexible), but what is it about TCP specifically that precludes its use for p2p? Is it easier to get through NATs et al with UDP?

Third party mediated hole punching really only works with UDP. TCP is stateful and thus negotiating a hole punch requires incredibly precise timing, which is hard to achieve in practice.

Without UDP we have a purely "cloud-to-ground" Internet unless we can convince router/NAT makers to always include and always turn on UPnP/NAT-PMP. Not likely, and those protocols suck anyway.

TCP has an explicit client and server (some caveats here). The userspace API for TCP requires you to do a connect, which does the TCP handshake in the TCP stack, before you can send traffic.

For UDP, you just specify the destination IP and port, and send packets.

For TCP, new incoming SYNs to most (S)NAT addresses will just get dropped - especially CGNAT - making it impossible to communicate in that direction. If you're both in that situation (really common, actually), you just can't talk to each other.

For UDP, the packets will also get dropped on the receiver side. However, the act of sending the packet will often cause the originator's side's NAT to register that five-tuple (source and destination IP and port + UDP proto), which would allow the other side to reply. If both sides do this with the same IP/port pairs, then magically they can communicate - some of the time, at least. There's a lot more involved (for example, how do you know your own external IP address behind NAT?) - read up on STUN - https://en.wikipedia.org/wiki/STUN - for more details.

Who disable UDP in 2020?

Schools tend to have it blocked.

Maybe someday a giant will push UDP broadcast. That would be neat.

That would require a ton of core upgrades and would be hard to implement without enormous abuse potential, so not very likely.

TOR, at the moment, is based on TCP and since the whole architecture is based on the assumption of TCP, I don't see it changing anytime soon. QUIC means TOR is now "legacy" unless we just do the right thing and boycott QUIC.

Why does For have to be used to access HTTP services? The web is crap for privacy already.

Reply on news.ycombinator.com