Hacker News new | ask | show | jobs
by alexforster 964 days ago
I don't think it's responsible to replace http/1.1 with either of these protocols. They both seem like complex beasts with poorly understood corner cases and little consideration for the abuse potential.
1 comments

My feeling is they both suffer “version-2-isms”, ie having added many nice-to-haves that are complex. That said, I think QUIC is a much, much bigger step. We are literally adding congestion and flow control to user space, as well as packet-level routing. This has been done before, but mostly for bespoke purposes (like UDT - or with per-OS batching, kernel extensions or at least kernel tuning). Now, it’s supposed to be general purpose, across hardware, platforms and languages.

Personally I think either QUIC makes it into kernels, or it will have a loooong time ahead of it with language- and vectorized/batched IO in the OS (maybe even down to the NICs?) catching up. Even the more mature implementations struggle compared with TCP today, for things like high bandwidth on consumer hardware. Not to mention CPU overhead and the battery drain that comes with it. (At least from my own high-bandwidth experiments)

Yes, I know a large part of web is already http3. But remember that http is used outside of browsers and data centers. I don’t know enough to back any specific proposals, but to me it sounds a lot easier to fix the tcp handshake, open 2-3 conns for the HOL-blocking issue, than to rearchitect the entire stack (and add new features) under UDP. I’m saying this as someone who is still very bullish and excited about QUIC.