QUIC is not quick enough over fast internet

EDITED.

I preference WebSockets over anything analogous to HTTP.

Commented edited because I mentioned performance conditions. Software developers tend to make unfounded assumptions/rebuttals of performance conditions they have not tested.

> * String headers > * round trips > * many sockets, there is additional overhead to socket creation, especially over TLS > * UDP. Yes, in theory UDP is faster than TCP but only when you completely abandon integrity.

Have you ever read up on the technical details of QUIC? Every single of one of your bullets reflects a misunderstanding of QUIC's design.

I'd use them more, but WebSockets are just unfortunately a little too hard to implement efficiently in a serverless environment, I wish there was a protocol that spoke to that environment's tradeoffs more effectively.

The current crop aside from WebSockets all seem to be born from taking a butcher knife to HTTP and hacking out everything that gets in the way of time to first byte. I don't think that's likely to produce anything worthwhile.

> QUIC is faster than prior versions of HTTP, but its still HTTP. It will never be fast enough because its still HTTP: > * String headers > * round trips > * many sockets, there is additional overhead to socket creation, especially over TLS

QUIC is a transport. HTTP can run on top of QUIC, but the way you’re equating QUIC and HTTP doesn’t make sense.

String headers and socket opening have nothing to do with the performance issues being discussed.

String headers aren’t even a performance issue at all. The amount of processing done for when the most excessive use of string headers is completely trivial relative to all of the other processing that goes into sending 1,000,000,000 bits per second (Gigabit) over the internet, which is the order of magnitude target being discussed.

I don’t think you understand what QUIC is or even the prior art in HTTP/2 that precedes these discussions of QUIC and HTTP/3.

That is a fair point. I wrote my own implementation of WebSockets in JavaScript and learned much in doing so, but it took tremendous trial and effort to get right. Nonetheless, the result was well worth the effort. I have a means to communicate to the browser and between servers that is real time with freedom to extend and modify it at my choosing. It is unbelievably more responsive than reliance upon HTTP in any of its forms. Imagine being able to execute hundreds of end-to-end test automation scenarios in the browser in 10 seconds. I can do that, but I couldn't with HTTP.

Honestly the entire comment is a head scratcher, from comparing QUIC to HTTP (different layers of the stack) or suggesting that string headers are a performance bottleneck.

Websockets are useful in some cases where you need to upgrade an HTTP connection to something more. Some people learn about websockets and then try to apply them to everything, everywhere. This seems to be one of those cases.

> String headers aren’t even a performance issue at all.

That is universally incorrect. String instructions require parsing as strings are for humans and binary is for machines. There is performance overhead to string parsing always, and it is relatively trivial to perf. I have performance tested this in my own WebSocket and test automation applications. That performance difference scales in logarithmic fashion provided the quantity of messages to send/receive. I encourage you to run your own tests.

This is an insane take.

Just to pick at one point of this craziness, you think that communicating over web sockets does not involve round trips????

That is correct.

QUIC isn’t HTTP, QUIC is a protocol that operates at a similar level to UDP and TCP.

HTTP/3 is HTTP over QUIC. HTTP protocols v2 and onwards use binary headers. QUIC, by design, does 0-RTT handshakes.

> Yes, in theory UDP is faster than TCP but only when you completely abandon integrity

The point of QUIC, is that it enables application/userspace level reconstruction with UDP levels of performance. There’s no integrity being abandoned here: packets are free to arrive out of order, across independent sub-streams, and the protocol machinery puts them back together. QUIC also supports full bidirectional streams, so HTTP/3 also benefits from this directly. QUIC/HTTP3 also supports multiple streams per client with backpressure per substream.

Web-sockets are a pretty limited special case, built on-top of HTTP and TCP. You literally form the http connection and then upgrade it to web-sockets, it’s still TCP underneath.

Tl;Dr: your gripes are legitimate, but they refer to HTTP/1.1 at most, QUIC and HTTP/3 are far more sophisticated and performant protocols.

QUIC is a reliable transport. It's not "fire and forget", there is a mechanism for recovering lost messages similar, but slightly superior to TCP. QUIC has the significant advantage of 0- and 1-rtt connection establishments which can hide latency better than TCP's 3-way handshake.

