Cloud, security, database and systems work all sit on top of the network, and most "the app is down" problems turn out to be network problems. This beginner course explains how networks really work, then gives you the habits to troubleshoot them. The first module maps protocols to the OSI and TCP/IP models, teaches you to read an IPv4 address, subnet mask and CIDR prefix (with a small JavaScript subnet calculator), and explains ports and the difference between TCP and UDP. The second module covers the services every network depends on: DNS, DHCP and NAT, and HTTP with TLS, including how to inspect a website's certificate. The final module is hands-on: ping, traceroute and netstat, mapping your own home network, and capturing packets with Wireshark. Every exercise runs on your own computer and your own network, and the course points to CompTIA Network+ as an optional next step.

Learn how data moves between computers: layers, IP addresses and subnets, ports, DNS, DHCP, HTTPS, and the tools to troubleshoot it.

Networking Fundamentals

## Why it matters

When a web page will not load, the cause could be a loose cable, a Wi-Fi password, a wrong IP address, a blocked port, a DNS failure, an expired certificate or a bug in the application. Network models give you a map so you can check these one layer at a time instead of guessing. They also give engineers a shared vocabulary: "it's a layer 3 problem" means "look at IP addressing and routing", and everyone on the call knows where to start.

## The core idea: layers

Sending data across a network is split into layers. Each layer does one job and relies on the layer below it. When you send something, every layer wraps the data in its own **header** (this is called **encapsulation**). The receiver unwraps the headers in reverse order.

## The OSI model (7 layers)

The OSI model is a teaching and troubleshooting model. Real networks do not implement it exactly, but its layer numbers are used everywhere.

| # | Layer | Job | Examples |
|---|---|---|---|
| 7 | Application | Services programs use | HTTP, DNS, SMTP, SSH |
| 6 | Presentation | Data format, encryption | TLS (often placed here), JPEG, UTF-8 |
| 5 | Session | Opening and closing conversations | session setup in some protocols |
| 4 | Transport | Delivery between programs | TCP, UDP (ports) |
| 3 | Network | Delivery between networks | IP, ICMP, routers |
| 2 | Data link | Delivery on one local network | Ethernet, Wi-Fi (802.11), MAC addresses, switches |
| 1 | Physical | Bits on a medium | cables, radio signals, fibre |

A common memory aid, from layer 1 up: "Please Do Not Throw Sausage Pizza Away".

## The TCP/IP model (4 layers)

The TCP/IP model describes how the internet is actually built. It merges some OSI layers:

| TCP/IP layer | Matches OSI layers | Examples |
|---|---|---|
| Application | 5, 6, 7 | HTTP, DNS, TLS, SSH |
| Transport | 4 | TCP, UDP |
| Internet | 3 | IP, ICMP |
| Link (network access) | 1, 2 | Ethernet, Wi-Fi |

You will hear both. People usually use OSI numbers ("layer 2 switch", "layer 7 load balancer") while describing the TCP/IP stack.

## Worked example: loading a web page

You type `https://example.com` and press Enter. Following the data down the stack on your laptop:

1. **Application:** the browser builds an HTTP request (`GET /`). TLS encrypts it.
2. **Transport:** TCP adds a header with the source port (a random high number such as 52814) and destination port 443.
3. **Internet:** IP adds a header with your IP address and the server's IP address.
4. **Link:** Wi-Fi adds a frame header with your laptop's MAC address and your router's MAC address, then sends it as radio signals.

Your router strips the link header, reads the IP header, decides where to send the packet next, and wraps it in a new link header for the next hop. Routers work at layer 3, so the IP addresses stay the same end to end (apart from NAT, covered later), while MAC addresses change at every hop.

## Units at each layer

- Layer 2: a **frame**
- Layer 3: a **packet**
- Layer 4: a **segment** (TCP) or **datagram** (UDP)

## Using the model to troubleshoot

Work bottom-up when the problem is "nothing works", and top-down when only one application fails:

- Layer 1: is the cable plugged in, is Wi-Fi connected?
- Layer 2: does the device see the local network (link lights, connected SSID)?
- Layer 3: does it have a valid IP address, can it `ping` the router?
- Layer 4: is the port open, is a firewall blocking it?
- Layer 7: does the name resolve in DNS, does the application return an error?

## Common mistakes

- **Treating the models as competing standards.** They describe the same thing at different levels of detail.
- **Putting DNS at the transport layer** because it uses UDP port 53. DNS is an application-layer protocol that *uses* the transport layer.
- **Forgetting that a switch and a router work at different layers.** A switch forwards frames by MAC address inside one network; a router forwards packets by IP address between networks.
- **Memorising without mapping.** The value is in placing a real protocol or fault on a layer, not reciting the list.

## Quick recap

- OSI has 7 layers; TCP/IP has 4 and is what the internet actually runs.
- Each layer adds a header on the way down and removes it on the way up.
- Ethernet and Wi-Fi are layer 2, IP is layer 3, TCP and UDP are layer 4, HTTP and DNS are layer 7.
- Use the layers as a checklist when something breaks.


Map common protocols such as Ethernet, IP, TCP, DNS and HTTP to the layers of the OSI and TCP/IP models.

The OSI and TCP/IP models

Understanding the OSI Model - N10-008 CompTIA Network+ : 1.1

TCP/IP Model Explained | Cisco CCNA 200-301

## Why it matters

Every device on an IP network needs an address, and every address belongs to a **subnet**. Cloud engineers carve virtual networks into subnets, security engineers write firewall rules for address ranges, and database administrators decide which networks may connect to a database. If you cannot read `10.0.4.0/22`, you cannot do any of these safely.

## An IPv4 address is 32 bits

`192.168.1.10` is four **octets** (8 bits each) written in decimal, separated by dots. Each octet ranges from 0 to 255. Underneath, it is one 32-bit number:

```text
192      .168      .1        .10
11000000 .10101000 .00000001 .00001010
```

