Every time you load a webpage, send a message, or join a video call, your data has to travel across a huge, chaotic network of cables, routers, and satellites to reach the right destination in the right shape. Left to chance, that data would show up late, out of order, or not at all. So the internet needs rules — agreed-upon ways for two machines to hand data back and forth reliably. Those rules are called protocols, and two of the oldest and most important ones are TCP and UDP.

If you're learning web development, you'll run into both constantly, even if you don't realize it. Understanding what they are, how they differ, and where HTTP fits into the picture will make a lot of other concepts — APIs, WebSockets, streaming, latency — click into place much faster.

What Are TCP and UDP, at a High Level

TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are both transport layer protocols. Their job is to take the data your application wants to send and get it from one device to another over the network. Neither of them cares what's inside the data — that's the application's problem. What they care about is how the data gets delivered.

TCP is built around a simple promise: everything you send will arrive, and it will arrive in the right order. To keep that promise, TCP sets up a connection before sending anything, checks that each piece of data was received, and resends anything that goes missing. It's careful, thorough, and a little slower because of all that checking.

UDP makes no such promise. It just sends the data and moves on. There's no setup, no confirmation, and no resending. If a piece of data doesn't arrive, UDP doesn't know and doesn't care. In exchange for giving up that safety net, UDP is much faster and has far less overhead.

A simple way to picture the difference: TCP is a phone call, and UDP is a public announcement over a loudspeaker.

On a phone call, you and the other person constantly confirm you're following along — "uh-huh," "okay," "wait, can you repeat that?" If the line drops for a second, you notice and pick the conversation back up. Nothing gets missed without both sides knowing about it.

A loudspeaker announcement is different. The person making the announcement just speaks. They don't stop to ask if everyone in the room heard every word. If someone was in the bathroom when their name got called, that's on them — the announcer isn't repeating it. It's fast, it reaches everyone at once, and it doesn't wait for confirmation.

Key Differences Between TCP and UDP

The phone call vs. loudspeaker analogy holds up well once you look at the actual mechanics.

TCP is connection-oriented. Before any real data moves, the two sides perform a "handshake" — a quick back-and-forth where they agree to start talking. UDP is connectionless. There's no handshake; the sender just starts firing off packets (called datagrams) the moment it has something to send.

TCP guarantees reliability. Every packet is tracked, and if one goes missing, TCP notices and asks for it again. UDP offers no such guarantee. Once a datagram is sent, UDP has no way of knowing whether it arrived, and it won't resend it even if it didn't.

TCP also guarantees ordering. Even if packets take different paths across the network and arrive out of sequence, TCP reassembles them in the correct order before handing the data to your application. UDP doesn't bother — datagrams are handed off in whatever order they show up, which might not be the order they were sent in.

All of that reliability comes at a cost: speed and overhead. TCP's handshake, acknowledgments, and reordering logic add delay and extra data to every exchange. UDP skips all of it, which makes it noticeably faster and lighter, especially when you're sending a continuous stream of small packets.

Finally, there's how each one behaves when the network gets congested. TCP has built-in congestion control — if it detects packet loss, it slows itself down to avoid making things worse. UDP has no such mechanism; it keeps sending at whatever rate the application asks for, congestion or not.

When to Use TCP

Reach for TCP whenever losing or scrambling even a small piece of data would break something. If you're building a feature where correctness matters more than raw speed, TCP is almost always the right tool.

That includes anything where the user is exchanging information that needs to be complete and exact: loading a webpage, submitting a form, transferring a file, sending an email, or processing a payment. Imagine downloading a PDF and having a random paragraph missing, or submitting a bank transfer where a digit gets dropped — that's the kind of failure TCP exists to prevent. The extra overhead is a small price to pay for that certainty.

When to Use UDP

Reach for UDP when speed and low latency matter more than perfect delivery, and when losing a small piece of data isn't a big deal because a slightly newer piece is on its way anyway.

This shows up most in real-time media: video calls, live streaming, and online gaming. If one video frame in a call gets dropped, you might see a tiny glitch — but by the time TCP would have finished retransmitting that missing frame, the conversation has already moved on. A late frame is often more disruptive than a missing one. The same logic applies to fast-paced multiplayer games, where a stale position update is worse than a skipped one, and to things like DNS lookups, where a quick retry is cheaper than a full handshake for a tiny request.

Common Real-World Examples of TCP vs UDP

It helps to see this side by side with things you use every day.

Web browsing, email, file downloads, and messaging apps that keep chat history all rely on TCP, because losing a byte of a webpage or a line of an email thread is unacceptable. Online banking and e-commerce checkouts use TCP for the same reason — every transaction detail has to arrive intact.

On the other side, live video streaming, voice and video calls, online multiplayer games, and DNS lookups typically rely on UDP. In each case, a dropped packet is a minor, often invisible hiccup, and waiting for a resend would hurt the experience more than the missing data itself does.