Current implementations have some disadvantages to TCP, but they are not inherent to the protocol, they just highlight the decades of work done to make TCP scale with network hardware.

Your points seem better directed at HTTP/3 than QUIC.

WebSockets are not built on top of HTTP, though that is how they are commonly implemented. WebSockets are faster when HTTP is not considered. A careful reading of RFC6455 only mentions the handshake and its response must be a static string resembling a header in style of RFC2616 (HTTP), but a single static string is not HTTP. This is easily provable if you attempt your own implementation of WebSockets.

Both HTTP/2 and HTTP/3 use binary protocol encoding and compressed (binary) headers. You're arguing a straw man that has little to do with reality.

… I mean, in theory someone could craft some protocol that just starts with speaking Websockets or starts with some other handshake¹, I suppose, but the overwhelming majority of the uses of websockets out there are going to be over HTTP, as that's what a browser speaks, and the client is quite probably a browser.

> A careful reading of RFC6455 only mentions the handshake and its response must be a static string resembling a header in style of RFC2616 (HTTP), but a single static string is not HTTP.

You're going to have to cite the paragraph, then, because that is most definitely not what RFC 6455 says. RFC 6455 says,

> The handshake consists of an HTTP Upgrade request, along with a list of required and optional header fields.

That's not "a single static string". You can't just say "are the first couple of bytes of the connection == SOME_STATIC", as that would not be a conforming implementation. (That would just be a custom protocol with its own custom upgrade-into-Websockets, as mentioned in the first paragraph, but if you're doing that, you might as well just ditch that and just start in Websockets.)

¹(i.e., I grant the RFC's "However, the design does not limit WebSocket to HTTP, and future implementations could use a simpler handshake", but making use of that to me that puts us solidly in "custom protocol" land, as conforming libraries won't interoperate.)

That is still incorrect. Once the handshake completes the browser absolutely doesn’t care about HTTP with regard to message processing over WebSockets. Therefore just achieve the handshake by any means and WebSockets will work correctly in the browser. The only browser specific behavior of any importance is that RFC6455 masking will occur on all messaging leaving the browser and will fail on all messaging entering the browser.

> You can't just say

I can say that, because I have my own working code that proves it cross browser and I have written perf tools to analyze it with numbers. One of my biggest learnings about software is to always conduct your own performance measurements because developers tend to be universally wrong about performance assumptions and when they are wrong they are frequently wrong by multiple orders of magnitude.

As far as custom implementation goes you gain many liberties after leaving the restrictions of the browser as there are some features you don’t need to execute the protocol and there are features of the protocol the browser does not use.

> That is still incorrect. Once the handshake completes the browser absolutely doesn’t care about HTTP with regard to message processing over WebSockets.

I never made any claim to the contrary.

> Therefore just achieve the handshake by any means and WebSockets will work correctly in the browser.

At which point you're parsing a decent chunk of HTTP.

> I can say that, because I have my own working code that proves it

Writing code doesn't prove anything; code can have bugs. According to the standard portion I quoted, your code is wrong. A conforming request isn't required to match.

> I have written perf tools to analyze it with numbers. One of my biggest learnings about software is to always conduct your own performance measurements because developers tend to be universally wrong about performance assumptions and when they are wrong they are frequently wrong by multiple orders of magnitude.

Performance has absolutely nothing to do with this.

Even if such an implementation appears to work today in browsers, this makes situations with a still-conforming UA damn near impossible to debug, and there's no guarantees made on header ordering, casing, etc. that would mean it would continue to work. Worse, non-conformant implementations like this are the sort of thing that result in ossification.

In my own implementation I wrote a queue system to force message ordering and support offline messaging state and so forth. Control frames can be sent at any time irrespective of message ordering without problems, however.

In the end an in house implementation that allows custom extensions is worth far more than any irrational unfounded fears. If in the future it doesn’t work then just fix the current approach to account for those future issues. In the meantime I can do things nobody else can because I have something nobody else is willing to write.

What’s interesting is that this entire thread is about performance concerns. If you raise a solution that people find unfamiliar all the fear and hostility comes out. To me such contrary behavior suggests performance, in general, isn’t a valid concern to most developers in comparison to comfort.