Skip to content

Commit 3f0c7cb

Browse files
Dude775claude
Dude775
and
claude
committed
docs(networking): add full module 03 - HTTP/HTTPS, DNS, ports, LB, TCP/IP
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
1 parent 7a2052e commit 3f0c7cb

8 files changed

Lines changed: 432 additions & 12 deletions

File tree

‎03-networking/README.md‎

Lines changed: 20 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,19 +1,28 @@
11
# Module 03: Networking - How Systems Talk
22

3-
> **Status**: Upcoming
4-
> **Prerequisites**: [Module 01 - Foundations](../01-foundations/)
3+
**Status**: In Progress
4+
**Prerequisites**: Module 01 - Foundations, Module 02 - Linux
55

66
## Overview
77

8-
Every DevOps tool communicates over a network. This module covers TCP/IP, DNS, HTTP, ports, firewalls, and load balancing - the invisible layer that connects everything.
8+
Every DevOps tool communicates over a network. This module covers the invisible layer
9+
that connects everything - from HTTP requests to DNS resolution to load balancing.
910

10-
## What Will Be Covered
11+
## Contents
1112

12-
- TCP/IP stack and the OSI model
13-
- DNS resolution and configuration
14-
- HTTP/HTTPS and TLS
15-
- Ports, firewalls, and security groups
16-
- Load balancing concepts
17-
- Network troubleshooting tools
13+
| File | Topic | Status |
14+
|------|-------|--------|
15+
| concepts/http-https.md | HTTP vs HTTPS, TLS, Status Codes | Done |
16+
| concepts/ports.md | Ports, Well-Known ports, Socket | Done |
17+
| concepts/dns.md | DNS Resolution, Records, Caching | Done |
18+
| concepts/load-balancing.md | LB algorithms, types, health checks | Done |
19+
| concepts/tcp-ip.md | TCP/IP model, 3-Way Handshake, UDP vs TCP | Done |
20+
| resources.md | All course-provided links (videos + articles) | Done |
1821

19-
Content will be added as the course progresses.
22+
## Iron Rules from This Module
23+
24+
- "DNS is the phonebook of the internet - without it, you know IPs, not names."
25+
- "HTTP is stateless. Every request starts from zero."
26+
- "IP gets you to the device. Port gets you to the application."
27+
- "TCP is reliable. UDP is fast. Choose accordingly."
28+
- "A Load Balancer eliminates the Single Point of Failure."

‎03-networking/concepts/dns.md‎

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
# DNS - Domain Name System
2+
3+
## What is DNS?
4+
5+
DNS is the "phonebook of the internet."
6+
Humans remember `google.com`. Computers communicate via `142.250.74.46`.
7+
DNS translates between the two.
8+
9+
Without DNS, you would need to memorize IP addresses for every website you visit.
10+
11+
## The 4 Actors in DNS Resolution
12+
13+
| Actor | Role | Analogy |
14+
|-------|------|---------|
15+
| DNS Resolver | Receives your query, hunts for the answer | The librarian |
16+
| Root Nameserver | Knows who handles each TLD (.com, .org) | Library index |
17+
| TLD Nameserver | Knows who handles specific domains under .com | Shelf in the library |
18+
| Authoritative Nameserver | Has the actual IP address for the domain | The specific book |
19+
20+
## The 8-Step DNS Lookup (uncached)
21+
22+
1. You type `example.com` in the browser
23+
2. Browser checks its own DNS cache
24+
3. OS checks its own DNS cache
25+
4. Query goes to the **DNS Resolver** (usually your ISP or 8.8.8.8)
26+
5. Resolver asks a **Root Nameserver**: "who handles .com?"
27+
6. Root server returns the address of the **.com TLD server**
28+
7. TLD server returns the address of `example.com`'s **Authoritative Nameserver**
29+
8. Authoritative Nameserver returns the **IP address**
30+
9. Browser opens a TCP connection to that IP and sends the HTTP request
31+
32+
In practice, most lookups skip steps 5-7 due to **caching**.
33+
34+
## DNS Caching and TTL
35+
36+
Every DNS record has a **TTL (Time To Live)** - how long it can be cached.
37+
38+
- Browser caches DNS (check in Chrome: `chrome://net-internals/#dns`)
39+
- OS caches DNS
40+
- Resolver caches DNS
41+
42+
When you change a server's IP, DNS propagation takes time = everyone's cache must expire.
43+
44+
## DNS Record Types
45+
46+
| Record | Purpose | Example |
47+
|--------|---------|---------|
48+
| A | Domain → IPv4 address | `google.com → 142.250.74.46` |
49+
| AAAA | Domain → IPv6 address | IPv6 equivalent |
50+
| CNAME | Domain → another Domain (alias) | `www.google.com → google.com` |
51+
| MX | Mail server for the domain | Gmail routing |
52+
| NS | Which nameservers are authoritative | Points to Cloudflare, etc. |
53+
| TXT | Text data (used for verification, SPF) | Domain ownership proof |
54+
55+
## Key Concepts
56+
57+
- DNS Resolver = asks the questions on your behalf
58+
- Authoritative Nameserver = the source of truth for a domain
59+
- A Record = most common, domain to IP
60+
- CNAME = alias, domain to domain (cannot be used on root domain)
61+
- TTL determines how long until a DNS change propagates

