One host can run several network services. Its IP address alone does not tell a client which service it wants. A service is a program function made available over the network, and a port number helps direct data to the intended endpoint.
A transport is a protocol that carries data between application endpoints. Here TCP, Transmission Control Protocol, and UDP, User Datagram Protocol, have separate port spaces. A port is a 16-bit number, from 0 through 65535. Read the number and transport together before interpreting a row.
Before you begin
- Recommended first
- Files, programs, and processes, Processes, Packages with apt, MAC, IP, DHCP, and private ranges
- Estimated time
- 15 min reading, 15 min activity. Setup and optional practice may take longer.
- Where you work
- Use the supplied original network cards, packet tables and stream transcripts in any browser, including on a phone. You need no account, paid lab or live network access. Reading a saved file in Wireshark is optional; installation time is separate from the estimate. Optional challenges take about ten extra minutes.
- Without a lab
- The page prints every address, row and message needed for its activity. Follow the numbered steps in notes and label your conclusions as predictions or interpretations of supplied evidence. The pcapng files are synthetic, constructed examples; opening one is different from recording a network. Reading works without JavaScript. Answer checking needs JavaScript and a secure context, such as HTTPS. Saving correct progress also needs usable browser storage.
After this lesson you can:
- Identify a stated endpoint using host context, port and transport.
- Distinguish a client port from a service listener.
- Separate a customary port association from evidence of an actual service.
01Example
This fictional status-page row supplies the endpoint the client must use. A listener is an endpoint waiting to receive traffic for a service. The row is given evidence, not an ss observation or a scan. Its port differs from a customary association.
Fictional service: status page
Listener on the stated host: 8081/tcp
Client destination port for this row: 8081
HTTP is commonly associated with 80/tcp.
That convention does not change the supplied 8081/tcp row.02The row is the observation
A socket is a communication endpoint. To distinguish endpoints here, retain an IP address, a port and a transport. For example, TCP at one address and port is different from UDP at that same address and number. The abbreviated cards assume one stated host and omit its address to focus on port and transport.
The client sends toward a destination port; the client also has its own local port. A conversation therefore has two ends. The dynamic port range is 49152 through 65535, often used for temporary client endpoints. It is a reserved range for local allocation, not evidence that every operating system always chooses clients from exactly that range.
On the activity host, 9090/tcp and 9090/udp are separate endpoints because the transports differ. The notes page uses the TCP row. The notes datagrams row uses UDP. Datagram means a separate message; the next lesson explains the transport difference.
HTTP is conventionally associated with 80/tcp, and HTTPS with 443/tcp. A convention is a common association, not proof of a listener or protocol. A label saying HTTP also does not verify what the program actually speaks. For this reading task, use the stated listener row; a real investigation needs more evidence.
A listener shows that an endpoint is waiting under the conditions described by the evidence. That alone does not show a vulnerability, authorization to connect, or successful application behavior.
Read the observed row as host context plus 8081/tcp; customary 80/tcp remains a separate reference association.Model. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
| Field | Supplied listener | Client destination for this row | Separate common association |
|---|---|---|---|
| Context | status page on the stated host | same stated host | HTTP convention, not this observation |
| Transport | tcp | tcp | tcp |
| Port | 8081 | 8081 | 80 |
Use the host context, transport and port actually stated.
Use the host context, transport and port actually stated.
Follow the explanation
- Use the host context, transport and port actually stated.
- The common HTTP association does not override the supplied 8081/tcp listener evidence; no scan or discovery occurred.
Read every state and value
1. Use the host context, transport and port actually stated.
- Selected Comparison
- row
- Highlighted Field
- Context · Transport · Port
2. The common HTTP association does not override the supplied 8081/tcp listener evidence; no scan or discovery occurred.
- Selected Comparison
- association
- Highlighted Field
- Port
03Read the activity rows, then the field row
Use the notes page and notes datagrams rows for the guided comparison. They use port 9090 with different transports. A separate customary HTTPS row supplies an association without supplying a listener. Keep that distinction as you read.
Predict which destination a notes-page client uses and compare with the printed check. Leave the separate demo row for the later question. The independent check cards give another case; do not substitute the activity port for those values.
Read the endpoint before guessing a service
A listener waits for incoming traffic at an endpoint. Keep an address,
port and transport when identifying an endpoint; these shortened rows
assume one host and omit its address. TCP and UDP use separate port
spaces even when the digits match. A client also has its own port.
Dynamic ports range from 49152 through 65535. The later client examples
use that range. A customary association such as HTTP with 80/tcp or
HTTPS with 443/tcp does not establish an actual listener or protocol.
The supplied row is evidence for this card, not a scan or vulnerability.
Original fictional listener card. Not output from ss.
Worked row
Service Listener Name that does not decide the port
status page 8081/tcp HTTP is often associated with 80/tcp
The client on this row uses 8081.
Activity rows
Service Listener Note
notes page 9090/tcp the stated listener for the page
notes datagrams 9090/udp same number, other transport, not the page
https customary 443/tcp no row says a listener is here
Predict before reading the check. Check: the notes page client uses 9090.
Separate row used by the question
Service Listener
demo HTTP 8080/tcp
- Find the notes page row and the notes datagrams row. Both use 9090. One is TCP and one is UDP.
- Name the port a client uses for the notes page. Ignore the customary 443/tcp row, which says no listener is there.
- Check: the notes page client uses 9090.
- Leave the field row for the question. Do not connect to a port and do not scan.
04Optional challenge
Allow about ten extra minutes. On paper, write the same IP address and port once with TCP and once with UDP. Explain what changed and why the endpoints are distinct. Then state why a familiar number alone cannot identify the actual program or prove a security flaw.
05Cards for the checks
The checks below use these cards. They are original fictional text, safe to read anywhere.
Independent listener card: fictional rows on one hostOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Service Listener
demo HTTP 8080/tcp
time sync 123/udp
metrics 9100/tcp
metrics feed 9100/udp
One conversation seen on the card
client end 52814/tcp -> listener 8080/tcp
06Fresh cases for the checks
Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.
Endpoint case A: separate host and conversationOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Server mint: IPv4 192.0.2.81; TCP listener port 8187.
Client fern: IPv4 192.0.2.82; temporary TCP port 53126.
Request: fern 192.0.2.82:53126 → mint 192.0.2.81:8187 over TCP.
Reply uses the reverse endpoint direction in this case.
These documentation addresses are fictional evidence.
07Explain your prediction
Optional written self-check: Describe both endpoints and their direction. Keep a listener, a customary port association and a verified application protocol as separate claims.
08Common mistakes
If you choose 80 or 443 solely from a service name, return to the named listener row. A customary association is weaker evidence than the endpoint explicitly supplied for this case.
If two identical numbers look like one endpoint, check both the transport and the host/address assumption. TCP and UDP have separate port spaces.
If you type /tcp when asked for digits, separate your reasoning from the response format. Keep transport in your notes while entering only the requested number.
References
- RFC 9293: Transmission Control Protocol
The port and segment introduction. TCP carries a 16-bit source port and destination port.
- RFC 768: User Datagram Protocol
The header description. UDP has its own 16-bit source and destination ports. Destination port meaning is local to the destination address.
- RFC 6335: Service Name and Port Number Procedures
The range and assignment notes. System ports are 0-1023, user ports 1024-49151, and dynamic ports 49152-65535. Traffic to an assigned port does not prove the assigned service.