Master Notebook:
Networking Foundations

OSI 7-Layer Model: Deep Dive

Why It Exists

• Created by ISO in 1984 as a vendor-neutral reference framework
• Goal: allow interoperability between different vendors' networking equipment
• It is a conceptual model, NOT an implementation — real protocols don't map 1:1
• Mnemonic (bottom→top): Please Do Not Throw Sausage Pizza Away

Layer-by-Layer Breakdown

* Protocol placement is debated — TLS spans L5-L6, ARP spans L2-L3, QUIC spans L4-L7.

TCP/IP 4-Layer Model

Why TCP/IP Won

• OSI was designed by committee (top-down, theoretical)
• TCP/IP was built by engineers (bottom-up, driven by ARPANET reality)
• TCP/IP shipped working code first → gained adoption → became the de facto standard
• OSI layers 5/6 (Session/Presentation) proved unnecessary as separate abstractions — apps handle them

The 4 Layers

How It Maps to the Linux Kernel

• Network Access → NIC driver + net_device struct
• Internet → ip_rcv() / ip_output() in net/ipv4/
• Transport → tcp_v4_rcv() / udp_rcv()
• Application → userspace via socket() syscall → read()/write()

Side-by-Side Comparison

Encapsulation & Decapsulation

How Data Flows Down the Stack (Sending)

1. Application generates data (e.g., HTTP request body)
2. Transport adds TCP/UDP header → creates a segment (TCP) or datagram (UDP)
3. Network adds IP header → creates a packet
4. Data Link adds MAC header + trailer (FCS) → creates a frame
5. Physical converts frame to bits → sends electrical/optical/radio signals

At the Receiver (Going Up)

• Each layer strips its header and passes the payload up
• This is decapsulation — reverse order of encapsulation
• Each layer only reads its own header; it treats everything above as opaque payload

Physical Layer (L1)

Core Responsibilities

• Bit transmission: converting 1s and 0s into electrical, optical, or radio signals
• Defines voltage levels, timing, data rates, cable specs, connector pinouts
• No intelligence — just raw signal transport

Media Types

Key Concepts

• Bandwidth = maximum theoretical throughput (e.g., 1 Gbps link)
• Throughput = actual achieved data rate (always ≤ bandwidth)
• Latency = time for a bit to travel from source to destination
• Latency components: propagation delay + transmission delay + queuing delay + processing delay
• Collision domain = network segment where simultaneous transmissions collide (hubs share one; switches isolate per port)

Data Link Layer (L2) & MAC Addresses

MAC Address Format

• 48 bits (6 bytes), written as hex: AA:BB:CC:DD:EE:FF
• First 3 bytes = OUI (Organizationally Unique Identifier) — identifies the manufacturer
• Last 3 bytes = NIC-specific — unique per device from that manufacturer
• Broadcast MAC: FF:FF:FF:FF:FF:FF — all devices on the LAN receive it
• MAC addresses are layer 2 only — they don't cross router boundaries (routers rewrite MACs)

L2 Responsibilities

• Framing: wrapping packets in headers/trailers for the local link
• Physical addressing: using MAC addresses for local delivery
• Error detection: FCS (Frame Check Sequence) using CRC-32
• Media access control: CSMA/CD (Ethernet), CSMA/CA (Wi-Fi)

Ethernet Frame Structure

Key Fields Explained

• Preamble (7 bytes) + SFD (1 byte): synchronization pattern (alternating 1010... then 10101011) — tells NIC "frame is starting"
• EtherType: identifies the upper-layer protocol — 0x0800 = IPv4, 0x0806 = ARP, 0x86DD = IPv6
• FCS (Frame Check Sequence): CRC-32 checksum for error detection (not correction — corrupt frames are silently dropped)
• MTU (Maximum Transmission Unit): max payload size = 1500 bytes for standard Ethernet; jumbo frames allow up to 9000 bytes

Switching & VLANs

How a Switch Learns & Forwards

1. Learning: switch reads the source MAC of incoming frames and records MAC → port mapping in its MAC address table (CAM table)
2. Flooding: if destination MAC is unknown (not in table), switch forwards frame out all ports except the source port
3. Forwarding: if destination MAC is known, switch sends frame only to the correct port
4. Filtering: if source and destination are on the same port, frame is dropped (no need to forward)
5. Aging: MAC entries expire after a timeout (default ~300 seconds) to handle device moves

VLANs (Virtual LANs)