An address has two parts: the **network part** (which network the device is on) and the **host part** (which device on that network).

## The subnet mask and CIDR prefix

The **subnet mask** says where the network part ends. Its 1-bits cover the network part:

```text
255.255.255.0  =  11111111.11111111.11111111.00000000
```

That mask has 24 one-bits, so it is written as the **CIDR prefix** `/24`. `192.168.1.10/24` means "the first 24 bits are the network".

| Prefix | Mask | Addresses | Usable hosts |
|---|---|---|---|
| /8 | 255.0.0.0 | 16,777,216 | 16,777,214 |
| /16 | 255.255.0.0 | 65,536 | 65,534 |
| /24 | 255.255.255.0 | 256 | 254 |
| /26 | 255.255.255.192 | 64 | 62 |
| /30 | 255.255.255.252 | 4 | 2 |

Each extra prefix bit halves the subnet.

## Network, broadcast and usable addresses

In each subnet, the first address (host bits all 0) is the **network address** and the last (host bits all 1) is the **broadcast address**. Neither is given to a device, so usable hosts = 2^(32 - prefix) - 2. (Cloud providers often reserve a few more; AWS reserves five per subnet.)

## Worked example 1: a /24

`192.168.1.10/24`: the network is `192.168.1.0`, the broadcast is `192.168.1.255`, and hosts run from `192.168.1.1` to `192.168.1.254`. A device at `192.168.2.5` is on a different network, so traffic to it must go through a router (your **default gateway**).

## Worked example 2: a /26

`192.168.1.130/26`. A /26 mask is `255.255.255.192`, so the last octet's block size is 256 - 192 = 64. The subnets start at .0, .64, .128 and .192. 130 falls in the block starting at 128, so:

- network: `192.168.1.128`
- broadcast: `192.168.1.191` (the next block starts at .192)
- usable: `192.168.1.129` to `192.168.1.190`, 62 hosts

The same answer comes from a bitwise AND of the address and the mask, which is what computers do and what you will code in the activity:

```text
130 = 10000010
192 = 11000000
AND = 10000000 = 128
```

## Worked example 3: same subnet or not?

A server is at `10.0.4.20/22` and a database at `10.0.7.200`. Are they on the same subnet? A /22 has 22 network bits, so the third octet's block size is 256 - 252 = 4: blocks start at 4, 8, 12 and so on. 4 and 7 both fall in the block 4 to 7, so the subnet is `10.0.4.0` to `10.0.7.255` and they can talk directly without a router. A host at `10.0.8.1` would be in the next block and would need the gateway.

## Private and special ranges

RFC 1918 reserves three ranges for private networks. They are not routed on the public internet:

- `10.0.0.0/8`
- `172.16.0.0/12` (172.16.0.0 to 172.31.255.255)
- `192.168.0.0/16`

Also worth knowing: `127.0.0.1` is **loopback** (this computer), and `169.254.x.x` is a self-assigned address that usually means DHCP failed.

## IPv6 in one paragraph

IPv4 has only about 4.3 billion addresses, so IPv6 uses 128 bits, written in hexadecimal groups such as `2001:db8::1` (`::` replaces a run of zero groups). Subnets are usually `/64`. The same network/host idea applies.

## Common mistakes

- **Giving a device the network or broadcast address.**
- **Overlapping subnets.** `10.0.0.0/16` already contains `10.0.5.0/24`; using both in one design causes routing confusion. This matters when you connect two cloud networks.
- **Thinking /24 always means the last octet.** A /22 such as `10.0.4.0/22` spans `10.0.4.0` to `10.0.7.255`.
- **Mixing up mask and prefix.** `255.255.255.192` is /26, not /192.

## Quick recap

- IPv4 = 32 bits, four octets; the prefix says how many bits are network.
- Network address = address AND mask; usable hosts = 2^(32 - prefix) - 2.
- Know the RFC 1918 private ranges, loopback and 169.254.

## Try it

Open the **Do** tab and finish a small JavaScript subnet calculator.


Read an IPv4 address, subnet mask and CIDR prefix, and work out a subnet's network address and host count.

IP addresses and subnets

Basics of IP Addressing

Subnetting Explained: Networking Basics

## Why it matters

An IP address gets data to the right computer, but a server runs many programs at once: a web server, an SSH server, maybe a database. **Ports** get data to the right program. Choosing between **TCP** and **UDP** decides whether that data arrives reliably or quickly. Firewall rules, cloud security groups and "connection refused" errors are all about ports.

## Ports

A port is a 16-bit number (0 to 65535) at the transport layer. A connection is identified by five things: protocol, source IP, source port, destination IP, destination port.

- **Well-known ports (0 to 1023)** are used by standard services.
- **Registered ports (1024 to 49151)** are used by many applications, such as databases.
- **Ephemeral ports (usually 49152 to 65535)** are picked at random by your computer for the client side of a connection.

Ports worth memorising:

| Port | Protocol | Service |
|---|---|---|
| 22 | TCP | SSH |
| 25 | TCP | SMTP (mail between servers) |
| 53 | UDP and TCP | DNS |
| 67/68 | UDP | DHCP |
| 80 | TCP | HTTP |
| 123 | UDP | NTP (time) |
| 443 | TCP (and UDP for HTTP/3) | HTTPS |
| 3306 | TCP | MySQL |
| 5432 | TCP | PostgreSQL |
| 3389 | TCP | Remote Desktop |

IANA keeps the official registry, but a port number is only a convention: you can run a web server on 8080. What matters is that client and server agree.

## TCP: reliable, ordered, connection-based

TCP sets up a connection before sending data, with a **three-way handshake**:

1. Client sends **SYN** ("I want to connect, my sequence number starts at x").
2. Server replies **SYN-ACK**.
3. Client sends **ACK**. The connection is open.

