Chapter 1: How the Internet Works

1.1 The OSI Model & TCP/IP Model

Why Layered Architecture?

The internet uses a layered architecture where each layer provides services to the layer above and consumes services from the layer below. This design principle enables:

• Separation of concerns: Physical transmission details are hidden from application developers
• Interoperability: Different implementations can work together as long as they follow layer contracts
• Evolution: Layers can be upgraded independently (e.g., IPv4 → IPv6 without changing HTTP)
• Fault isolation: Problems at one layer don't cascade to all layers

Alternative considered and rejected: A monolithic design where each application handles its own physical transmission, error correction, routing, etc. This would require every app to reinvent the wheel and make protocol evolution impossible.

The Two Models

The OSI (Open Systems Interconnection) model is a theoretical 7-layer reference model. The TCP/IP model is the practical 4-layer implementation the internet actually uses.

What Happens at Each Layer

When you send an HTTP request, data flows down the stack on the sender side and up the stack on the receiver side:

1.2 DNS (Domain Name System)

What is DNS?

DNS is the internet's phone book. It translates human-readable domain names (google.com) into IP addresses (142.250.185.46). Without DNS, you'd need to memorize IP addresses for every website.

Typical DNS lookup time: 20-120ms (cached: <1ms, uncached: 50-200ms)

DNS Hierarchy

DNS is a distributed hierarchical system with three levels:

1. Root servers: 13 root server clusters (a.root-servers.net to m.root-servers.net) that know where TLD servers are
2. TLD (Top-Level Domain) servers: Manage .com, .org, .net, etc. Operated by registries like Verisign
3. Authoritative name servers: The final authority for a domain, usually managed by hosting providers or domain owners

Recursive vs Iterative Resolution

When you type "www.google.com", your computer doesn't query all these servers. Your ISP's DNS resolver does the work:

Recursive query: Client asks resolver to do all the work and return final answer

Iterative query: Resolver asks each server "Who should I ask next?" and follows the chain

DNS Record Types

DNS Caching & TTL

DNS responses include a TTL (Time To Live) value that tells resolvers how long to cache the result:

• Low TTL (60-300s): Fast updates, more DNS queries, higher load
• High TTL (3600-86400s): Fewer queries, slower updates, better performance

Caching happens at multiple levels: browser cache → OS cache → ISP resolver cache → authoritative server

Advanced DNS Techniques

DNS Load Balancing

Return multiple A records with different IPs, rotated on each query (round-robin DNS):

example.com.  300  IN  A  93.184.216.34
example.com.  300  IN  A  93.184.216.35
example.com.  300  IN  A  93.184.216.36

Limitation: Doesn't account for server health or load. Use dedicated load balancers for production.

GeoDNS

Return different IPs based on client location. Example: US clients get us-east-1 server, EU clients get eu-west-1 server. Reduces latency by ~50-200ms.

DNS Failover

Health check primary server; if down, return secondary IP. TTL must be low (60-300s) for fast failover.

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

Encrypt DNS queries to prevent ISP snooping and man-in-the-middle attacks. DoH uses HTTPS (port 443), DoT uses TLS (port 853). Supported by Chrome, Firefox, Cloudflare (1.1.1.1), Google (8.8.8.8).

What Happens When You Type "google.com"?

1.3 TCP (Transmission Control Protocol)

What is TCP?

TCP is a reliable, ordered, connection-oriented transport protocol. It guarantees that data arrives in the correct order without errors, retransmitting lost packets as needed. Used by HTTP, HTTPS, SSH, email protocols.

TCP handshake cost: 1 RTT (~50-200ms for intercontinental connections, ~1-20ms within region)

TCP 3-Way Handshake (Connection Establishment)

Before sending data, TCP establishes a connection using a 3-way handshake:

1. SYN: Client sends synchronization packet with initial sequence number (ISN)
2. SYN-ACK: Server acknowledges client's ISN and sends its own ISN
3. ACK: Client acknowledges server's ISN. Connection established.

Why 3 steps instead of 2? To prevent old duplicate SYNs from establishing unwanted connections. Both sides must agree on initial sequence numbers.

TCP 4-Way Connection Termination

Closing a TCP connection requires 4 messages (can be optimized to 3):

Why TIME-WAIT? Client waits 2*MSL (Maximum Segment Lifetime, typically 30-120s) to ensure the final ACK isn't lost. If server doesn't receive it, server retransmits FIN, and client can re-send ACK.

TCP Sliding Window (Flow Control)

TCP uses a sliding window to send multiple packets without waiting for individual ACKs. The window size is advertised by the receiver based on its buffer space.

