1 TCP, UDP, and Port Fundamentals

How TCP and UDP deliver data

TCP and UDP are transport-layer protocols that carry data between applications on different devices. They use port numbers to identify the sending and receiving applications.

TCP establishes a connection before exchanging data. It provides a reliable, ordered byte stream: lost data is retransmitted, and received data is acknowledged. Web browsing, email, and remote login commonly use TCP.

UDP sends separate messages called datagrams without first establishing a connection. UDP does not itself guarantee delivery, order, or protection from duplicates. Its lower overhead can suit brief queries, voice or video, and other delay-sensitive traffic; an application can add its own reliability mechanisms if needed.

Neither protocol is universally better. The application's needs determine which is appropriate.

Port numbers and their ranges

A Port number is a 16-bit number ranging from $0$ to $65535$, used with a transport protocol to identify an application endpoint on a device. TCP and UDP maintain separate port-number spaces, so TCP port $53$ and UDP port $53$ are distinct endpoints. A port number identifies a service convention, but it does not guarantee which program is actually using that port.

IANA divides port numbers into three ranges:

• System (well-known): $0$–$1023$, for common, standardized services.

• User (registered): $1024$–$49151$, for registered application services.

• Dynamic/private: $49152$–$65535$, often used for temporary client ports.

Client-server communication

In the usual client-server pattern, the client initiates communication to a server's IP address and service port. The server listens for requests, while the client uses a temporary port so the reply can be directed back to the correct application.

For example, a client might connect from 192.0.2.10:53000 to a web server at 203.0.113.20:443 using TCP. The server's reply travels back to the client's address and port. Together, the source and destination addresses, source and destination ports, and transport protocol distinguish a flow.

With TCP, the endpoints establish a connection before exchanging application data. With UDP, the client sends a datagram to the server; no TCP-style connection handshake is required.

Common services and ports

These common or standard assignments can help identify likely services:

• SSH: TCP port $22$, commonly used for secure remote login and command execution.

• DNS: UDP port $53$ and TCP port $53$, for domain-name lookups; DNS supports both transports.

• HTTP: TCP port $80$, for unencrypted web traffic by default.

• HTTPS: TCP port $443$; HTTP/3 uses QUIC over UDP, commonly on port $443$, for encrypted web traffic.

• DHCP: UDP port $67$ for the server and UDP port $68$ for the client, for automatic address and network-configuration assignment.

• NTP: UDP port $123$, for network time synchronization.

These assignments are not proof of the traffic's actual contents. Services may use other ports, and traffic on a familiar port may not be the expected service. HTTPS is not synonymous with TCP because HTTP/3 uses QUIC over UDP.

Interpreting protocol-and-port pairs

Interpret a service as a transport protocol plus a port number, and use the assignment as a clue about the application.

1. Identify the transport. TCP or UDP changes how the traffic is delivered.

2. Read the port. TCP port $22$ commonly indicates SSH; UDP port $123$ commonly indicates NTP.

3. Check the context. A destination port is often more informative about the intended server service than a temporary client source port.

4. Treat the result as a clue, not a certainty. Ports can be reassigned locally, services can use nonstandard ports, and registered port numbers do not authenticate traffic.

For example, a packet addressed to destination UDP port $53$ is likely DNS traffic. A packet addressed to destination TCP port $53$ may also be DNS; the port number alone does not reveal which query or response is being carried.