Table of Contents
Big Picture Comparison
TCP and UDP are both transport layer protocols that sit above IP. They both use port numbers to deliver data to the right application. The main difference is in how they handle reliability, ordering, and overhead.
TCP is connection oriented and focuses on reliable, ordered delivery. UDP is connectionless and focuses on speed and simplicity, even if some data is lost or arrives out of order.
You will see TCP used when correctness matters more than speed, and UDP when speed and low delay matter more than reliability.
Core Feature Differences
Although both TCP and UDP carry data between applications, they provide very different services.
TCP sets up a connection before data transfer. This uses a handshake so both sides agree on starting sequence numbers and are ready to communicate. Once the connection exists, TCP numbers bytes, keeps track of what has been received, and resends lost data.
UDP sends individual messages called datagrams without creating a formal connection. Each UDP datagram is independent. There is no handshake, and the sender does not track what the receiver got.
The effect is that TCP hides many network problems from the application by fixing them, while UDP exposes those problems to the application, which then decides whether to handle them or ignore them.
Summary Table
| Aspect | TCP | UDP |
|---|---|---|
| Connection model | Connection oriented | Connectionless |
| Reliability | Yes, with retransmissions | No, best effort only |
| Ordering | Guaranteed ordered delivery | No ordering guarantee |
| Congestion control | Yes | No, application must handle if needed |
| Flow control | Yes | No |
| Header size | Larger, more fields | Smaller, fewer fields |
| Speed / latency | Higher overhead, usually slower | Lower overhead, usually faster |
| Typical use cases | Web, email, file transfer, SSH | VoIP, online games, streaming, DNS |
Reliability and Delivery Guarantees
The most important difference is how each protocol treats the data delivery promise.
TCP guarantees that data is delivered reliably and in order, or that the connection fails. It detects lost segments and resends them. It detects duplicates and discards them. It reorders out of order segments before passing data to the application. The application sees a clean byte stream.
UDP makes almost no guarantees. A UDP datagram can be lost, duplicated, or delivered out of order. The network tries to deliver it, but there is no built in correction if something goes wrong. The application receives whatever arrives and must decide what to do.
TCP provides reliable, ordered, and error checked delivery of a byte stream.
UDP provides unreliable, unordered, best effort delivery of individual datagrams.
This difference has a huge impact on application design. Applications that use TCP can be simpler because they rely on the transport layer to correct many errors. Applications that use UDP must either tolerate loss or implement their own reliability logic.
Connection Oriented vs Connectionless
With TCP, a connection is a logical relationship between two endpoints identified by IP addresses and port numbers. The connection has state. Both ends store information about sequence numbers, acknowledgments, and window sizes. This state must be created and later removed.
With UDP, there is no connection state in the protocol itself. The sender just builds a UDP datagram with a source port, destination port, and data, then sends it. The receiver does not need to agree in advance. It simply listens on a port and processes whatever arrives.
From an application viewpoint, a TCP connection often looks like a virtual pipe. Data is pushed in at one end and comes out in the same order at the other end. A UDP interaction is more like mailing individual postcards. Each postcard stands alone, and there is no continuous pipe.
Header Structure and Overhead
TCP and UDP wrap application data differently. Both sit on top of IP, but their headers contain different information.
A simple way to compare is by looking at minimum header sizes.
| Protocol | Typical header size (without options) |
|---|---|
| TCP | 20 bytes |
| UDP | 8 bytes |
UDP has a very small header. It includes source port, destination port, length, and checksum. There are no fields for sequence numbers, acknowledgments, or window sizes.
TCP has more fields because it supports reliability, ordering, and control. It includes source and destination ports, sequence number, acknowledgment number, flags, window size, and more. Options can increase the header size beyond the minimum.
UDP header minimum size: 8 bytes.
TCP header minimum size: 20 bytes.
The larger TCP header increases overhead. For very small messages, this overhead can be significant, especially in applications that send many small packets. UDP keeps overhead low, which can be important for latency sensitive data.
Performance, Latency, and Bandwidth Use
TCP spends extra time and bandwidth to provide reliability and fair use of the network. This improves correctness but can increase delay.
TCP needs a handshake before sending data, which adds at least one round trip time before useful data can flow. TCP also waits for acknowledgments and adapts its sending rate based on network congestion. When packets are lost, TCP resends them and may slow down.
UDP starts sending data immediately, with no handshake. Because it does not track state or wait for acknowledgments, it can achieve lower one way delay. There is no automatic slowdown if the network is overloaded, so the application must be careful not to send more than the network can handle.
For bulk file transfer, the extra delay of TCP is usually acceptable because the main goal is correct delivery. For real time audio or video, missing a packet can be better than waiting to resend it, so many such applications prefer UDP.
It is common for applications to limit their own rate when using UDP, to avoid overwhelming the network and causing loss.
Typical Use Cases and Application Choices
Different types of applications choose TCP or UDP based on what they need most.
TCP is used when accuracy, ordering, and completeness are important. Examples include web browsing, email, remote administration, and file transfers. If an HTTP response arrives with missing data, the page might be broken, so reliability is critical. SSH must not lose characters from commands, and file transfers must deliver exact copies.
UDP is used when timeliness and low overhead matter more than perfect delivery. Examples include live audio and video, online gaming, and voice over IP. Losing a single voice packet is usually better than pausing the call to retransmit. Games often care more about the latest position than about old positions arriving late.
Some protocols like DNS use UDP because queries and responses are small and simple. If a DNS response is lost, the client can just try again. In some cases, DNS can also use TCP when responses are too large or when reliability is more important.
Trade Offs and Design Decisions
Choosing between TCP and UDP is about trade offs. No protocol is universally better. The right choice depends on what the application values most.
If an application needs certainty that every byte arrives and arrives in order, and it can accept some extra delay and overhead, TCP is usually the right choice. If an application values speed and can tolerate some loss, and it is willing to handle reliability or accept errors itself, UDP is a better fit.
Some modern applications use UDP and then build their own custom reliability and congestion control on top. This gives them more control over behavior than standard TCP, but also increases complexity.
The key idea is that TCP hides many network issues and provides a simple ordered stream, at the cost of delay and overhead. UDP removes most of that support, giving the application more responsibility, but enabling very low latency and flexible behavior.