HTTP & Web Protocols

HTTP/1.1 — The Foundation

HTTP/1.1 (RFC 2616, later refined by RFC 7230-7235) is a text-based, request-response protocol. The client sends a plaintext request with a method, path, headers, and optional body. The server responds with a status code, headers, and a body.

Methods

Key Headers

Host (required in HTTP/1.1), Content-Type, Content-Length, Authorization, Cache-Control, Accept-Encoding, Connection: keep-alive, Transfer-Encoding: chunked.

Status Codes

Keep-Alive & Chunked Transfer

HTTP/1.0 opened a new TCP connection for every request. HTTP/1.1 defaults to persistent connections via Connection: keep-alive, reusing the same TCP connection for multiple requests. Transfer-Encoding: chunked allows the server to stream a response in pieces without knowing the total Content-Length upfront.

HTTP/2 — Binary & Multiplexed

HTTP/2 (RFC 7540, 2015) keeps the same semantics (methods, status codes, headers) but fundamentally changes how data is framed and transported over the wire.

Binary Framing Layer

Instead of plaintext, HTTP/2 uses a binary framing layer. Each HTTP message is broken into small binary frames (HEADERS frame, DATA frame, etc.) that are interleaved on a single TCP connection.

Multiplexing

Multiple requests and responses are sent concurrently as interleaved frames over a single TCP connection. Each request-response pair lives on its own numbered "stream". This eliminates HTTP-level HOL blocking.

HPACK Header Compression

HTTP/2 uses HPACK, a purpose-built header compression algorithm. It maintains a dynamic table of previously seen headers on both client and server, sending only indices or diffs for repeated headers. This dramatically reduces overhead — headers like Cookie, User-Agent, and Authorization are often identical across requests.

Server Push

The server can proactively send resources it predicts the client will need (e.g., pushing CSS/JS after receiving an HTML request) using PUSH_PROMISE frames. In practice, this feature was rarely used well and is deprecated in most browsers as of 2022.

Stream Priority

Clients can assign priority weights and dependencies to streams, hinting to the server which resources to send first (e.g., CSS before images). HTTP/2's priority model was complex and inconsistently implemented, leading to a simpler model in HTTP/3.

HTTP/3 — QUIC & UDP

HTTP/3 (RFC 9114, 2022) replaces TCP with QUIC (RFC 9000), a transport protocol built on UDP. QUIC was originally developed by Google and standardized by the IETF.

Key Advantages

HTTP/1.1 vs HTTP/2 vs HTTP/3

A side-by-side comparison of the three major HTTP versions.

Real-Time: WebSockets & SSE

WebSockets

WebSockets (RFC 6455) provide full-duplex, bidirectional communication over a single TCP connection. The connection starts as HTTP/1.1 and is upgraded via the Upgrade: websocket header.

After the handshake, data flows as lightweight frames (2-14 bytes overhead per frame vs. HTTP headers for each message). WebSockets support text and binary frames, ping/pong for keepalive, and close frames for graceful shutdown.

Server-Sent Events (SSE)

SSE is a simpler, one-way streaming protocol. The server sends events over a long-lived HTTP connection with Content-Type: text/event-stream. The client uses the browser-native EventSource API.

// Server response
Content-Type: text/event-stream

event: update
data: {"price": 42.50}

event: update
data: {"price": 43.10}

SSE supports auto-reconnection with Last-Event-ID and event types. It works over standard HTTP/2, benefiting from multiplexing (many SSE streams on one connection).

SSE vs WebSocket vs Polling

gRPC — HTTP/2 RPC Framework

gRPC is a high-performance RPC framework developed by Google. It uses HTTP/2 for transport and Protocol Buffers (protobuf) for serialization by default.

How It Works

Services and messages are defined in .proto files. The protoc compiler generates client stubs and server interfaces in 10+ languages. Calls look like local function calls but execute remotely.

// example.proto
service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
  rpc ListUsers (ListRequest) returns (stream UserResponse);
  rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}

message UserRequest {
  string id = 1;
}

Four Streaming Types

gRPC vs REST