Class notes · Professor Messer, CompTIA A+ 220-1201 Core 1 · Section 2 primer (supports objective 2.1)

Quick reference: the short version of this lesson is the Introduction to IP cheat sheet, part of Section 2.

Note: this video doesn’t map directly to an exam objective. Messer presents it as a primer: everything in the networking domain builds on it, so it’s worth learning well.

Learning objectives

By the end of these notes you should be able to:

Explain the roles of the network, IP, TCP/UDP and application data using the road, truck and box analogy.
Describe encapsulation and decapsulation, and name the headers and trailers in an Ethernet frame carrying web traffic.
Compare TCP and UDP: connections, reliability, acknowledgements, retransmission and flow control.
Choose TCP or UDP for an application, and explain why real-time traffic prefers UDP.
Explain multiplexing, and how IP addresses and port numbers direct data to the right service.
Distinguish non-ephemeral (well-known) server ports from ephemeral client ports.
Read a simple protocol decode and identify the client, the server and each application.
Explain why port numbers are not a security mechanism.

1. The big picture

1.1 Many networks, one protocol

Networks move information from one device to another over many kinds of link: Ethernet, wireless, DSL and others. From the Internet Protocol’s point of view, it doesn’t matter which one carries it. What matters is the information inside the packets.

1.2 The analogy: road, truck, boxes

Networking

Analogy

Job

The network (Ethernet, wireless, DSL…)

The road

Carries traffic from place to place

IP (Internet Protocol)

The truck

Carries the data between devices, using addresses

TCP or UDP

The boxes in the truck

Package the data, and label which service it’s for

Application data

The contents of each box

The information that matters: a web page, an email, a voice call

We load the truck, drive it across the road, and unpack it at the other end.

2. Encapsulation

2.1 Nesting data inside data

Each layer wraps the one inside it — boxes inside the truck, contents inside the boxes.

Encapsulation is wrapping data in more layers as it’s sent.
Decapsulation is unwrapping it at the receiving end.

2.2 Worked example — a web request on Ethernet

A laptop sends a request to a web server over Ethernet:

Ethernet frame: an Ethernet header at the start and a trailer at the end mark exactly where the data starts and stops. Everything between them is the Ethernet payload.
Inside the Ethernet payload: an IP header plus the IP payload — because this frame carries IP traffic.
Inside the IP payload: a TCP header plus the TCP payload.
Inside the TCP payload: HTTP (Hypertext Transfer Protocol) data — the actual web communication.

The web server decapsulates in the same order: Ethernet, then IP, then TCP, then HTTP to the web server software. Other protocols can have even more layers to drill into.

3. TCP and UDP

3.1 Two ways to carry data

TCP and UDP both transport data inside IP, but they behave very differently.

Note: networking professionals (and Network+ material) call TCP and UDP OSI Layer 4 protocols. The A+ exam doesn’t require the OSI model, but you’ll see the term in books and other study material.

3.2 Multiplexing

TCP and UDP allow multiplexing: communicating with multiple devices, and running many different kinds of traffic, at the same time — with everything arriving at the right place on the other side. Your browser, email and a voice call can all share one network connection simultaneously.

3.3 TCP — Transmission Control Protocol

TCP is connection-oriented: there’s a formal setup before data flows, and a formal teardown at the end.

The phone-call analogy:

You dial, it rings, the other person says hello, and you say hello back — setup.
You have the conversation.
You say goodbye, they say goodbye, and you hang up — teardown.

TCP feature

What it means

Reliable delivery

You know the data was received, because the receiver acknowledges it

Acknowledgements

Every piece of data sent is confirmed back to the sender

Retransmission

If data arrives damaged or corrupted, the receiver tells the sender, and it’s resent

Flow control

The receiver can tell the sender to speed up or slow down, depending on how much it can handle

This constant cycle of send and acknowledge is what gives TCP its reliability — like sending post with a return receipt.

Note (beyond this lesson): the setup is the three-way handshake — SYN, SYN-ACK, ACK — covered in the Section 2 networking notes.

3.4 UDP — User Datagram Protocol

UDP is connectionless: no formal setup, no formal teardown — it just sends.

UDP characteristic