As ACKs arrive, the window slides forward, allowing more data to be sent. This improves throughput by keeping the pipe full.

TCP Congestion Control

TCP adjusts its sending rate based on network congestion. Key algorithms:

Congestion Window (cwnd) States

1. Slow Start: Begin with small cwnd (typically 10 segments = 14KB). Double cwnd every RTT until reaching ssthresh (slow start threshold) or packet loss occurs.
   • RTT 1: 10 segments
   • RTT 2: 20 segments
   • RTT 3: 40 segments (exponential growth)
2. Congestion Avoidance: After ssthresh, increase cwnd by 1 segment per RTT (linear growth). Continue until packet loss.
3. Fast Retransmit: If 3 duplicate ACKs received, immediately retransmit the lost packet without waiting for timeout. This indicates packet loss, not network death.
4. Fast Recovery: After fast retransmit, set ssthresh = cwnd / 2, set cwnd = ssthresh, and enter congestion avoidance. This avoids slow start's performance hit.

Real numbers: For a 100ms RTT connection with 10 Mbps bandwidth, slow start takes ~4 RTTs (400ms) to ramp up. This is why TCP is slow for short-lived connections.

Nagle's Algorithm

Nagle's algorithm reduces small packet overhead by buffering small writes until either:

• Enough data accumulated to fill a full segment (MSS, typically 1460 bytes)
• All previously sent data has been acknowledged

Problem: Adds latency (up to 1 RTT) for interactive applications like SSH or gaming.

Solution: Disable Nagle with TCP_NODELAY socket option. HTTP/2 and gRPC do this by default.

Head-of-Line Blocking

TCP delivers data in order. If packet 5 is lost, packets 6, 7, 8 must wait for packet 5 to be retransmitted, even if they arrived successfully. This is head-of-line blocking.

Impact: On lossy networks (1% loss), TCP throughput can drop by 50%. HTTP/2 multiplexing over a single TCP connection amplifies this problem. HTTP/3 solves it by using QUIC over UDP with per-stream ordering.

1.4 UDP (User Datagram Protocol) & QUIC

What is UDP?

UDP is a connectionless, unreliable transport protocol. It sends packets (datagrams) without handshakes, acknowledgments, or retransmissions. Minimal overhead, but no guarantees.

Latency: No connection setup. First packet can be sent immediately (0 RTT).

TCP vs UDP Comparison

When to Use UDP

UDP is ideal when:

• Low latency matters more than reliability: Gaming (lost frame is OK, stale frame is not), live video streaming
• Small request-response: DNS (single packet query + response, faster than TCP handshake)
• Real-time communication: VoIP (Zoom, Skype), video conferencing (dropped packet = brief glitch, not worth delaying)
• Broadcast/multicast: IPTV, service discovery
• Custom reliability: When you want to build your own congestion control (QUIC, game engines)

QUIC: UDP's Evolution

QUIC (Quick UDP Internet Connections) is a modern transport protocol built on UDP. It combines UDP's low latency with TCP-like reliability, plus built-in encryption (TLS 1.3).

QUIC Advantages over TCP

