TCP vs UDP Explained: Key Differences and Use Cases

What You’ll Learn

• The practical difference between a byte stream and a datagram.
• What TCP reliability actually does for an application.
• What UDP leaves for the application to decide.
• Why UDP is not automatically “faster” in every situation.
• How ports and sockets fit both protocols.
• How to inspect TCP and UDP sockets on Linux safely.

TCP vs UDP: Start with the Promise

The easiest way to understand TCP vs UDP is to stop thinking about famous port numbers for a moment. Both protocols sit above IP and below application protocols. IP moves packets between hosts. TCP or UDP determines what kind of delivery service an application receives.

TCP promises an ordered stream of bytes. If an application writes data in a particular order, the receiving application reads that stream in the same order. When network loss occurs, TCP can retransmit missing data before presenting the completed sequence.

UDP promises much less. An application gives UDP one message, called a datagram, and UDP sends it toward a destination address and port. That datagram may arrive, arrive more than once, arrive after another datagram, or fail to arrive. The receiving application gets separate messages rather than one continuous stream.

This model builds on two earlier lessons: IP addresses identify hosts and interfaces, while ports and sockets identify application endpoints.

How TCP Works

Before normal application data flows, TCP establishes state at both endpoints. The familiar three-way handshake exchanges SYN and ACK information so each side can initialize sequence tracking and confirm that the path works in both directions.

After the connection is established, TCP uses sequence numbers to place bytes correctly and acknowledgments to track progress. If data appears to be missing, the sender can retransmit it. TCP also uses flow control so a fast sender does not overwhelm a slower receiver, and congestion control so it responds to conditions on the network path.

The application does not normally manage those individual segments. It reads and writes a stream. That abstraction is useful, but it has one important consequence: TCP does not preserve application message boundaries. If an application writes two pieces of data, the receiver might read them together or in smaller parts. The application protocol still needs a way to frame its own messages.

How UDP Works

UDP does not perform a TCP-style handshake before sending application data. Its header carries source and destination ports, the datagram length, and a checksum. The protocol preserves each datagram as a distinct message, but it does not acknowledge delivery or reorder messages for the application.

This smaller contract is useful when old information quickly loses value. During a voice call, a delayed audio fragment may be less useful than the next live fragment. In a game, the newest position update may matter more than an older one that was lost. A DNS query is small enough that the client can retry if a response does not arrive.

That does not mean applications using UDP must be unreliable. An application can add acknowledgments, retransmission, ordering, encryption, or congestion control when it needs them. QUIC, the transport used by HTTP/3, runs over UDP and implements reliable streams and congestion control above it.

TCP vs UDP Comparison

Is UDP Faster Than TCP?

UDP has a smaller header and does not require TCP’s connection setup, acknowledgment, retransmission, and ordering machinery. That can reduce protocol work and avoid waiting for recovery when an application prefers fresh data.

But “UDP is faster” is too broad to be useful. Performance also depends on network latency, loss, congestion, packet size, application design, encryption, server capacity, and how much reliability the application adds. A poorly designed UDP protocol can perform worse than a mature TCP implementation.

The real question is: what should happen when data is delayed or lost? TCP usually waits and repairs the ordered stream. A UDP application can ignore the loss, retry one transaction, replace old state with new state, or implement its own recovery rules.

When Applications Choose TCP or UDP

These examples are common patterns, not permanent assignments. DNS normally begins with UDP for ordinary queries but can use TCP in defined situations. Modern HTTP/3 uses QUIC over UDP, while earlier HTTP versions normally use TCP. An application’s name alone does not prove which transport a particular connection is using.

A practical decision sequence

1. Decide whether every byte must arrive and remain in order.
2. Decide whether old data is still valuable after a delay.
3. Determine whether the application already implements recovery and congestion control.
4. Check network and firewall requirements for the actual protocol in use.
5. Measure the complete application behavior rather than comparing header sizes alone.

Ports, Sockets, and the Same Number

TCP and UDP have separate port-number spaces. TCP port 53 and UDP port 53 are different transport endpoints even though both are associated with DNS. A firewall rule that permits TCP on a port does not automatically permit UDP on the same number.

A socket combines the transport protocol with local and remote addressing information. A listening TCP socket waits for connection attempts. A UDP socket can receive datagrams without creating one accepted socket per remote peer in the TCP sense.

# Show listening TCP sockets without resolving names
ss -lnt

# Show listening UDP sockets without resolving names
ss -lnu

The option letters are useful to read rather than memorize blindly: -l selects listening sockets, -n keeps addresses and ports numeric, -t selects TCP, and -u selects UDP.

Mini Lab: Inspect TCP and UDP on Linux

ss -lnt

ss -lnu

ss -nt

getent services domain
getent services ssh

Common TCP and UDP Mistakes

Knowledge Check

Continue Learning

• What Is TCP? How Reliable Network Connections Actually Work
• What Is a Port? TCP and UDP Ports Explained for Beginners
• Ports and Sockets Explained: How Network Applications Communicate
• Linux Firewall Explained: How Firewall Rules Control Network Traffic

Official References

• RFC 9293: Transmission Control Protocol (TCP)
• RFC 768: User Datagram Protocol
• RFC 9000: QUIC — A UDP-Based Multiplexed and Secure Transport
• Linux manual: tcp(7)
• Linux manual: udp(7)
• IANA Service Name and Transport Protocol Port Number Registry