What it means

“Unreliable” delivery

There’s no way to know whether the data was received

No acknowledgements

The receiver never replies to confirm

No error recovery or retransmission

Lost or damaged data is simply gone — at the UDP level

No flow control

The receiver can’t ask the sender to speed up or slow down

Very little overhead

No setup, and no acknowledgement traffic. It’s best effort

“Unreliable” doesn’t mean bad — it means UDP doesn’t guarantee delivery.

3.5 Why use UDP?

Real-time communication — voice over IP (VoIP) and live video. If part of a conversation is lost, you can’t rewind time and replay that moment through the same connection. Resending old audio would only arrive too late to be useful. So real-time apps prefer UDP’s low overhead, and simply carry on. If someone missed a word, they ask you to repeat it.

Simple request-and-response protocols — they need low overhead, and if something fails the application just tries again:

DHCP (Dynamic Host Configuration Protocol): automatically assigns IP addresses.
TFTP (Trivial File Transfer Protocol): sends small amounts of data, without needing retransmission.

The application can take over reliability. UDP doesn’t retransmit, but an application using UDP can track what it sent and decide for itself whether to resend. Some apps (like DHCP retrying) do; others (like VoIP) deliberately don’t.

3.6 Why use TCP?

Applications that must get every byte right rely on TCP to handle delivery, so the application doesn’t have to:

HTTPS (Hypertext Transfer Protocol Secure) — web communication.
SSH (Secure Shell) — encrypted terminal sessions.

TCP maintains the whole data flow, confirms receipt and resends anything missing.

3.7 TCP vs UDP at a glance

TCP

UDP

Connection

Connection-oriented (formal setup and teardown)

Connectionless

Delivery

Reliable — acknowledged

“Unreliable” — best effort

Retransmission

Yes, by TCP

No (the application may do it)

Flow control

Yes

Overhead

Higher

Very low

Examples

HTTPS, SSH, web, email

VoIP, video, DHCP, TFTP

3.8 Worked example — TCP or UDP?

Application

Protocol

Reasoning

Downloading a software update

TCP

Every byte must arrive intact

A live video call

UDP

Real-time; late data is useless, so don’t retransmit

Getting an IP address when a laptop joins a network

UDP (DHCP)

Small and simple; if it fails, just ask again

Remote admin of a Linux server

TCP (SSH)

Commands and output must be exact

Streaming a live football match

UDP (typically)

Real-time; a dropped frame is better than a pause

4. Addresses and ports

4.1 IP addresses — the street address

A removal company needs an address to collect from and an address to deliver to. In networking, these are IP addresses. Every device on the network has one, just as every house on a street has an address.

4.2 Port numbers — the room

A house has many rooms, and a server runs many services. One server might be a web server, a DNS (Domain Name System) server, a file server and a VoIP server all at once. When data arrives at the server’s IP address, the server still has to decide which service gets it.

In the house analogy:

The operating system stands at the front door, reading the label on each box.
Each box is labelled with its destination room: bedroom, living room, kitchen.
TCP and UDP label boxes with a port number instead of a room name. Each service is assigned its own number, so incoming data reaches the right application.

4.3 What identifies a communication

Every flow involves, at each end:

Server side

Client side

IP address

The server’s IP

The client’s IP

Protocol

TCP or UDP

Port number

The service’s port

The client’s own port — so replies find their way back

4.4 Non-ephemeral (well-known) ports

Services tend to use the same port every time. These are non-ephemeral (permanent) ports, usually in the range 0–1,023, although a service can be configured with any available port.
The port is part of the service’s configuration. A web server, email server or file server is set to a port, so clients always know where to send data.
They’re also called well-known ports: the client needs to know the port in advance to communicate with the service.

4.5 Ephemeral ports

The client picks a temporary port for its own end, usually somewhere from 1,024 to 65,535.
It’s used for a single communication. When the conversation ends, the port is released.
A new connection gets a new random port.

Note (beyond this lesson): the official split (IANA) is 0–1,023 well-known, 1,024–49,151 registered and 49,152–65,535 dynamic. Windows picks ephemeral ports from 49,152–65,535 by default. For the exam, Messer’s “1,024–65,535” is the idea to know: clients use temporary high-numbered ports.

