Ports, TCP, and UDP

Why it matters

An IP address gets data to the right computer, but a server runs many programs at once: a web server, an SSH server, maybe a database. Ports get data to the right program. Choosing between TCP and UDP decides whether that data arrives reliably or quickly. Firewall rules, cloud security groups and "connection refused" errors are all about ports.

Ports

A port is a 16-bit number (0 to 65535) at the transport layer. A connection is identified by five things: protocol, source IP, source port, destination IP, destination port.

• Well-known ports (0 to 1023) are used by standard services.
• Registered ports (1024 to 49151) are used by many applications, such as databases.
• Ephemeral ports (usually 49152 to 65535) are picked at random by your computer for the client side of a connection.

Ports worth memorising:

IANA keeps the official registry, but a port number is only a convention: you can run a web server on 8080. What matters is that client and server agree.

TCP: reliable, ordered, connection-based

TCP sets up a connection before sending data, with a three-way handshake:

1. Client sends SYN ("I want to connect, my sequence number starts at x").
2. Server replies SYN-ACK.
3. Client sends ACK. The connection is open.

After that, TCP numbers every byte, the receiver acknowledges what it got, and anything lost is resent. TCP also puts data back in order and slows down when the network is congested (flow and congestion control). The cost is extra round trips and waiting: one lost packet holds up everything behind it.

Use TCP when every byte must arrive: web pages, file transfers, email, SSH, database queries.

UDP: fast, simple, connectionless

UDP just sends datagrams. There is no handshake, no acknowledgement, no resending and no ordering. Its header is 8 bytes versus TCP's 20 or more.

UDP beats TCP when:

• Late data is useless. In a video call or online game, a resent packet from half a second ago is worse than a small glitch.
• Messages are tiny. A DNS question fits in one packet; a handshake would triple the time.
• The application handles reliability itself. QUIC, the protocol under HTTP/3, runs on UDP and adds its own faster reliability.

Worked example: two connections at once

You open two browser tabs to the same site. Your laptop (192.168.1.20) creates two TCP connections:

192.168.1.20:52814  ->  93.184.215.14:443
192.168.1.20:52815  ->  93.184.215.14:443

The server tells them apart by the source port. Meanwhile your laptop asks DNS a question over UDP:

192.168.1.20:61002  ->  192.168.1.1:53   (UDP)

Listening, open and closed

A server program listens on a port. If you connect to a port where nothing listens, the computer answers TCP with a reset and you see "connection refused". If a firewall silently drops the traffic, you see a timeout instead. That difference is a useful clue: refused means you reached the machine; timeout often means a firewall or routing problem.

Common mistakes

• Opening more ports than needed. Every listening port is attack surface. Expose only what a service needs, and only to the networks that need it (for example, a database port only to the app servers, never to the whole internet).
• Assuming DNS is UDP only. Large responses and zone transfers use TCP 53.
• Calling UDP "unreliable" as if it were broken. It is simply best-effort; for real-time traffic that is the right trade.
• Confusing the port with the protocol. HTTPS is usually on 443, but a port number does not guarantee what is running there.

Quick recap

• Ports (0 to 65535) deliver data to the right program; clients use random ephemeral ports.
• TCP: handshake, acknowledgements, retransmission, ordering. Reliable but slower.
• UDP: no handshake or retransmission. Fast and light, good for DNS, voice, video and games.
• "Refused" vs "timed out" tells you whether you reached the host.