Ports and Transport Protocols

Networking path · Step 11Available

Connect an application to a socket, port, transport protocol, and firewall decision without treating a port number as proof of a service.

Difficulty: Beginner
Time: 45 min
Practice: Verify a listening service
Assessment: Knowledge check

Before you start

Who is this for?

For IT learners who need to interpret service access and distinguish network reachability from application success.

Prerequisites

Basic IP addressing
The idea of a client and server

What you'll be able to do

Explain TCP and UDP trade-offs
Read a socket tuple
Recognise common service ports
Verify a listener without assuming its application works

Practical outcome

You can describe a failed connection using source, destination, protocol, port, and response evidence.

1. A port identifies a process endpoint

An IP address identifies an interface or host. A transport port identifies an endpoint owned by an application on that host. A flow is described by source IP, source port, destination IP, destination port, and protocol. The source port is usually ephemeral; the server commonly listens on a documented port.

A port number is a convention. HTTPS commonly uses TCP 443, but an application can listen elsewhere and a firewall can block or redirect traffic.

2. TCP and UDP

TCP establishes a connection, numbers bytes, acknowledges received data, retransmits loss, and presents an ordered stream to the application. The three-way handshake is SYN → SYN/ACK → ACK. TCP reliability does not guarantee that the application authenticated successfully.

UDP sends independent datagrams without a transport handshake or built-in retransmission. It is useful when the application handles timing, loss, or retransmission itself, as with DNS queries, streaming, and some real-time protocols.

Neither protocol is automatically secure. Security comes from the application protocol, authentication, encryption, and policy.

3. Common ports

Service	Typical port	Transport	Meaning
HTTP	80	TCP	Web without transport encryption
HTTPS	443	TCP	Web over TLS
DNS	53	UDP and TCP	Queries, replies, and zone transfers
DHCP	67/68	UDP	Server/client configuration exchange
SSH	22	TCP	Encrypted remote administration
SMTP submission	587	TCP	Authenticated mail submission
IMAPS	993	TCP	Mail retrieval over TLS
RDP	3389	TCP/UDP	Remote desktop transport

Port lists help you form a hypothesis. They do not prove the service is installed, reachable, or correctly configured.

4. Verify the complete flow

On Windows, inspect local listeners and test an authorised destination:

Get-NetTCPConnection -State Listen
Test-NetConnection -ComputerName example.test -Port 443

On Linux:

ss -lntup
curl --verbose https://example.test/

Interpret the layers separately: DNS resolution, route selection, TCP/UDP reachability, TLS negotiation, authentication, and application response. A successful ping does not prove TCP 443 works; a successful TCP handshake does not prove the HTTP request succeeded.

Common mistakes

Calling every port “open” because a service is registered there.
Testing only ICMP when the real application uses TCP or UDP.
Confusing a local listening socket with a remotely reachable socket.
Forgetting that host firewalls, network firewalls, NAT, and application policy are separate decisions.
Publishing an administrative service to the Internet without a documented need and controls.

Practical exercise

In your own VM, start a local web server, identify its listener, access it through the expected port, then stop it. Record the exact evidence for each state. Do not scan third-party systems.

What you should be able to do now

You should be able to read a transport flow, choose a protocol-aware test, and state what a result proves—and what it does not prove.