TCP vs UDP: What's the Difference?
TCP is reliable and ordered; UDP is fast and connectionless. Here's how the two transport protocols actually differ, when each is used, and how to tell which one a port is running.
Every open port on your Mac speaks one of two transport protocols: TCP or UDP. They both move data between ports, but they make opposite trade-offs. TCP prioritizes getting every byte there, in order. UDP prioritizes getting it there fast and doesn’t care if a little goes missing.
Here’s what that actually means in practice, and how to tell which protocol a given port is using.
The one-sentence version
- TCP (Transmission Control Protocol): a connection is established first, every packet is acknowledged, and lost packets are resent. Reliable, ordered, slower.
- UDP (User Datagram Protocol): packets are fired off with no handshake and no delivery guarantee. Fast, lightweight, lossy.
How TCP works
TCP opens a connection with a three-way handshake before any real data moves:
- The client sends
SYN(“let’s talk”). - The server replies
SYN-ACK(“sure, I’m here”). - The client sends
ACK(“great, here’s my data”).
Once the connection is up, TCP numbers every segment, waits for the other side to acknowledge each one, and retransmits anything that gets lost. It also handles flow control (don’t overwhelm a slow receiver) and congestion control (back off when the network is busy). The result is a stream where bytes arrive complete and in the order they were sent.
That reliability costs round-trips and overhead, which is why TCP feels “heavier.”
How UDP works
UDP skips all of it. There’s no handshake, no acknowledgment, no retransmission, no ordering. Each datagram is independent: the sender ships it and moves on. If it arrives, great. If it doesn’t, UDP won’t notice or care, that’s the application’s problem to solve (or ignore).
This makes UDP dramatically lower-latency and lower-overhead. For a video call, a packet that arrives 300ms late is useless anyway, so there’s no point waiting for a retransmission. Dropping it and moving on is the correct behavior.
Side-by-side
What uses TCP
Anything where missing or scrambled data breaks the result:
- HTTP and HTTPS (web): ports 80 and 443
- SSH (remote shell): port 22
- SMTP, IMAP, POP3 (email)
- Database connections: PostgreSQL (5432), MySQL (3306), Redis (6379)
- FTP (file transfer): ports 20 and 21
A half-downloaded web page or a database row with missing bytes is useless, so these all use TCP.
What uses UDP
Anything where speed matters more than perfection, or where the app does its own reliability:
- DNS lookups: port 53 (small, fast, one-shot queries)
- DHCP: ports 67 and 68
- VoIP and video calls: real-time audio and video
- Online games: low-latency position updates
- Streaming and QUIC: HTTP/3 runs over UDP, with reliability rebuilt in user space for lower latency than TCP
A common myth: “UDP is just unreliable TCP”
Not quite. UDP isn’t a broken version of TCP, it’s a different tool. Modern protocols like QUIC (which powers HTTP/3) deliberately chose UDP precisely because it gets out of the way, then added their own faster, more flexible reliability layer on top. “Unreliable” at the transport layer doesn’t mean “unreliable” for the user.
How to tell which protocol a port is using
On a Mac, lsof shows the protocol in the NODE column:
sudo lsof -i -n -P | grep LISTEN
node 1421 aaron 23u IPv6 TCP *:3000 (LISTEN)
launchd 142 root 8u IPv4 UDP *:5353
TCP and UDP are spelled out explicitly. You can also filter to one protocol:
# Only TCP listeners
sudo lsof -iTCP -sTCP:LISTEN -n -P
# Only UDP
sudo lsof -iUDP -n -P
Note that UDP sockets don’t have a LISTEN state the way TCP does, UDP is connectionless, so there’s nothing to “listen” for in the TCP sense. That’s why the -sTCP:LISTEN filter only applies to TCP.
See TCP and UDP ports at a glance
Remembering lsof flags to separate the two protocols gets old. Portie shows every open TCP and UDP port on your Mac in one live table, with the protocol labeled on each row, refreshed automatically every 3 seconds. Sort by protocol, port, or process, and click any row for the full connection details.
Local monitoring is free. The $8.99 one-time unlock adds one-click process termination and remote port scanning. Download Portie and stop guessing which protocol a port is speaking.