After that, TCP numbers every byte, the receiver acknowledges what it got, and anything lost is resent. TCP also puts data back in order and slows down when the network is congested (**flow and congestion control**). The cost is extra round trips and waiting: one lost packet holds up everything behind it.

Use TCP when every byte must arrive: web pages, file transfers, email, SSH, database queries.

## UDP: fast, simple, connectionless

UDP just sends **datagrams**. There is no handshake, no acknowledgement, no resending and no ordering. Its header is 8 bytes versus TCP's 20 or more.

UDP beats TCP when:

- **Late data is useless.** In a video call or online game, a resent packet from half a second ago is worse than a small glitch.
- **Messages are tiny.** A DNS question fits in one packet; a handshake would triple the time.
- **The application handles reliability itself.** QUIC, the protocol under HTTP/3, runs on UDP and adds its own faster reliability.

## Worked example: two connections at once

You open two browser tabs to the same site. Your laptop (192.168.1.20) creates two TCP connections:

```text
192.168.1.20:52814  ->  93.184.215.14:443
192.168.1.20:52815  ->  93.184.215.14:443
```

The server tells them apart by the source port. Meanwhile your laptop asks DNS a question over UDP:

```text
192.168.1.20:61002  ->  192.168.1.1:53   (UDP)
```

## Listening, open and closed

A server program **listens** on a port. If you connect to a port where nothing listens, the computer answers TCP with a reset and you see "connection refused". If a firewall silently drops the traffic, you see a **timeout** instead. That difference is a useful clue: refused means you reached the machine; timeout often means a firewall or routing problem.

## Common mistakes

- **Opening more ports than needed.** Every listening port is attack surface. Expose only what a service needs, and only to the networks that need it (for example, a database port only to the app servers, never to the whole internet).
- **Assuming DNS is UDP only.** Large responses and zone transfers use TCP 53.
- **Calling UDP "unreliable" as if it were broken.** It is simply best-effort; for real-time traffic that is the right trade.
- **Confusing the port with the protocol.** HTTPS is usually on 443, but a port number does not guarantee what is running there.

## Quick recap

- Ports (0 to 65535) deliver data to the right program; clients use random ephemeral ports.
- TCP: handshake, acknowledgements, retransmission, ordering. Reliable but slower.
- UDP: no handshake or retransmission. Fast and light, good for DNS, voice, video and games.
- "Refused" vs "timed out" tells you whether you reached the host.


Explain what ports are, how TCP gives reliable delivery, and when UDP is the better choice.

Ports, TCP, and UDP

Network Ports Explained

TCP vs UDP Comparison

The layer models, IPv4 addresses and subnets, and how ports, TCP and UDP deliver data to the right program.

How Networks Work

Look up a name: run `nslookup example.com` (or `dig example.com`). Write down the IP address(es) and which DNS server answered.

Ask for other record types: `nslookup -type=MX gmail.com` and `nslookup -type=AAAA google.com` (or `dig gmail.com MX`, `dig google.com AAAA`). Note what each record type returns.

Find a CNAME: run `nslookup www.github.com` (or `dig www.github.com`) and note any alias (canonical name) before the final address.

Ask a specific resolver: `nslookup example.com 1.1.1.1` (or `dig @1.1.1.1 example.com`). Compare the answer with step 1.

If you have dig, run `dig +trace example.com` and identify the root servers, the .com servers and the example.com name servers in the output. (Without dig, read the trace walkthrough in the lesson instead.)

With dig, look at the TTL value in an answer, run the same query again a minute later, and note how the TTL has gone down (served from cache).

Look up a name that does not exist, such as `no-such-name.example.com`, and note the NXDOMAIN response.

## Why it matters

People remember names; networks route by IP address. The **Domain Name System (DNS)** translates one to the other. It is so central that "it's always DNS" is a running joke among engineers: a wrong record, an expired domain or a slow resolver can take down a service whose servers are perfectly healthy. Cloud and security engineers edit DNS records, and attackers abuse DNS for phishing and data theft, so you need to know how a lookup works.

## Names are a tree

A name such as `www.example.com.` is read right to left:

- `.` the **root** (usually hidden)
- `com` a **top-level domain (TLD)**
- `example` a domain registered under .com
- `www` a name inside that domain

Each level is run by different name servers. The root servers know who runs `.com`; the `.com` servers know who runs `example.com`; the `example.com` name servers are **authoritative** and hold the actual records.

## Who does the work

- Your computer has a **stub resolver**: it just asks one server and waits.
- A **recursive resolver** (your ISP's, your router's, or a public one such as 1.1.1.1 or 8.8.8.8) does the legwork and caches answers.
- **Authoritative servers** give the final answer for their zone.

## Worked example: tracing a lookup

You visit `www.example.com` with empty caches:

1. Your laptop checks its own cache and the hosts file. Nothing.
2. It asks the recursive resolver configured by DHCP, say `192.168.1.1`, over UDP port 53.
3. The resolver asks a **root server**: "where is www.example.com?" The root replies: "I don't know, but here are the .com servers."
4. The resolver asks a **.com server**, which replies with the name servers for example.com.
5. The resolver asks an **example.com name server**, which answers: `www.example.com A 93.184.215.14`, with a TTL.
6. The resolver caches the answer for the TTL and returns it to your laptop, which caches it too.

(The real address you see for example.com may differ; addresses in these lessons are illustrations.) The next visitor using that resolver gets the answer from cache in a millisecond or two.

## Record types you will meet

| Type | Holds | Example |
|---|---|---|
| A | IPv4 address | `example.com A 93.184.215.14` |
| AAAA | IPv6 address | `example.com AAAA 2606:2800:21f:cb07:6820:80da:af6b:8b2c` |
| CNAME | alias to another name | `www.shop.com CNAME shop.example-cdn.net` |
| MX | mail servers for a domain | `gmail.com MX 5 gmail-smtp-in.l.google.com` |
| TXT | free text: verification, SPF, DKIM | `"v=spf1 include:_spf.google.com ~all"` |
| NS | the zone's name servers | `example.com NS a.iana-servers.net` |

