[bullen]

The mistake they did was to assume only one TCP socket should be used; the TCP has it's own head-of-line limitations just like HTTP/1.1 has if you limit the number of sockets (HTTP/1.1 had 2 sockets allowed per client, but Chrome doesn't care...) it's easily solvable by using more sockets but then you get into concurrency problems between the sockets.

That said if you, like SSE on HTTP/1.1; use 2 sockets per client (breaking the RFC, one for upstream and one for downstream) you are golden but then why use HTTP/2 in the first place?

HTTP/2 creates more problems than solutions and so does HTTP/3 unfortunately until their protocol fossilizes which is the real feature of a protocol, to become stable so everyone can rely on things working.

In that sense HTTP/1.1 is THE protocol of human civilization until the end of times; together with SMTP (the oldest protocol of the bunch) and DNS (which is centralized and should be replaced btw).

[jupp0r]

The issues with TCP head-of-line blocking are resolved in HTTP/3 (QUIC).

[bullen]

Sure but then HTTP/3 is still binary and it's in flux meaning most routers don't play nice with it yet and since HTTP/1.1 works great for 99.9% of the usecases I would say it's a complete waste of time, unless you have some new agenda to push.

Really people should try and build great things on the protocols we have instead of always trying to re-discover the wheel, note: NOT the same as re-inventing the wheel: http://move.rupy.se/file/wheel.jpg

[sleepydog]

TCP is not perfect. There is ambiguity between the acknowledgement of a segment and the retransmission of a segment that we have tried to address with extensions and heuristics. It can introduce latency for upper protocols which are comprised of fixed-length messages. SACK reneging is a crime against humanity.

It's amazing that we've been able to adapt the protocol in a backwards-compatible fashion for over 30 years, but QUIC addresses problems with TCP in ways that could not be done in a backwards-compatible fashion. Personally I wish the protocol were simpler, but I lack the expertise to say what should be removed.

[bushbaba]

For FANG scale, a 1% performance improvement for certain services has measurable business results.

Take Snap. Say they reduced time to view a snap by 10ms. After 100 snaps that’s an additional 1 second of engagement. This could equate to an additional ad impression every week per user. Which is many millions of additional revenue.

[vlovich123]

HTTP/3 is E2E encrypted and built on UDP. What does “most routers don’t play nice with it yet” mean in that context? Do you mean middleware boxes/routers rather than end user routers?

[anderspitman]

For me the question is not so much "yet" as "maybe never", since some networks block UDP altogether, and HTTP/3 has a robust fallback mechanism.

[ikiris]

It means they don't actually understand networking, but think they do.

[klabb3]

> HTTP/3 is E2E encrypted

Please elaborate.

[homarp]

https://www.youtube.com/watch?v=J4fR5aztSwQ - Securing the Next Version of HTTP: How QUIC and HTTP/3 Compare to HTTP/2

"QUIC is a new always-encrypted general-purpose transport protocol being standardized at the IETF designed for multiplexing multiple streams of data on a single connection. HTTP/3 runs over QUIC and roughly replaces HTTP/2 over TLS and TCP. QUIC combines the cryptographic and transport handshakes in a way to allow connecting to a new server in a single round trip and to allow establishing a resumed connection in zero round trips, with the client sending encrypted application data in its first flight. QUIC uses TLS 1.3 as the basis for its cryptographic handshake.

This talk will provide an overview of what the QUIC protocol does and how it works, and then will dive deep into some of the technical details. The deep dive will focus on security-related aspects of the protocol, including how QUIC combines the transport and cryptographic handshakes, and how resumption, including zero-round-trip resumption works. This will also cover how QUIC’s notion of a connection differs from the 5-tuple sometimes used to identify connections, and what QUIC looks like on the wire.

In addition to covering details of how QUIC works, this talk will also address implementation and deployment considerations. This will include how a load balancer can be used with cooperating servers to route connections to a fleet of servers while still maintaining necessary privacy and security properties. It will also look back at some of the issues with HTTP/2 and discuss which ones may need to be addressed in QUIC implementations as well or are solved by the design of QUIC and HTTP/3."

[klabb3]

I think the common definition of e2e encryption covers user-to-user communication, so I'm confused how a transport protocol can offer e2e encryption at all (it would only do so if Quic is used over p2p between users, but that's a property of the application).

But even if the definition were different, http+tls would also be e2e encrypted (if used in conjunction which it pretty much always is).

I appreciate Quic but from a security perspective I don't see how it's different to what we've had for at least a decade.

[fwsgonzo]

While I agree, we shouldn't discount one less RTT for encrypted connections. Latency is a problem that never really goes away, and we can only try to reduce RTTs.

[jupp0r]

If people had tried to build great things on the protocols we have instead of re-discovering the wheel, we'd still have gopher, FTP and telnet for most things. Technology evolves and that's a good thing.

[jupp0r]

Routers are operating on the IP layer of the network stack, they don't have anything to do with application level protocols.

[y4mi]

> and DNS (which is centralized and should be replaced btw

So much nonsense in a single paragraph, amazing.

If anything DNS is less centralized then http and SMTP. Its a surprisingly complicated system for what it does because of all the caching etc, but calling it more centralized then http is just is just ignorant to a silly degree

[bastawhiz]

Sorry, what do you mean by "one for upstream and one for downstream"? You can't send messages back to the server with SSE.