Is QuicTransport a replacement for WebSockets?

[uasan]

In Chrome Canary, implemented class QuicTransport.
Do you think this is a real competitor to WebSockets in the future?
https://web.dev/quictransport/#is-quictransport-a-replacement-for-websockets

[ghost]

Interesting read. This whole QUIC thing is far from standardized though. Http2 is barely out the door and this all depends on Http3. Then you have WebRTC DataChannels

[ghost]

It is interesting. I'm looking into this, but QUIC is dramatically different and would have to be its own separate project, if anything. It could be made, sure.

[ghost]

Alright I'm hooked :) Will definitely make a project for QuicTransport - it's definitely a successor to WebSockets.

This is actually not dependent on any HTTP at all, it's entirely separate and could be implemented with little effort. Esp. if one would take the pub/sub and app concepts of µWS over to this thing, as a new project.

A pub/sub-over-QUIC kind of minimal server library pretty much like µWS but without HTTP.

[uasan]

Uber has been using it for a year now
Employing QUIC Protocol to Optimize Uber’s App Performance

Google wants to collect feedback from users of the protocol...
I don't understand how to auth user without an HTTP upgrade request, according to the current design QuicTransport?

[ghost]

Yes Google have been using QUIC since 2014 or something - but that doesn't mean it's a standard you can build apps with. Google control their own browser and can do all kinds of experiments behind the scenes and fall back to TCP otherwise. Also it seems QuicTransport is a whole new standard for browsers that build atop of QUIC and being part of WebTransports, so there are many experimental cogs involved that will take many years to properly become mainstream and widespread. Maybe even a decade?

It's interesting, sure, but WebSockets were standardized in 2011 but lacked compression until 2015 and I started implementing it in 2016 so WebSockets are still kind of a new standard that people use in production systems today and will do for many years to come.

I think this whole thing is interesting and there have come many nice QUIC implementations but the browser end is lacking still. You can't even find QuickTransport on caniuse.com

[ghost]

I don't understand how to auth user without an HTTP upgrade request, according to the current design QuicTransport?

Right, I was wondering that also. There seems to be no relation to HTTP at all, it only relies on QUIC and ALPN.

There seem to be a concept of URL and query and fragment though, so you could send info that way (I guess?) and reject the connection. Or, just do the classic thing and send first message with some auth info.

[ghost]

I asked a question in that draft repo and they replied like so:

Essentially, I understand it as QuickTransport is a thin protocol that builds on top of QUICK. They are not 1-to-1 but quite close. There should be no HTTP3 involved as I understand it.

That's a good summary, and yes, the name is confusing (that's a known issue, we'd probably have to fix that at some point).

For the origin trial, we're experimenting with QuicTransport as described in the linked draft. Longer term, we're currently debating (in IETF) whether the correct solution is to use the current approach or build a protocol on top of HTTP/3.

Looking at the bold text, it REALLY seems experimental. They don't even know if it should build on HTTP3 or not. I bet this will take a decade before we see any real adoption.

[uasan]

Thanks for answers.

There seem to be a concept of URL and query and fragment though, so you could send info that way (I guess?) and reject the connection. Or, just do the classic thing and send first message with some auth info.

This violates the our security requirements, the client JS runtime should not have access to access tokens, therefore we always use httpOnly cookies.

[ghost]

Alright I'm closing and we can reopen next decade :)