## Querying DNS yourself

```bash
nslookup example.com              # works on Windows, macOS, Linux
dig example.com                   # macOS / Linux, more detail
dig gmail.com MX                  # a specific record type
dig @1.1.1.1 example.com          # ask a specific resolver
dig +trace example.com            # follow the delegation from the root
```

In `dig` output, the ANSWER section shows the records, with the TTL in seconds:

```text
;; ANSWER SECTION:
example.com.   3600   IN   A   93.184.215.14
```

## TTL and caching

The **time to live (TTL)** tells resolvers how long to cache a record. Long TTLs (hours) reduce load and speed up lookups; short TTLs (60 to 300 seconds) let you move a service quickly. Before a planned migration, engineers lower the TTL a day ahead so the change spreads fast. "DNS propagation" is mostly old cached answers expiring.

## Security notes

Classic DNS is unencrypted, so anyone on the path can see and potentially tamper with lookups. **DNS over HTTPS (DoH)** and **DNS over TLS (DoT)** encrypt the query to the resolver, and **DNSSEC** lets resolvers verify that answers are signed by the zone owner.

## Common mistakes

- **Editing a record and expecting instant change** while the old TTL is still cached.
- **Putting a CNAME at the zone apex** (`example.com` itself). Standard DNS does not allow it; providers offer ALIAS or flattening records instead.
- **Blaming the server** when the problem is a resolver: test with a second resolver (`dig @1.1.1.1`).
- **Forgetting the hosts file**, which overrides DNS on that one machine.

## Quick recap

- DNS turns names into addresses through a tree: root, TLD, authoritative.
- A recursive resolver does the lookups and caches by TTL.
- Know A, AAAA, CNAME, MX, TXT and NS records.
- Use `nslookup` and `dig` to check what DNS really returns.

## Try it

Open the **Do** tab and trace a few lookups from your own computer.


Trace how a name like www.example.com becomes an IP address, and query DNS yourself with nslookup or dig.

How DNS Works - Computerphile

How a DNS Server (Domain Name System) works.

## Why it matters

When you join a Wi-Fi network, your phone gets an IP address, a gateway and DNS servers within a second, and then reaches the internet even though dozens of devices in the house share one public address. Two services make that happen: **DHCP** hands out the settings, and **NAT** shares the address. Both appear in cloud networks too (managed DHCP options and NAT gateways), and both are common sources of "no internet" problems.

## DHCP: automatic configuration

A device needs four settings to use an IP network:

1. an **IP address**
2. a **subnet mask**
3. a **default gateway** (the router that leads off the local network)
4. one or more **DNS servers**

Typing these by hand on every device would be slow and error-prone, so the **Dynamic Host Configuration Protocol** does it. On a home network, the DHCP server is built into the router.

### DORA: the four-message exchange

DHCP uses UDP (server port 67, client port 68). A device that has no address yet goes through **DORA**:

1. **Discover:** the client broadcasts "is there a DHCP server?" (it has no address, so it sends from `0.0.0.0` to `255.255.255.255`).
2. **Offer:** the server offers an address, for example `192.168.1.23`, plus mask, gateway and DNS.
3. **Request:** the client broadcasts "I'd like 192.168.1.23", so other servers know their offers were declined.
4. **Acknowledge:** the server confirms, and the client starts using the address.

### Leases

Addresses are **leased**, not given forever. A typical home lease is 24 hours. The client renews at about halfway through. When devices leave, their addresses return to the **pool**. A router often hands out a range such as `192.168.1.100` to `192.168.1.199`.

A **reservation** (static lease) makes the router always give the same address to one device's MAC address, which is handy for a printer or a home server.

If no server answers, the device gives itself a `169.254.x.x` address and cannot reach the internet. That address is a strong clue that DHCP failed.

## NAT: sharing one public address

Your ISP usually gives your home **one public IPv4 address**. Inside, devices use private RFC 1918 addresses such as `192.168.1.x`, which are not routable on the internet. **Network Address Translation (NAT)** on the router rewrites addresses as traffic leaves and returns.

The form used at home is **PAT** (port address translation, also called NAT overload): many inside devices share the one public address, told apart by port numbers.

### Worked example: the NAT table

Your public address is `203.0.113.7`. Two devices browse at the same time:

```text
Inside (private)        ->  Outside (public)          ->  Server
192.168.1.23:52814      ->  203.0.113.7:40001         ->  93.184.215.14:443
192.168.1.40:52814      ->  203.0.113.7:40002         ->  93.184.215.14:443
```

Both devices happened to pick source port 52814. The router rewrites each to a unique public port and records the mapping. When a reply arrives at `203.0.113.7:40002`, the router looks it up and forwards it to `192.168.1.40:52814`.

### Side effects of NAT

- **Inbound connections are blocked by default.** An outside device cannot start a connection to `192.168.1.40` because the router has no mapping for it. This acts like a basic firewall, but it is not a security control to rely on.
- **Port forwarding** creates a permanent mapping (for example public port 8443 to `192.168.1.50:443`) to expose one inside service. Do it only when you understand the risk.
- **Carrier-grade NAT (CGNAT):** some ISPs put customers behind another layer of NAT, so your router's "WAN" address may itself be private (often in `100.64.0.0/10`).
- **IPv6** has enough addresses that NAT is generally not needed; firewalls do the filtering.

## In the cloud

A cloud virtual network uses private subnets too. Instances in a private subnet reach the internet through a **NAT gateway**, which lets them download updates while blocking inbound connections. NAT gateways are usually billed per hour and per gigabyte, so they are a common surprise on a cloud bill.

## Common mistakes

