Network Protocols — Core Concepts

Interview Relevance: High — Every system design involves choosing the right protocol. Know when and why to use each one.

Network protocols define the rules for how data travels between clients and servers. In a FAANG interview, you're not expected to implement them — you're expected to choose the right one for the job and justify why.

---

The Protocol Landscape

---

Protocol 1 — HTTP / HTTPS

What It Is

HTTP (HyperText Transfer Protocol) is the foundation of web communication. It follows a request-response model: the client sends a request, the server sends back a response, and the connection is (typically) closed.

HTTPS = HTTP + TLS encryption (everything encrypted in transit).

How It Works

HTTP vs HTTPS — The TLS Handshake

HTTP Versions at a Glance

Version	Connection	Multiplexing	Header Compression	Use Case
HTTP/1.0	New per request	❌ No	❌ No	Legacy only
HTTP/1.1	Keep-Alive	❌ Sequential	❌ No	Still common
HTTP/2	Single TCP	✅ Yes (streams)	✅ HPACK	Modern REST APIs
HTTP/3	QUIC (UDP-based)	✅ Yes	✅ QPACK	Low-latency apps

When to Use HTTP/HTTPS in System Design

• ✅ Public-facing REST APIs (GET /products, POST /orders)
• ✅ Browser-to-server communication (always HTTPS)
• ✅ Webhooks and callbacks between services
• ✅ Any stateless request-response interaction
• ❌ Not suitable for real-time bidirectional communication
• ❌ Not optimal for high-frequency small messages (use WebSockets or gRPC)

---

Protocol 2 — TCP vs UDP

Core Difference

TCP vs UDP Comparison

Property	TCP	UDP
Connection	Connection-oriented (3-way handshake)	Connectionless
Reliability	✅ Guaranteed delivery	❌ Best-effort only
Ordering	✅ Packets delivered in order	❌ May arrive out of order
Error checking	✅ Built-in (retransmit on loss)	⚠️ Checksum only (no retransmit)
Speed	Slower (overhead for reliability)	✅ Faster (no handshake, no ACKs)
Flow control	✅ Yes	❌ No
Header size	20 bytes	8 bytes

Real-World Use Cases

Interview Trade-off: TCP vs UDP for Video Streaming

Question: "Should Netflix use TCP or UDP for video streaming?"

TCP approach:
  + Every packet guaranteed → no corruption
  - If a packet is lost, playback stalls waiting for retransmission
  - Head-of-line blocking: packet 500 holds up packets 501-600
  - Adds ~100-200ms latency on packet loss events

UDP + Application-level Recovery:
  + No stall on packet loss — player interpolates missing frames
  + Player can request only critical missing segments (adaptive)
  + Much lower latency tail (no retransmit wait)
  - Requires custom error correction logic (FEC - Forward Error Correction)

Netflix answer: Adaptive Bitrate (ABR) over HTTP/TCP for VOD
              but UDP (QUIC/WebRTC) for live & interactive use cases

---

Protocol 3 — WebSockets

What It Is

WebSockets provide a persistent, full-duplex communication channel over a single TCP connection. Unlike HTTP where the client must always initiate, with WebSockets either side can send a message at any time.

The Handshake & Upgrade

HTTP Polling vs WebSockets

WebSocket Use Cases

System	Why WebSockets
Chat (WhatsApp, Slack)	Messages pushed instantly both ways
Live Sports Scores	Server pushes score updates without client asking
Collaborative Editing (Google Docs)	Every keystroke synced in real-time
Trading Dashboards	Price ticks pushed every millisecond
Online Multiplayer Games	Player positions and events synced continuously
Live Notifications	Server pushes alerts the moment they happen

When NOT to Use WebSockets

• ❌ Standard request-response APIs (use HTTP REST)
• ❌ One-way server push only (use Server-Sent Events (SSE) — simpler)
• ❌ Microservice-to-microservice communication (use gRPC or message queues)
• ❌ When connection state is a problem (WebSockets are stateful — hard to load-balance)

---

Protocol 4 — gRPC

What It Is

gRPC (Google Remote Procedure Call) is a high-performance RPC framework that:

