Why Real-Time Multiplayer Games Discard TCP for Custom UDP Netcode

Real-time multiplayer games transmit data using the User Datagram Protocol (UDP) rather than the Transmission Control Protocol (TCP) because TCP's mandatory guaranteed delivery creates game-breaking latency spikes the moment a single packet drops. When a network loses a TCP packet, the protocol halts all subsequent incoming data until the missing information is successfully retransmitted, freezing the local game state while the server waits.[1][5]

In a competitive shooter or fighting game running at a 60Hz server tick rate, the server dispatches a new world state every 16.6 milliseconds. If a player's connection drops just one of those updates, TCP's architecture forces the client to wait for a round-trip retransmission—often 50 to 100 milliseconds—before processing the newer packets that have already arrived.[1]

"The problem with using TCP for real-time games is that it abstracts network communication into a reliable, ordered stream of data," writes network programmer Glenn Fiedler in his foundational 2008 analysis of game networking. "If a packet is lost, TCP will stop and wait for that packet to be retransmitted."[1]

This phenomenon, known as head-of-line blocking, is the primary reason the $180 billion gaming industry discards the internet's default transmission protocol. While TCP flawlessly loads web pages and streams video by ensuring every byte arrives in perfect order, it fundamentally misunderstands the temporal nature of a live multiplayer environment.[1][5]

In a live match, data has a strict expiration date. If a server sends a packet stating an enemy player is at coordinates X and Y, and that packet is lost in transit, retransmitting it 80 milliseconds later is useless. By the time the delayed packet arrives, the enemy has already moved.[4]

UDP solves this by stripping away the guarantees. It is a connectionless, fire-and-forget protocol. A UDP packet carries an 8-byte header—compared to TCP's 20-byte minimum—and simply hurls the payload at the destination IP address without waiting for an acknowledgment.[5]

If a UDP packet drops, the protocol does not care. The game client simply accepts the loss and processes the very next packet that arrives, interpolating the missing 16.6 milliseconds of movement to keep the visual experience smooth.[1][4]

However, raw UDP is too chaotic for a complete game state. While a dropped movement update is easily ignored, a dropped packet containing a sniper rifle firing, a health pack being consumed, or a chat message being sent breaks the game logic entirely.[4]

To bridge this gap, network engineers build custom reliability layers directly on top of UDP, creating what the industry calls Reliable UDP (RUDP). This approach allows developers to categorize data into distinct channels, applying guaranteed delivery only to the specific actions that require it.[4]

A 2018 study published in the MDPI journal Electronics quantified this hybrid approach, demonstrating that an RUDP implementation could reduce average latency by 34% compared to a pure TCP connection during periods of network congestion.[3]

"By implementing reliability at the application level, game developers can decide exactly what data needs to be resent and what data can be safely discarded," notes the technical breakdown from iThare. This selective retransmission ensures that a dropped movement packet never delays a critical weapon firing event.[4]

The bandwidth savings are equally critical at scale. A massive multiplayer online game or a 100-player battle royale generates immense traffic. Researchers analyzing popular online games found that the constant stream of small, time-sensitive packets makes TCP's overhead mathematically punishing for server infrastructure.[2]

With TCP, the mandatory 20-byte header attached to every single transmission adds up. At 60 packets per second, that header alone consumes 1,200 bytes per second per client. For a server hosting 100 players, that is 120 kilobytes per second of pure overhead, before a single byte of actual game data is transmitted.[5]

UDP's 8-byte header slashes that baseline overhead by 60%. While the application-layer reliability adds its own bytes back into the payload, the developer controls exactly how and when that overhead is applied, rather than accepting TCP's blanket tax on every transmission.[4][5]

Empirical evaluations of TCP performance in online games repeatedly confirm its unsuitability for twitch-based mechanics. A study analyzing TCP in fast-paced environments found that even a 1% packet loss rate on a standard broadband connection resulted in latency spikes exceeding 200 milliseconds—a delay that renders competitive play impossible.[6]

This forces a strict architectural divide in game development. Turn-based strategy games, digital card games, and asynchronous mobile titles can safely rely on TCP, as a 200-millisecond delay in drawing a card is imperceptible to the player.[1][6]

But for any title where human reaction time dictates the outcome—where a 15-millisecond advantage wins a gunfight—the network architecture must prioritize recency over completeness. The server must be allowed to forget the past to deliver the present.[1][4]

The dominance of UDP in real-time gaming is a triumph of specialized engineering over generalized standards. By rejecting the internet's built-in safety nets, developers take on the immense burden of managing packet loss, ordering, and congestion control themselves.[4][7]

That burden is the hidden cost of modern esports. Every smooth character animation, every registered hit, and every perfectly timed parry relies on a custom-built protocol racing across the internet, dropping the data that no longer matters to deliver the frame that does.[7]