‎03-networking/concepts/http-https.md‎

Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,60 @@
1+
# HTTP / HTTPS
2+
3+
## What is HTTP?
4+
5+
HyperText Transfer Protocol - the application-layer protocol that defines how a
6+
client (browser) communicates with a server. It is **stateless** - every request
7+
is independent; the server remembers nothing between requests. This is why cookies
8+
and sessions exist.
9+
10+
## Request Structure
11+
12+
Every HTTP request has:
13+
- **Method**: GET (fetch), POST (send), PUT (update), DELETE (remove)
14+
- **Headers**: metadata - browser type, preferred format, auth tokens
15+
- **Body**: actual content (only in POST/PUT)
16+
17+
## Response Structure
18+
19+
Every HTTP response has:
20+
- **Status Code**: what happened
21+
- **Headers**: content type, caching rules, etc.
22+
- **Body**: the actual content (HTML, JSON, etc.)
23+
24+
## Status Codes
25+
26+
| Range | Meaning | Examples |
27+
|-------|---------|---------|
28+
| 2xx | Success | 200 OK, 201 Created |
29+
| 3xx | Redirect | 301 Moved Permanently |
30+
| 4xx | Client error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
31+
| 5xx | Server error | 500 Internal Server Error, 503 Service Unavailable |
32+
33+
## HTTPS = HTTP + TLS
34+
35+
HTTPS is not a different protocol - it is HTTP with an encryption layer (TLS) on top.
36+
37+
### How TLS Works (simplified)
38+
39+
1. Client says: "I want to connect securely"
40+
2. Server sends its certificate (proof of identity)
41+
3. Both sides agree on an encryption algorithm
42+
4. Keys are exchanged
43+
5. All subsequent communication is encrypted
44+
45+
### HTTP vs HTTPS
46+
47+
| Feature | HTTP | HTTPS |
48+
|---------|------|-------|
49+
| Default Port | 80 | 443 |
50+
| Encryption | None - plain text | TLS encrypted |
51+
| Security | Vulnerable to MITM | Protected |
52+
| Browser indicator | "Not Secure" | Padlock icon |
53+
| Performance | Slightly lighter | Slightly heavier (but modern TLS is fast) |
54+
55+
## Key Concepts to Remember
56+
57+
- HTTP is **stateless** - cookies/sessions are workarounds
58+
- HTTPS = HTTP + TLS (formerly SSL - same concept, newer name)
59+
- Status codes: 2xx success, 4xx client fault, 5xx server fault
60+
- GET = read, POST = write, PUT = update, DELETE = remove

