UDP vs TCP
UDP and TCP are the two classic transport protocols games choose between. TCP resends lost data and delivers bytes in order, so a lost piece holds back everything behind it until the resend arrives. UDP guarantees neither, so a lost packet is simply gone and play moves on. Many real-time games send gameplay over UDP because stale data is often worse than missing data.
Also called
UDP, TCP, TCP vs UDP
,
What Is the Difference Between UDP and TCP?
Both carry data between two machines on the internet. They differ in what they promise about it.
TCP | UDP | |
|---|---|---|
Connection | Set up with a handshake before any data moves | None; each packet is sent on its own |
Delivery | Lost data is resent until acknowledged, or the connection eventually gives up | No promise; a lost packet is gone |
Order | Bytes arrive in the order they were sent | Packets can arrive out of order |
Header size | At least 20 bytes (RFC 9293) | 8 bytes (RFC 768) |
Typical uses | Web pages, file downloads, logins, store and chat services | Real-time gameplay, voice, most DNS lookups |
For a game, one consequence of TCP’s promises matters most. Because TCP delivers one ordered stream, a lost piece holds back everything sent after it until it is resent, which takes at least one round trip. The data behind it may have arrived already; it waits anyway. UDP lets each packet stand alone, so a newer position update can be used the moment it lands, even if the one before it never arrives.
In Practices - Insights from Edgegap's Blog
Article's key insights
Latency has a floor, and everything else stacks on top of it: The physical travel time between two machines is the minimum delay any online game can have. Routing, tick rate, update rate and processing all add to it. Netcode cannot remove that delay. It can only decide where players feel it.
The shortest path is rarely the fastest: A direct peer-to-peer connection looks like the shortest route between two players, but packets still cross both players' ISPs and whatever routes those networks choose. A well-placed server between them is often both faster and fairer.
Lag compensation moves the cost, it doesn't erase it: Lag compensation rewinds the server so a high-ping player's shot counts, which means the target can be hit after reaching cover. The only real fix is keeping ping gaps small, which makes it a matchmaking and server placement problem as much as a netcode one.
Tick rate is a time budget: A server's tick rate sets how many milliseconds it has to simulate each step of the game. Higher rates cut delay and sharpen hit registration, but cost more CPU and bandwidth. A server that overruns its budget stutters for everyone in the match.
Two separate choices, not one: Where the game runs (peer-to-peer, relay or dedicated server) and how state is shared (lockstep, rollback or state replication) are independent decisions. Any sync model can run on any hosting model.
Is UDP or TCP Better for Gaming?
It depends on the data more than on the game, and many online games use both.
The match itself, meaning movement, aim and world state, is usually sent over UDP to the game server, because a late update is often worth less than the next one. Many engines and libraries default to it: Unreal Engine replicates over UDP by default, Unity Transport defaults to UDP outside the browser (Unity documentation), and Mirror ships a UDP-based transport, KCP, for every platform except WebGL (Mirror documentation).
Everything around the match often runs over TCP, as HTTPS calls to login, matchmaking, the store and chat. These are messages that must arrive and can afford a short wait.
Pace decides the rest. Mirror’s documentation puts it simply: TCP “is better for slower paced games where latency isn’t important but the game data is”, and UDP suits fast-paced games where latency between server and client matters. A turn-based card game can run its whole match over TCP. A shooter usually can’t.
How Do Games Make UDP Reliable Where It Matters?
Some messages must arrive: a shot that hit, an item picked up, a round that ended. Games running on UDP add their own reliability for those, usually as separate channels next to an unreliable one for state that the next update replaces. Packet loss covers which data a game resends and which it skips; the transport layer covers the libraries that provide these channels.
Rebuilt reliability can bring TCP’s stall back, for that channel. Unreal Engine’s documentation is explicit. RPCs are unreliable by default. A reliable RPC “is re-sent until it is acknowledged by the receiver”, and “all subsequent RPC executions are suspended until this RPC is acknowledged”. The same page warns that reliable RPCs “require additional bandwidth, as such, use them sparingly” (Epic documentation).
That is why games keep reliable traffic small and separate. A lost reliable event can then delay the reliable events queued behind it, while unreliable position updates keep flowing.
What About Browser Games?
A browser game can’t simply choose UDP. As Unity’s documentation puts it, “web browsers don’t offer direct access to UDP sockets”, so a Unity WebGL build connects over WebSocket, which runs on TCP (Unity documentation). Web developers have three main options:
WebSocket. Supported everywhere and simple to run, with TCP’s stall when a packet is lost.
WebRTC data channels. Can be set to unordered and to limit or skip resends, which behaves much like UDP (MDN). They need a signaling step to connect, and some networks need a TURN relay.
WebTransport. Runs over QUIC, the UDP-based protocol behind HTTP/3, and offers unreliable datagrams. It needs an HTTP/3 server. Current versions of Chrome, Edge, Firefox and Safari support it (Safari from version 26.4), but older browsers, and networks that block UDP, still call for a WebSocket fallback (Can I use, October 2026).
QUIC keeps TCP-style reliable, ordered streams, but a lost packet only delays the streams whose data it carried, not the whole connection.
WebSocket also helps native games on restrictive networks. Photon’s documentation notes that “most of the networks with restricted internet access still allow a secure connection via Secure WebSockets”, on port 443 (Photon documentation).
On Edgegap, a game server can expose a WebSocket port and turn on the TLS Upgrade option, currently in Beta, so browser players can connect over secure WebSocket; Edgegap’s Mirror and FishNet WebGL samples show the setup (Edgegap docs). If the netcode can listen on two transports at once, the same deployment can also expose a UDP port, so native and browser players can connect to one server.
A word from our sponsor (ourselves!)
Most lag comes from distance, not from code. Edgegap's Edge Cloud is a distributed network with up to 615+ locations available on demand, so each match runs at the best available location for its players. Independent replays of live studio traffic measured a 58% drop in average round-trip time compared with public cloud.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Choose UDP or TCP for Each Kind of Message, Not Once for the Whole Game
Start from what the player sees. List every kind of message your game sends: movement, shots, ability use, chat, inventory, purchases. For each one, ask two questions. Is it still useful if it arrives 200 ms late? Must it arrive if it’s lost?
The answers sort each message: an unreliable channel for state the next update replaces, a reliable channel for events that must land, and a backend call over HTTPS for anything that can wait a moment. Most games end up using all three.
If you ship a web build, test the browser path before launch, not after. On Edgegap, one deployment can open a UDP port for native players and a WebSocket port for browser players, when the netcode can listen on both. Route length matters whichever transport you pick, since every resend waits on at least one round trip. In independent replays of one studio’s live traffic, dedicated server placement measured a 58% average round-trip time reduction against public-cloud relay placement (platform data, 30 September 2026).
Philip Coté, CTO
,
