# TCP vs UDP: Understanding the Two Core Transport Protocols

Every time you load a page, send a message, or join a video call, your data is broken into smaller units, sent across a chain of routers, and reassembled at the other end. None of that works unless the machines involved follow a common set of rules: how to address data, how to detect missing information, and what to do when something goes wrong.

Those rules are part of what’s called the **transport layer** of networking. The internet gives applications several transport options, but two of the most important are **TCP (Transmission Control Protocol)** and **UDP (User Datagram Protocol)**. Much of the internet’s traffic relies on one of these protocols, directly or through another protocol built on top of them.

So, what’s the difference between TCP and UDP, and when does each one make sense? Let’s break it down.

## What Are TCP and UDP?

**TCP** is a connection-oriented protocol. Before application data is exchanged, the endpoints establish a connection through a process called a handshake. TCP uses sequence numbers, acknowledgments, retransmissions, and other mechanisms to provide a reliable, ordered stream of bytes to an application.

Its goal is to deliver data reliably and in order. If some data is lost, TCP can retransmit it. If segments arrive out of order, TCP reorders the data before delivering it to the application.

**UDP** is connectionless. It does not establish a connection before sending datagrams, and it does not provide built-in acknowledgments, retransmissions, or ordering guarantees. An application sends a datagram, and UDP makes a best-effort attempt to deliver it to the destination process. If the datagram is lost, UDP itself does not recover it.

That makes UDP a simpler transport with less protocol overhead. However, applications that need reliability, security, or congestion control may have to implement those features themselves or use a protocol built on top of UDP.

A couple of ways to picture the difference:

| TCP | UDP |
| --- | --- |
| **A phone call:** You establish a connection before talking. Both sides can exchange information, and the communication system works to deliver the data reliably. | **A quick announcement:** You send a message without first establishing a connection or waiting for a built-in acknowledgment. You may not know whether it arrived. |
| **A tracked courier:** Delivery is tracked, and missing data can be sent again. | **A live broadcast:** The message goes out without waiting for every recipient to confirm receipt. |
| **Reliable, ordered byte stream:** Useful when the application needs complete data in sequence. | **Datagrams:** Useful when the application wants to decide how to handle loss, delay, or ordering. |

## TCP vs UDP: What’s the Actual Difference?

Here’s a side-by-side comparison:

| Feature | TCP | UDP |
| --- | --- | --- |
| Connection model | Connection-oriented | Connectionless |
| Delivery guarantee | Reliable delivery provided by TCP | No delivery guarantee |
| Ordering | Delivers bytes in order | No ordering guarantee |
| Acknowledgments | Uses acknowledgments | No built-in acknowledgments |
| Retransmission | Retransmits lost data when needed | No built-in retransmission |
| Data model | Continuous byte stream | Individual datagrams |
| Header size | 20 bytes minimum, without options | 8 bytes |
| Overhead | Generally more protocol overhead | Generally less protocol overhead |
| Common uses | Web traffic with HTTP/1.1 or HTTP/2, SSH, many database connections | DNS queries, real-time traffic, and protocols built over UDP |

**One thing people get wrong:** **TCP is not simply slow, and UDP is not automatically fast.** UDP has less built-in transport overhead, but real-world performance depends on the network, the application, and how much reliability the application needs to add.

## How TCP Works: The Three-Way Handshake

Before TCP endpoints exchange application data, they establish a connection using a process known as the **three-way handshake**.

Imagine your browser needs to establish a TCP connection with a web server. The process looks like this:

1.  **SYN:** Your computer sends a SYN segment to request a connection.
    
2.  **SYN-ACK:** The server responds with SYN-ACK, acknowledging the request and indicating that it is ready to connect.
    
3.  **ACK:** Your computer sends an acknowledgment back to the server.
    