‎03-networking/concepts/load-balancing.md‎

Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,60 @@
1+
# Load Balancing
2+
3+
## What is a Load Balancer?
4+
5+
A Load Balancer sits in front of multiple servers and distributes incoming
6+
requests among them. It acts as a "traffic cop" - no single server gets overwhelmed.
7+
8+
## Why It Exists: Problems Without a Load Balancer
9+
10+
- **Single Point of Failure**: if the one server goes down, the whole service is down
11+
- **Overloaded Server**: one server can only handle a limited number of requests
12+
- **No Scalability**: adding more servers doesn't help if all traffic hits only one
13+
14+
## How It Works
15+
16+
1. All incoming requests go to the Load Balancer first
17+
2. LB checks which servers are healthy (health checks)
18+
3. LB picks a server based on the chosen algorithm
19+
4. Request is forwarded; response returns through (or bypasses) the LB
20+
21+
## Distribution Algorithms
22+
23+
| Algorithm | Logic | Best For |
24+
|-----------|-------|---------|
25+
| Round Robin | Each request goes to the next server in rotation | Equal servers, stateless apps |
26+
| Least Connections | Next request goes to the server with fewest active connections | Variable-length sessions |
27+
| IP Hash | Same client IP always hits the same server | Session-heavy apps |
28+
| Weighted | Servers get traffic proportional to their assigned weight | Mixed server capacities |
29+
30+
## LB by OSI Layer
31+
32+
| Layer | What it sees | Capability |
33+
|-------|-------------|------------|
34+
| Layer 4 (Transport) | IP + Port only | Fast, no content inspection |
35+
| Layer 7 (Application) | HTTP headers, URL, cookies | Smart routing (e.g. /api → server A, /images → server B) |
36+
37+
Layer 7 is what Nginx does in reverse-proxy mode.
38+
39+
## Health Checks
40+
41+
Load Balancers continuously monitor backend servers:
42+
- **Active (Heartbeat)**: LB sends periodic test pings to each server
43+
- **Passive**: LB watches real traffic for errors/timeouts
44+
- If a server fails → traffic is automatically rerouted to healthy servers
45+
- When server recovers → it's automatically added back to the pool
46+
47+
## Software vs Hardware
48+
49+
| Type | Examples | Use Case |
50+
|------|---------|---------|
51+
| Software LB | Nginx, HAProxy, AWS ELB | Most modern applications |
52+
| Hardware LB | F5 Networks appliances | Large enterprise data centers |
53+
| Cloud LB | AWS ALB/NLB, GCP LB | Cloud-native workloads |
54+
55+
## Key Concepts
56+
57+
- LB eliminates Single Point of Failure
58+
- Round Robin = simple rotation, Least Connections = smarter
59+
- Layer 4 = fast + blind, Layer 7 = slower + smart
60+
- Health checks are automatic - failed servers are removed from rotation

‎03-networking/concepts/ports.md‎

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
# Ports
2+
3+
## What is a Port?
4+
5+
An IP address gets data to the right **device**.
6+
A port number gets data to the right **application** on that device.
7+
8+
The full address for any network connection:
9+
10+
```
11+
IP + Port + Protocol = Socket
12+
```
13+
14+
Example: `192.168.1.10:8000 (TCP)` - your FastAPI app listening locally.
15+
16+
## Port Number Ranges
17+
18+
| Range | Name | Description |
19+
|-------|------|-------------|
20+
| 0 - 1023 | Well-Known / System Ports | Reserved for standard protocols |
21+
| 1024 - 49151 | Registered Ports | Application-specific (DBs, custom services) |
22+
| 49152 - 65535 | Dynamic / Private Ports | Temporary client-side ports per session |
23+
24+
Port numbers are 16-bit unsigned integers: values 0 to 65535.
25+
Assigned and managed by IANA (Internet Assigned Numbers Authority).
26+
27+
## Common Ports to Know
28+
29+
| Port | Protocol | Description |
30+
|------|----------|-------------|
31+
| 20, 21 | FTP | File Transfer |
32+
| 22 | SSH | Secure Shell - remote server access |
33+
| 25 | SMTP | Email sending |
34+
| 53 | DNS | Domain Name resolution |
35+
| 67/68 | DHCP | Dynamic IP assignment |
36+
| 80 | HTTP | Web traffic (unencrypted) |
37+
| 110 | POP3 | Email receiving |
38+
| 143 | IMAP | Email (modern) |
39+
| 443 | HTTPS | Web traffic (encrypted) |
40+
| 3306 | MySQL | Database |
41+
| 5432 | PostgreSQL | Database |
42+
| 6379 | Redis | Cache / message broker |
43+
| 3389 | RDP | Remote Desktop |
44+
45+
## How the OS Routes Traffic
46+
47+
When data arrives at a device:
48+
1. IP layer delivers packet to the correct device
49+
2. Transport layer reads the port number
50+
3. OS checks which process is listening on that port
51+
4. Data is forwarded to that process
52+
53+
This is why you can run a web server (port 80), SSH daemon (port 22),
54+
and PostgreSQL (port 5432) all on the same machine simultaneously.
55+
56+
## Firewall and Ports
57+
58+
Firewalls use port numbers to allow or block traffic.
59+
60+
- Opening port 22 = allowing SSH connections
61+
- Closing port 3306 externally = protecting MySQL from internet access
62+
- Security Groups in AWS are essentially firewall rules per port