- **Setting a static IP inside the DHCP pool.** The router may later hand the same address to another device, causing an address conflict. Use a reservation or an address outside the pool.
- **Running two DHCP servers on one network** (for example, a second router left in router mode). Devices get conflicting gateways.
- **Confusing your private and public addresses.** `ipconfig`/`ip addr` shows the private one; a "what is my IP" site shows the public one.
- **Treating NAT as a firewall.** Keep a real firewall enabled.

## Quick recap

- DHCP gives devices an address, mask, gateway and DNS servers via Discover, Offer, Request, Acknowledge, on a lease.
- NAT (PAT) lets many private addresses share one public address by rewriting ports.
- 169.254.x.x means DHCP failed; inbound traffic needs port forwarding through NAT.


Explain how a home router hands out addresses with DHCP and shares one public address with NAT.

DHCP and NAT

DHCP Explained - Dynamic Host Configuration Protocol

NAT Explained - Network Address Translation

Open any HTTPS site you use (for example, a news site). Click the icon left of the address bar and open the certificate details (in Chrome: "Connection is secure", then "Certificate is valid"; in Firefox: "Connection secure", "More information", "View Certificate").

Record the certificate's subject (Common Name and Subject Alternative Names), the issuer (which certificate authority signed it) and the validity dates. How many days until it expires?

Find the certificate chain (Certification Path or the tabs along the top). Write down the leaf, intermediate and root certificate names.

Open the developer tools (F12 or Cmd+Option+I), go to the Network tab, and reload the page.

Click the first request (the page itself). Note the request method, the status code, and the `content-type` and `cache-control` response headers.

Find one request that returned a 3xx or 304 status, or type the site's address with `http://` to see a redirect to HTTPS. Note the `location` header if there is one.

Visit https://expired.badssl.com/ (a test site made for this purpose) and read the browser warning. Do not click through; note which error it reports.

## Why it matters

Almost every application talks over **HTTP**, and almost all of that traffic is protected by **TLS** (HTTP over TLS is **HTTPS**). APIs, cloud consoles, database admin panels and model-serving endpoints all use it. Reading status codes and headers is a daily debugging skill, and understanding certificates helps you fix "your connection is not private" errors and spot attacks.

## HTTP: requests and responses

HTTP is a text-based request/response protocol. The client sends a **request**:

```http
GET /docs/start HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
```

The server sends a **response**:

```http
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600
Content-Length: 5120

<!doctype html> ...
```

**Methods** say what the client wants: `GET` reads, `POST` creates or submits, `PUT`/`PATCH` update, `DELETE` removes.

**Status codes** are grouped by the first digit:

| Range | Meaning | Common examples |
|---|---|---|
| 2xx | success | 200 OK, 201 Created, 204 No Content |
| 3xx | redirect or cached | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | client error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx | server error | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout |

HTTP is **stateless**: each request stands alone. Logins work by the server setting a **cookie** that the browser sends back on later requests.

Versions: HTTP/1.1 sends one request at a time per connection, HTTP/2 multiplexes many over one TCP connection, and HTTP/3 runs over QUIC on UDP.

## The problem TLS solves

Plain HTTP crosses many networks (your Wi-Fi, your ISP, other carriers). Anyone on the path could read passwords or change the page. TLS provides three things:

1. **Confidentiality:** traffic is encrypted.
2. **Integrity:** tampering is detected.
3. **Authentication:** you are talking to the real `example.com`, proven by a certificate.

## Certificates and trust

A **certificate** binds a public key to one or more names (listed in the Subject Alternative Names). It is signed by a **certificate authority (CA)**. Your operating system and browser ship with a list of trusted **root CAs**. Sites usually send a **chain**: their leaf certificate plus an intermediate certificate, which was signed by a root you already trust.

The browser checks that:

- the chain leads to a trusted root,
- the name you typed matches the certificate,
- today is within the validity dates,
- the certificate has not been revoked.

Free CAs such as Let's Encrypt issue certificates valid for 90 days or less and renew them automatically, so expiry problems are usually an automation failure.

## The TLS 1.3 handshake, simplified

1. **ClientHello:** the browser lists supported cipher suites and sends a key share.
2. **ServerHello:** the server picks a cipher suite, sends its key share, its certificate and a signature proving it holds the private key.
3. Both sides compute the same **session keys** from the key shares (a Diffie-Hellman exchange). From here on, everything is encrypted with fast symmetric encryption.
4. The HTTP request travels inside the encrypted tunnel.

TLS 1.3 needs one round trip before data flows; TLS 1.0 and 1.1 are obsolete and disabled by modern browsers.

## What an observer still sees

With HTTPS, someone on your network cannot see page contents, paths, cookies or form data. They can still see your IP address, the server's IP address, timing and volume, and usually the site's name (from DNS and the Server Name Indication field), unless encrypted DNS and Encrypted Client Hello are in use.

## Worked example: reading a failure

A user reports `NET::ERR_CERT_DATE_INVALID`. You open the certificate and see it expired yesterday: the renewal job failed. A different error, `ERR_CERT_COMMON_NAME_INVALID`, would mean the certificate does not list the name used, for example a certificate for `example.com` served on `api.example.com`.

## Common mistakes

- **Treating the padlock as "safe site".** It means the connection is encrypted to that name; phishing sites have valid certificates too.
- **Clicking through certificate warnings** on public networks.
- **Mixing HTTP resources into an HTTPS page** (mixed content), which browsers block.
- **Reading 401 and 403 as the same.** 401: not authenticated (log in); 403: authenticated but not allowed.

## Quick recap

- HTTP: methods, status codes, headers; stateless, with cookies for sessions.
- TLS adds encryption, integrity and server authentication.
- Certificates chain up to a trusted root CA and must match the name and dates.

## Try it

Open the **Do** tab to inspect a certificate and real HTTP traffic in your browser.


Follow an HTTP request and response, explain what TLS adds, and inspect a website's certificate in your browser.

HTTP and TLS

SSL, TLS, HTTPS Explained