• Logically segment a single physical switch into multiple broadcast domains
• 802.1Q tag: 4-byte header inserted between Src MAC and EtherType, containing VLAN ID (12 bits → up to 4094 VLANs)
• Access port: carries traffic for one VLAN only (untagged)
• Trunk port: carries traffic for multiple VLANs (tagged with 802.1Q)
• Inter-VLAN routing: devices on different VLANs CANNOT communicate without a Layer 3 device (router or L3 switch)

Spanning Tree Protocol (STP)

• Problem: redundant switch links create loops → broadcast storms (frames circle forever)
• Solution: STP (IEEE 802.1D) elects a root bridge and blocks redundant paths
• Root bridge election: switch with lowest Bridge ID (priority + MAC) wins
• Blocked ports stay in standby; if active link fails, blocked port activates (convergence: 30-50 seconds for classic STP)
• RSTP (802.1w): rapid convergence in ~1-2 seconds

ARP (Address Resolution Protocol)

Purpose

• Maps IP address → MAC address on the local network
• Required because Ethernet frames need destination MAC, but applications only know IP addresses
• Operates at the boundary of L2 and L3

ARP Resolution Process

ARP Details

• ARP Request: sent as Ethernet broadcast (FF:FF:FF:FF:FF:FF) — all hosts on the LAN receive it
• ARP Reply: sent as unicast — only back to the requester
• ARP Cache: each host maintains a local cache of IP→MAC mappings (check with arp -a)
• Cache timeout: typically 15-20 minutes (Linux: configurable via gc_stale_time)
• Gratuitous ARP: a host broadcasts its own IP→MAC mapping unsolicited — used for IP conflict detection and failover

ARP Security Issues

• ARP Spoofing/Poisoning: attacker sends fake ARP replies to associate their MAC with a victim's IP → enables Man-in-the-Middle
• Defense: Dynamic ARP Inspection (DAI) on switches, static ARP entries for critical servers, ARP rate limiting

IPv4 Addressing

IPv4 Header Structure

Critical Header Fields

