Protocols
Unpacked

Like ordering at a counter. You hand over a slip (the request) with a short header and maybe a bag of content, and you get a slip back (the response) with a status number telling you how it went.

HTTP/1.1 sends text messages over TCP and handles one request at a time per connection, so browsers open about six connections per site. HTTP/2 multiplexes many streams over one TCP connection using binary frames and HPACK header compression, but one lost packet stalls every stream (TCP head of line blocking). HTTP/3 runs on QUIC over UDP with TLS 1.3 built in, so streams lose packets independently and connections survive a network change.

Like a library catalogue. Every book has its own address, /books/42, and the same few verbs work on any book: read it, add one, change it, remove it. Learn the verbs once and every REST API feels familiar.

Defined by Roy Fielding in 2000 as a set of constraints: client and server, stateless requests, cacheable responses, a uniform interface and layered systems. Clients transfer representations of resources, usually JSON. Methods carry the meaning, status codes carry the outcome, ETag and Cache-Control drive caching, and OpenAPI documents the contract. Versioning lives in the URL (/v2) or a header.

Like sending an official letter in a fixed envelope. Every message has the same envelope, an optional header for stamps and signatures, and a body with the request. A WSDL file is the office rulebook saying which letters it accepts and what it sends back.

SOAP 1.2 (W3C) defines Envelope, Header, Body and Fault. Messages are usually POSTed to one endpoint, with the operation named by SOAPAction (1.1) or the action parameter of application/soap+xml (1.2). WSDL describes operations and XSD types, so clients are generated from it. WS-* standards add message level security (WS-Security signatures and encryption), reliable delivery and transactions. Errors come back as a soap:Fault.

Like a buffet where you fill one plate with exactly what you want, instead of ordering three fixed meals. One request can fetch a user, their last two orders and nothing else.

The server publishes a schema of types plus Query, Mutation and Subscription roots. Clients POST {query, variables} to /graphql, resolvers run per field, and the answer is {data, errors}, often HTTP 200 even with partial errors. It removes over and under fetching, but needs care: batch resolvers with DataLoader to avoid N+1 queries, cap query depth and cost, and use persisted queries since HTTP caching is harder. Subscriptions usually run over WebSocket.

Like calling a function that happens to live on another computer. Both sides share one contract file, and messages travel packed in a small binary form that is quick to send and quick to read.

Services and messages are written in the Protocol Buffers IDL; protoc generates client stubs and server interfaces in each language. Every call is an HTTP/2 stream: POST /package.Service/Method with content-type application/grpc, length prefixed protobuf messages, and the result in trailers (grpc-status). There are four call shapes: unary, server streaming, client streaming and bidirectional, plus deadlines, cancellation and metadata. Browsers cannot read HTTP/2 trailers, so web clients go through gRPC-Web or Connect.

Like the frontend and backend sharing one dictionary. Rename a field on the server and your editor underlines every place in the frontend that uses it, before anything runs.

You define procedures (query, mutation, subscription) on a router with input validators such as Zod, then export only its type. The client is a typed proxy inferred from that type at compile time. On the wire it is plain HTTP and JSON: queries are GET /trpc/proc?input=…, mutations are POST, httpBatchLink merges calls made in the same tick, and subscriptions run over SSE or WebSocket. Both ends must be TypeScript sharing the types, usually in a monorepo.

Short polling is a child asking "are we there yet?" every five minutes. Long polling is asking once, and the driver only answers when you arrive, or after a while to say "not yet".

Short polling sends requests at a fixed interval, so latency is up to one interval and most answers are empty. Long polling keeps each request open until data arrives or a timeout (often 25 to 30 seconds, below proxy idle limits), then the client asks again at once with a cursor so no event is missed. It works through every proxy and firewall, but each waiting client holds a connection, and synchronized retries can create a thundering herd. RFC 6202 lists the trade offs.

Like giving a shop your phone number so they call when the parcel arrives, instead of you phoning them every hour.

