Source: https://gameye.com/glossary/udp-vs-tcp/ --- title: "UDP vs TCP | Gameye" description: "UDP vs TCP for multiplayer games: TCP guarantees delivery and order; UDP trades reliability for speed. Most real-time games choose UDP." --- # 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](https://gameye.com/glossary/netcode/) · [Latency](https://gameye.com/glossary/latency/) · [Packet Loss](https://gameye.com/glossary/packet-loss/) · [Data Packet](https://gameye.com/glossary/data-packet/) Building a multiplayer game? Gameye hosts dedicated game servers: ship your server as a Docker container and start one per match with a single API call, in a region near your players. [See how it works →](https://gameye.com/how-it-works/) [Back to Glossary](https://gameye.com/glossary/) ## Related terms - ### Netcode Netcode synchronises game state between players. Poor netcode causes lag, rubber-banding, and hit registration issues in multiplayer games. [Read more](https://gameye.com/glossary/netcode/) - ### Latency Latency is how fast data is moving. How quickly does it get from point A to point B? (And it’s generally measured in milliseconds.) [Read more](https://gameye.com/glossary/latency/) - ### Packet Loss Packet loss is when network data never arrives. Even 1-3% loss causes rubber-banding, missing inputs, and broken hit registration in games. [Read more](https://gameye.com/glossary/packet-loss/) - ### Tick rate Tick rate is how many times per second a game server updates the game state, measured in hertz (Hz). A 64-tick server updates 64 times a second; a 128-tick server, 128. [Read more](https://gameye.com/glossary/tick-rate/) - ### Data packet A data packet is game data — position, inputs, events — sent across the network. Packet size and send rate directly affect latency and bandwidth use. [Read more](https://gameye.com/glossary/data-packet/)