These two terms come up constantly in networking, and both are genuinely simple. The analogy: one IP address is one building, and a port is a door number in that building. A protocol is the language spoken once the door opens.

Understanding both answers a question that comes up often and feels mysterious: why the internet works fine, every site loads, yet one particular app refuses to connect.

Ports as door numbers

One server can offer many services from a single address. What distinguishes which request is for which service is the port number. When you open a website, the request goes to the server's address on port 443. When a mail app collects messages, it goes to a possibly identical address on a different port.

Numbers run from 1 to 65535, and those under 1024 are agreed for specific services. Only a few are worth remembering:

  • 443, encrypted web. Nearly all your daily traffic goes through here.
  • 80, unencrypted web. Still used to redirect to 443, and often used by network devices for their settings pages.
  • 53, translating names into addresses. When this is disrupted, the symptoms look like a dead connection when it isn't, covered in DNS server not responding and what DNS is.
  • 123, clock synchronisation. Small but important, because a wrong clock makes site certificates fail.
  • 22, command-line access to servers. Often blocked on office and hotel networks.

The rest rarely needs memorising. What's more useful is knowing the numbers exist, and that they can be blocked one at a time.

TCP and UDP

Beneath ports sit two ways of sending data, and the difference shows up directly in everyday use.

TCP ensures everything arrives, in order and complete. Anything lost is resent before the rest continues. It's what loads websites, downloads files, and sends mail, because a file missing one chunk is useless.

UDP sends without waiting for acknowledgement and without resending losses. That sounds worse, but for a video call it's exactly right: audio delayed a second while waiting for a missing fragment is far more disruptive than audio that drops briefly. That's why video calls and online games use UDP, and why their symptoms differ when the network struggles.

It also explains the complaints in choppy video calls and high ping while gaming: both are sensitive to delay and loss, not to raw speed. The measurements are distinguished in bandwidth, latency, and throughput.

When one app fails and everything else works

This is what understanding ports is for. The symptom is distinctive: all sites load, speed is normal, but one app spins forever without connecting. The connection isn't broken; one door is shut.

Several parties can be the one shutting it:

  • The network you're on. Office, school, hotel, and cafe Wi-Fi often open only web ports and close the rest. This is the most common reason games, VPNs, and video calls fail in public places.
  • A firewall on your router or computer (what a firewall is).
  • Your provider, particularly for ports commonly abused.
  • Address blocking rather than port blocking. When the site address is what's blocked, the symptoms differ, covered in how site blocking works.

Confirming it is simple and needs no tools: try the same app over a phone hotspot. If it works there, the filtering is on the first network, not in your app or device. Next steps in when one app won't open.

Inbound ports, the risky part

Everything above concerns connections you start from inside. The opposite direction behaves differently. By default a router refuses connections arriving from the internet, and that's the most useful protection you have without doing anything. The mechanism is explained in NAT and CGNAT.

Opening an inbound port cancels that protection for one specific door. Sometimes it's genuinely needed, for viewing a camera remotely or running a small home server. Three things to accept before doing it:

  • Automated scanners will find it, typically within hours, not months. No port is hidden by having an unusual number.
  • Whatever sits behind it must be ready. Default password changed, firmware current, and if the device no longer receives updates, don't open it at all.
  • A VPN is nearly always the better choice. It gives you access to your home network without opening a door to anyone else. Full discussion in port forwarding on your router.

For cameras and smart devices the answer is nearly always don't. Why, in CCTV camera security.

Seeing it yourself

Two commands cover almost every everyday check, and both are already on your computer with nothing to install:

  • ping confirms an address is reachable and measures the delay.
  • tracert on Windows, or traceroute on macOS and Linux, shows where the journey stops, telling you whether the problem is at home, at the provider, or at the destination.

How to read the output, including why a hop that doesn't answer isn't necessarily a fault, is in using ping and traceroute.

What to remember

A port is a door number at one address, and they can be blocked individually, so one app can fail while every site loads normally. TCP guarantees completeness, UDP prioritises timeliness, which explains why video-call symptoms differ from download symptoms. And inbound is not the same as outbound: opening an inbound port is a decision that needs a reason, not a first step when trying to fix something.

Frequently asked questions

What's the practical difference between TCP and UDP?

TCP guarantees every piece arrives and in order, by resending what's lost. UDP sends without waiting for acknowledgement. That's why video calls use UDP: audio delayed by a second is worse than audio that briefly drops.

Sites load but one app won't connect. What do I check?

Most likely the port that app uses is blocked while web ports stay open. Test from another network such as a phone hotspot. If it works there, the filtering is on the first network.

Is opening a port on the router dangerous?

Yes, if the device behind it isn't ready to face the internet. Opening a port invites the whole internet to knock, and automated scanners find it within hours.