4.6 Port facts to remember

Fact

Detail

Range

0–65,535 for TCP, and separately 0–65,535 for UDP

TCP and UDP are separate

TCP port 80 is not the same as UDP port 80 — same numbering scheme, different protocols

Ports aren’t security

A port is just a reference number. Moving a service to an unusual port doesn’t hide it — it’s easy to find

5. Many conversations at once — a worked example

5.1 The setup

Client: 10.0.0.1
Server: 10.0.0.2, running three services:

Service

Protocol and port

Web server

TCP 80

VoIP server

UDP 5004

Email server

TCP 143

All three conversations run at the same time over Ethernet (Ethernet header and trailer), each carrying IP, and inside that either TCP or UDP.

5.2 Reading the protocol decode

A packet capture shows three flows:

Flow

Source IP

Destination IP

Protocol

Source port

Destination port

Application

10.0.0.1

10.0.0.2

TCP

51,734 (random)

Web (HTTP)

10.0.0.1

10.0.0.2

UDP

62,208 (random)

5004

VoIP

10.0.0.1

10.0.0.2

TCP

49,915 (random)

143

The source ports are illustrative — the point is that they’re random and different.

How to read it:

Same IP addresses in every flow. One client (10.0.0.1) talking to one server (10.0.0.2).
Destination ports are the well-known service ports (80, 5004, 143). That tells you which application each flow is for.
Source ports are random and all different. They’re the client’s ephemeral ports, one per conversation, so replies return to the right place.
The protocol column shows the TCP/UDP split. The two ports numbered 80 on a network would still be different things if one were TCP and one UDP.

If the client opened a fourth connection — say, a second browser tab to the same server — it would pick another random source port. That’s multiplexing in action.

5.3 Seeing it on your own machine

netstat -an \

Proto, Local Address, Foreign Address, State

Get-NetTCPConnection -State Established | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePortExample netstat line:

Proto Local Address Foreign Address State TCP 10.0.0.1:51734 10.0.0.2:80 ESTABLISHED

Reading it: the local (client) side uses ephemeral port 51734; the remote (server) side uses well-known port 80. That’s an HTTP connection.

ss -tun \

TCP and UDP sockets, numeric addresses and ports

6. Security perspective

Ports are not security. Changing a service to a non-standard port (“security through obscurity”) doesn’t protect it. Port scanners find open ports in seconds. Real protection comes from firewalls, authentication and patching.
Ports are how firewalls make decisions. Firewall rules filter by IP address, protocol (TCP/UDP) and port. Knowing that TCP 80 ≠ UDP 80 matters when you read or write rules.
Unexpected listening ports are a warning sign. If netstat shows a service listening that you don’t recognise, investigate — it could be unwanted software or malware.
Encapsulation isn’t encryption. A protocol decode shows every layer. Unencrypted HTTP data can be read by anyone capturing the traffic; HTTPS and SSH encrypt the application data inside the TCP payload.
UDP’s lack of a handshake makes it easier to fake the source of traffic. This is one reason UDP-based services are sometimes abused in denial-of-service attacks (beyond this lesson).

Summary

IP doesn’t care about the link (Ethernet, wireless, DSL). Network = road, IP = truck, TCP/UDP = boxes, application data = contents.
Encapsulation nests data: Ethernet header + [IP header + [TCP header + HTTP data]] + Ethernet trailer. Decapsulation unwraps it at the other end.
TCP and UDP (OSI Layer 4) enable multiplexing — many conversations at once.
TCP: connection-oriented (formal setup and teardown), reliable (acknowledgements), retransmission, flow control. Used by HTTPS and SSH.
UDP: connectionless, “unreliable”, no acknowledgements, retransmission or flow control, and very low overhead. Used for real-time VoIP and video, DHCP and TFTP; the application can handle retries itself.
Each end of a flow has an IP address, a protocol and a port number.
Ports:
- Non-ephemeral (well-known) server ports are usually 0–1,023.
- Ephemeral client ports are usually 1,024–65,535 (Windows: 49,152–65,535) — random and temporary.
- The range is 0–65,535 for each protocol, and TCP 80 ≠ UDP 80.
- Ports aren’t a security mechanism.