‎03-networking/concepts/tcp-ip.md‎

Lines changed: 88 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,88 @@
1+
# TCP/IP and Socket Connections
2+
3+
## The TCP/IP Model
4+
5+
TCP/IP is the foundational framework that defines how data travels across the internet.
6+
It has 4 layers (simpler than the 7-layer OSI model):
7+
8+
| Layer | Name | What it does | Examples |
9+
|-------|------|-------------|---------|
10+
| 4 | Application | User-facing protocols | HTTP, DNS, SSH, FTP |
11+
| 3 | Transport | End-to-end communication | TCP, UDP |
12+
| 2 | Internet | Addressing and routing | IP |
13+
| 1 | Network Access | Physical transmission | Ethernet, WiFi |
14+
15+
Each layer handles its own responsibility and passes data to the layer above/below.
16+
Your FastAPI app lives at Layer 4. It doesn't know or care about Layers 1-2.
17+
18+
## TCP vs UDP
19+
20+
| Feature | TCP | UDP |
21+
|---------|-----|-----|
22+
| Full name | Transmission Control Protocol | User Datagram Protocol |
23+
| Reliability | Guaranteed delivery | Best-effort, no guarantee |
24+
| Order | Packets arrive in order | Order not guaranteed |
25+
| Speed | Slower (overhead for reliability) | Faster (no overhead) |
26+
| Connection | Connection-oriented (handshake) | Connectionless |
27+
| Use cases | HTTP, SSH, email, file transfer | Live video, DNS, gaming, VoIP |
28+
29+
Rule of thumb: if losing data is unacceptable → TCP. If speed matters more → UDP.
30+
31+
## The TCP 3-Way Handshake
32+
33+
Before any data is sent over TCP, a connection must be established.
34+
This takes exactly 3 messages:
35+
36+
```
37+
Client Server
38+
| |
39+
|-------- SYN ----------------->| "I want to connect, my seq=X"
40+
| |
41+
|<------- SYN-ACK --------------| "OK, I got X, my seq=Y, ack=X+1"
42+
| |
43+
|-------- ACK ----------------->| "Got it, ack=Y+1, let's go"
44+
| |
45+
|====== Data Transfer ==========|
46+
```
47+
48+
- **SYN** (Synchronize): client initiates
49+
- **SYN-ACK**: server acknowledges and responds
50+
- **ACK** (Acknowledge): client confirms - connection open
51+
52+
Only after all 3 steps does actual data begin flowing.
53+
54+
## What is a Socket?
55+
56+
A Socket is the software abstraction that represents one endpoint of a network connection.
57+
58+
```
59+
Socket = IP Address + Port + Protocol
60+
```
61+
62+
Examples:
63+
- Server socket: `0.0.0.0:8000 (TCP)` - your FastAPI app listening for connections
64+
- Client socket: `192.168.1.5:52341 (TCP)` - your browser's temporary connection port
65+
66+
When you run `uvicorn main:app --host 0.0.0.0 --port 8000`, you are:
67+
1. Creating a socket
68+
2. Binding it to port 8000
69+
3. Telling the OS: "give me everything arriving on port 8000"
70+
71+
## Full Flow: Browser to Server
72+
73+
```
74+
1. DNS lookup: google.com → 142.250.74.46
75+
2. TCP Handshake: SYN → SYN-ACK → ACK (port 443)
76+
3. TLS Handshake: agree on encryption keys
77+
4. HTTP GET / sent (encrypted)
78+
5. HTTP 200 OK response received (encrypted)
79+
6. Browser renders HTML
80+
```
81+
82+
## Key Concepts
83+
84+
- TCP/IP = 4-layer model. Your app lives at Application layer.
85+
- TCP = reliable, ordered, connection-oriented (3-way handshake)
86+
- UDP = fast, unreliable, connectionless
87+
- Socket = IP + Port + Protocol
88+
- 3-Way Handshake = SYN, SYN-ACK, ACK - happens before every TCP connection

0 commit comments

Comments
 (0)