1. Uses Protocol Buffers (Protobuf) as the message format (binary, ~5-10× smaller than JSON)
2. Runs over HTTP/2 (multiplexed, header compression, bidirectional streaming)
3. Generates strongly-typed client/server code from a .proto schema file

gRPC vs REST Comparison

The Protobuf Schema (.proto file)

// user.proto — the contract both client and server share

syntax = "proto3";

service UserService {
  rpc CreateUser (CreateUserRequest) returns (CreateUserResponse);
  rpc GetUser    (GetUserRequest)    returns (User);
  rpc StreamUsers (GetUsersRequest) returns (stream User);  // server streaming
}

message CreateUserRequest {
  string name  = 1;
  string email = 2;
  int32  age   = 3;
}

message CreateUserResponse {
  int64  id     = 1;
  string status = 2;
}

message User {
  int64  id    = 1;
  string name  = 2;
  string email = 3;
}

gRPC Streaming Modes

gRPC vs REST — When to Use Which

Scenario	Use REST	Use gRPC
Public-facing API	✅ (browsers, mobile, third parties)	❌ (browsers don't support natively)
Internal microservices	Acceptable	✅ (faster, typed, streaming)
Polyglot services	Any language	✅ (auto-generated clients for 10+ languages)
Streaming data	❌ (polling or WebSockets)	✅ (built-in streaming)
Payload size matters	❌ JSON is verbose	✅ Protobuf is ~5-10× smaller
Human readability	✅ (JSON is debuggable)	❌ (binary, need tooling)
Contract-first design	❌ (OpenAPI optional)	✅ (proto files enforce schema)

---

Choosing the Right Protocol — Decision Tree

---

Real-World Architecture: Mixed Protocols

Most large systems use multiple protocols simultaneously. Here's how they coexist:

---

Interview Cheat Sheet

Quick Comparison Table

Protocol	Transport	Connection	Direction	Format	Best For
HTTP/1.1	TCP	Per-request	Client → Server	Text (JSON/XML)	Standard web APIs
HTTP/2	TCP	Multiplexed	Client → Server	Text + Binary	Modern REST, gRPC
HTTPS	TCP + TLS	Same as HTTP	Client → Server	Encrypted	Any production API
WebSocket	TCP	Persistent	Bidirectional	Text or Binary	Real-time chat, games
gRPC	TCP (HTTP/2)	Multiplexed	Bidirectional	Binary (Protobuf)	Microservice RPC
TCP	—	Connection-based	Bidirectional	Any	Reliable data transfer
UDP	—	Connectionless	Bidirectional	Any	Latency-sensitive streams

The Three Interview Phrases

ON HTTP vs WebSocket:
"For real-time bidirectional communication like a chat system,
 HTTP polling wastes bandwidth and adds latency. I'd use WebSockets
 to maintain a persistent connection so the server can push messages
 instantly without the client polling."

ON REST vs gRPC:
"For internal microservice communication, I'd choose gRPC over REST
 because Protobuf payloads are 5-10x smaller than JSON, HTTP/2
 multiplexing eliminates head-of-line blocking, and auto-generated
 typed clients reduce integration errors between services."

ON TCP vs UDP:
"For a video calling app like Zoom, I'd use UDP. A dropped video
 frame is better than freezing the call waiting for a TCP retransmit.
 The application layer handles jitter and packet loss through
 interpolation — latency matters more than perfect delivery."

---

Red Flags vs. Green Flags

🔴 Red Flag	🟢 Green Flag
Use WebSockets for all APIs	WebSockets only for bidirectional real-time needs
Use REST for all microservices	gRPC for internal services, REST for public APIs
"HTTP is just TCP"	Know the distinction between transport and application layers
Forget HTTPS in production	Always specify TLS for any user-facing endpoint
Ignore HTTP/2 multiplexing	Know that HTTP/2 solves head-of-line blocking over HTTP/1.1
Say "UDP is unreliable so never use it"	Know exactly which systems benefit from UDP's speed

TIP

In an interview, always connect the protocol choice to your non-functional requirements. "We need sub-100ms latency and can tolerate frame drops → UDP. We need reliable delivery for financial transactions → TCP/HTTP."

IMPORTANT

HTTPS is not optional in any production system you design. Default to it. If you specify HTTP without HTTPS in an interview, call it out and say it's for simplicity — not for production.