Layer 4 (Transport): TCP, UDP & ports

Acutis · plain-English network help · updated June 2026

Layer 4 is where a working IP path turns into a working conversation between two programs. If ping succeeds but an app still won't connect, you've almost certainly found a Layer 4 problem. The Transport layer manages connections, decides whether delivery should be reliable or fast, and uses port numbers to direct traffic to the right program on a machine. The two protocols you'll deal with are TCP and UDP, and most "the network is up but my app is broken" cases come down to a blocked port, a reset connection, or a quietly dropped packet.

TCP vs UDP

TCP is the reliable, ordered protocol. It sets up a connection, confirms every chunk of data arrives, and retransmits anything lost. Web pages, email, file transfers and most apps use it, because they need every byte intact. UDP is the fast, fire-and-forget protocol. It skips the setup and the delivery guarantees in exchange for low latency, which is why live video, voice calls, DNS lookups and online games lean on it. Neither is "better" — they're tuned for different jobs. Knowing which one an app uses tells you what to test and what symptoms to expect.

Ports and the three-way handshake

An IP address gets a packet to the right machine; a port gets it to the right program on that machine. Web servers listen on port 443 (HTTPS) and 80 (HTTP), mail and database servers each have their own. When a TCP connection starts, the two sides perform a three-way handshake: your device sends a SYN, the server replies SYN-ACK, and your device finishes with ACK. Only then can data flow. If that handshake never completes, nothing happens — and that's exactly what a blocked port looks like. For more on ports themselves, see what is a port.

Common Layer 4 symptoms

• Ping works but the app won't connect. The IP path is fine (Layer 3 is healthy), but the specific port the app needs is blocked or nothing is listening on it.
• A specific port is blocked. A firewall — on your machine, your router, or the server side — silently drops the connection attempt, so it just hangs and eventually times out.
• Connection reset. You get an immediate "connection refused" or reset. That usually means something actively rejected the connection rather than dropping it — often a firewall configured to reject, or no service listening on that port.
• Timeouts. The handshake gets no reply at all. Typical of a firewall that drops silently, or a server that's overloaded or down.
• MTU issues. Small requests work, large transfers stall. Oversized packets that can't be fragmented get dropped, often on VPNs or PPPoE links where the usable packet size is smaller than the default.

How to diagnose Layer 4

The key move is to test the exact port the app uses, not just whether the host is reachable. A successful ping only proves Layer 3; you need to confirm the transport-layer port actually opens.

1. Confirm the host is reachable first. Ping the server's IP. If ping fails, drop back to Layer 3 — this isn't a transport problem yet.
2. Test the specific port. On Windows PowerShell: Test-NetConnection host -Port 443. On macOS/Linux: nc -vz host 443. The older telnet host 443 also works — if it connects, the port is open; if it hangs or refuses, it isn't.
3. Read the result. A clean open means Layer 4 is fine and the problem is higher up (TLS at Layer 6, or the app at Layer 7). A timeout points to a silent firewall drop; a refusal means nothing is listening or a firewall is actively rejecting.
4. Suspect MTU if only big transfers fail. Test with a large, do-not-fragment ping — on Windows ping -f -l 1472 host — and lower it until it succeeds to find the working packet size, then set the MTU on your router or VPN accordingly.

🔧 Inspect it with our free tools

Port testing is a command-line step — we deliberately don't run a public port-scanner — but our ping tool isolates the layer for you first:

1. Run the Ping Test to confirm Layer 3 is clean. If ping is fine but the app still won't connect, the fault is at Layer 4 — a blocked port or firewall — not below it.
2. Then test the specific port from a terminal. Windows: Test-NetConnection host -Port 443. macOS/Linux: nc -vz host 443. A timeout means the port is blocked or filtered; a refusal means nothing is listening on it.