UDP vs TCP
UDP and TCP are the two transport protocols multiplayer games choose between. TCP guarantees every packet arrives and arrives in order; UDP sends packets and does not check whether they arrive. For real-time games, UDP’s speed usually matters more than TCP’s reliability guarantees.
What TCP does
TCP (Transmission Control Protocol) establishes a connection and guarantees reliable, ordered delivery. If a packet is lost, TCP detects it and automatically retransmits. The receiver reassembles packets in the correct order before delivering them to the application.
The cost is latency. Retransmission takes time. And even when no packets are lost, TCP’s ordering requirement means a delayed packet holds up all the packets behind it — a problem called head-of-line blocking. In a game sending updates 60 times a second, waiting for a lost packet to be retransmitted before processing any newer updates is actively harmful.
What UDP does
UDP (User Datagram Protocol) sends packets with no delivery guarantee and no ordering. Each packet is independent. If one is lost, the application never finds out unless it implements its own detection. If packets arrive out of order, the application handles it.
This sounds like a weakness. For games, it is a feature. The game engine knows that a position update from 50ms ago is worthless if a newer one has arrived. UDP lets the game ignore stale data rather than blocking on retransmission of it.
Why most games use UDP
The calculation is straightforward for fast-paced multiplayer games. Player positions, inputs, and game state updates are time-sensitive and frequently redundant — the next update will arrive in 16ms anyway. Retransmitting stale data wastes bandwidth and introduces the kind of irregular latency spikes that make games feel broken.
With UDP, the game implements its own reliability layer for the packets that genuinely need it — things like match start events, score updates, and session control messages — while letting position and input data flow unreliably at high frequency.
Engines like Unreal (with its NetDriver), Unity (with Netcode for GameObjects), and purpose-built networking libraries like ENet, GameNetworkingSockets, and ENET all build their reliability layer on top of UDP rather than using TCP.
When TCP makes sense
Some game data actually needs reliable delivery. Chat messages, inventory transactions, matchmaking results, and persistent state changes should not be silently dropped. Many games use TCP (or a TCP-like reliable channel within their UDP stack) for these low-frequency, high-importance messages, while using UDP for the high-frequency real-time simulation data.
Purely turn-based games, mobile games with forgiving latency requirements, and games that do not send continuous position data often use TCP without noticeable problems — the head-of-line blocking penalty only matters when updates are continuous and time-sensitive.
QUIC: a newer alternative
QUIC is a modern transport protocol built on UDP that adds selective reliability, multiplexed streams, and built-in encryption. It solves head-of-line blocking (each stream is independent) while providing some of TCP’s guarantees where needed. A small number of modern games and game backends have adopted QUIC, though UDP with a custom reliability layer remains the dominant approach in shipped titles.
See also: Netcode · Latency · Packet Loss · Data Packet