HTML5 Multiplayer Games over UDP (client/server) using


I just wanted to share a library I built a while ago. I read a lot, even in newer posts, that networking over UDP is not possible in the browser. But it is possible. WebRTC’s DataChannel can send unordered and unreliable message via UDP (SCTP). But WebRTC does not only work in browsers. It works, amongst other things, on Node.js. So if you want to network your multiplayer game over UPD, use WebRTC on the browser and on node.js.

That’s exactly what my library does. Sending client/server messages via UDP between browser and node.js. Take a look! I’m sure some of you can use it :slight_smile:

This is a copy paste of a topic I just created in the babylon.js forum. But I feel like it fits also just perfectly in here.


Nice! Can you please give a bit more detail about differences between websockets and WebRTC? (unless they are the same, I’m kinda ignorant with networking. I just recall Colyseus framework used ws:// for real-time communications and HTTP for ordered updates.)


The big difference between WebSockets and WebRTC is that

  • WebSocket runs on top of TCP
  • WebRTC’s DataChannel runs on top of UDP


What this can mean for you multiplayer game, you can watch here.

I just saw that there is one related open issue and one that got closed. Maybe they will add it someday. Maybe I could write to them and help them add it. I have no idea what their plans are :confused:


Good job, I believe it will help me a lot in my mmorpg project, I had doubts about the websocket and you touched on an important point, UDP or TCP, thanks for sharing!

1 Like

This is sick! Never thought that the web will ever support UDP. This is going to fix all those lags we have in those fun little web games. Amazing work!!


This is great!
Are you aware of WebTransport?


Yes, if it (or something similar over quic (HTTP/3)) becomes widely available, I will integrate it and use WebRTC only as a fallback :slight_smile:


I made a one to one comparison between and Hope it helps :smiley:


Awesome showcase! You should definitely put it up on readme, showcasing the difference between UDP and TCP (or between and Nothing is quite as convincing as a clear visualization :slight_smile:


Done :slightly_smiling_face:


This is fantastic work!

Out of curiosity, what kinds of conditions would cause significant packet loss?

Living in the Netherlands with Tele2 internet connection… :’)


Very interesting dude! But isn’t WebRTC DataChannel only available between peer to peer?

Bad network, I guess. I’m not really a networking pro and do also not have any statistics about package loss. Would be great to see some per country based statistics.

But package loss is not the only thing protects you. It smooths out huge latency spikes.

Below an screenshot taken from my phone. Where I live, package loss seams not to be an issue, however some packages arrived with 100ms (or more) delay.

Now, imagine you send every 16ms (60 times per second) a new update to your client and the 100th package has a delay of 100ms. Even though you may already have received packages 101, 102 and 103, if you use TCP, the client will have to wait for package nr. 100 before it can read 101, 102 and so on. If you use (UDP) you can instantly read 101, 102 and drop 100 when it arrives.

Hope this helps :slight_smile:


Yes, but peer to peer is not necessarily only browser to browser. One node can be a browser and the second node a server.

Oh I see. That’s awesome dude! Such a brilliant idea!

1 Like

Cool, someone had to do it one day. By the way, maybe you will interested to read this topic:

1 Like

@yannick great stuff - I bump into your post in my quest for the ultimate html5 multi user server speed.

I have a question how your library is different from this here ?

The PDF:

The talk:

QUIC is not yet supported in any browser. See

WebRTC on the other hand is very well supported ( uses Client/Server WebRTC DataChannels. But once quic will be widely available, it will use it and just fallback to WebRTC if needed.

1 Like

so the second scenario with UDP between the server and browser.
Great stuff thanks :+1:

For the future I see that we can play with QUIC/HTTP3 as an experimental feature for now:
firefox > about:config > http3 > network.http.http3.enable > true
chrome > chrome://flags/ > quic > experimental quic protocol > enable