Webtransport / QUIC for Phoenix channels?

Does Phoenix have any plans to support channels with the new protocol coming up Webtransport / QUIC ? Seems like it would be great for liveview on lossy wireless connections.

I think this would require a new Phoenix pub/sub adapter but not sure.


QUIC is HTTP/2 replacement.

Channels just upgrade from HTTP/1 to Websockets.

I am not entirely sure CUIC will be used for sockets.

Before webtransport becomes supported we’d first need webserver libraries supporting http/3 (in a stable manner). It would need a new Phoenix.Socket.Transport to support channels, but phoenix pubsub would be unaffected.


Webtransport has very similar functionality to websockets but uses UDP/QUIC instead of TCP. Uni/Bi-directional multiplexed channels etc. Also reliable (tcp like) or unreliable (udp like) transport. Seems really cool imo

1 Like

That’s not correct. HTTP/3 is HTTP/2 replacement, QUIC is just yet another transport protocol. HTTP is L7 protocol while QUIC is L4.5-ish protocol. Completely different layers.

1 Like

Yeah, because QUIC is SCTP replacement ha-ha. QUIC is almost 100% like SCTP over UDP

1 Like

Hey I just replied QUICly, without much thought.


Well I’m not that technical yet with Elixir but it would be super cool to get a new Phoenix.Socket.Transport adapter for Webtransport.

Imagine the reliablilty of liveview apps from your phone. I would also think it relevant to the phoenix mobile stuff they’ve been experimenting with.

1 Like

Likely the first thing I’m planning on tackling in Bandit post-1.0 is QUIC support (with HTTP/3 / WebTransport support in Bandit coming soon thereafter). I’m expecting my first work to begin on this maybe March 2023, with some sort of early (QUIC) demo maybe later that summer. Absolutely no promises though.


The recent work in Phoenix 1.7 to factor out WebSocket support via the WebSock library was written with the intent of also support WebTransport when the time comes. Phoenix itself shouldn’t need to change for such support to land - it’s entirely on the underlying server to implement (see my last about Bandit’s plans for this)


I should have read about WebTransport.

“Webtransport is designed as a ‘QUIC-native’ client-server communication protocol to replace websockets. You can think of it like websockets but better (faster handshake, it reuses the http2 / QUIC connection, and you can relax websocket’s reliability & ordering constraints). Or you can think of it as WebRTC, except way simpler for the 95% case where you want to communicate server/client.”

This is an, eye opening, excerpt I took from Ycombinator.

This is awesome.


If anyone can do it its you Mat! Watching your ElixirConf 2021 video now on Bandit. Also shout out from T-Dot as well :stuck_out_tongue:


I heard about WebTransport earlier this year while brushing up on WebSockets and LiveView. The multichannel support for both reliable and unreliable communication is going to be just what I need.

This feature allows you to do more with each connection, leading to richer communication between a greater number of simultaneous users. It means that you can send different types of content on different channels, so something like a large image could be sent over a different connection than other data, which would mean that the image can’t block chat communication.

What is WebTransport and can it replace WebSockets? | Ably Blog: Data in Motion

BTW, the WebSock behavior is glorious, @mtrudel & @axelson! :bowing_man: