Hacker News Reader

Comment by contravariant | Hacker News Reader

After all I've read on HTTP/2 I'm still not entirely sure what problem it is trying to solve.

The main benefit is multiplexing - being able to use the same connection for multiple transactions at the same time. This can have benefits in finding and keeping the congestion window at its calculated maximum size, reduce connection-related start-up, as well as overcome waiting for a currently-used connection to be free if you have a max connection per server model.

The other potential benefits were priorities and server-initiated push, but both I’d say largely went unused and/or were too much trouble to use. Priorities were redesigned in HTTP 3 - more at https://blog.cloudflare.com/adopting-a-new-approach-to-http-... - and Chrome recently decided push in HTTP 2 wasn’t worth keeping around - https://www.ctrl.blog/entry/http2-push-chromium-deprecation....

HTTP 2’s main problem is head-of-line blocking in TCP - basically, if you lose a packet, you wait until you get that packet and acknowledge a maximum amount of packets thereafter - slowing the connection down. With multiplexing, this means that a bunch of in-flight transactions, as well as potentially future ones, are blocked at the same time. With multiple TCP connections, you don’t have this problem of a dropped packet affecting multiple transactions.

HTTP 3 has many more benefits - basically, all the benefits of multiplexing without the head of line blocking (instead, only that stream is affected), as well as ability to negotiate alternative congestion control algorithms when client TCP stacks don’t support newer ones - or come with bad defaults. And the future is bright for non-HTTP and non-reliable streams as well over QUIC, the transport HTTP 3 is built on.

Right, all this kind of feels as if HTTP/2 is trying to solve transport layer problems in the application layer. Especially if you leave out the server initiated push. I can't really pretend to know much about this but I can't say I'm surprised that this causes problems when the underlying transport-layer protocol is trying to solve the same problem.

So is it correct to view HTTP/3 as basically taking a step back and just running HTTP over a different transport-layer protocol (QUIC)? (If so I think the name is a bit confusing, HTTP over QUIC would be much clearer)

It was originally called HTTP over QUIC, and got renamed to HTTP/3 in order to avoid some other confusion.

https://en.wikipedia.org/wiki/HTTP/3#History

HTTP/2 is what you do if you're confined to using TCP. HTTP/3 is what you get if you use UDP to solve the same problems (and new problems discovered by trying it over TCP).

That's true, but the transport layer has ossified, and the application layer is the only place we can still innovate. RIP SCTP.

Still sad, it would have been much nicer to just keep HTTP as is and just put in a different transport layer. Or maybe extend HTTP a little but right now we've got a protocol independent HTTP/1.1 and a new HTTP/3 which rather than being more general strictly relies on a single protocol.

In some ways, HTTP 3 is the same HTTP messages, just over QUIC.

But as you get into other features, there are differences. And your clients and servers need to both have fallbacks to HTTP 2, since UDP connectivity might not be available, and fallback is expected.

So, you have to build support for having working push, or not. Or having working priorities, or not. Or having long-lived non-HTTP sockets, or using fallbacks like web sockets or even long polling. There’s even more fun on the horizon, and I’m not looking forward to my colleagues thinking of a fallback strategy for some of those...

HTTP/2 does solve one issue very well. The server goodbye message indicates the last request seen, which enables the client to know if a request sent before closing can be retried or not.

In http/1.1, if you send a non-idempotent request on a keep-alive socket and the server closes it 'simultaneously', you won't know if the server didn't see it (safe to retry), or if the server crashed while processing it (not intrinsicly safe to retry).

TCP-in-TCP offers predictably bad worse cases, but does offer some nice effects in good cases.

Reply on news.ycombinator.com