![](https://cdn.hashnode.com/uploads/covers/6968fdf8ef230a1c0a332de9/153eaed8-8341-4624-8c36-682dcc65b624.png align="center")

Once the connection is established, the endpoints can exchange application data.

But what happens if a segment gets lost along the way?

TCP uses sequence numbers, acknowledgments, timers, and retransmission mechanisms to help detect and recover from data loss. It also ensures that the application receives the byte stream in the correct order.

Imagine downloading a PDF file. You need the complete file, not just the parts that happened to arrive. TCP helps deliver a complete, ordered stream of bytes to the application, retransmitting missing data when necessary.

TCP also has flow-control and congestion-control mechanisms. Flow control helps prevent a sender from overwhelming the receiving application, while congestion control helps the sender respond to conditions in the network.

## How UDP Works: No Handshake, No Waiting

UDP takes a different approach.

There is no built-in connection establishment before sending a datagram. An application can prepare a UDP datagram and send it without waiting for the receiver to acknowledge it.

![](https://cdn.hashnode.com/uploads/covers/6968fdf8ef230a1c0a332de9/3206aa28-f88d-4f83-8b32-8db540adf358.png align="center")

The sender does not have to wait for a response after each datagram. This can be useful when **getting fresh information quickly matters more than recovering every lost packet**.

Consider a multiplayer game. Your character is moving across a map, and the game frequently sends updates about your position.

Suppose one position update gets lost. Would you want the game to pause and wait for that old update to be retransmitted?

Probably not. By the time it arrives, your character may already be somewhere else. In many real-time applications, receiving the latest update is more useful than recovering every previous one.

UDP makes this approach possible, although applications can still add their own reliability, sequencing, or congestion-control mechanisms when needed.

Remember: UDP itself does not guarantee that datagrams will arrive, arrive in order, or arrive only once. Applications must account for those possibilities if they matter.

## Where Is TCP Used?

TCP is commonly used when an application needs reliable, ordered delivery.

### 1\. File downloads

When you download a document, the application generally needs the entire file, not just the parts that happened to arrive. TCP provides a reliable, ordered byte stream.

### 2\. Email

Email protocols such as SMTP, IMAP, and POP3 traditionally use TCP to exchange messages reliably.

### 3\. SSH and remote access

When you connect to a remote server using SSH, reliable, ordered communication is important for exchanging commands and their output.

### 4\. Database connections

Many database protocols use TCP to exchange queries and results between applications and database servers.

### 5\. Web traffic

HTTP/1.1 and HTTP/2 typically use TCP as their transport. When you visit a website using HTTPS with these versions of HTTP, TLS protects the application data over the TCP connection.

Modern web traffic is not limited to TCP, though. **HTTP/3 uses QUIC, which runs over UDP** and provides its own connection management, reliability features, and security.

## Where Is UDP Used?

UDP is useful when low overhead, low latency, or application-specific control over delivery is important.

### 1\. Online multiplayer gaming

Games often exchange frequent position, movement, and state updates. For some updates, a fresh value is more useful than retransmitting an outdated one.

### 2\. Voice and video calls

Real-time communication applications need to deliver audio and video with minimal delay. A late audio packet may be less useful than a packet that never arrives.

### 3\. Live streaming

Some real-time streaming systems use UDP-based transport to reduce latency. The exact protocol depends on the streaming technology.

### 4\. DNS lookups

Traditional DNS queries commonly use UDP because a request and response can often be exchanged without establishing a TCP connection. DNS also supports TCP when required, including for certain larger responses and zone transfers.

### 5\. Real-time state synchronization

Applications may use UDP datagrams to send frequent updates while implementing their own strategies for important events, acknowledgments, or recovery.

One more thing: **UDP does not automatically make an application secure or reliable.** Those features must come from the application or another protocol layered above UDP.

## What Happens When You Type `google.com`?

Let's connect this to something you probably do every day.

You type `google.com` into your browser and press Enter. What happens next?

First, your browser needs to resolve the domain name to an IP address. It typically uses a DNS resolver, and traditional DNS queries often use UDP.

Once the address is available, the browser establishes the appropriate connection to Google's server infrastructure.

If the connection uses HTTP/2 over TLS, TCP establishes the transport connection before the browser exchanges protected HTTP data.

If the connection uses HTTP/3, the browser can instead use QUIC over UDP. QUIC handles connection establishment, encryption, reliable streams, and other transport functions itself.

Your request travels through network infrastructure, the server processes it, and the response makes its way back to your browser. The browser then processes the response and renders the webpage.

A simple action like opening a website can involve DNS, IP, a transport protocol, encryption, HTTP, and the browser itself.

That is one example of how multiple networking layers work together.

## Can TCP and UDP Be Used Together?

Absolutely. An application can use both protocols for different purposes, and a device can maintain many TCP connections while also sending UDP datagrams.

Imagine a multiplayer game that has several kinds of traffic:

*   Frequent movement updates may use UDP to keep latency low.
    
*   Login and account operations may use HTTPS over TCP.
    
*   Voice chat may use a real-time communication protocol over UDP.
    

The exact design depends on the game, but the principle is the same: different kinds of data have different requirements.

Some data must arrive correctly. Other data needs to arrive as quickly as possible.

Choosing a transport protocol means understanding those requirements rather than blindly choosing the one that sounds faster.

## So, Which One Should You Choose?

There is no universal winner. The right choice depends on what your application needs.

Choose **TCP** when you need a reliable, ordered byte stream and want the transport layer to handle retransmissions and related mechanisms for you.

Choose **UDP** when datagrams, low overhead, and application-specific control are a good fit for your use case—and when you are prepared to handle any additional reliability requirements yourself.

Keep in mind that UDP does not guarantee lower latency in every situation, and TCP can perform very well on modern networks. The application's design matters just as much as the protocol.

## Final Thoughts

TCP and UDP solve different problems.

TCP prioritizes reliable, ordered delivery. UDP provides a simpler datagram service without built-in delivery guarantees.

Neither protocol is inherently better than the other. They exist because applications have different needs.

The next time you download a file, join a video call, play an online game, or open a website, remember that the data does not simply travel across the internet by magic. Protocols define how devices communicate, and TCP and UDP are two important pieces of that system.