• Version (4 bits): always 4 for IPv4
• IHL (Internet Header Length, 4 bits): header length in 32-bit words (min 5 = 20 bytes)
• TTL (Time To Live, 8 bits): decremented by 1 at each router; packet dropped when TTL=0 → prevents infinite loops
• Protocol (8 bits): identifies transport protocol — 6=TCP, 17=UDP, 1=ICMP
• Total Length (16 bits): entire packet size in bytes → max 65,535 bytes
• Flags: DF (Don't Fragment) = if set and packet exceeds MTU, router drops it + sends ICMP "fragmentation needed"
• Fragment Offset: position of this fragment within the original packet (units of 8 bytes)

Private Address Ranges (RFC 1918)

Special Addresses

• 127.0.0.0/8 — loopback (localhost)
• 169.254.0.0/16 — link-local (auto-assigned when DHCP fails, aka APIPA)
• 0.0.0.0 — "any" address (used in routing tables and listening sockets)
• 255.255.255.255 — limited broadcast (current network only)

IPv6

Why IPv6

• IPv4 has only 2³² ≈ 4.3 billion addresses — already exhausted
• IPv6 has 2¹²⁸ ≈ 340 undecillion addresses — enough for every atom on Earth's surface
• Simplified header (40 bytes fixed, no checksum, no fragmentation at routers)
• Built-in IPsec support, better multicast, auto-configuration (SLAAC)

IPv4 vs IPv6 Comparison

IPv6 Address Types

• Global Unicast (2000::/3): routable on the Internet (like IPv4 public addresses)
• Link-Local (fe80::/10): auto-generated, valid only on the local link (always present)
• Unique Local (fc00::/7): private addresses (like RFC 1918)
• Multicast (ff00::/8): replaces broadcast
• Loopback: ::1 (equivalent to 127.0.0.1)

Subnetting & CIDR

Core Concepts

• Subnet mask: separates the network portion from the host portion of an IP address
• CIDR notation: /n means the first n bits are the network prefix
• Network address: all host bits = 0 (identifies the subnet itself)
• Broadcast address: all host bits = 1 (sends to all hosts in subnet)
• Usable hosts = 2^(32-n) - 2 (subtract network + broadcast addresses)

Quick Reference Table

* /31 uses both addresses as host addresses per RFC 3021 — no network/broadcast waste.

Worked Example: Subnet 10.0.0.0/16 into 4 Equal Subnets

• Original: 10.0.0.0/16 → 65,534 usable hosts
• Need 4 subnets → borrow 2 bits from host portion → new prefix: /18
• Each subnet: 2¹⁴ - 2 = 16,382 usable hosts

NAT (Network Address Translation)

Types of NAT

How PAT (Port Address Translation) Works

1. Host 192.168.1.10:5000 sends packet to 8.8.8.8:53
2. Router rewrites source to 203.0.113.1:12345 (public IP + random high port)
3. Router stores mapping in NAT translation table: 192.168.1.10:5000 ↔ 203.0.113.1:12345
4. Reply from 8.8.8.8:53 arrives at 203.0.113.1:12345
5. Router looks up the mapping, rewrites destination back to 192.168.1.10:5000

NAT Traversal Problems

• Hosts behind NAT cannot receive unsolicited inbound connections
• P2P is hard: both peers behind NAT → neither can initiate
• STUN: discovers your public IP:port via a public server, works for most NAT types
• TURN: relays all traffic through a public server (fallback when STUN fails)
• ICE: framework that tries STUN first, falls back to TURN (used by WebRTC)

ICMP (Internet Control Message Protocol)

Key ICMP Message Types

How Traceroute Uses ICMP

1. Send packet with TTL=1 → first router decrements to 0, drops it, sends back ICMP Time Exceeded
2. Send packet with TTL=2 → second router responds
3. Repeat, incrementing TTL, until destination is reached (returns ICMP Port Unreachable or Echo Reply)
4. Each hop's IP address and round-trip time is recorded

Path MTU Discovery (PMTUD)

• Sender sets DF (Don't Fragment) flag on all packets
• If a router encounters a smaller MTU, it drops the packet and sends ICMP Type 3, Code 4 with the next-hop MTU
• Sender reduces packet size to fit
• Problem: some firewalls block ICMP → PMTUD fails → "black hole" connections (TCP hangs)

Routing Protocols

Routing vs Forwarding

• Routing = building and maintaining the routing table (control plane)
• Forwarding = looking up the destination IP in the table and sending the packet out the correct interface (data plane)
• Routing is slow and complex; forwarding is fast (hardware-accelerated in modern routers)

Types of Routing Protocols

BGP (Border Gateway Protocol)

• The "routing protocol of the Internet" — connects autonomous systems (ASes)
• eBGP: between different ASes (external) — the inter-domain routing protocol
• iBGP: within the same AS (internal) — distributes external routes internally
• Uses TCP port 179 for peering sessions
• Path selection criteria (simplified): highest local preference → shortest AS path → lowest origin type → lowest MED → eBGP over iBGP → lowest router ID
• BGP hijacking: malicious AS announces someone else's IP prefix → traffic routed through attacker
• Defense: RPKI (Resource Public Key Infrastructure) — cryptographic validation of route origins

OSPF (Open Shortest Path First)

• Link-state protocol using Dijkstra's algorithm to compute shortest path tree
• Divides network into areas; Area 0 is the backbone (all other areas must connect to Area 0)
• Sends LSAs (Link State Advertisements) when topology changes — convergence in seconds
• Metric = cost (typically based on interface bandwidth: cost = reference BW / interface BW)
• Supports ECMP (Equal-Cost Multi-Path) — load balances across equal-cost routes

TCP vs UDP

When to Use Which

• TCP when: data must arrive complete and in-order (web pages, file downloads, APIs, database connections)
• UDP when: speed matters more than reliability, or app handles its own reliability (real-time video, game state updates, DNS queries)
• QUIC: UDP + reliability + encryption (HTTP/3) — best of both worlds for modern web

Ports & Sockets

Port Ranges

Socket & Connection Identity

• Socket = IP address + port number (e.g., 192.168.1.10:443)
• Connection = uniquely identified by 5-tuple: (protocol, src IP, src port, dst IP, dst port)
• This means a server on port 443 can handle millions of simultaneous connections — each has a unique 5-tuple
• The 5-tuple is why PAT works: even with one public IP, different source ports distinguish connections

TCP Handshake & Teardown

3-Way Handshake (Connection Establishment)

Why 3-Way (Not 2-Way)?

• Both sides must synchronize sequence numbers — each direction needs its own SYN + ACK
• 2-way would only confirm one direction → server wouldn't know client received its sequence number
• Prevents stale connection problem: old SYN packets from a previous connection would falsely establish connections

4-Way Teardown (Connection Termination)

1. FIN from initiator → "I'm done sending data"
2. ACK from receiver → "I got your FIN" (receiver can still send data = half-close)
3. FIN from receiver → "I'm also done sending data"
4. ACK from initiator → "Got it." Enters TIME_WAIT (lasts 2×MSL ≈ 60 seconds)

TIME_WAIT Explained

• Duration: 2 × MSL (Maximum Segment Lifetime) — typically 60 seconds total
• Why it exists: ensures delayed segments from the old connection are flushed before the same 5-tuple can be reused
• Also handles the case where the final ACK is lost — allows retransmission of the last FIN
• Problem at scale: servers closing many short-lived connections accumulate TIME_WAIT sockets → port exhaustion
• Fix: net.ipv4.tcp_tw_reuse=1 (safe — reuses TIME_WAIT for outgoing connections with newer timestamps)

TCP Fast Open (TFO)

• Eliminates 1 RTT on repeat connections by caching a crypto cookie on the first handshake
• Subsequent connections send data in the SYN packet itself (along with the cookie)
• Enable: net.ipv4.tcp_fastopen=3 (3 = both client and server)

Flow Control

Sliding Window Mechanism

How It Works

• Receiver advertises its receive window (rwnd) in every ACK — tells sender "I have this much buffer space"
• Sender cannot have more than rwnd bytes of unacknowledged data in flight
• As ACKs arrive, window slides forward → sender can transmit more
• Zero window: receiver's buffer is full → rwnd=0 → sender must stop and wait
• Zero-window probe: sender periodically sends tiny probe packets to check if rwnd has reopened
• Window scaling (RFC 7323): allows rwnd up to 1 GB (original header field maxes at 64 KB)

Congestion Control

The Problem

• Flow control prevents overwhelming the receiver
• Congestion control prevents overwhelming the network (routers, links)
• Sender maintains a congestion window (cwnd) — actual send rate = min(cwnd, rwnd)

The 4 Phases

1. Slow Start: cwnd starts at 1 MSS, doubles every RTT (exponential growth) until threshold (ssthresh)
2. Congestion Avoidance: cwnd increases by 1 MSS per RTT (linear growth = AIMD — Additive Increase)
3. Fast Retransmit: 3 duplicate ACKs → assume packet lost → retransmit immediately (don't wait for timeout)
4. Fast Recovery: after fast retransmit, set ssthresh = cwnd/2, set cwnd = ssthresh (Multiplicative Decrease) → resume congestion avoidance

Congestion Control Algorithms Comparison

Error Recovery

Retransmission Mechanisms

• Retransmission Timeout (RTO): if no ACK received within RTO, retransmit the segment
• RTO calculation (Jacobson's algorithm): RTO = SRTT + 4×RTTVAR
  • SRTT = smoothed RTT (exponential moving average)
  • RTTVAR = RTT variance
• Fast Retransmit: 3 duplicate ACKs for the same sequence number → retransmit immediately (don't wait for timeout)
• SACK (Selective ACK): receiver reports which non-contiguous blocks it has received → sender retransmits only the missing segments
• Without SACK: sender must retransmit everything after the gap (Go-Back-N behavior)

TCP Header Flags

HTTP Evolution: 1.0 → 1.1 → 2 → 3

HTTP/2 Key Concepts

• Binary framing layer: messages split into frames, interleaved across streams
• Stream: logical channel within a single connection; each request-response pair = one stream
• HPACK: header compression using static + dynamic tables — eliminates redundant header bytes
• Stream prioritization: client can hint which resources are most important
• Remaining problem: TCP-level head-of-line blocking — one lost TCP segment stalls ALL streams

HTTP/3 & QUIC

• Replaces TCP with QUIC (built on UDP) → each stream has independent loss recovery
• Lost packet in stream 1 does NOT block streams 2, 3, 4
• TLS 1.3 is integrated into QUIC → 1-RTT handshake (vs TCP + TLS = 2-3 RTTs)
• Connection migration: connections identified by Connection ID, not IP:port → survives network changes (Wi-Fi → cellular)

HTTP Methods & Status Codes

Methods & Properties

* GET technically allows a body (RFC 7231) but most servers/proxies ignore it. PATCH can be idempotent depending on implementation.

Status Code Families

Critical Headers

• Content-Type: MIME type of body (application/json, text/html)
• Cache-Control: caching directives (max-age=3600, no-cache, no-store)
• ETag: entity tag for cache validation (server returns 304 if unchanged)
• Authorization: credentials (Bearer <token>, Basic base64(user:pass))
• Connection: keep-alive: persistent connection (HTTP/1.1 default)
• Transfer-Encoding: chunked: streaming response without knowing total size upfront

DNS Deep Dive

DNS Resolution Flow

Recursive vs Iterative Queries

• Recursive: client asks resolver → resolver does ALL the work and returns the final answer
• Iterative: resolver asks root → root says "ask .com" → resolver asks .com → .com says "ask ns.example.com" → resolver asks ns.example.com → gets answer
• Client→Resolver is typically recursive; Resolver→authoritative servers is iterative

DNS Record Types

DNS Caching Hierarchy

1. Browser cache (Chrome: chrome://net-internals/#dns)
2. OS cache (systemd-resolved, nscd)
3. Recursive resolver cache (ISP's resolver, 8.8.8.8, 1.1.1.1)
4. Authoritative server (source of truth)

• TTL (Time To Live): how long a record can be cached (set by authoritative server)
• Low TTL (60s) = faster propagation for changes, more queries to authoritative
• High TTL (86400s) = fewer queries, but changes take up to 24 hours to propagate
• DNS propagation is not "propagation" — it's cache expiry across the Internet

DHCP (Dynamic Host Configuration Protocol)

DORA Process

1. Discover: client broadcasts "I need an IP address" (UDP, src=0.0.0.0, dst=255.255.255.255, port 67)
2. Offer: DHCP server(s) respond with an available IP + config
3. Request: client broadcasts acceptance of one offer (informing other servers to retract)
4. Acknowledge: selected server confirms the lease

What DHCP Provides

• IP address + subnet mask
• Default gateway (router)
• DNS server addresses
• Lease duration (how long the IP assignment is valid)
• Optional: NTP servers, domain name, TFTP server (for PXE boot)

DHCP Relay

• DHCP uses broadcast → doesn't cross router boundaries
• DHCP relay agent (on the router) intercepts broadcasts and forwards them as unicast to a DHCP server on another subnet

FTP, SSH, SMTP

FTP (File Transfer Protocol)

• Uses two connections: control (port 21) and data (port 20 or ephemeral)
• Active mode: server connects back to client's data port → fails through NAT/firewalls
• Passive mode: client initiates both connections → works through NAT (server sends PASV response with port)
• Largely replaced by SFTP (SSH-based) or HTTPS for file transfer

SSH (Secure Shell)

• Port 22, encrypted remote access and tunneling
• Key exchange: Diffie-Hellman (ECDH) to establish shared secret
• Authentication: password or public-key (client proves ownership of private key)
• Tunneling: forward local port to remote (-L), reverse tunnel (-R), SOCKS proxy (-D)
• ssh -L 3306:db.internal:3306 bastion → access remote DB via local port 3306

Email Protocols

TLS/SSL (1.2 vs 1.3)

TLS 1.2 vs 1.3 Comparison

Certificate Chain of Trust

1. Root CA: self-signed, pre-installed in OS/browser trust store (e.g., DigiCert, Let's Encrypt ISRG Root)
2. Intermediate CA: signed by Root CA (root stays offline for security)
3. Leaf/Server Certificate: signed by Intermediate CA — this is what the server presents
4. Client verifies chain: leaf → intermediate → root (found in trust store)

Key Concepts

• Forward Secrecy: use ephemeral keys (ECDHE) so that compromising the server's long-term key doesn't decrypt past sessions
• OCSP Stapling: server includes a signed "certificate not revoked" proof from CA → avoids client's separate OCSP query
• Certificate Pinning: app hardcodes expected certificate/public key hash — prevents CA compromise attacks (deprecated in browsers, still used in mobile apps)
• SNI (Server Name Indication): client includes hostname in cleartext ClientHello → allows virtual hosting on shared IP
• ECH (Encrypted Client Hello): encrypts SNI field → hides which site you're connecting to (TLS 1.3 extension)

HTTPS & HSTS

Why HTTPS Everywhere

• Confidentiality: encrypts data in transit (prevents Wi-Fi sniffing, ISP inspection)
• Integrity: prevents tampering (ISP ad injection, content modification)
• Authentication: proves the server is who it claims (via certificate)
• Google ranks HTTPS sites higher; browsers show "Not Secure" for HTTP sites

HSTS (HTTP Strict Transport Security)

• Server sends header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
• Browser remembers: always use HTTPS for this domain (even if user types http://)
• Prevents SSL stripping attacks: attacker downgrades connection to HTTP
• HSTS Preload List: domain hardcoded into browsers so even the very first visit uses HTTPS
• Caution: once preloaded, removing is extremely slow (~months); ensure HTTPS works perfectly first

Mixed Content

• HTTPS page loading HTTP resources (scripts, images) = mixed content
• Active mixed content (scripts, iframes): blocked by browsers
• Passive mixed content (images, video): may load with warning

CORS (Cross-Origin Resource Sharing)

Same-Origin Policy

• Browser restricts scripts from making requests to a different origin (scheme + host + port)
• https://api.example.com ≠ https://www.example.com (different host)
• http://example.com ≠ https://example.com (different scheme)
• CORS is the mechanism to relax same-origin policy in a controlled way

Simple vs Preflight Requests

• Simple request: GET/HEAD/POST with standard headers, no preflight needed
• Preflight required when: custom headers, methods like PUT/DELETE/PATCH, or content-type other than form-data/text-plain/form-urlencoded

Key CORS Headers

WebSockets

How WebSockets Work

• Starts as an HTTP/1.1 request with Upgrade: websocket header
• Server responds with 101 Switching Protocols → connection upgrades to full-duplex binary/text framing
• Persistent connection: both sides can send messages at any time (no request-response pattern)
• Low overhead per message: 2-14 byte frame header (vs HTTP's hundreds of bytes of headers per request)

WebSocket vs Alternatives

gRPC

Core Concepts

• Google's RPC framework built on HTTP/2 with Protocol Buffers (protobuf) serialization
• Binary format: smaller payloads, faster serialization/deserialization than JSON
• Strong typing via .proto schema files → auto-generated client/server code

4 Communication Patterns

gRPC vs REST vs GraphQL

Load Balancers (L4 vs L7)

L4 vs L7 Comparison

Load Balancing Algorithms

Health Checks

• Active: LB periodically sends probes (TCP connect, HTTP GET /health) to backends
• Passive: LB monitors response codes and timeouts from real traffic
• Unhealthy server removed from pool; re-added after consecutive successful checks
• Graceful degradation: if all servers fail health checks, some LBs still route traffic (better than total outage)

CDNs (Content Delivery Networks)

How CDNs Work

1. User makes DNS request for cdn.example.com
2. DNS resolves to the nearest edge POP (Point of Presence) via Anycast or geo-DNS
3. Cache HIT: edge has the content → returns it directly (low latency)
4. Cache MISS: edge fetches from regional cache (mid-tier) or origin server → caches it → returns to user

CDN Architecture

Cache Invalidation Strategies

• TTL-based: content expires after configured time (simple but stale window)
• Purge: explicitly remove content by URL/path (API call to CDN)
• Cache tags: tag content with labels, purge by tag (e.g., purge all product images)
• Versioned URLs: app.v2.js or app.js?v=abc123 — new URL = new cache entry (immutable caching)
• Stale-while-revalidate: serve stale content while fetching fresh version in background

Anycast

How It Works

• Same IP address is advertised from multiple locations via BGP
• Routers send traffic to the nearest (by BGP path) advertising location
• No DNS tricks needed — it's pure routing

Use Cases

• DNS root servers: 13 root server IPs, but hundreds of actual instances worldwide (all Anycast)
• CDN edge routing: Cloudflare, AWS CloudFront use Anycast for user → edge routing
• DDoS mitigation: attack traffic gets distributed across all Anycast locations (dilutes the attack)
• Works best for stateless protocols (DNS/UDP); TCP Anycast requires connection pinning (same destination for all packets in a flow)

Reverse Proxies

Forward Proxy vs Reverse Proxy

Reverse Proxy Functions

• SSL/TLS termination: decrypt HTTPS at proxy, forward plain HTTP to backends
• Compression: gzip/brotli compress responses before sending to client
• Caching: cache static/dynamic responses to reduce backend load
• Request routing: route /api/* to API service, /* to frontend
• Rate limiting: throttle abusive clients
• Header manipulation: add X-Forwarded-For, X-Request-ID

Nginx vs Envoy vs HAProxy

Firewalls & DDoS Mitigation

Firewall Types

• Stateless (Packet Filter): inspects each packet independently against rules (src/dst IP, port, protocol). Fast but limited — can't track connections.
• Stateful: tracks connection state (NEW, ESTABLISHED, RELATED). Allows return traffic automatically. This is what iptables/nftables provides.
• WAF (Web Application Firewall): L7 firewall that inspects HTTP content. Blocks SQL injection, XSS, etc. (e.g., AWS WAF, Cloudflare WAF, ModSecurity)

AWS Security Model

DDoS Mitigation Techniques

• Rate limiting: cap requests per IP/token per time window (e.g., 100 req/min)
• SYN cookies: don't allocate state for SYN requests until the handshake completes (prevents SYN flood)
• Anycast diffusion: spread attack traffic across global POPs
• Scrubbing centers: route traffic through DDoS mitigation providers (Cloudflare, AWS Shield, Akamai)
• BGP blackholing: last resort — drop all traffic to a targeted IP at the ISP level

Zero Trust Networking

• Traditional: "trust everything inside the network perimeter" (castle-and-moat)
• Zero Trust: "never trust, always verify" — every request must be authenticated & authorized, regardless of network location
• Key principles: verify identity, enforce least privilege, assume breach, inspect all traffic
• Implementation: mTLS between services, identity-aware proxies (BeyondCorp), microsegmentation

ping & traceroute

ping

• Sends ICMP Echo Request (type 8) → receives ICMP Echo Reply (type 0)
• Measures: RTT (round-trip time), packet loss, and TTL of replies

• TTL=118: started at 128 (Windows default) → 10 hops away. Linux default=64, Cisco=255.
• High RTT → network congestion or distant server
• Packet loss → congestion, faulty link, or ICMP being rate-limited/blocked
• Some hosts/firewalls block ICMP — "no reply" doesn't always mean unreachable

traceroute / tracert / mtr

• traceroute (Linux/Mac): sends UDP packets with incrementing TTL → each hop sends back ICMP Time Exceeded
• tracert (Windows): uses ICMP Echo Request with incrementing TTL
• mtr: combines ping + traceroute in real-time — shows per-hop loss and latency continuously

• * * * = hop doesn't respond to ICMP (common for firewall-protected routers; not necessarily a problem)
• Asymmetric routing: forward path ≠ return path → latency spikes at a hop don't always mean that hop is slow
• Key insight: if latency increases at hop N and stays high at hop N+1, N+2... the problem is at hop N. If it returns to normal, it's just that router being slow to respond to ICMP.

dig & nslookup

dig (DNS Information Groper)

Reading dig Output

• QUESTION: what was asked
• ANSWER: the resolved records (with TTL in seconds)
• AUTHORITY: authoritative nameservers for the domain
• ADDITIONAL: glue records (IP addresses of nameservers)
• Query time: how long the resolution took
• SERVER: which resolver answered

netstat & ss

ss (modern replacement for netstat)

TCP Connection States to Know

curl

Interpreting Timing Breakdown

• High dns → DNS resolver is slow, try another (8.8.8.8, 1.1.1.1)
• High connect - dns → network latency to server (far away or congested)
• High tls - connect → slow TLS handshake (large cert chain, slow server crypto)
• High ttfb - tls → server processing time is slow (backend issue, not network)
• High total - ttfb → large response body and/or slow download speed

tcpdump & Wireshark

tcpdump Essentials

Reading tcpdump Output

Wireshark Tips

• Display filters (Wireshark): http.request.method == "GET", tcp.flags.syn == 1, ip.addr == 10.0.1.5
• Capture filters (BPF syntax, same as tcpdump): port 443 and host 10.0.1.5
• Follow TCP Stream: right-click any packet → "Follow" → "TCP Stream" → see full conversation
• Expert Info: Analyze → Expert Information → shows retransmissions, window problems, errors
• TCP retransmissions: look for [TCP Retransmission] in info column — indicates packet loss

Socket Programming

BSD Socket API (The Foundation)

I/O Models Evolution

The C10K Problem

• Problem (circa 1999): how to handle 10,000 concurrent connections on a single server
• Thread-per-connection fails: 10K threads × 1MB stack = 10GB RAM just for stacks
• Solution: event-driven architecture with epoll/kqueue — single thread monitors thousands of sockets
• Modern reality: C10M (10 million) connections is the new challenge → requires kernel bypass (DPDK/XDP)

epoll: Edge-Triggered vs Level-Triggered

• Level-triggered (LT): epoll_wait returns a FD as long as it has data available (like poll). Simpler, more forgiving.
• Edge-triggered (ET): epoll_wait returns a FD only when NEW data arrives. Must read all available data immediately or it's lost until next event.
• ET is faster (fewer wakeups) but requires non-blocking I/O + drain-all-data loops
• Nginx uses ET; most other software uses LT

Connection Pooling

Why Pool?

• TCP handshake = 1 RTT; TLS = 1-2 more RTTs → total: 2-3 RTTs before first byte
• Connection pooling: establish once, reuse many times → amortize setup cost over many requests
• Reduces server-side socket churn (fewer TIME_WAIT, less kernel overhead)

Types of Connection Reuse

Pool Sizing: Little's Law

• L = λ × W where L = concurrent connections needed, λ = requests/sec, W = avg latency per request
• Example: 500 req/s, 20ms avg DB query → L = 500 × 0.02 = 10 connections needed
• Add headroom for variance: typically 1.5-2× the calculated value
• Too small pool → requests queue, latency spikes
• Too large pool → wastes DB resources, can actually reduce throughput (lock contention, context switching)

Service Mesh

Architecture

• Sidecar proxy pattern: every service instance gets a proxy (typically Envoy) running alongside it
• All traffic goes through the sidecar → the mesh controls communication without changing application code
• Data plane: the sidecars — handle actual traffic (routing, load balancing, encryption)
• Control plane: centralized config (Istio's istiod, Linkerd's control plane) — pushes policy to sidecars

What a Service Mesh Provides

• mTLS (mutual TLS): automatic encryption + authentication between all services
• Observability: distributed tracing, metrics, access logs — without app instrumentation
• Traffic management: canary deployments, A/B testing, circuit breaking, retries with budgets
• Access control: fine-grained authorization policies (service A can call service B's /api/v2 only)

Istio vs Linkerd

DNS over HTTPS (DoH) & DNS over TLS (DoT)

Comparison

Trade-offs

• Privacy benefit: ISP can't see DNS queries → can't track/sell browsing history
• Enterprise concern: DoH bypasses corporate DNS filtering/monitoring
• DoH controversy: centralizes DNS at a few providers (Cloudflare, Google) instead of distributed ISP resolvers

QUIC Protocol (Deep Dive)

Key QUIC Features

• No TCP head-of-line blocking: each stream has independent loss recovery — lost packet in stream 1 doesn't block stream 2
• 1-RTT handshake: combines transport + crypto handshake (TCP+TLS = 2-3 RTTs)
• 0-RTT resumption: returning clients send data immediately using cached keys
• Connection migration: connections identified by Connection ID (not IP:port 4-tuple) → survives Wi-Fi↔cellular transitions
• Built-in TLS 1.3: encryption is mandatory, not optional
• Userspace implementation: QUIC runs in userspace (not kernel) → faster iteration, easier deployment

Zero-Copy Networking & Kernel Bypass

The Problem: Traditional Data Path

1. NIC receives frame → DMA to kernel buffer
2. Kernel copies data to user-space buffer (read() syscall)
3. Application processes data
4. Application writes to user-space buffer
5. Kernel copies to kernel buffer (write() syscall)
6. Kernel sends to NIC via DMA

→ 4 copies + 4 context switches per request = significant CPU overhead

Zero-Copy Solutions

Kernel Bypass

• Why: even with zero-copy, the kernel network stack adds microseconds of latency per packet (interrupt handling, protocol processing, syscall overhead)
• For ultra-low-latency (HFT, telecom) or ultra-high-throughput (100Gbps+), bypass the kernel entirely

eBPF for Networking

What is eBPF?

• Extended Berkeley Packet Filter — sandboxed programs that run inside the Linux kernel
• Verified at load time (no crashes, no infinite loops) → safe to run in production
• Attached to kernel hook points: XDP, TC, socket, kprobes, tracepoints
• Think of it as "JavaScript for the kernel" — programmable, safe, dynamic

eBPF Hook Points for Networking

Cilium: eBPF-Based Networking

• Kubernetes CNI (Container Network Interface) plugin built on eBPF
• Replaces kube-proxy: eBPF handles service load balancing instead of iptables rules
• iptables with 10K+ services = slow (linear rule evaluation); eBPF = O(1) hash lookup
• Provides: L3/L4/L7 network policy, transparent encryption, observability (Hubble)

iptables vs eBPF