The provider POSTs an event as JSON to an HTTPS endpoint you registered. Verify every delivery: compute an HMAC SHA-256 of the raw body (plus a timestamp, to stop replays) with the shared secret and compare in constant time. Answer 2xx within a few seconds and do the real work from a queue. Providers retry with backoff when you fail, so the same event can arrive twice or out of order; store the event id and skip duplicates. The Standard Webhooks spec describes the headers.

Like a radio station. You tune in once and the server keeps broadcasting to you. You can listen, but you cannot talk back on the same channel; for that, send a normal request.

The client sends GET with Accept: text/event-stream; the server answers 200 with Content-Type: text/event-stream and keeps writing UTF-8 frames made of data:, event:, id: and retry: lines, each event ending with a blank line. The browser's EventSource reconnects on drop and sends Last-Event-ID so the server can resume. Text only and one direction. On HTTP/1.1 browsers allow about six connections per site, which HTTP/2 removes. Turn off proxy buffering. LLM token streaming uses SSE.

Like a phone call instead of letters. Once connected, both people can talk whenever they like, without dialling again for every sentence.

It opens as an HTTP/1.1 GET with Upgrade: websocket and a random Sec-WebSocket-Key; the server replies 101 Switching Protocols with Sec-WebSocket-Accept, the base64 SHA-1 of the key plus a fixed GUID. After that the TCP connection carries frames: text or binary messages (masked from client to server), ping and pong heartbeats, and a close frame with a code. There is no built in reconnect, rooms, acknowledgements or backpressure; Socket.IO adds those. Scale out with sticky sessions and a pub/sub backplane such as Redis.

Like a noticeboard in a building. A sensor pins a note under home/kitchen/temp, and everyone who asked to watch that heading gets a copy. Nobody needs to know who else is there.

A binary protocol over TCP (1883, 8883 with TLS) or WebSocket, with a fixed header as small as 2 bytes. Clients CONNECT to a broker such as Mosquitto, EMQX or HiveMQ with a keep alive, PUBLISH to slash separated topics and SUBSCRIBE with wildcards: + for one level, # for the rest. QoS 0 is at most once, 1 at least once (PUBACK), 2 exactly once (a four step handshake). Retained messages give newcomers the last value, and a Last Will is published if a client vanishes. MQTT 5 adds reason codes, shared subscriptions and message expiry.

Like a post office sorting room. You hand a letter to the counter (the exchange), sorting rules drop it into the right pigeonhole (the queue), and the worker who takes it signs for it. If the worker drops it, it goes back for someone else.

AMQP 0-9-1, RabbitMQ's main protocol, runs over TCP on 5672 (5671 with TLS) with many channels per connection. Exchanges route by type: direct (exact routing key), topic (patterns with * and #), fanout (every bound queue) and headers. Bindings connect exchanges to queues. Consumers ack, nack or requeue; prefetch caps unacknowledged messages per consumer; durable queues, persistent messages and publisher confirms give at least once delivery; dead letter exchanges catch failures. AMQP 1.0 is a different standard that RabbitMQ 4 also speaks.

Like a ledger that only gains new lines at the bottom. Any team can read it, keep its own bookmark and reread old pages later. Reading never erases anything.

Kafka uses its own binary request and response protocol over TCP, usually port 9092. Topics split into partitions, each an ordered append only log replicated to other brokers (leader plus in sync replicas). The producer picks a partition by hashing the key, so one key keeps its order; acks=all with the idempotent producer avoids duplicates. Consumers in a group share the partitions and commit offsets; joining or leaving triggers a rebalance. Data stays for a retention period or is compacted per key. Kafka 4 runs on KRaft without ZooKeeper.

Like two people swapping addresses through a mutual friend, then talking directly. The friend is the signaling server; a STUN server tells each person their public address; if the walls are too thick, a TURN server relays the call.

Each side creates an RTCPeerConnection and exchanges an SDP offer and answer over your own signaling channel, often a WebSocket. ICE gathers candidate addresses (host, server reflexive from STUN, relay from TURN) and tests pairs until one connects through the NATs. Media is always encrypted with DTLS-SRTP, and data channels run SCTP over DTLS, reliable or unordered. Calls with many people route through an SFU such as LiveKit or mediasoup instead of a full mesh.