1. 0-RTT Connection Establishment: First request sent immediately (vs TCP's 1-RTT handshake + 1-RTT TLS = 2 RTT total)
   sequenceDiagram participant Client participant Server Note over Client,Server: QUIC 0-RTT (Resumed Connection) Client->>Server: QUIC Initial + TLS ClientHello + HTTP Request Server-->>Client: QUIC Handshake + TLS ServerHello + HTTP Response Note over Client,Server: Total: 1 RTT (data sent on first packet!) Note over Client,Server: vs TCP + TLS 1.3 Client->>Server: TCP SYN Server-->>Client: TCP SYN-ACK Client->>Server: TCP ACK + TLS ClientHello Server-->>Client: TLS ServerHello Client->>Server: HTTP Request Server-->>Client: HTTP Response Note over Client,Server: Total: 2-3 RTT
2. No Head-of-Line Blocking: QUIC supports multiple independent streams over a single connection. Lost packet in stream 1 doesn't block stream 2.
3. Connection Migration: Connection identified by ID (not 4-tuple of IP:port). Switch from WiFi to cellular without reconnecting.
4. Improved Congestion Control: Congestion control in userspace (not kernel), easier to update algorithms.
5. Built-in Encryption: All QUIC packets are encrypted (TLS 1.3 mandatory). No plaintext metadata.

QUIC Adoption

• HTTP/3 uses QUIC (replacing TCP)
• Google (YouTube, Search, Gmail), Facebook, Cloudflare use QUIC
• ~25% of internet traffic uses QUIC (2024 estimate)
• Supported by Chrome, Firefox, Edge, Safari (partial)

1.5 IP (Internet Protocol): IPv4 & IPv6

What is IP?

IP is the network layer protocol responsible for addressing and routing packets across networks. It's connectionless and best-effort (no guarantees). TCP/UDP sit on top of IP.

IPv4 vs IPv6

IPv4 Address Classes (Historical)

Originally, IPv4 addresses were divided into classes:

• Class A: 1.0.0.0 - 126.255.255.255 (8-bit network, 24-bit host = 16M hosts per network)
• Class B: 128.0.0.0 - 191.255.255.255 (16-bit network, 16-bit host = 65K hosts)
• Class C: 192.0.0.0 - 223.255.255.255 (24-bit network, 8-bit host = 254 hosts)

Obsolete: Replaced by CIDR (Classless Inter-Domain Routing) in 1993. Now use /prefix notation: 10.0.0.0/8 means first 8 bits are network, last 24 bits are host.

Subnetting Basics

CIDR notation: 192.168.1.0/24 means first 24 bits are network, last 8 bits are host.

• /24 = 256 addresses (254 usable, 2 reserved: network address + broadcast)
• /16 = 65,536 addresses
• /8 = 16,777,216 addresses

Example: Split 10.0.0.0/16 into 4 subnets:

• 10.0.0.0/18 (10.0.0.0 - 10.0.63.255)
• 10.0.64.0/18 (10.0.64.0 - 10.0.127.255)
• 10.0.128.0/18 (10.0.128.0 - 10.0.191.255)
• 10.0.192.0/18 (10.0.192.0 - 10.0.255.255)

NAT (Network Address Translation)

NAT allows multiple devices on a private network (e.g., 192.168.1.x) to share a single public IP. The router translates private IPs to its public IP for outgoing traffic.

NAT Translation Table:

Problem with NAT: Breaks end-to-end connectivity. Inbound connections can't reach private IPs without port forwarding or NAT traversal (STUN, TURN).

Unicast vs Multicast vs Anycast

• Unicast: One sender, one receiver. Standard IP addressing (most traffic).
• Multicast: One sender, multiple receivers in a group. Used for IPTV, video conferencing, stock tickers. IPv4: 224.0.0.0/4, IPv6: ff00::/8.
• Anycast: Multiple servers share the same IP. Routers send traffic to the nearest server (by BGP routing). Used by DNS root servers (13 IPs, 1000+ physical servers), CDNs (Cloudflare 1.1.1.1).

Private IP Ranges (RFC 1918)

These ranges are not routable on the public internet:

• 10.0.0.0/8 (10.0.0.0 - 10.255.255.255) — Large enterprises, AWS VPCs
• 172.16.0.0/12 (172.16.0.0 - 172.31.255.255) — Medium networks, Docker default
• 192.168.0.0/16 (192.168.0.0 - 192.168.255.255) — Home routers, small offices

1.6 HTTP/1.1

What is HTTP?

HTTP (Hypertext Transfer Protocol) is the application-layer protocol for the web. It defines how clients (browsers) and servers exchange requests and responses. HTTP/1.1 (RFC 2616, 1999) is the foundation of the modern web.

Request-Response Model

HTTP is a stateless, text-based protocol. Every interaction is a request-response pair:

Request (Client → Server):
GET /api/users/123 HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Authorization: Bearer eyJhbGc...

Response (Server → Client):
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 87
Cache-Control: max-age=3600

{"id":123,"name":"Alice","email":"alice@example.com"}

HTTP Methods

Safe: Does not modify server state (read-only)
Idempotent: Multiple identical requests have same effect as one
*PATCH: Can be idempotent depending on implementation

HTTP Status Codes

Important HTTP Headers

Request Headers

• Host: Target domain (required in HTTP/1.1)
• User-Agent: Client software (browser, bot)
• Accept: Content types client can handle (application/json, text/html)
• Authorization: Credentials (Bearer token, Basic auth)
• Cookie: Session state
• If-None-Match: ETag for conditional requests
• Range: Partial content request (byte-range downloads)

Response Headers

• Content-Type: MIME type (application/json, text/html)
• Content-Length: Body size in bytes
• Cache-Control: Caching policy (max-age=3600, no-cache)
• ETag: Resource version hash (for conditional requests)
• Set-Cookie: Set client cookie
• Location: Redirect URL
• Server: Server software (nginx, Apache)

HTTP/1.1 Features

Persistent Connections (Keep-Alive)

HTTP/1.0 opened a new TCP connection for each request. HTTP/1.1 defaults to persistent connections (Connection: keep-alive), reusing the same TCP connection for multiple requests.

Benefit: Avoids TCP handshake overhead (1 RTT saved per request after the first)

Default timeout: 5-15 seconds idle before server closes connection

HTTP Pipelining (Failed Experiment)

Pipelining allows sending multiple requests without waiting for responses (similar to TCP sliding window). Example: Send GET /a, GET /b, GET /c, then receive all responses in order.

Problem: Head-of-line blocking. If /a takes 5 seconds, /b and /c must wait, even if they're ready in 100ms.

Reality: Disabled in all major browsers due to buggy proxies and servers. HTTP/2 multiplexing solved this properly.

Connection Limits per Domain

Browsers limit concurrent connections per domain to prevent overwhelming servers:

• HTTP/1.1: 6 connections per domain (Chrome, Firefox)
• Workaround: Domain sharding (static1.example.com, static2.example.com) to get 6 connections × N domains
• HTTP/2: 1 connection per domain, unlimited streams (domain sharding is anti-pattern)

1.7 HTTP/2

What is HTTP/2?

HTTP/2 (RFC 7540, 2015) is a major revision designed to solve HTTP/1.1's performance bottlenecks. It maintains HTTP semantics (methods, status codes, headers) but completely changes the transport layer using a binary framing layer.

Adoption: ~50% of websites support HTTP/2 (2024). All modern browsers support it over TLS.

Binary Framing Layer

HTTP/1.1 is text-based (human-readable but inefficient). HTTP/2 encodes messages into binary frames, making parsing faster and less error-prone.

Frame structure: Each frame has a 9-byte header (length, type, flags, stream ID) followed by a payload.

Multiplexing: Multiple Streams Over One Connection

HTTP/2's killer feature: send multiple request-response pairs concurrently over a single TCP connection without head-of-line blocking at the HTTP layer.

Key concepts:

• Stream: Independent bidirectional message flow (one request-response pair)
• Stream ID: Odd numbers = client-initiated, even numbers = server-initiated (server push)
• Concurrency: 100+ streams can be active simultaneously on one connection
• No more 6-connection limit: Only 1 connection needed per origin

Performance impact: Reduces page load time by 10-30% compared to HTTP/1.1, especially on high-latency connections.

Server Push

Server can proactively send resources to the client before they're requested. Example: Browser requests /index.html, server pushes /style.css and /script.js immediately.

Reality: Server push is tricky. If the client already has the resource cached, push wastes bandwidth. Chrome deprecated support in 2022. HTTP/3 has early hints (103 status) instead.

Header Compression (HPACK)

HTTP headers are repetitive (User-Agent, Cookie, Authorization sent on every request). HTTP/2 uses HPACK compression to reduce overhead.

How HPACK works:

1. Static table: Common headers pre-defined (61 entries like :method GET = index 2)
2. Dynamic table: Recently used headers stored in a shared table (LRU cache)
3. Huffman encoding: Compress header values

Example:

Request 1 (full headers):
:method: GET
:path: /api/users
user-agent: Mozilla/5.0
cookie: session=abc123...

Request 2 (compressed):
:path: /api/orders (only path changes, rest references dynamic table)
Dynamic table index: 4, 5, 6 (method, user-agent, cookie)

Compression ratio: 80-95% reduction in header size. Critical for mobile networks where RTT is high (100-300ms).

Stream Prioritization

Clients can assign priorities to streams (dependencies + weights). Example: HTML (high priority) → CSS (medium) → images (low).

Reality: Many servers ignore priorities. CDNs (Cloudflare, Fastly) implement it, but origin servers often don't.

Flow Control

Each stream and the connection have flow control windows (similar to TCP). Receiver advertises how much data it can accept (WINDOW_UPDATE frames).

Purpose: Prevent fast sender from overwhelming slow receiver. Important for proxies handling many connections.

HTTP/1.1 vs HTTP/2 Comparison

Why HTTP/2 Was Needed

HTTP/1.1 problems that HTTP/2 solves:

• Head-of-line blocking: HTTP/1.1 pipelining failed. HTTP/2 multiplexing succeeds.
• Connection overhead: Opening 6 TCP connections per domain = 6 handshakes (6 RTT). HTTP/2 uses 1 connection.
• Header overhead: Repetitive headers on every request. HPACK reduces bandwidth by 80-95%.
• Resource loading: Modern pages load 100+ resources. HTTP/1.1 serializes them (even with 6 connections). HTTP/2 parallelizes on 1 connection.

Real numbers: Page with 100 resources, 50ms RTT:

• HTTP/1.1: ~17 rounds (100 resources ÷ 6 connections) × 50ms = ~850ms
• HTTP/2: ~1 round (all multiplexed) × 50ms = ~50ms (17x faster)

1.8 HTTP/3 & QUIC

What is HTTP/3?

HTTP/3 (RFC 9114, 2022) is the latest version of HTTP, built on QUIC instead of TCP. It solves HTTP/2's remaining problem: TCP head-of-line blocking.

Adoption: ~30% of websites (Google, Facebook, Cloudflare, Shopify). Supported by Chrome, Firefox, Edge, Safari.

Why HTTP/3? The TCP Problem

HTTP/2 multiplexes streams over a single TCP connection. If one TCP packet is lost, the entire connection stalls (all streams) until the packet is retransmitted. This is TCP head-of-line blocking.

Impact: On networks with 1% packet loss, HTTP/2 throughput drops 20-50% compared to HTTP/1.1 with multiple connections.

QUIC Architecture

QUIC (Quick UDP Internet Connections) is a transport protocol built on UDP. It reimplements TCP's reliability, congestion control, and flow control in userspace, while adding stream multiplexing and built-in encryption.

Key insight: QUIC moves reliability and encryption from kernel (TCP + TLS) to userspace (QUIC library). This enables faster iteration and per-stream ordering.

0-RTT Connection Establishment

HTTP/2 over TCP + TLS 1.3 requires 2 RTT minimum (1 for TCP, 1 for TLS). QUIC supports 0-RTT resumption for previously seen servers.

Latency savings:

• US-Europe (100ms RTT): 200ms saved per request
• Mobile (200ms RTT): 400ms saved per request

Security note: 0-RTT data is not forward-secure and vulnerable to replay attacks. Only safe for idempotent requests (GET, not POST).

Independent Stream Multiplexing (No HOL Blocking)

QUIC provides per-stream ordering, not global ordering. Lost packet in stream 1 only blocks stream 1, not streams 2, 3, 4.

Performance impact: On 1% lossy network, HTTP/3 is 30-50% faster than HTTP/2.

Connection Migration

TCP connections are identified by 4-tuple (source IP, source port, dest IP, dest port). Changing networks (WiFi → cellular) breaks the connection.

QUIC connections are identified by a Connection ID (independent of IP/port). Connection survives network changes.

Use case: Mobile apps downloading large files. User walks out of WiFi range, switches to cellular. Download continues without restarting.

HTTP/2 vs HTTP/3 Comparison

Why HTTP/3 Exists Despite HTTP/2 Being Recent

HTTP/2 was standardized in 2015. Why replace it 7 years later?

1. TCP HOL blocking is unfixable: TCP is a kernel protocol with in-order delivery baked in. Can't change without breaking the internet.
2. Mobile networks are lossy: 1-2% packet loss is common on cellular. HTTP/2 performance degrades badly on lossy networks.
3. TLS handshake is slow: 1-2 RTT adds 50-400ms on every connection. 0-RTT is a game-changer for mobile.
4. Connection migration needed: Users switch networks constantly (WiFi ↔ cellular). TCP can't handle it.
5. Innovation velocity: TCP is in the kernel, updated every ~5 years. QUIC is userspace, updated every ~6 months.

Google's motivation: YouTube and Search make millions of requests/second. Saving 1 RTT per request = billions of RTT saved = faster load times = more engagement.

1.9 TLS/SSL (Transport Layer Security)

What is TLS?

TLS (Transport Layer Security) encrypts data between client and server, providing confidentiality, integrity, and authentication. It sits between the application layer (HTTP) and transport layer (TCP).

SSL (Secure Sockets Layer) is the deprecated predecessor. SSL 3.0 was replaced by TLS 1.0 in 1999. Today "SSL" colloquially refers to TLS.

TLS Versions

• TLS 1.0 (1999): Deprecated (insecure)
• TLS 1.1 (2006): Deprecated (insecure)
• TLS 1.2 (2008): Widely used (74% of connections in 2024), secure if configured properly
• TLS 1.3 (2018): Modern standard (26% of connections, growing), faster and more secure

TLS 1.2 Handshake (2-RTT)

TLS 1.2 requires 2 round trips to establish a secure connection (after TCP handshake):

Key steps:

1. ClientHello: Client announces supported TLS versions, cipher suites, compression methods
2. ServerHello: Server picks TLS version and cipher suite, sends certificate
3. Certificate validation: Client verifies server's certificate against trusted CAs
4. Key exchange: Client generates pre-master secret, encrypts with server's public key
5. Session keys: Both derive symmetric encryption keys from pre-master + random nonces
6. Finished: Both send encrypted "Finished" messages to confirm handshake

Total latency: 3 RTT (1 TCP + 2 TLS) = 150-600ms for intercontinental connections

TLS 1.3 Handshake (1-RTT)

TLS 1.3 reduces handshake to 1 RTT by combining key exchange with ClientHello:

Key improvements:

• 1-RTT handshake: Client speculatively sends key share in first message
• Fewer cipher suites: Removed weak algorithms (RC4, MD5, SHA-1, RSA key exchange)
• Forward secrecy mandatory: Ephemeral Diffie-Hellman (DHE/ECDHE) required
• Encrypted handshake: More of the handshake is encrypted (hides server certificate from eavesdroppers)
• 0-RTT resumption: For repeated connections, send encrypted data in first packet (like QUIC)

Latency savings: 50-200ms per connection (1 RTT saved)

Certificate Chain Validation

TLS uses a chain of trust from website certificate → intermediate CA → root CA. Client trusts the root CA (pre-installed in OS/browser).

Validation steps:

1. Client receives server certificate (leaf) and intermediate CA certificate
2. Verify leaf certificate signature using intermediate CA's public key
3. Verify intermediate CA certificate signature using root CA's public key
4. Check root CA is in trusted store (browser/OS)
5. Verify certificate is not expired and domain matches
6. Check Certificate Revocation List (CRL) or OCSP (Online Certificate Status Protocol)

Public Key Infrastructure (PKI)

Certificate Authorities (CAs) are trusted organizations that issue certificates. Browsers/OS ship with ~100-200 trusted root CAs.

Major CAs: DigiCert, Let's Encrypt, GlobalSign, Sectigo

Let's Encrypt: Free, automated CA. Issues 300M+ certificates. Uses ACME protocol (Automatic Certificate Management Environment) for domain validation.

Cipher Suites Explained

A cipher suite defines algorithms for key exchange, authentication, encryption, and MAC (Message Authentication Code).

Example (TLS 1.2): TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• ECDHE: Elliptic Curve Diffie-Hellman Ephemeral (key exchange, forward secrecy)
• RSA: RSA signature (authentication)
• AES_128_GCM: AES encryption in Galois/Counter Mode (128-bit key, authenticated encryption)
• SHA256: Hash function for HMAC

Example (TLS 1.3): TLS_AES_256_GCM_SHA384 (simplified, key exchange implicit)

Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy ensures that if the server's private key is compromised, past sessions remain secure. Achieved by using ephemeral keys (generated per session).

How it works (Diffie-Hellman):

1. Client and server generate temporary key pairs (discarded after session)
2. Exchange public keys
3. Both compute shared secret using their private key + other's public key
4. Derive session keys from shared secret
5. Discard temporary private keys after session ends

Without PFS: Attacker records encrypted traffic, steals server's private key years later, decrypts all past sessions.

With PFS: Server's private key only used for authentication (signing), not encryption. Past sessions remain secure.

Certificate Pinning

Certificate pinning hardcodes expected certificate or public key in the application. Prevents man-in-the-middle attacks using rogue CAs.

Use case: Mobile apps connecting to specific API. Pin the expected certificate fingerprint.

Risk: If certificate expires or rotates, app breaks. Must be updated.

Alternative: HTTP Public Key Pinning (HPKP, deprecated) or Certificate Transparency logs.

Mutual TLS (mTLS)

Standard TLS: client verifies server's certificate. Mutual TLS: server also verifies client's certificate.

Use case:

• Service-to-service communication: Microservices authenticate each other (zero-trust architecture)
• API authentication: Client certificate instead of API keys
• Enterprise VPNs: User certificate for authentication

Adoption: Common in service meshes (Istio, Linkerd, Consul Connect).

TLS 1.2 vs TLS 1.3 Comparison

1.10 WebSockets

What are WebSockets?

WebSockets (RFC 6455, 2011) provide full-duplex, bidirectional communication over a single TCP connection. Unlike HTTP's request-response model, WebSockets allow server and client to send messages independently at any time.

Use cases: Real-time chat, live notifications, multiplayer games, collaborative editing, live dashboards, stock tickers

HTTP Upgrade Handshake

WebSockets start as HTTP, then upgrade to the WebSocket protocol using the Upgrade header:

Key headers:

• Upgrade: websocket - Request protocol upgrade
• Connection: Upgrade - Connection should be upgraded
• Sec-WebSocket-Key - Random base64 value (prevents caching proxies from reusing connection)
• Sec-WebSocket-Accept - SHA-1 hash of key + magic string (proves server understands WebSocket)

Full-Duplex Communication

Unlike HTTP (client initiates, server responds), WebSockets are full-duplex: both sides can send messages independently.

Benefit: Server can push data without client polling. Eliminates latency of request-response cycle.

WebSocket Frame Format

After the upgrade, all data is sent as frames (binary protocol, not text like HTTP):

WebSocket Frame Structure:
┌─────────┬─────────┬─────────┬─────────────┬─────────────┬──────────────┐
│   FIN   │  RSV1-3 │ Opcode  │   Mask      │   Payload   │   Payload    │
│  (1 bit)│ (3 bits)│ (4 bits)│   (1 bit)   │  Length     │    Data      │
└─────────┴─────────┴─────────┴─────────────┴─────────────┴──────────────┘

Opcode values:
0x0 - Continuation frame (multi-frame message)
0x1 - Text frame (UTF-8)
0x2 - Binary frame
0x8 - Close connection
0x9 - Ping (heartbeat)
0xA - Pong (heartbeat response)

Masking:
- Client → Server: Always masked (XOR with random key)
- Server → Client: Never masked
- Prevents proxy cache poisoning attacks

Why masking? Prevents malicious JS from crafting frames that look like HTTP requests to trick caching proxies.

When to Use WebSockets

Use WebSockets when:

• Real-time bidirectional communication: Chat apps, multiplayer games, collaborative editing (Google Docs)
• High-frequency updates: Live sports scores, stock tickers, monitoring dashboards
• Low latency critical: Gaming (10-50ms updates), financial trading, remote desktop
• Server-initiated messages: Notifications, alerts, live updates

When not to use WebSockets:

• Simple request-response: Standard HTTP is simpler and better supported
• Infrequent updates: Polling or SSE is sufficient (don't maintain persistent connection)
• Large file uploads: HTTP handles resumption better
• RESTful APIs: HTTP is the standard (cacheable, stateless)

WebSocket vs Alternatives

1.11 Server-Sent Events (SSE)

What is SSE?

Server-Sent Events (SSE) is a standard for one-way streaming from server to client over HTTP. The server holds the connection open and sends events as they occur.

Use cases: Live notifications, news feeds, stock tickers, server logs, progress updates, social media feeds

How SSE Works

SSE uses standard HTTP with Content-Type: text/event-stream. Server keeps connection open and sends events in text format:

Event Format

Events are text-based, newline-delimited:

Simple event:
data: This is a simple message

Multi-line event:
data: First line
data: Second line
data: Third line

Named event with ID:
event: userJoined
data: {"userId": 123, "name": "Alice"}
id: 1

Comment (ignored by client):
: This is a comment

Retry interval (milliseconds):
retry: 10000

Fields:

• data - Event payload (text or JSON)
• event - Event type (default: "message")
• id - Event ID for reconnection
• retry - Reconnection delay in milliseconds

EventSource API (Browser)

JavaScript code:

// Create connection
const eventSource = new EventSource('/events');

// Listen for messages (default event type)
eventSource.onmessage = (event) => {
  console.log('New message:', event.data);
};

// Listen for custom event types
eventSource.addEventListener('userJoined', (event) => {
  const user = JSON.parse(event.data);
  console.log('User joined:', user.name);
});

// Handle errors
eventSource.onerror = (error) => {
  console.error('SSE error:', error);
  // EventSource auto-reconnects
};

// Close connection
eventSource.close();

Automatic Reconnection with Last-Event-ID

If the connection drops, EventSource automatically reconnects and sends the Last-Event-ID header. Server can resume from that point.

Server-side implementation:

// Node.js + Express example
app.get('/events', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  const lastEventId = req.headers['last-event-id'];
  // Resume from lastEventId if provided

  let eventId = parseInt(lastEventId || '0');

  const sendEvent = (data) => {
    eventId++;
    res.write(`id: ${eventId}\n`);
    res.write(`data: ${JSON.stringify(data)}\n\n`);
  };

  // Send event every 5 seconds
  const interval = setInterval(() => {
    sendEvent({ message: 'Hello', timestamp: Date.now() });
  }, 5000);

  // Clean up on disconnect
  req.on('close', () => {
    clearInterval(interval);
  });
});

When to Prefer SSE Over WebSockets

Use SSE when:

• Server-to-client only: Notifications, feeds, logs, monitoring (no need for client-to-server messages)
• Simplicity: SSE is standard HTTP (easier debugging, caching, proxies)
• Automatic reconnection: Built into EventSource (WebSockets require manual reconnection logic)
• HTTP/2 multiplexing: Multiple SSE streams share one connection (no 6-connection limit)
• Progressive enhancement: Falls back gracefully (polyfills for old browsers)

SSE limitations:

• Unidirectional: Server → Client only (client must use separate HTTP requests to send data)
• Text only: Data must be UTF-8 text (JSON, XML, plain text). Binary requires base64 encoding.
• Browser connection limit: 6 SSE connections per domain (HTTP/1.1). Use HTTP/2 for multiplexing.

SSE Sequence Diagram

1.12 gRPC

What is gRPC?

gRPC (gRPC Remote Procedure Call) is a high-performance, open-source RPC framework developed by Google. It uses HTTP/2 for transport, Protocol Buffers for serialization, and supports 4 types of streaming.

Use cases: Microservices communication, mobile backends, real-time services, IoT, APIs with strict performance requirements

gRPC Architecture

Key components:

• Protocol Buffers (protobuf): Binary serialization format (smaller and faster than JSON)
• HTTP/2: Multiplexing, streaming, header compression
• Code generation: Client stubs and server skeletons generated from .proto files
• Service definitions: Strongly typed contracts (like WSDL for SOAP)

Protocol Buffers (Protobuf)

Protobuf is a language-neutral, platform-neutral binary serialization format. It's 3-10x smaller and 20-100x faster than JSON.

Example .proto file:

syntax = "proto3";

package ecommerce;

service ProductService {
  rpc GetProduct (ProductRequest) returns (ProductResponse);
  rpc ListProducts (ListProductsRequest) returns (stream ProductResponse);
  rpc CreateProduct (stream ProductRequest) returns (ProductSummary);
  rpc UpdateProducts (stream ProductRequest) returns (stream ProductResponse);
}

message ProductRequest {
  int32 product_id = 1;
}

message ProductResponse {
  int32 product_id = 1;
  string name = 2;
  double price = 3;
  repeated string tags = 4;
}

message ListProductsRequest {
  int32 page_size = 1;
  string page_token = 2;
}

message ProductSummary {
  int32 total_created = 1;
}

Code generation:

# Generate Go code
protoc --go_out=. --go-grpc_out=. product.proto

# Generate Python code
python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. product.proto

# Generate Java code
protoc --java_out=. --grpc-java_out=. product.proto

Protobuf vs JSON:

Four Streaming Modes

gRPC supports four communication patterns:

1. Unary RPC (Request-Response)

Standard request-response, like REST:

rpc GetProduct (ProductRequest) returns (ProductResponse);

2. Server Streaming

Client sends one request, server sends stream of responses:

rpc ListProducts (ListProductsRequest) returns (stream ProductResponse);

Use case: Large result sets, live updates, log streaming

3. Client Streaming

Client sends stream of requests, server sends one response:

rpc CreateProduct (stream ProductRequest) returns (ProductSummary);

Use case: Batch uploads, telemetry, file uploads

4. Bidirectional Streaming

Both client and server send streams independently:

rpc UpdateProducts (stream ProductRequest) returns (stream ProductResponse);

Use case: Chat applications, real-time collaboration, game servers

gRPC vs REST vs GraphQL

When to Use gRPC

Use gRPC when:

• Microservices: Internal service-to-service communication (high throughput, low latency)
• Real-time streaming: Live data feeds, bidirectional communication
• Polyglot systems: Services in different languages (protobuf supports 10+ languages)
• Mobile backends: Bandwidth-constrained, battery-sensitive (smaller payloads)
• Performance critical: Trading systems, gaming, IoT (5-10x faster than JSON)

Don't use gRPC for:

• Public APIs: REST is standard, more accessible (curl, Postman, browsers)
• Browser clients: Requires gRPC-Web + proxy (Envoy). WebSockets simpler for bidirectional.
• Simple CRUD: REST is simpler, more tooling, HTTP caching
• Human debugging: Binary format not readable (use logging, monitoring)

Service Definition Example

Complete example with all 4 streaming modes:

syntax = "proto3";

package chat;

service ChatService {
  // Unary: Login
  rpc Login (LoginRequest) returns (LoginResponse);

  // Server streaming: Receive messages
  rpc StreamMessages (StreamRequest) returns (stream Message);

  // Client streaming: Send multiple messages
  rpc SendMessages (stream Message) returns (SendSummary);

  // Bidirectional streaming: Live chat
  rpc Chat (stream Message) returns (stream Message);
}

message LoginRequest {
  string username = 1;
  string password = 2;
}

message LoginResponse {
  string token = 1;
  string user_id = 2;
}

message StreamRequest {
  string user_id = 1;
  int64 since_timestamp = 2;
}

message Message {
  string message_id = 1;
  string user_id = 2;
  string content = 3;
  int64 timestamp = 4;
}

message SendSummary {
  int32 messages_sent = 1;
}