TLS Handshake Explained - Computerphile

DNS, DHCP and NAT, and HTTP with TLS: the services that make a network usable and secure.

Core Network Services

Show your configuration: `ipconfig /all` (Windows), `ip addr` and `ip route` (Linux) or `ifconfig` and `netstat -rn` (macOS). Write down your IP address, subnet mask or prefix, default gateway and DNS servers.

Ping yourself: `ping 127.0.0.1` (add `-c 4` on macOS/Linux). This tests your own network stack.

Ping your default gateway (from step 1). Note the round-trip times.

Ping a public IP address: `ping 1.1.1.1`. Then ping a name: `ping example.com`. If the IP works but the name fails, which layer is the problem?

Trace the route: `tracert example.com` (Windows) or `traceroute example.com` (macOS/Linux). Count the hops, note where the times jump, and note any `* * *` lines.

List listening ports: `netstat -an` (Windows: also try `netstat -ano` to see process IDs; Linux: `ss -tulpn`; macOS: `netstat -an | grep LISTEN`). Find two listening ports and look up which service usually uses them.

List established connections (`netstat -an` and look for ESTABLISHED). Open a website and run it again: find the new connections to port 443.

Write a short troubleshooting note: for each layer you tested (local stack, LAN, internet, DNS, application), what you ran and what the result showed.

## Why it matters

"I can't connect" is one of the most common tickets in IT, cloud and database work. Three built-in tools answer most of it in a few minutes: **ping** (can I reach it?), **traceroute** (where does the path break?), and **netstat** or **ss** (what is my computer connected to and listening on?). The skill is not the commands themselves but running them in a sensible order and reading the results.

## Start with your own configuration

Before testing anything remote, check what your machine thinks its settings are:

```bash
ipconfig /all          # Windows
ip addr; ip route      # Linux
ifconfig; netstat -rn  # macOS
```

Look for: an IP address in the expected range (not `169.254.x.x`), a subnet mask, a **default gateway**, and DNS servers.

## ping: is it reachable?

`ping` sends ICMP echo requests and reports replies and round-trip time:

```text
$ ping -c 4 1.1.1.1
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=11.9 ms
...
4 packets transmitted, 4 received, 0% packet loss
```

(On Windows `ping` sends 4 by default; on macOS/Linux it runs until Ctrl+C unless you add `-c 4`.)

Read the result:

- **Replies with low, steady times:** reachable.
- **Request timed out:** no reply. The host may be down, the path broken, or a firewall may block ICMP. Many servers block ping on purpose, so a timeout alone does not prove a server is down.
- **Destination host unreachable:** a router (or your own machine) has no route.
- **Packet loss or very uneven times:** a congested or flaky link, often Wi-Fi.

## traceroute: where does it break?

Every IP packet has a **TTL** (hop limit) that each router decrements; at zero, the router discards it and sends back an ICMP "time exceeded". `traceroute` (Windows: `tracert`) sends packets with TTL 1, 2, 3 and so on, so each router along the path reveals itself:

```text
$ traceroute example.com
 1  192.168.1.1     1.8 ms
 2  10.40.0.1       9.7 ms
 3  * * *
 4  72.14.215.85   14.2 ms
 ...
11  93.184.215.14  21.3 ms
```

- Hop 1 is your router. If that fails, the problem is in your home or office.
- `* * *` on a middle hop is usually just a router that does not answer traceroute; if later hops answer, ignore it.
- If every hop after a certain point is `* * *`, the path breaks there (or a firewall drops the probes).
- A big, sustained jump in time from one hop onward points to a slow link at that hop.

## netstat and ss: what is my machine doing?

```bash
netstat -an            # all connections and listening ports, numeric
netstat -ano           # Windows: add the process ID
ss -tulpn              # Linux: TCP/UDP listening sockets with process
```

Look for states: **LISTEN** (a service waiting for connections), **ESTABLISHED** (an active connection), **TIME_WAIT** (recently closed). This answers "is my web server actually listening on 8080?" and "what is this program connected to?".

## Worked example: a layered diagnosis

A user cannot open an internal web app at `http://intranet.local:8080`.

1. `ipconfig` shows `192.168.1.57/24`, gateway `192.168.1.1`. Settings look fine.
2. `ping 192.168.1.1` replies. The local network works.
3. `ping 1.1.1.1` replies. Internet routing works.
4. `nslookup intranet.local` returns NXDOMAIN. **DNS is the problem.** The user's DNS server is a public resolver that does not know internal names.
5. The fix is to use the company DNS server. If DNS had worked, the next step would be `netstat`/`ss` on the server to confirm something LISTENs on 8080, and then the firewall.

The order matters: you proved each lower layer before moving up, and stopped at the first failure.

## Other handy tools

- `nslookup` / `dig` for DNS (previous module).
- `curl -v https://example.com` shows the TCP connection, TLS handshake and HTTP response in one go.
- `Test-NetConnection example.com -Port 443` in PowerShell, or `nc -vz example.com 443` on macOS/Linux, checks one TCP port.

## Common mistakes

- **Concluding a server is down because ping fails.** Try the actual service port.
- **Panicking over `* * *` in the middle of a traceroute** when the destination still answers.
- **Skipping the local checks** and debugging the internet when the laptop has a 169.254 address.
- **Scanning or tracing networks you do not own** beyond normal use. Probing other people's systems can break policies or laws.

## Quick recap

- Check your own config first, then ping loopback, gateway, public IP, then a name.
- traceroute shows each hop; look at where replies stop or times jump.
- netstat/ss shows listening ports and connections.
- Work up the layers and stop at the first failure.

## Try it

Open the **Do** tab and run a full troubleshooting pass on your own machine.


Use ping, traceroute and netstat to diagnose a connectivity problem one layer at a time.

ping, traceroute, and netstat

PING and TRACERT (traceroute) networking commands

NETSTAT Command Explained

