Game protocols, how Minecraft, Valve, and Steam relay traffic work differently

The high-level story: games move data between players and servers. The actual protocols games use differ wildly in design, with consequences for how games feel and how they're hosted.

This article tours the protocols of several major games, comparing approaches.

The basic question

When designing a game's networking, the architect chooses:

• TCP or UDP as transport.
• Authoritative server or peer-to-peer.
• Push or pull for state updates.
• Custom protocol or library (RakNet, ENet, custom).
• Reliability model (everything reliable, partial reliability, no reliability).
• Encryption (none, TLS-like, custom, partial).

Different choices produce different feel. A game with bad latency tolerance might be unplayable at 100ms ping. A game with good prediction can feel fine at 200ms.

Minecraft Java

The most-popular game we cover. Network design:

Transport: TCP. Unusual for a real-time game. TCP's reliability and ordering have specific costs (head-of-line blocking under loss).

Authoritative server. The server is the source of truth. Client predicts but server decides.

Push from server. Server sends world updates to clients on each tick (20 times per second).

No native encryption. The protocol is unencrypted by default. Some plugins add TLS-like protection. Hosting providers sometimes use TCP-level proxying.

Compression. Packets are compressed (zlib) above a configurable threshold.

Why TCP? Mojang's Java codebase predates many UDP-based game frameworks. Minecraft's design tolerates TCP's overhead in exchange for simpler implementation. The result: Minecraft can feel laggy on poor networks where a UDP-based game would feel fine.

For hosting: TCP port 25565. Simple to forward, simple to proxy, simple to load-balance for cluster setups.

Minecraft Bedrock

The other Minecraft. Different protocol:

Transport: UDP (via RakNet). RakNet is a real-time game networking library originally written by Jenkins Software. Bedrock uses it.

Reliability on top of UDP. RakNet provides selective reliability: critical packets are reliable, frequent updates aren't.

Lower latency feel. UDP-based design tolerates network issues better than Minecraft Java.

For hosting: UDP port 19132. Forwarding is similar but UDP. Some networks block UDP more aggressively than TCP.

Note: Bedrock's protocol differs enough from Java that they can't directly interoperate. The Geyser bridge (covered in earlier articles) translates between them for cross-play.

Valve Source Engine games

Counter-Strike, Team Fortress 2, Half-Life 2 multiplayer, Garry's Mod, etc.

Transport: UDP. Standard for action games.

Authoritative server, lag-compensated. Server runs the simulation, clients send inputs, server reconciles with knowledge of each player's latency.

Tick rate: 64 to 128 Hz. Higher than Minecraft. More updates per second; better feel.

Client-side prediction. Standard.

Steam authentication. Server checks that connecting players have legitimate Steam accounts (anti-cheat-adjacent).

For hosting: UDP 27015 typically. Often multiple ports (game, query, RCON each on different ports).

Source-engine games are known for "fair" netcode at modest pings. Counter-Strike has been competitively playable at 60-80ms ping for two decades.

Modern Valve games (CS2, Counter-Strike 2)

Built on Source 2 engine, released 2023. Updates the Source-engine networking:

• 128 Hz tick rate.
• Subtick processing (player actions are time-stamped within ticks for sub-tick precision).
• Steam Datagram Relay as standard transport.
• Improvements to lag compensation.

The result: a game that feels precise at modest ping, with hits registering accurately even when network conditions are imperfect.

For hosting: Steam Datagram Relay (SDR) is the recommended transport. Servers don't directly expose IPs; players reach them via Valve's network.

Steam Datagram Relay

Worth a deeper look, because SDR shapes hosting for many modern Steam games.

What it is: Valve operates a network of relay servers worldwide. Game traffic between players and servers goes through SDR's relay closest to each side.

Why:

