The short answer
If any of your players use a web browser, you need WebSocket or WebRTC. Native clients on Windows, macOS, Linux, Android and iOS can use UDP, which handles packet loss more gracefully. Many teams run both: UDP for native, WebSocket for web, one authoritative server behind them.
How they differ
| Native UDP (ENet, KCP, Unity Transport) | WebSocket | WebRTC data channel | |
|---|---|---|---|
| Runs in a browser | No | Yes | Yes |
| Transport underneath | UDP | TCP | UDP (DTLS/SCTP) |
| Ordering and reliability | Your choice per message | Always reliable and ordered | Configurable |
| Effect of a lost packet | Only that packet | Delays everything behind it | Depends on settings |
| Needs a server | Yes (dedicated) | Yes (dedicated) | Signaling server, peers connect directly |
| Network traversal | Server has a public address | Server has a public address | ICE; may need a TURN relay |
| From an HTTPS page | n/a | Must be wss:// | Allowed |
Head-of-line blocking, in plain words
TCP delivers bytes in order. If one packet is lost, later packets wait until it is retransmitted, even if they already arrived. For a turn-based or slower game that is invisible. For a fast action game on a flaky connection it shows up as stutter. UDP lets you drop stale state and send the newest, which is why fast games prefer it.
Choosing
- Turn-based, card, puzzle, or slow co-op in the browser: WebSocket to an authoritative server is the simplest and the most reliable to host.
- Fast action in the browser: consider WebRTC data channels, accepting connectivity risk, or keep WebSocket messages small and use client prediction.
- Native only: use UDP and skip the browser lane.
- Both: run one authoritative server that speaks both transports, or one server per transport.
What this means on NetCraftGames
- Native UDP games run on the dedicated server lane (Mirror, NGO, Unreal, Godot ENet).
- Browser WebSocket games run behind a
wss://gateway (browser WSS, Godot WebSocket). - WebRTC games get signaling rooms (browser WebRTC); there is no TURN relay, so some networks will fail to connect.
Mixed content, the classic web trap
A page served over HTTPS may only open secure WebSocket connections. A game that works on http://localhost with ws:// will fail in production unless it uses wss://. The gateway terminates TLS so your server does not need certificates.
Frequently asked questions
Can a browser game use UDP?
Not directly. Browsers do not expose raw UDP sockets to web pages. They offer WebSocket, which runs over TCP, and WebRTC data channels, which run over UDP-based protocols and can be unreliable and unordered. Native clients can use real UDP, so many games offer UDP for native and WebSocket for browsers.
Is WebSocket fast enough for a multiplayer game?
For turn-based, card, puzzle and many co-op games, yes. For fast action on unreliable networks it can stutter, because TCP holds later data behind a lost packet. Keep messages small, send state snapshots instead of every event, use client prediction, or evaluate WebRTC data channels if you accept the connectivity trade-offs.
Sources
- MDN: WebSockets API, accessed October 3, 2026
- MDN: WebRTC protocols (ICE, STUN, TURN), accessed October 3, 2026