Glossary

Term

Definition

IP (Internet Protocol)

Carries data between devices using IP addresses

Packet

A unit of data sent across a network

Ethernet frame

The unit of data on an Ethernet network, with a header and trailer

Header / trailer

Control information at the start / end of a unit of data

Payload

The data carried inside a frame, packet or segment

Encapsulation

Wrapping data inside successive protocol layers when sending

Decapsulation

Unwrapping those layers when receiving

HTTP / HTTPS

Hypertext Transfer Protocol / its secure, encrypted version

TCP

Transmission Control Protocol — connection-oriented and reliable

UDP

User Datagram Protocol — connectionless, best effort

OSI Layer 4

The transport layer of the OSI model, where TCP and UDP sit

Multiplexing

Carrying many simultaneous conversations over one network

Connection-oriented

Having a formal setup and teardown

Connectionless

Sending without any setup or teardown

Acknowledgement

Confirmation from the receiver that data arrived

Retransmission

Resending data that was lost or damaged

Flow control

The receiver regulating how fast the sender transmits

Overhead

Extra traffic and processing beyond the data itself

VoIP

Voice over IP — real-time voice communication

DHCP

Protocol that automatically assigns IP addresses (uses UDP)

TFTP

Trivial File Transfer Protocol — simple file transfer over UDP

SSH

Secure Shell — encrypted terminal communication over TCP

Port number

A number (0–65,535) identifying a service or connection endpoint

Non-ephemeral / well-known port

A permanent service port, usually 0–1,023

Ephemeral port

A temporary client port, chosen randomly for one connection

Protocol decode

A breakdown of captured traffic, showing each layer’s fields

Review questions

In the road and truck analogy, what are the road, the truck and the boxes?
Why doesn’t IP care whether it travels over Ethernet, wireless or DSL?
What do the Ethernet header and trailer do?
List the layers, outermost first, of a web request sent over Ethernet.
What’s the difference between encapsulation and decapsulation?
What is multiplexing?
Give three features that make TCP “reliable”.
What does flow control allow the receiver to do?
Why does voice over IP prefer UDP?
Name two protocols, other than VoIP, that use UDP.
UDP has no retransmission. How can an application using UDP still recover lost data?
What three pieces of information identify each end of a network communication?
What are the typical ranges for non-ephemeral and ephemeral ports?
Is TCP port 80 the same as UDP port 80? Explain.
A decode shows three flows from 10.0.0.1 to 10.0.0.2, with destination ports 80, 5004 and 143 and three different high source ports. Explain what you’re seeing.
An administrator moves a service to port 8443 “so attackers can’t find it”. Is this effective?

Answer key

The road is the network, the truck is IP, and the boxes are TCP or UDP (holding the application data).
IP only cares about what’s inside the packets and where they’re going. The underlying network type is just the road it travels on.
They mark exactly where the frame’s data begins (header) and ends (trailer).
Ethernet (header and trailer) → IP → TCP → HTTP data.
Encapsulation wraps data in protocol layers for sending; decapsulation unwraps them on receipt.
Running many different conversations and kinds of traffic simultaneously over the network, each reaching the right destination.
Any three of: connection setup and teardown; acknowledgements; retransmission of damaged or lost data; flow control.
Tell the sender to speed up or slow down, depending on how much data it can handle.
It’s real-time. Lost audio can’t usefully be replayed later, so UDP’s low overhead and lack of retransmission suit it.
DHCP and TFTP.
The application itself tracks what it sent and resends if needed — UDP leaves reliability to the application.
IP address, protocol (TCP or UDP) and port number.
Non-ephemeral (well-known): usually 0–1,023. Ephemeral: usually 1,024–65,535 (Windows defaults to 49,152–65,535).
No. TCP and UDP each have their own 0–65,535 range; the same number on each protocol refers to different things.
One client talking to one server using three services at once: web (TCP 80), VoIP (UDP 5004) and email (TCP 143). The random high source ports are the client’s ephemeral ports — one per conversation.
No. Ports are only reference numbers, and scanning quickly finds services on any port. Use firewalls, authentication and patching instead.