Part of my notebook. Terse by design.
OSI in one breath
“APSTNDP”: Application, Presentation, Session, Transport, Network, Data link, Physical. In practice you think in four: the physical layer moves raw bits, the data link layer frames them (Ethernet), the network layer routes across networks (IP), the transport layer does end-to-end delivery (TCP/UDP), and everything above collapses into application protocols (HTTP, FTP, DNS).
TCP vs UDP
TCP is connection-oriented: handshake to establish, ordered delivery, acknowledgments, retransmission, congestion control. Use for anything that requires reliability over latency: web servers, databases, SMTP, FTP, SSH.
The handshake:
- Client → Server:
SYN, seq = x - Server → Client:
SYN-ACK, seq = y, ack = x+1 - Client → Server:
ACK, ack = y+1
UDP is connectionless: datagrams may arrive out of order or not at all, no congestion control. Use when the lowest latency matters and late data is worse than lost data: games, voice, DNS lookups, and increasingly as the substrate for better protocols (QUIC).
HTTP’s evolution
- HTTP/1.0 (1996): every request opens its own TCP connection.
- HTTP/1.1 (1997): keep-alive reuses the connection; pipelining exists but suffers head-of-line blocking (one stuck request blocks everything behind it), so browsers used parallel connections instead.
- HTTP/2 (2015): multiplexed streams over one connection kill application-layer head-of-line blocking; server push.
- HTTP/3 (2022): rides QUIC over UDP; streams are first-class at the transport level, and the connection ID survives network switches (Wi-Fi → 4G → 5G), which is why it’s built for mobile.
HTTPS and the TLS handshake
Plain HTTP is readable by every interceptor on the path. TLS fixes that in four steps (TLS 1.2 flavor):
- TCP handshake as above.
- Certificate check: client hello (TLS version, cipher suites) → server hello (chosen suite) → server sends its certificate with public key.
- Key exchange: client generates a session key, encrypts it with the server’s public key (asymmetric, expensive, used exactly once), server decrypts with its private key.
- Data transmission: both sides use the shared session key (symmetric, fast).
TLS 1.3 tightens this to a single round trip and drops RSA key exchange for Diffie-Hellman, which never sends the key material over the network at all. Handshakes cost real latency (250-500 ms cross-region), which is one reason CDNs terminate TLS at the edge.
RPC vs REST, gRPC, GraphQL
RPC: invoke a procedure on a remote machine as if local; stubs handle
serialization (/readPerson?id=1234 shape). Frameworks: Protobuf, Thrift,
Avro.
REST: client acts on server-managed resources through representations
(/person/1234); stateless, cacheable.
gRPC (Google, 2016): the modern RPC default for service-to-service. Protobuf binary encoding (~5x faster than JSON), codegen for every major language, built on HTTP/2. Weak in browsers (they can’t speak raw HTTP/2 frames; gRPC-Web via proxy is a partial fix), so it lives mostly east-west inside data centers.
GraphQL (Meta): a query language where the client decides the response shape, aggregating what would be several REST calls; mutations for writes, subscriptions for server push. The costs: heavy tooling on both ends, POST by default so HTTP caching (browsers, proxies, CDNs) mostly stops working, and a client can write a query that table-scans your database. For simple CRUD, not worth it.
The realtime web, compared
| WebSockets | SSE | Long polling | WebTransport | |
|---|---|---|---|---|
| Direction | Bi-directional | Server → client | Bi-directional (simulated) | Bi-directional |
| Transport | TCP (HTTP upgrade) | HTTP event-stream | Repeated HTTP | HTTP/3 (QUIC) |
| Latency / overhead | Low / low | Low / low | Medium / high | Very low / very low |
| Multiplexed streams | No | No | No | Yes |
| Browser support | Excellent | Good | Universal | Newest browsers |
| Best for | Chat, games, collab | Notifications, feeds | Legacy fallback | High-perf streaming, IoT |
HTTP streaming deserves a mention: Transfer-Encoding: chunked, sender
streams data beyond its own memory limits, receiver processes before the
response ends, client never knows the final length. It’s how LLM responses
and deployment logs reach you. Airbnb wrote a good one:
Improving performance with HTTP streaming.
Media and streaming protocols
- WebRTC: peer-to-peer over UDP, tolerates unordered chunks; calls and conferencing.
- RTMP: TCP, the contribution protocol; streamer → ingest servers near the CDN. SRT is the lower-latency UDP alternative.
- HLS/DASH: HTTP/TCP delivery with adaptive bitrate; how video reaches viewers.
A live stream end to end: streamer → encoder (OBS/webcam) → RTMP/SRT to a point-of-presence → transcoding into the bitrate/resolution ladder (1080p, 720p, …) → HLS/DASH segments → CDN → player decodes.
DNS
The internet’s directory, hierarchical with heavy caching at every level: browser cache → OS cache → resolver (your ISP’s, or 1.1.1.1 / 8.8.8.8) → root nameservers → TLD nameservers → authoritative nameservers. Stale answers propagate for up to the TTL, hence the trick: before a migration, drop the TTL to something short, then update.
Records that matter:
- NS: which nameservers answer for the domain.
- A / AAAA: name → IPv4 / IPv6 address.
- CNAME: alias → canonical name (which then resolves via its own records); the standard way to point subdomains at CDNs.
- MX: mail servers.