TCP vs UDP, explained through the ports on your own machine

Most explanations of TCP and UDP start with the OSI model and lose you by the third paragraph. This one starts with something you can check on your own Mac in ten seconds.

They are two separate sets of ports

TCP has 65,536 ports. UDP has its own 65,536 ports. They do not share, and they do not collide.

You can prove it. Bind a TCP socket to port 9955 and leave it listening, then bind a UDP socket to 9955 at the same time. Both succeed. The operating system treats them as completely different addresses, because the protocol is part of the address.

This matters in practice when a tool tells you a port is busy and another tells you it is free. They are probably not looking at the same protocol. It is the first thing to check before assuming a tool is lying to you.

What TCP actually gives you

TCP is a conversation with a beginning, a middle and an end.

Before any data moves, the two sides perform a handshake to agree they are both there and ready. After that, TCP guarantees three things: your bytes arrive, they arrive in the order you sent them, and they arrive exactly once. If a packet goes missing, TCP notices and sends it again. If packets arrive out of order, TCP puts them back in order before your program sees them.

All of that costs something. The handshake adds a round trip before the first byte. The ordering guarantee means a single lost packet holds up everything behind it until the retransmission arrives.

For nearly everything you build, that trade is obviously worth it. HTTP, SSH, database connections, your dev server, all TCP.

What UDP gives you instead

UDP sends a packet and stops caring. No handshake, no acknowledgement, no retransmission, no ordering. If it arrives, it arrives. If it does not, nobody tells you.

That sounds useless until you think about a video call. A packet of audio from 400 milliseconds ago is worthless, and stopping the call to wait for it is worse than skipping it. You would rather have a small glitch now than perfect audio that arrives late. Same for live video, online games and most streaming.

DNS is the other classic case. A lookup is one small question and one small answer. Setting up a TCP connection for that is more work than the query itself, so DNS uses UDP by default and falls back to TCP when a response is too large.

Why almost everything you debug locally is TCP

When you are hunting a port conflict, it is nearly always TCP, because the things that conflict are servers, and servers are nearly always TCP.

That is why the standard command carries a TCP filter:

lsof -i -P -n -sTCP:LISTEN

-sTCP:LISTEN keeps only TCP sockets in the LISTEN state. It cuts out established connections and everything UDP, which is what makes the output readable at all.

If you do want to see UDP:

lsof -i udp

You will notice something. UDP sockets have no LISTEN state, and that is not a quirk of the tool. LISTEN is a TCP concept, part of the connection state machine. UDP has no connections, so there is no state to be in. A UDP socket is either bound to a port or it is not.

A rule of thumb for reading your own machine

If you are chasing “port already in use”, assume TCP and use the filtered command. If a port genuinely looks free under TCP but something insists it is taken, check UDP before concluding anything is broken.

And remember the protocol is part of the identity of a port. “Port 5353” is not a complete description. On a Mac, UDP 5353 is mDNS, the thing that makes .local names work, and it is busy on essentially every machine.

We also wrote about what a port actually is and how the ranges are divided, which fill in the rest of this picture.

Bosun lists what is listening on your Mac from the menu bar, with the process, container or tunnel behind each port. macOS 14 or later, 14 day trial, no account.