Untitled
Wrklog
saved··
i recently spent time learning more about QUIC and the HTTP3 ecosystem
while researching my upcoming aiminterviews.com with Justin Uberti the creator of webrtc I came across this Chinese interview he did a few years ago where he talks about how QUIC could be huge for the webrtc ecosystem
I believe QUIC will have a significant impact on the future of WebRTC. The reason I say this is because creating a WebRTC server is still very difficult. HTTP-based applications already have great infrastructure, but creating a WebRTC server is a process of building from scratch. Being able to transmit WebRTC traffic via QUIC means that setting up cloud WebRTC endpoints and transmitting data to them will become much easier. It's also a good thing that we don't have to continue developing a completely separate transport protocol (and supporting libraries) for WebRTC.
https://juejin.cn/post/7039521638362120199
interesting also that John Carmack has been talking about this https://x.com/ID_AA_Carmack/status/2056780156535279812
one of the cool things about quic over webrtc is the no head-of-line (HOL) blocking and per track flow control (for vid audio or tokens etc)
last week i thought i'd try an experiment taking a quic protocol library and trying to build more of a webrtc style subscriber interface that let you assign these custom queuing behaviors to streams
this is basically how it works:
its a WIP but early performance tests are promising
it does well for server originated multi-stream bursts especially for worst case scenarios
there still isn't a good way to do browser p2p with quic
but the 0-round trip time is really cool and makes it feel super fast head to head with webrtc