Hacker News Reader

Comment by bawolff | Hacker News Reader

Snark aside - the interesting thing here is that we have basically fixed all the issues.

HTTP/2 was fixing all the issues while still keeping TCP as the transport layer. Http/3 is fixing all the issues you can fix if you are allowed to change the transport layer.

There are no more layers to fix.

View on HN

> There are no more layers to fix.

Or rather the next layers suffer too much protocol ossification to do anything about them. Replacing UDP isn't viable because too much network gear refuses to route anything but TCP and UDP. And the layer below that is upgrading at a pace comparable to our fight against climate change, with IPv6's 30th birthday coming up in two years.

Why would you want to replace UDP? It's just 8 bytes overhead. Like 0.5% of typical packet payload. With basically no guarantees or algorithms in OS to handle. As simple as possible.

While its true that there is severe ossification at those layers, changing them would have about zero impact on HTTP.

TCP isn't "ossified" it's stable.

Yup. We've finally been able to consolidate the redundant flow/congestion control in the HTTP multiplexing and TCP layers while solving the head-of-line blocking problems. It only took 15 years (2009 was SPDY)!

HTTP has been around since 1991, 33 years ago. We really pushed things faster in the second half of HTTP's life so far.

The layer to fix is not below, it's above. Web apps are ridiculously heavy and advertising / surveillance traffic has been the real driver for HTTP/3.

That doesn't make sense. HTTP2&3 has been largely about better multiplexing & congestion control, particularly to reduce latency. Most ad-tech (at least historically) were served from separate domains involving separate connections, so shouldn't really get much benefit for http 2&3.

The snark is because the "issues" are misattributed and HTTP does not need to be replaced.

TCP is fine. HTTP is fine. We need to stop pretending HTTP/2 and HTTP/3 are "upgrades" and just call it a separate protocol. Maybe someday chrome will be able to load from QUIC://news.ycombinator.com

QUIC is a lot better than TCP, but it still has plenty of room for improvement. However, I do not know enough about HTTP to know if any of them would be relevant for the HTTP use case, or if they would only be relevant for other transport use cases.

Reply on news.ycombinator.com