Networking
Fundamentals

Networking 01

TCP vs UDP

Every byte your application sends travels over one of two transport protocols. Choosing the wrong one for your use case is a common architecture mistake.

The TCP 3-Way Handshake

Client                    Server
  |                          |
  |--- SYN (seq=x) -------->|   Client initiates
  |                          |
  |<-- SYN-ACK (seq=y,      |   Server acknowledges
  |    ack=x+1) ------------|
  |                          |
  |--- ACK (ack=y+1) ------>|   Client confirms
  |                          |
  |=== Connection Open ======|
  |                          |

This handshake adds one round-trip time (RTT) before any data flows. At 150ms cross-continent latency, that's 150ms just to open the connection — before a single byte of your HTTP request is sent. This is why HTTP keep-alive and connection pooling matter so much.

Networking 02

HTTP/1.1 vs HTTP/2 vs HTTP/3

Each version of HTTP was invented to solve performance bottlenecks of the previous one. Understanding why they were created reveals deep insight into how the web works.

Networking 03

TLS & HTTPS

TLS (Transport Layer Security) provides encryption, authentication, and integrity for network communication. HTTPS = HTTP over TLS.

TLS 1.3 Handshake (Simplified)

Client                              Server
  |                                    |
  |-- ClientHello (supported ciphers,  |
  |   random, key_share) ------------->|
  |                                    |
  |<-- ServerHello (chosen cipher,     |
  |    random, key_share, cert,        |
  |    Finished) ----------------------|
  |                                    |
  |-- Finished + HTTP Request -------->|   ← 1 RTT only in TLS 1.3!
  |                                    |
  |<-- HTTP Response ------------------|

Where TLS Termination Happens

• At the load balancer / reverse proxy: Most common. NGINX/ALB decrypts traffic, forwards plain HTTP to backend. Simpler certificate management, backend servers don't need TLS config. Traffic inside your network is unencrypted.
• End-to-end (mTLS): Traffic is encrypted all the way to the backend service. Required for zero-trust architectures. Each service has a certificate and verifies the other (mutual TLS). More secure, more operational overhead.

Networking 04

DNS Resolution

DNS translates human-readable domain names (google.com) into IP addresses (142.250.80.46). Every network request begins with DNS — it's the phone book of the internet.

Resolution Flow

Browser → OS DNS cache?  → Yes: use IP
                         → No:
Browser → Local Resolver (ISP / 8.8.8.8)
  Resolver → Root Name Server (knows TLDs)
  Resolver → TLD Name Server (.com, .net)
  Resolver → Authoritative Name Server (owns google.com records)
  Authoritative → returns IP + TTL
  Resolver → caches + returns to browser

DNS Record Types

DNS for System Design

• DNS load balancing: Return multiple A records for the same domain. Client picks one (often first). Low-overhead global LB, but no health checks — dead servers still get traffic until TTL expires.
• GeoDNS: Return different IPs based on client's location. Users in Asia get Asia region IPs. Used by CDNs and multi-region apps.
• Low TTL for failover: Set TTL to 60 seconds for services that need fast failover. Cost: more DNS queries, more load on resolvers.
• DNS propagation: Changing a DNS record takes up to TTL seconds to propagate. Plan deployments around this.

Networking 05

WebSockets

WebSockets provide full-duplex, persistent communication between client and server over a single TCP connection. Unlike HTTP (request → response), WebSockets allow the server to push data to the client at any time.

Upgrade Handshake

Client → Server:
  GET /chat HTTP/1.1
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Key: dGhlIHNhbXBsZQ==

Server → Client:
  HTTP/1.1 101 Switching Protocols
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

// Connection is now a WebSocket. Both sides can send frames anytime.

WebSockets at Scale: The Hard Parts

• Sticky sessions required: A WebSocket connection is stateful — it lives on one server. Your load balancer must route a client to the same server every time (sticky sessions / IP hash).
• Horizontal scaling problem: If User A is on Server 1 and User B is on Server 2, how does a message from A reach B? You need a pub/sub broker (Redis Pub/Sub, Kafka) to broadcast between servers.
• Connection limits: Each open WebSocket is a file descriptor. A Linux server defaults to ~65k open connections. Tune ulimit, use event-driven servers (Node.js, Golang), not one thread per connection.
• Heartbeats: Idle connections are killed by NATs and load balancers after 60–90 seconds. Send ping/pong frames every 30s to keep connections alive.

Networking 06

REST APIs

REST (Representational State Transfer) is an architectural style for building APIs over HTTP. It's not a protocol — it's a set of constraints. When followed correctly, REST gives you a predictable, cacheable, scalable interface.

REST Constraints

• Stateless: Each request contains all information needed. Server holds no client state. Enables horizontal scaling.
• Uniform interface: Resources identified by URLs. Standard HTTP verbs (GET, POST, PUT, DELETE, PATCH). Standard status codes.
• Cacheable: GET responses can be cached by browsers, CDNs, proxies. Must be explicit about cache headers.
• Client-Server: Clear separation of concerns. UI and data storage evolve independently.

HTTP Status Codes That Matter

Networking 07

GraphQL

GraphQL is a query language for APIs. Instead of the server deciding what data to return, the client specifies exactly what it needs. This eliminates over-fetching and under-fetching.

# GraphQL: client asks for exactly what it needs
query {
  user(id: "123") {
    name
    email
    posts(last: 5) {
      title
      createdAt
    }
  }
}
# One request → exactly the data you asked for

Networking 08

gRPC

gRPC is a high-performance RPC framework by Google. Uses HTTP/2 as transport, Protocol Buffers for serialisation. Designed for internal service-to-service communication.

Networking 09

Connection Pooling

Opening a TCP connection + TLS handshake takes ~3 RTTs and significant CPU. Creating a database connection is even more expensive (auth, session setup). Connection pooling reuses existing connections instead of creating a new one per request.

Sizing a Connection Pool

A common formula: pool_size = (core_count * 2) + effective_spindle_count. More connections don't always mean more throughput — too many connections cause context switching overhead. Start small (10–20), measure, then tune.

Networking 10

Long Polling & Server-Sent Events