Find your router's address (your default gateway, from `ipconfig` or `ip route`) and your public address (search "what is my IP" in a browser). Are they the same? If not, why?

Identify the physical boxes: modem (or ONT for fibre), router, any separate access points, mesh nodes or switches. Note which cables connect what.

If it is your router, log in to its admin page (often printed on its label) and open the list of connected devices (DHCP clients). Otherwise, use your phone's or laptop's list of devices it can see.

List each device with its name, IP address and whether it is wired or wireless. Note any device you cannot identify.

Check the Wi-Fi settings on your laptop or phone: network name (SSID), band (2.4 GHz or 5 GHz, sometimes 6 GHz) and security type (WPA2 or WPA3).

Walk to the far side of your home and compare signal strength or speed (a speed test site, or the signal bars) with standing next to the router.

Draw the map on paper or in a drawing tool: internet, modem, router, switches/access points, devices, with IP addresses and bands.

Write down two improvements, for example: change a default admin password, turn off WPS, put smart-home devices on a guest network, or move the router to a central spot.

## Why it matters

Your home network is a full working network in miniature: addressing, DHCP, NAT, DNS, wireless and security, all in one box. Understanding it makes you better at supporting remote colleagues ("my VPN keeps dropping"), helps you secure your own devices, and gives you a lab you already own. Cloud virtual networks reuse the same ideas, just without the antennas.

## The boxes and what they do

- **Modem** (cable or DSL) or **ONT** (fibre): converts the ISP's signal to Ethernet. It is the edge of your ISP's network.
- **Router:** routes between your private network and the internet. It also runs NAT, the DHCP server, a firewall, and usually a DNS forwarder.
- **Switch:** connects wired devices on the same network (layer 2). Most home routers have a small switch built in (the LAN ports).
- **Wireless access point (AP):** bridges Wi-Fi devices onto the wired network. Also usually built into the router.
- **Mesh nodes:** several APs that cooperate to cover a larger home under one network name.

Many ISPs supply a single "gateway" that combines all of these.

## A typical home layout

```text
Internet
   |
[Modem/ONT] --- public address 203.0.113.7
   |
[Router: NAT, DHCP, firewall, Wi-Fi AP]  192.168.1.1
   |--- wired: desktop 192.168.1.20, TV 192.168.1.31
   |--- 5 GHz Wi-Fi: laptop 192.168.1.57, phone 192.168.1.58
   |--- 2.4 GHz Wi-Fi: smart plug 192.168.1.80, printer 192.168.1.90
```

Every inside device has a private address from DHCP and shares the public address through NAT.

## How Wi-Fi works, briefly

Wi-Fi (the IEEE 802.11 family) is layer 1 and 2 over radio. Devices and the AP take turns on a shared **channel**. Because only one device can transmit on a channel at a time, Wi-Fi speed is shared, and neighbours on the same channel slow each other down.

| Band | Range | Speed | Notes |
|---|---|---|---|
| 2.4 GHz | longest, passes walls best | lowest | crowded; only 3 non-overlapping channels (1, 6, 11) in most regions |
| 5 GHz | medium | high | many more channels |
| 6 GHz (Wi-Fi 6E/7) | shortest | highest | needs newer devices |

Generations you will see on boxes: Wi-Fi 5 (802.11ac), Wi-Fi 6/6E (802.11ax), Wi-Fi 7 (802.11be).

Signal strength drops with distance, walls (especially concrete and metal), floors, and interference from microwaves and other networks.

## Wi-Fi security

- **WPA3-Personal** is the current standard; **WPA2-Personal (AES)** is acceptable if devices do not support WPA3.
- **WEP and WPA (TKIP)** are broken; do not use them.
- **WPS** (push-button or PIN pairing) has a history of weaknesses; turning it off is a common hardening step.
- A long, unique Wi-Fi passphrase matters because anyone nearby can try to guess it offline after capturing a handshake.

Router admin hygiene matters just as much: change the default admin password, keep firmware updated (or choose a router that updates itself), and disable remote administration unless you need it.

## Guest networks and segmentation

A **guest network** puts visitors, and ideally smart-home ("IoT") devices, on a separate segment that cannot reach your laptops and file shares. This is a small-scale version of **network segmentation**, a core idea in security engineering: if one device is compromised, it should not reach everything.

## Worked example: "Wi-Fi is slow upstairs"

1. Check whether it is Wi-Fi or the internet: run a speed test next to the router. Fast there? The ISP is fine.
2. Upstairs, the laptop shows 2.4 GHz with one bar. Far from the router, it fell back to the longer-range band.
3. Options, cheapest first: move the router to a central, raised position away from metal; set a less crowded channel; add a wired access point or mesh node upstairs.
4. Re-test in both places and record the numbers.

## Common mistakes

- **Leaving the default router password**, or exposing the admin page to the internet.
- **Assuming more bars means faster.** Interference and crowded channels matter too.
- **Putting a second router in router mode** behind the first (double NAT, two DHCP servers). Use access-point mode instead.
- **Ignoring unknown devices** in the client list.

## Quick recap

- Modem/ONT, router (NAT, DHCP, firewall), switch and access point are separate roles, often in one box.
- 2.4 GHz reaches further; 5 and 6 GHz are faster but shorter range.
- Use WPA3 or WPA2-AES, change default passwords, update firmware, and segment guests and IoT.

## Try it

Open the **Do** tab and map your own home network.


Explain how a home router, Wi-Fi bands and security settings fit together, and map your own home network.

Wi-Fi and home networks

Routers vs. Switches vs. Access Points - And More

2.4 GHz vs 5 GHz WiFi: What is the difference?

Install Wireshark from https://www.wireshark.org/ (on Windows, accept the Npcap install; on macOS, accept the ChmodBPF helper). Open it and pick your active interface (the one with a moving traffic graph).

Start a capture, then in a terminal run `nslookup example.com`, and open https://example.com in your browser. Stop the capture after about 10 seconds.

