HTTP in System Design

HTTP is the foundation of web communication and APIs.

HTTP Request Structure

GET /api/v1/users/123 HTTP/1.1
Host: api.example.com
Authorization: Bearer token123
Accept: application/json
User-Agent: MyApp/1.0

HTTP Response Structure

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=3600
X-Request-Id: abc-123

{
  "id": 123,
  "name": "John Doe"
}

HTTP Headers

Request Headers:
- Authorization: Authentication credentials
- Content-Type: Body format
- Accept: Desired response format
- User-Agent: Client identifier
- Cache-Control: Caching directives

Response Headers:
- Content-Type: Response body format
- Cache-Control: Caching rules
- ETag: Resource version
- X-Request-Id: Request tracking
- Rate-Limit: Rate limit info

HTTP/1.1 Limitations

1. One request per TCP connection (without pipelining)
2. Head-of-line blocking
3. No server push
4. Text-based headers (verbose)
5. No multiplexing

HTTP in System Design

Client → CDN → Load Balancer → API Gateway → Service
        (static)  (routing)     (auth, rate limit)  (business)

Each hop uses HTTP with specific headers:
- X-Forwarded-For: Client IP
- X-Request-Id: Distributed tracing
- Authorization: Authentication

HTTP/2 and HTTP/3 address HTTP/1.1 limitations.

HTTP/2 Features

1. Multiplexing
   Multiple requests over single TCP connection:
   
   Stream 1: GET /users ──────────→ Response
   Stream 2: GET /posts ────────→ Response
   Stream 3: GET /comments ──→ Response
   
   All concurrent, no head-of-line blocking

2. Header Compression
   - HPACK compression
   - Reduces overhead

3. Server Push
   Server can push resources before client requests:
   Client: GET /page.html
   Server: PUSH /style.css, /script.js

4. Binary Protocol
   - More efficient parsing
   - Less error-prone

HTTP/3 Features

1. QUIC Protocol
   - Built on UDP
   - Faster connection setup
   - No head-of-line blocking at transport level

2. Connection Migration
   - Survives network changes
   - No reconnection needed

3. 0-RTT Connection Setup
   - Faster repeat connections
   - Reduced latency

4. Built-in Encryption
   - TLS 1.3 integrated
   - Better security by default

HTTP Version Comparison

Feature	HTTP/1.1	HTTP/2	HTTP/3
Multiplexing	No	Yes	Yes
Header Compression	No	HPACK	QPACK
Server Push	No	Yes	Yes
Transport	TCP	TCP	QUIC (UDP)
Head-of-Line Blocking	Yes	Yes (TCP)	No
Connection Setup	1-RTT	1-RTT	0-RTT

When to Use Each

HTTP/1.1:
- Legacy clients
- Simple APIs
- Low concurrency

HTTP/2:
- Modern web apps
- APIs with many resources
- Performance-critical

HTTP/3:
- Mobile clients
- High-latency networks
- Real-time applications

Performance Impact

Example: Loading 100 resources

HTTP/1.1:
- 6 TCP connections (browser limit)
- ~17 requests per connection
- Serial within connection
- Total: ~500ms

HTTP/2:
- 1 TCP connection
- All 100 concurrent
- Total: ~100ms (5x faster)

HTTP/3:
- 1 QUIC connection
- No head-of-line blocking
- Total: ~80ms (6x faster)

WebSocket provides persistent bidirectional communication.

WebSocket vs HTTP

HTTP (Request-Response):
Client ──Request──→ Server
Client ←──Response── Server
Client ──Request──→ Server
Client ←──Response── Server
(Each request opens new connection or uses keep-alive)

WebSocket (Persistent):
Client ──Upgrade──→ Server
Client ←──101 Switching── Server
Client ←──→ Server (persistent)
Client ←──→ Server (persistent)
(One connection, bidirectional)

WebSocket Handshake

Client → Server:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

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

WebSocket Use Cases

Use Case	Why WebSocket
Chat apps	Real-time messaging
Gaming	Low-latency updates
Collaboration	Live editing
Live feeds	Stock prices, sports
Notifications	Push updates

WebSocket vs Alternatives

Technology	Direction	Latency	Use Case
HTTP	Request-Response	Higher	CRUD operations
SSE	Server → Client	Medium	Live feeds
WebSocket	Bidirectional	Lowest	Chat, gaming
Long Polling	Request-Response	High	Fallback

WebSocket Scaling

Challenge: WebSocket connections are stateful

Solution: Sticky sessions or external state

Client → Load Balancer → Server 1 (connection 1)
Client → Load Balancer → Server 1 (sticky)

Or: External state store (Redis)
Client → Server 1 → Redis ← Server 2 ← Client