This note explains how ports, protocols, and layers fit together in everyday networking. The goal is to understand what service a host is trying to use, how the traffic is transported, and where in the stack a failure is likely to sit.
Why this matters
many troubleshooting problems become easier once you know whether the issue is name resolution, reachability, transport, or the application itself
Linux, security, firewall, and cloud work all rely on understanding ports and protocols
“the network is broken” is usually too vague until you identify which layer is failing
Environment / Scope
Item
Value
Topic
ports, protocols, and basic stack layers
Best use for this note
building a clear troubleshooting mental model
Main focus
IP, TCP/UDP, application services
Safe to practise?
yes
Key concepts
Protocol - a defined way systems communicate, such as IP, TCP, UDP, HTTP, or DNS
Port - a numbered endpoint used to direct traffic to the right service on a host
Layer - a logical part of the network stack, such as addressing, transport, or application behaviour
Application service - the actual service you care about, such as SSH, HTTPS, or DNS
Mental model
Think about the stack like this:
Layer view
What it answers
Addressing / routing
can the traffic reach the destination network and host?
Transport
is the service using TCP or UDP, and is the port reachable?
Application
is the service itself behaving correctly?
Example:
you resolve github.com to an IP address
your host routes traffic to that destination
TCP connects to port 443
HTTPS then runs on top of that connection
Everyday examples
Service
Common protocol
Common port
SSH
TCP
22
HTTP
TCP
80
HTTPS
TCP
443
DNS
UDP or TCP
53
DHCP
UDP
67/68
Common misunderstandings
Misunderstanding
Better explanation
”Port and protocol mean the same thing”
protocol is the communication method, port is the destination number for a service
”If ping works, the application must work”
ping only tests basic IP reachability, not application health
”TCP and UDP are just two port types”
they are transport protocols with different behaviour
”If port 443 is open, the website is fine”
the application on that port can still be broken
Verification
Check
Expected result
ping <host>
basic IP reachability works
nslookup <name> or dig <name>
name resolution works
traceroute <host>
shows path towards destination
curl https://example.com or app-specific test
confirms application response
Pitfalls / Troubleshooting
Problem
Likely cause
What to check
Name resolves but app fails
transport or application issue
service port, firewall, app health
Ping works but SSH fails
service or port problem
SSH service, port 22, local firewall
DNS query fails but IP ping works
name resolution problem
DNS server, resolver config
Service listens but clients still fail
wrong interface, filtering, or app issue
bind address, firewall, logs
Key takeaways
protocol, port, and application are related but not the same thing
a working lower layer does not guarantee the upper layer works
strong troubleshooting starts by asking which layer is actually failing