Apply the display filter `dns` and find the query and its response. In the details pane, expand Ethernet, IP, UDP and DNS, and note the source and destination port and the answer address.

Apply the filter `tcp.flags.syn == 1` and find the SYN and SYN-ACK to the address from the DNS answer. Right-click a packet, choose Follow > TCP Stream, and confirm the content is unreadable (TLS-encrypted).

Apply the filter `tls.handshake.type == 1` to find the Client Hello, and look for the server_name (SNI) field. What does it reveal even though the traffic is encrypted?

Open Statistics > Protocol Hierarchy and note the three most common protocols in your capture.

Delete or securely store the capture file when you are done: captures can contain sensitive data from your own machine.

## Why it matters

Every tool so far gives you a summary. A **packet capture** shows the actual frames on the wire, so you can see exactly what a device sent and what came back. Security engineers use captures to investigate suspicious traffic, network and cloud engineers use them to prove where a connection fails, and database administrators use them to debug slow or dropped client connections. **Wireshark** is the free, standard tool.

## Before you capture: rules

Capture only traffic you are authorised to see: your own computer on your own network, or a lab you are allowed to use. On a work or school network, ask first; capturing other people's traffic can break the law and policy even if the tool makes it easy. Captures can also contain your own secrets (cookies, internal names), so store them carefully and delete them when done.

## How a capture works

Your network adapter normally hands the operating system only the frames meant for it. A capture library (**Npcap** on Windows, **libpcap** on macOS/Linux) copies frames as they pass through the adapter. On switched wired networks you see your own traffic plus broadcasts; on Wi-Fi you normally see only your own traffic. Captures are saved as `.pcapng` files.

The command-line equivalent is `tcpdump`:

```bash
sudo tcpdump -i en0 -n port 53        # DNS on interface en0
sudo tcpdump -i eth0 -n -w out.pcap   # save to a file for Wireshark
```

## The Wireshark window

1. **Packet list:** one row per frame: number, time, source, destination, protocol, length, info.
2. **Packet details:** the layers of the selected frame, one expandable line each: Frame, Ethernet II, Internet Protocol, TCP or UDP, then the application protocol. This is the OSI model made visible.
3. **Packet bytes:** the raw hex.

## Filters

There are two kinds:

- **Capture filters** (BPF syntax, set before you start) decide what is recorded: `port 53`, `host 192.168.1.1`.
- **Display filters** (set after) decide what is shown, and are far more flexible:

```text
dns                          DNS only
ip.addr == 93.184.215.14     to or from one address
tcp.port == 443              HTTPS traffic
tcp.flags.syn == 1           connection attempts
tcp.analysis.retransmission  resent segments (a sign of loss)
http || dns                  combine with or
!(arp || mdns)               hide noise
```

The filter bar turns green when the syntax is valid.

## Worked example: reading a DNS lookup

You capture while running `nslookup example.com` and filter on `dns`:

```text
No.  Source         Destination    Protocol  Info
12   192.168.1.57   192.168.1.1    DNS       Standard query 0x3a1f A example.com
13   192.168.1.1    192.168.1.57   DNS       Standard query response 0x3a1f A example.com A 93.184.215.14
```

Expanding packet 12: **Ethernet II** shows your MAC and the router's MAC; **IPv4** shows the two IP addresses and a TTL; **UDP** shows source port 58123 and destination port 53; **DNS** shows the transaction ID 0x3a1f and the question. Packet 13 has the same ID, which is how your computer matches the answer to the question.

## Worked example: a TCP handshake

Filter `tcp.port == 443` after opening a site:

```text
21  192.168.1.57 -> 93.184.215.14  TCP  52814 -> 443 [SYN]
22  93.184.215.14 -> 192.168.1.57  TCP  443 -> 52814 [SYN, ACK]
23  192.168.1.57 -> 93.184.215.14  TCP  52814 -> 443 [ACK]
24  192.168.1.57 -> 93.184.215.14  TLSv1.3  Client Hello
```

The time between 21 and 22 is the network round trip. If you saw SYNs repeated with no SYN-ACK, a firewall or a dead server would be the suspect; a reply with `[RST, ACK]` means the host answered but nothing listens on that port.

Follow TCP Stream on an HTTPS connection shows unreadable bytes: TLS works. The Client Hello still shows the **SNI** (server name), which is why an observer can usually tell which site you visited.

## Common mistakes

- **Capturing everything for an hour** and drowning. Reproduce the problem, capture for seconds, then filter.
- **Confusing capture and display filter syntax** (`port 53` vs `udp.port == 53`).
- **Expecting to see other devices' Wi-Fi traffic.** You normally see only your own.
- **Sharing a capture file** without checking what personal data it holds.

## Quick recap

- Wireshark shows every frame with its layers decoded: Ethernet, IP, TCP/UDP, application.
- Use display filters (`dns`, `tcp.port == 443`, `tcp.flags.syn == 1`) to find what matters.
- A handshake, a reset or repeated SYNs tell you exactly where a connection fails.
- Capture only what you are authorised to capture, and handle files as sensitive.

Next step if you enjoyed this course: CompTIA Network+ is a common vendor-neutral certification; see https://www.comptia.org/certifications/network for the current exam details (Checked on 2026-10-23).

## Try it

Open the **Do** tab and capture and read your own DNS and HTTPS traffic.


Capture your own traffic in Wireshark, filter it, and read the layers of a DNS query and a TCP handshake.

Packet capture basics

Learn Wireshark! Tutorial for BEGINNERS

Learn Wireshark in 10 minutes - Wireshark Tutorial for Beginners

Diagnose problems with ping, traceroute and netstat, map your home network, and read packets in Wireshark.

Networking Fundamentals

About this course

Course content

How Networks Work

Core Network Services

Troubleshooting

Where this course leads

Next course on the path

Careers that use it