TCP and UDP Explained: Ports, Services, and the TCP Handshake
TCP and UDP are the two most common transport protocols on the internet, and port numbers are how services on the same host stay separated from each other. If you want to understand how web servers, SSH, SMTP, or custom applications are exposed and monitored, you need the basics of TCP, UDP, ports, and the TCP three-way handshake.
What TCP and UDP actually are
TCP, or Transmission Control Protocol, is designed for reliable communication. It establishes a connection, keeps packets in order, retransmits missing data, and makes sure both sides agree on the state of the exchange. That is why TCP is commonly used for websites, APIs, SSH, databases, and mail delivery.
UDP, or User Datagram Protocol, is much lighter. It sends datagrams without setting up a connection first and without built-in retransmission or ordering guarantees. That makes UDP useful for DNS queries, streaming, VoIP, online gaming, and other situations where low latency matters more than perfect delivery.
When the TCP vs UDP difference matters
You are troubleshooting service reachability
A TCP service may fail because the port is closed, filtered, or the application is not listening. A UDP service behaves differently because there is no formal connection setup to confirm readiness in the same way.
You are choosing a protocol for an application
TCP is usually the default when correctness and ordered delivery matter. UDP is chosen when speed, low overhead, or real-time behavior matter more than retransmission.
You need to understand firewall and port rules
The same port number can exist separately for TCP and UDP. For example, a firewall rule may allow TCP 443 but block UDP 443, which changes how traffic behaves.
You want to monitor service availability
For many infrastructure and application checks, testing whether a TCP port accepts a connection is one of the clearest indicators that the service endpoint is reachable and listening.
How the TCP three-way handshake works
The client sends SYN
A TCP connection starts when the client sends a SYN packet to the target port. This means it wants to open a connection and begin a session.
The server replies with SYN-ACK
If the port is open and the service is listening, the server answers with SYN-ACK. This acknowledges the request and signals that the server is ready to continue.
The client sends ACK
The client confirms with an ACK packet. At that point, the TCP connection is established and application data can start flowing.
If the handshake fails, the service may be closed or filtered
A refused connection, timeout, or missing reply often means the target port is closed, blocked by a firewall, or the service is not available on that endpoint.
How to think about ports and common services
A port number identifies the service on a host that should receive incoming traffic. Here are a few common examples:
22 SSH Remote shell and secure administration 25 SMTP Mail transfer between servers 53 DNS Domain name resolution 80 HTTP Unencrypted web traffic 443 HTTPS Encrypted web traffic over TLS 587 SMTP Mail submission from clients
Port 22
SSH uses TCP 22 for secure remote administration, command-line access, and automation.
Port 25 and 587
SMTP commonly uses TCP 25 for server-to-server mail transfer and TCP 587 for authenticated mail submission by clients.
Port 80 and 443
HTTP usually runs on TCP 80, while HTTPS runs on TCP 443. These are the most familiar web service ports.
TCP vs UDP on the same number
A port number by itself is not enough. TCP 53 and UDP 53 are both DNS-related, but they are still different transport paths with different behavior.
Why ports do not always behave the same way
An open TCP port usually means a service is actively listening and willing to complete a handshake. A closed port may reject the connection immediately, while a filtered port may simply time out.
UDP is harder to validate because there is no built-in handshake equivalent. A UDP service may be working even when you do not get a direct response to a simple probe, depending on the protocol and application behavior.
TCP vs UDP
| Topic | TCP | UDP |
|---|---|---|
| Connection model | Connection-oriented, with handshake before data transfer. | Connectionless, with no handshake before sending data. |
| Reliability | Provides retransmission, ordering, and delivery tracking. | Does not guarantee delivery, ordering, or retransmission. |
| Best for | Web apps, APIs, SSH, databases, email, and predictable service sessions. | DNS, streaming, gaming, VoIP, and latency-sensitive traffic. |
Need a quick latency and reachability check too?
Ping helps you test basic host responsiveness and packet loss, while TCP port checks focus on whether a specific service endpoint is accepting connections.
Read the ping guide βHow to interpret common scenarios
A host replies to ping but TCP 443 fails
The server may be reachable at the network layer, but the HTTPS service can still be down, blocked, misconfigured, or not listening on that port.
TCP 22 is open but login does not work
The SSH daemon is probably reachable, but authentication, authorization, or shell access can still fail after the port-level check succeeds.
A port times out instead of refusing the connection
That often points to filtering or a firewall policy rather than a clean closed-port response.
UDP service seems silent during testing
That does not automatically mean the service is down. Many UDP-based protocols only answer when the probe format is valid for the application.
Important limitations
- β A successful TCP port check proves the port is reachable, not that the full application workflow is healthy.
- β An open port can still front a broken service that fails after the initial connection.
- β UDP services are harder to validate generically because many of them do not provide obvious handshake-like confirmation.
- β Firewall behavior, NAT, and rate limiting can change how ports appear from different source locations.
How people test ports manually
nc -vz example.com 443 A common quick test for whether a TCP port accepts a connection from your current source.
telnet example.com 25 Still useful for simple manual SMTP or TCP banner checks, although many systems no longer install telnet by default.
nmap -p 22,25,80,443 example.com Nmap can test multiple ports and provide a broader view of exposed services, depending on the scan type and permissions.
Frequently asked questions
Manual port checks are useful once. Monitoring TCP ports is useful all the time.
nsmon helps you continuously check TCP ports from probe locations, so you can detect when a service stops accepting connections before users report it. Create a free account to start monitoring critical TCP endpoints such as SSH, SMTP, HTTP, HTTPS, and custom application ports.