UDP 对比 TCP
UDP 和 TCP 是游戏可以选择的两种传输协议。TCP 保证每个数据包都按顺序到达，并在丢失的数据包被重新发送之前，阻断其后的所有数据。UDP 则两者都不保证，因此丢失的数据包就直接消失了，游戏继续进行。实时游戏使用 UDP，因为过期的数据比丢失的数据更糟糕。
又称
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.
实践中 - 来自 Edgegap 博客的见解
文章的核心洞察
延迟存在下限，其他一切因素都在其之上累加：两台机器之间的物理传输时间是任何网络游戏所能拥有的最小延迟。路由、Tick率、更新率以及处理过程都会增加延迟。网络代码无法消除这种延迟，它只能决定玩家在何处感受到它。
最短路径很少是最快的：直接的P2P（点对点）连接看起来是两名玩家之间的最短路线，但数据包仍需经过两名玩家的互联网服务提供商（ISP）以及这些网络所选择的任何路由。在他们之间设立一个位置合理的服务器，往往既更快又更公平。
延迟补偿转移了代价，而不是消除了代价：延迟补偿会回溯服务器状态，以使高Ping玩家的射击有效，这意味着目标在到达掩体后仍可能被击中。唯一的真正解决办法是缩小Ping值差距，这使得它既是一个网络代码问题，也是一个匹配机制和服务器部署问题。
Tick率就是时间预算：服务器的Tick率设定了它模拟游戏每个步骤所拥有的毫秒数。更高的速率可以减少延迟并提高命中判定精度，但会消耗更多的CPU和带宽。超出预算的服务器会导致对局中的每个人都发生卡顿。
这是两个独立的选择，而非一个：游戏在哪里运行（P2P、中继或专用服务器）与状态如何共享（锁步同步、回滚同步或状态复制）是相互独立的决策。任何同步模型都可以在任何托管模型上运行。
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.
来自我们的赞助商（其实就是我们自己！）的寄语
大多数延迟来自距离，而非代码。Edgegap 的边缘云是一个分布式网络，按需提供高达 615+ 个可用位置，因此每场比赛都能在最适合玩家的可用位置运行。对直播工作室流量的独立重放测试表明，与公共云相比，平均往返时间减少了 58%。
Edgegap 的观点（仅代表个人意见，姑且听之即可！）
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
，
