When you write a game server, the first architectural decision you eventually run into is the transport-layer protocol: for a TCP vs UDP game server, which one is the right call? The answer isn't as simple as "always UDP" or "always TCP". Both run over the same IP network, but they carry your data with completely different guarantees, and those guarantees directly shape how responsive your game feels. In this article I'll explain what the two protocols actually do, which game genre fits which one, and how I decide in practice.
What do TCP and UDP actually do?
TCP (Transmission Control Protocol) is connection-based and reliable. It establishes a connection with a three-way handshake (SYN, SYN-ACK, ACK) and guarantees that every byte you send arrives at the other end in order and complete. It automatically retransmits lost packets, fixes ordering, and throttles its own rate when the network gets congested.
UDP (User Datagram Protocol) is connectionless and "fire and forget". It sends a datagram and stays out of the rest: a packet can be lost, arrive out of order, or even show up twice. In return it adds almost no overhead; no handshake, no waiting for retransmission.
In short, the real trade-off between them is this:
- TCP: always correct and ordered data, but jitter and the risk of head-of-line blocking.
- UDP: minimal latency and full control, but you have to build reliability yourself.
What drives latency in games: head-of-line blocking
To understand why UDP is so loved in games, you need to see TCP's sneakiest problem. Because TCP guarantees ordered delivery, when a single packet is lost, all packets that arrive after it sit in the operating system buffer; none of them are handed to your application until the lost packet is retransmitted and arrives. This is called head-of-line blocking.
In a fast-paced shooter this is disastrous: a lost packet containing the player's position from 40 ms ago holds up the most recent position packets too, even though that old one is already stale. Yet in game logic the latest state is usually what matters; losing the position from three frames ago is nothing to worry about. UDP lets you handle each datagram independently here: you discard the old one and immediately use the freshest.
Which one for which genre?
A practical decision framework looks like this:
- Real-time, fast-paced (FPS, MOBA, fighting, racing, action MMO): UDP. For the constant stream of position/input updates, low latency matters above all, and the loss of a single packet is tolerable.
- Turn-based / slow-paced (card game, chess, browser-based strategy, social/chat): TCP. Every action is critical, milliseconds don't matter, and simplicity plus guaranteed delivery win.
- Classic MMORPGs (such as Metin2 or Tibia): in practice most use TCP. Inventory, trade, chat and world state demand reliability; while movement could be a bit smoother, TCP's consistency is enough for the genre and greatly simplifies the server code.
One important point: many modern games use both at once. Movement and input flow over UDP, while login authentication, purchases, chat and persistent state go over TCP. Don't assume "I have to pick one protocol".
A simple comparison on Linux
Seeing how differently the two protocols are set up at the socket level makes the decision concrete. Below are the skeletons of a TCP listener and a UDP listener in C++ (POSIX sockets). The difference is SOCK_STREAM versus SOCK_DGRAM, and the listen/accept steps in TCP:
// TCP server skeleton
int fd = socket(AF_INET, SOCK_STREAM, 0);
bind(fd, (sockaddr*)&addr, sizeof(addr));
listen(fd, 128);
int client = accept(fd, nullptr, nullptr); // accept a connection
recv(client, buf, sizeof(buf), 0); // reliable, ordered stream
// UDP server skeleton
int fd = socket(AF_INET, SOCK_DGRAM, 0);
bind(fd, (sockaddr*)&addr, sizeof(addr));
sockaddr_in from; socklen_t len = sizeof(from);
recvfrom(fd, buf, sizeof(buf), 0,
(sockaddr*)&from, &len); // connectionless datagramWith UDP there is no accept and no persistent connection; each datagram tells you who it came from via recvfrom. That's why you have to build the "who is which player" mapping, session management and reliability yourself, at the application layer.
If you chose UDP: you build reliability yourself
UDP's "free speed" isn't actually free; you hand-write part of what TCP gives you out of the box. Typically you'll need:
- Sequence numbers: stamp each packet with an increasing number to filter out old or duplicate packets.
- Selective reliability: ACK-guarantee only the things that can't be lost (e.g. "shot fired", "died" events), not everything.
- Congestion and rate control: tune the send rate so you don't flood the network.
The good news: you don't have to write this from scratch. Mature libraries like ENet, GameNetworkingSockets (Valve) or KCP add optional reliable/ordered channels on top of UDP. For most teams the right path is to use one of these rather than raw UDP.
A practical decision checklist
- Is the game fast-paced and is the "latest state" more valuable than the old one? → UDP.
- Is every message critical and is ordering essential, while milliseconds don't matter? → TCP.
- Is development time tight, are you building a prototype? → Start with TCP, move movement to UDP later if needed.
- Does a hybrid make sense? → Yes, most production games do exactly that.
Frequently Asked Questions
Is UDP always faster than TCP?
In terms of raw throughput (bandwidth) there's no meaningful difference; both use the same network. UDP's advantage is latency consistency: because it doesn't stall on packet loss, it avoids jitter and head-of-line blocking. So it's more accurate to say "more responsive and predictable" rather than "faster".
Can I use UDP in a browser-based game?
You can't open raw UDP directly from a browser. WebSocket runs over TCP; for low-latency, UDP-like transport you use a WebRTC data channel (over UDP, with optional reliable/unordered modes). Most browser games work just fine with WebSocket if speed isn't critical.
Is TCP enough for an MMORPG like Metin2?
Yes. The original architecture of these games is built on TCP and runs smoothly with thousands of players. The flow isn't so high-frequency that TCP's ordered delivery becomes a problem; and for trade, inventory and world consistency, TCP's guarantees are exactly what you want.
Conclusion: The right answer depends on your game's rhythm; UDP for fast pacing, TCP for critical and ordered messages, and a combination of the two in most production environments. Want to nail down the TCP/UDP decision, scaling or the network layer for your game server architecture together? Get in touch and let's talk through your project's requirements.