TCP gives an application a reliable, ordered stream of bytes: lost packets are resent, duplicates dropped and everything arrives in the order it was sent. UDP just sends individual datagrams and promises nothing: they may arrive late, out of order, twice or not at all. Choose TCP when every byte must arrive intact (web pages, file transfers, email, SSH); choose UDP when a late packet is worthless anyway (voice, video calls, games) or when the application wants to build its own reliability, as QUIC does.
At a glance
| Property | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented: three-way handshake (SYN, SYN-ACK, ACK) before data |
Connectionless: the first datagram can carry data |
| Delivery | Guaranteed: lost segments are retransmitted | Best effort: lost datagrams are simply gone |
| Ordering | Bytes delivered in the order sent | No ordering; datagrams can arrive in any order |
| Data model | A continuous byte stream with no message boundaries | Discrete messages; each send is one datagram |
| Header size | 20 bytes minimum, up to 60 with options | 8 bytes, always |
| Flow and congestion control | Yes: slows down when the receiver or network is overloaded | None built in; the application must behave |
| Broadcast and multicast | No, one-to-one only | Yes |
| Head-of-line blocking | Yes: one lost segment stalls everything behind it | No |
| Typical uses | HTTP/1.1 and HTTP/2, TLS, SSH, SMTP, IMAP, FTP | DNS queries, DHCP, NTP, SNMP, VoIP/RTP, games, QUIC (HTTP/3), WireGuard |
Both protocols use 16-bit port numbers (0 to 65535), but the two port spaces are separate: TCP port 53 and UDP port 53 are different endpoints. Look up what normally runs on a port with the Port Number Lookup.
TCP
TCP turns an unreliable network into something that behaves like a pipe. Every byte has a sequence number, the receiver acknowledges what it got, and anything not acknowledged in time is sent again. A sliding window stops a fast sender from overwhelming a slow receiver, and congestion control backs off when the network itself drops packets.
That reliability has a price. A new connection costs one round trip for the handshake before any data moves (plus the TLS handshake on top for HTTPS), and a single lost segment holds up all the data behind it until the retransmission arrives. On a link with 100 ms round trips, that is noticeable.
Choose TCP when:
- Every byte matters and order matters: web pages, APIs, downloads, database connections, email, remote shells.
- You want the operating system to handle retransmission, pacing and congestion for you.
- Firewalls and middleboxes must pass the traffic without special treatment; TCP is the safest default.
UDP
UDP adds almost nothing to IP: source port, destination port, length and checksum. A datagram either arrives whole or not at all; the protocol never splits or merges messages. A single UDP datagram over IPv4 can carry at most 65,507 bytes of data, but anything larger than the path MTU (often about 1,500 bytes on Ethernet) is fragmented by IP, and losing any fragment loses the whole datagram, so real applications keep datagrams small.
Choose UDP when:
- Freshness beats completeness: in a voice or video call, a packet that arrives 300 ms late is useless, so resending it only adds delay.
- The exchange is one small request and one small reply (DNS, NTP), where a handshake would double the cost.
- You need broadcast or multicast, as DHCP does to find a server it does not know yet.
- You are building your own transport on top. QUIC, the basis of HTTP/3, runs over UDP so it can avoid head-of-line blocking between streams and evolve without waiting for operating-system TCP stacks.
Which should you choose?
- Default to TCP unless you have a specific reason not to.
- Real-time media, games, telemetry where old data is worthless: UDP.
- Tiny request/response lookups: UDP, with a TCP fallback for large answers (exactly what DNS does).
- You want modern web performance without designing a protocol: use HTTP/3 or a QUIC library rather than raw UDP.
- Opening firewall rules: specify the protocol as well as the port; allowing TCP 443 does not allow UDP 443. The TCP/UDP Port Range Generator writes the rules for both.
To see the difference on the wire, capture some traffic and open it in PCAP Forensics: TCP conversations show the handshake, acknowledgements and retransmissions, while UDP flows are just a series of independent datagrams.