What Is HTTP, and Where Does It Fit?

This is where a lot of beginners get tripped up, so it's worth slowing down here.

HTTP (Hypertext Transfer Protocol) is an application layer protocol. It's not concerned with how data physically travels across the network — that's not its job. Instead, HTTP defines the format and meaning of the messages your browser and a web server exchange: things like "GET me this page," "here's a 200 OK response with some HTML," or "this request failed with a 404."

Think of it this way: TCP and UDP are the delivery system — the mail truck and the roads it drives on. HTTP is the letter itself — the actual content and structure of what's being said, written in a format both sides agree to understand. HTTP doesn't know or care how the letter physically gets from sender to receiver. It just defines what a well-formed letter looks like.

To actually get from your browser to a server and back, that HTTP "letter" needs to be handed to a transport protocol — and that protocol is TCP.

The Relationship Between TCP and HTTP

HTTP runs on top of TCP. When your browser makes a request to a website, here's roughly what happens: your browser first asks TCP to establish a connection with the server. Once that TCP connection is open, your browser sends the actual HTTP request — the "GET /page" message — through it. The server sends its HTTP response back over that same connection, and TCP quietly handles making sure every byte of that response arrives complete and in order.

In other words, HTTP is the message, and TCP is the reliable courier carrying it. HTTP gets to stay simple and readable, focused purely on describing requests and responses, because it trusts TCP to handle all the messy work of actually getting bytes across the network without loss or corruption.

Why HTTP Doesn't Replace TCP

HTTP and TCP solve completely different problems, so one can't substitute for the other. TCP handles how data travels — connections, acknowledgments, retransmission, ordering. HTTP handles what the data means — request methods, headers, status codes, response bodies. Even the newest versions of HTTP still need a transport layer underneath them to actually move bytes across the network; HTTP has never been designed to do that job itself.

This is also a good moment to mention that not every version of HTTP sits directly on TCP. HTTP/3, the newest version, actually runs over a protocol called QUIC, which is itself built on top of UDP rather than TCP — but QUIC rebuilds TCP-like reliability on top of UDP specifically to get both speed and correctness. That's a more advanced topic, but it's worth knowing it exists so you're not surprised by it later. For nearly all web development you'll do day to day, especially early on, HTTP/1.1 and HTTP/2 running over TCP is what you'll actually be working with.

Clearing Up a Common Beginner Confusion: "Is HTTP the Same as TCP?"

No — and this is one of the most common mix-ups when people are first learning how the web works. HTTP and TCP operate at completely different layers of the stack and do completely different jobs.

TCP is a general-purpose transport protocol. It doesn't know or care whether it's carrying a webpage, an email, or a file — it just guarantees reliable, ordered delivery of whatever bytes it's handed. HTTP, on the other hand, is specifically about web communication. It defines requests like GET and POST, response codes like 200 and 404, and headers that describe things like content type — none of which TCP knows or cares about.

A good way to remember the distinction: you could build an entirely different application protocol — say, for email or file transfer — and it could still ride on top of TCP, because TCP doesn't know or care what it's carrying. HTTP is just one of many possible passengers that TCP is willing to carry.

Layering It All Together

Zooming out, here's a simplified picture of how everything stacks:

At the top, the application layer is where HTTP (and protocols like DNS and SMTP) live — this is where the meaning of the data is defined. Below that, the transport layer is where TCP and UDP operate, deciding how that data actually gets moved between two programs. Below that, the internet layer (IP) is responsible for finding a path and getting packets from one machine to another across the network. And at the very bottom, the network access layer handles turning all of this into actual signals sent over a wire or through the air.

Each layer only worries about its own job and trusts the layer below it to do the rest. HTTP trusts TCP to deliver its messages intact. TCP trusts IP to find a path to the destination. And IP trusts the network access layer to actually move the bits. That separation of concerns is what makes it possible for the web to work at all — nobody has to reinvent the whole stack just to build a new application protocol.

Wrapping Up

TCP and UDP are two different answers to the same basic problem: how do you move data across a network that wasn't built to be perfectly reliable? TCP answers with patience and confirmation — it's slower, but nothing gets lost or scrambled. UDP answers with speed — it's faster, but it doesn't look back to check what made it and what didn't.

HTTP sits a layer above both of these, defining what a web request and response actually look like, while leaving the job of physically delivering that data to TCP underneath it. They're not competitors and they're not interchangeable — they're partners, each doing a job the other one isn't built for.

Once that layering clicks, a lot of other web development concepts start making more sense too — why some things load instantly and others stall, why video calls sometimes glitch instead of freeze, and why "the internet" is really just a stack of much simpler protocols, each trusting the one below it to do its part.

TCP vs UDP: When to Use What, and How TCP Relates to HTTP