Why You Die Behind Cover: The Networking Secret Hiding in Every Online Game

You sprint behind a wall in PUBG. You're safe. You can see the wall on your screen, you're clearly tucked behind it — and then you're dead. The kill cam shows your enemy shooting you while you were still out in the open. You curse the game, the server, your internet, maybe the laws of physics.

It turns out the real culprit is a design decision made decades ago, baked into the protocol that almost every fast-paced online game relies on. Understanding it doesn't just explain your frustrating deaths — it's a window into one of the most important trade-offs in all of computing.

The "I'd rather be fast than perfect" protocol

Most real-time games send your data over UDP (User Datagram Protocol). UDP has one defining personality trait: it fires packets at the server and never looks back. There's no confirmation, no receipt, no "did you get that?" If a packet carrying your latest position gets lost somewhere along the way, UDP doesn't resend it. It doesn't even notice. It just keeps sending the next one.

So picture the moment you duck behind cover. Your game client fires off a packet: "I'm behind the wall now." But that packet gets dropped — maybe a momentary blip on your connection, maybe congestion somewhere on the route. The server never receives the update. As far as the server is concerned, you're still standing in the open. Your enemy fires, the server confirms the hit against the last position it knew about, and you die.

On your screen you were safe. On the server — the version of reality that actually counts — you never moved. The discrepancy is the lag, and the lag is UDP doing exactly what it was designed to do: prioritize speed over certainty.

This sounds like a flaw, but it's a feature. In a shooter, slightly stale data is annoying. Slow data is unplayable. A protocol that paused the entire game to recover one lost position packet would feel far worse than the occasional death behind cover.

TCP vs. UDP: reliable versus fast

To appreciate why games choose UDP, you have to meet its more careful sibling.

TCP (Transmission Control Protocol) is the reliable one. Before it sends anything, it establishes a connection through a three-way handshake — a little back-and-forth where both sides agree they're ready to talk. From then on, every packet is tracked. If something gets lost, TCP detects the gap and resends it. It guarantees that your data arrives complete and in the correct order.

That reliability is non-negotiable for a whole class of applications. When you transfer your bank balance, request a file, or load a webpage, you cannot tolerate missing bytes. A bank transaction that drops half its data isn't "a little laggy" — it's broken. TCP is the protocol you want whenever correctness matters more than milliseconds.

UDP flips the priorities. No handshake, no tracking, no retransmission. It's lean and fast, which makes it ideal for anything live: voice and video calls, real-time gaming, streaming. In a video call, if you lost a fraction of a second of audio, you'd rather the conversation keep flowing than freeze while the system hunts down a lost packet. By the time it recovered that audio, the moment would be gone anyway. Fresh-but-imperfect beats perfect-but-late.

The mental model is simple: TCP is registered mail with a signature on delivery. UDP is shouting across a crowded room. One guarantees the message arrives intact; the other gets it out instantly and accepts that a word might get lost in the noise.

Where it gets interesting: the problems engineers actually fight

Once you understand the core trade-off, a whole layer of real-world engineering opens up.

Head-of-line blocking

TCP's strict ordering has a nasty side effect called head-of-line blocking. Because TCP insists on delivering data in order, a single lost packet stalls everything behind it. Imagine a checkout line where one person can't find their wallet, and the rule is that nobody can pay until they do — even though everyone else is ready. The whole line freezes for one straggler.

This was a genuine performance ceiling for the modern web, where a page might be loading dozens of resources at once. One dropped packet on one resource could hold up all the others.

The solution was QUIC, the transport protocol underneath HTTP/3. QUIC pulls off a clever trick: it runs on top of UDP — inheriting its speed and freedom from forced ordering — but builds its own reliability layer on top, with independent streams that don't block each other. A lost packet on one stream no longer freezes the rest. It's the best of both worlds: UDP's "no waiting in line" combined with custom-built reliability where it's needed.

Connection pooling

Remember TCP's handshake? It's reliable, but it isn't free. Setting up a connection costs time and resources, and if your server opens a brand-new connection for every single request, that overhead piles up fast.

Connection pooling fixes this by reusing existing connections instead of constantly tearing them down and rebuilding them. Think of a taxi stand at an airport: instead of every passenger calling a car from scratch and waiting for it to drive over, there's a line of cabs already idling, ready to go the moment you walk up. The difference in throughput is enormous — pooling can take a server from handling something like 5,000 requests to 50,000, simply by eliminating wasted setup work.

Socket exhaustion

This is the production bug that catches teams off guard. Socket exhaustion happens when an application opens a new connection for every request and never properly reuses them. Connections linger in the background, the available pool of network sockets drains, and eventually new requests fail entirely — often under exactly the heavy load you most needed to survive.

The fix is to stop hand-rolling connections per request and lean on the tools built for the job, such as an HTTP client factory that manages and recycles connections for you. It's a small architectural choice that quietly prevents a category of 3 a.m. outages.

A quick word on security

A common misconception is that one protocol is "more secure" than another. It isn't. Security isn't a property of TCP or UDP themselves — both happily transmit whatever you hand them, encrypted or not.

Security comes from a layer added on top: encryption. For TCP, that layer is TLS (the S in HTTPS). For UDP, the equivalent is DTLS. The transport protocol decides how your data travels; encryption decides whether anyone can read it along the way. Those are separate concerns, and good systems address both.

The decision framework: the "RFC" rule

So how do you actually choose? There's a memorable shortcut — and the fact that it spells RFC is a nice in-joke, since "Request for Comments" is the name for the very documents that define these protocols.

Boil the choice down to two questions:

• Reliability — Can you afford to lose data? If the answer is no — banking, file transfers, anything where a missing byte means a broken result — reach for TCP.
• Freshness — Do you need the data this instant? If the answer is yes — live calls, streaming, gaming, anything where late data is worthless data — reach for UDP.

Most of the time those two questions point you straight to an answer. And when you genuinely need both speed and reliability, that's exactly the gap newer protocols like QUIC were invented to fill.

The takeaway

The next time you die behind cover, you can be annoyed with a little more sophistication. That death isn't a bug — it's the visible edge of a deliberate trade-off. The game chose speed over certainty because, for a shooter, that's the right call almost every time.

That same trade-off — do I need this to be correct, or do I need it right now? — runs underneath the entire internet. Banks lean one way, video calls lean the other, and an entire field of engineering exists to bend the rules and get a little more of both. Understanding which way to lean, and why, is one of the quietly fundamental skills in building anything that talks over a network.