UDP vs TCP
UDP et TCP sont les deux protocoles de transport entre lesquels les jeux choisissent. Le protocole TCP garantit que chaque paquet arrive dans l'ordre, et bloque tout ce qui se trouve derrière un paquet perdu jusqu'à ce qu'il soit renvoyé. Le protocole UDP ne garantit ni l'un ni l'autre, de sorte qu'un paquet perdu est simplement égaré et le jeu continue. Les jeux en temps réel utilisent l'UDP car des données périmées sont pires que des données manquantes.
Aussi appelé
UDP, TCP
,
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.
En pratique - Aperçus du blog de Edgegap
Points clés de l'article
La latence a un plancher incompressible, et tout le reste s'y ajoute : Le temps de trajet physique entre deux machines est le délai minimal que tout jeu en ligne peut avoir. Le routage, le tickrate, le taux de rafraîchissement et le traitement s'y ajoutent tous. Le netcode ne peut pas supprimer ce délai. Il peut seulement décider où les joueurs le ressentent.
Le chemin le plus court est rarement le plus rapide : Une connexion directe en peer-to-peer semble être le trajet le plus court entre deux joueurs, mais les paquets traversent quand même les FAI des deux joueurs et les itinéraires que ces réseaux choisissent. Un serveur bien placé entre eux est souvent à la fois plus rapide et plus équitable.
La compensation de lag déplace le coût, elle ne l'efface pas : La compensation de lag rembobine le serveur pour que le tir d'un joueur à fort ping soit pris en compte, ce qui signifie que la cible peut être touchée après s'être mise à couvert. La seule vraie solution consiste à maintenir de faibles écarts de ping, ce qui en fait autant un problème de matchmaking et de placement de serveur que de netcode.
Le tickrate est un budget temps : Le tickrate d'un serveur définit le nombre de millisecondes dont il dispose pour simuler chaque étape du jeu. Des fréquences plus élevées réduisent le délai et améliorent la détection des tirs, mais consomment plus de CPU et de bande passante. Un serveur qui dépasse son budget saccade pour tout le monde dans la partie.
Deux choix distincts, et non un seul : L'endroit où le jeu s'exécute (peer-to-peer, relais ou serveur dédié) et la manière dont l'état est partagé (lockstep, rollback ou réplication d'état) sont des décisions indépendantes. N'importe quel modèle de synchronisation peut fonctionner sur n'importe quel modèle d'hébergement.
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.
Un mot de notre sponsor (nous-mêmes !)
La majeure partie du lag provient de la distance, non du code. L'Edge Cloud d'Edgegap est un réseau distribué disposant de plus de 615 emplacements disponibles sur demande, garantissant que chaque partie se déroule au meilleur endroit possible pour ses joueurs. Des tests indépendants sur le trafic d'un studio en direct ont mesuré une baisse de 58 % du temps de trajet aller-retour moyen par rapport au cloud public.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
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
,
