TCP Handshakes and Port States Explained

The three-way handshake

TCP is defined in RFC 9293, which replaced the original RFC 793 in 2022. Each side picks a random starting sequence number, and the handshake is how each learns the other’s:

1. SYN: the client sends a segment with the SYN flag and its initial sequence number, to the server’s address and port, from a temporary (ephemeral) port of its own.
2. SYN-ACK: if a program is listening, the server’s operating system answers with SYN and ACK set, its own sequence number, and an acknowledgment of the client’s.
3. ACK: the client acknowledges the server’s sequence number. The connection is now established, and either side can send data.

The handshake costs one round trip before the first byte of data, which is why the time it takes to connect is a good rough measure of network latency between two points. TLS, HTTP and every other protocol on top of TCP add their own round trips after it.

The operating system completes the handshake, not the application. A server can accept the connection and then do nothing, which is why an open port proves that something is listening, not that the service behind it works.

Open, closed and filtered

The same SYN gets one of three answers:

A closed port is not a failure of the network: the RST is the host saying “nothing here” quickly and honestly. A filtered port is ambiguous by design. Dropping packets silently gives an outsider no way to tell whether the host exists, which is why most firewalls drop rather than reject traffic from the internet.

Port scanners such as Nmap use the same three words. Nmap also has open|filtered and closed|filtered for scan types that can’t tell those states apart; a full connection attempt, like the one described here, always can.

Why a filtered port takes so long

When a SYN gets no answer, the client can’t know whether it was lost or dropped, so it sends it again with a growing wait between tries. RFC 6298 sets the first retransmission timeout at one second and doubles it each time.

• Linux tries six more times by default (net.ipv4.tcp_syn_retries), so a connection to a filtered port can hang for about two minutes.
• Windows gives up after about 21 seconds by default, which is why Test-NetConnection takes a while before it reports a failure.
• Tools such as nc -w 5 or the TCP Port Check set their own, shorter limit.

A fast failure and a slow one tell you different things. A refusal within milliseconds means you reached the host. A long silence means something in the path is discarding your packets.

Common reasons a port isn’t open

• The service isn’t running, or it crashed. The host answers RST.
• It listens on the wrong address. A service bound to 127.0.0.1 or ::1 accepts connections only from the same machine. From anywhere else, the port is closed.
• A host firewall such as Windows Defender Firewall, nftables, firewalld or ufw blocks the port. These usually drop, so the port looks filtered.
• A cloud security group or network ACL doesn’t allow the port, or allows it only from some source addresses. Cloud providers drop by default.
• NAT without a port forward. A home or office router has no rule sending the port to the machine behind it. See NAT and private IP ranges.
• The provider blocks it. Many residential and cloud networks block outbound port 25, and some block inbound ports such as 80 or 445 for home connections.
• IPv4 works but IPv6 doesn’t, or the other way round. A name with both A and AAAA records can give different answers for each, because firewalls often have separate rules for each family.

How to test a port yourself

Only test systems you own or have permission to test. Each of these makes a full connection attempt, like the handshake above:

To see what a server itself is listening on, run ss -tlnp on Linux, lsof -iTCP -sTCP:LISTEN -n -P on macOS or Get-NetTCPConnection -State Listen in PowerShell. A port that is listening on the server but filtered from outside points to a firewall in between.

Test from more than one place when you can. A check from your own computer, from the server’s own network and from the internet, such as the TCP Port Check running on Cloudflare, narrows down which hop is blocking the connection.

Services that speak first

Once the handshake completes, some protocols wait for the client and some greet it. SSH sends a version line such as SSH-2.0-OpenSSH_9.6, and SMTP, FTP, POP3 and IMAP servers send a greeting that starts with a status code. HTTP, TLS and most databases send nothing until the client speaks. Reading that first line, often called banner grabbing, is a quick way to confirm which service is behind a port. Because a version string helps an attacker look up known vulnerabilities, many teams trim it.