• Hides server IPs (DDoS protection).
• Routes traffic via Valve's network (often better paths than the public internet).
• Reduces hosting complexity (servers don't need public IPs).

How it works (simplified):

• Server registers with SDR.
• Players connect to SDR's nearest relay.
• Relay forwards traffic to/from the server.
• Latency: server-to-relay + relay-to-relay + relay-to-player.

Cost: Free for Steam games. Valve absorbs the cost as part of the Steam platform.

For game hosting on Steam-based games that support SDR: SDR removes the "make my server reachable" problem entirely. The server just needs outbound Internet.

Valheim

A casual co-op survival game. Network design:

Transport: UDP. Player authority: the host has authority. Players who join are clients.

Network library: Steamworks API for matchmaking; direct UDP for game traffic.

Reliability: mixed. Critical events reliable; high-frequency updates not.

Performance: generally good for small groups. Degrades past ~10 simultaneous players.

For hosting: UDP 2456, 2457, 2458. Three consecutive ports.

Valheim's network shines at small scale and struggles at larger. The engine wasn't designed for big groups; the protocol reflects that.

Vintage Story

A Minecraft-likeoid.

Transport: UDP. Unlike Java Minecraft.

Authoritative server.

Reliability layer: custom, on top of UDP.

Latency tolerance: decent. Better than Java Minecraft on poor networks for this reason.

For hosting: UDP 42420.

VS's choice of UDP gives it real-time feel that Java Minecraft lacks. Tradeoff: more complex implementation.

Eco

A simulation game with deeper backend.

Transport: TCP-based.

Authoritative server.

Backend complexity: Eco has substantial server-side simulation (economy, biome, politics) that requires the server to do real work. Network traffic is moderate but server compute is significant.

For hosting: TCP ports configurable; default 3000.

Eco's networking isn't optimized for real-time tightness because the gameplay isn't really real-time-tight. It's optimized for reliable transport of complex state.

Modern AAA online games

Fortnite, Apex Legends, Warzone, etc. Vary widely. General patterns:

• Custom UDP protocols. Often built on engines like Unreal (which has its own networking).
• Authoritative servers with sophisticated lag compensation.
• High tick rates (60 Hz often, up to 120 Hz for competitive).
• Encryption typically present for anti-cheat and integrity.
• Anti-cheat integration at the network layer (detecting modified clients, etc.).

For hosting (which is usually done by the game's publisher, not players): massive infrastructure, regional servers, sophisticated matchmaking, integration with anti-cheat.

Web-based games

Games running in browsers, often via WebSocket or WebRTC:

• WebSocket: TCP-based, real-time messaging. Used by many browser games.
• WebRTC data channels: UDP-based, can use SCTP for reliability options. Used by browser games needing low-latency real-time.

These have their own tradeoffs (browser-specific overheads, fewer privileged operations). Browser games are increasingly capable; some compete with native games on netcode.

Anti-cheat and network protocols

Modern games often integrate anti-cheat into their protocols:

• Encrypted client-server communication prevents middle-actors from manipulating data.
• Signed inputs prevent some forms of input injection.
• Server-side validation of physics and actions catches client-side cheating.
• Heuristics on packet patterns detect impossible inputs.

Anti-cheat at the network layer is complementary to client-side anti-cheat (BattlEye, Easy Anti-Cheat, kernel-mode protections). Together they make cheating harder.

For game hosting: anti-cheat is usually a black box. The host provides the network; the game's anti-cheat does its thing.

Protocol implications for hosting

Different protocols have different operational characteristics:

TCP-based games: straightforward to proxy, load-balance, log. Connection state visible at TCP layer. Easy DDoS mitigation patterns (SYN cookies, rate limits).

UDP-based games: harder to proxy classically. Different DDoS patterns (volumetric attacks dominate). Per-game tooling often necessary.

SDR-using games: server doesn't need public IP. Massively simplifies hosting. Limited to Steam games.

WebRTC-using games: signaling via HTTPS, media via UDP. Different from traditional game networking.

When evaluating hosting for a specific game, the protocol shapes what hosting features matter.

Network design patterns in games

A few recurring patterns:

Authoritative dedicated server. Server is truth. Players send inputs; receive state. Most modern competitive games.

Authoritative host. One player's machine is the "host." Other players connect to them. Friendlier for casual play, terrible if host has bad network.

Pure P2P. No central authority. Players negotiate state. Hard to keep fair; rare in modern competitive games. Used in fighting games' "delay-based netcode" and some legacy designs.

Hybrid (rollback). Used in modern fighting games. Players predict opponent inputs, rollback if wrong. Allows very low effective latency at the cost of complex implementation.

Each has tradeoffs. Modern AAA games are almost universally authoritative-dedicated-server. Indie and casual games span more variety.

Conclusion

Games don't all do networking the same way. The protocol choices made by the game's designers shape:

• How the game feels at various latencies.
• How easy it is to host.
• What hosting requires (TCP/UDP, ports, etc.).
• How DDoS-resilient the game is.
• How cheating-resistant the game is.

For players: knowing what protocol a game uses helps explain why it feels the way it does.

For hosting: knowing the protocol determines what your hosting infrastructure needs to look like.

For developers: protocol choices made early are hard to change. Pick carefully.

Coming up

Next: authoritative servers vs peer-to-peer, the architectural choice underneath most game networking.