Networking Protocols Guide
Complete guide to networking protocols: TCP/IP, HTTP, WebSocket, gRPC, and protocol selection.
What is a networking protocol?
A networking protocol is a shared contract for moving and interpreting data between systems. It can define how an endpoint is named, how packets are routed, whether bytes arrive in order, how a peer is authenticated, or how an application asks for a resource.
Protocol names are often compared as if they compete. They usually do not. A browser API might use DNS to find an address, IP to route packets, QUIC or TCP to carry data, TLS to protect it, and HTTP to describe the request. The useful decision is: choose the layer whose guarantee matches the workload, then state what the application must still handle.
Reliable transport does not make a business operation reliable. A payment, enqueue, or reservation still needs a deadline, idempotency rule, durable result, and observable recovery path.
Assign each layer one responsibility
One request crosses several contracts. Read them by the job each one owns, rather than treating DNS, TLS, HTTP, and TCP as alternatives.
A protected API request
Each layer owns a different kind of decision and failure.
Name to address
DNS
Maps a service name to reachable addresses, subject to caching and record lifetime.
Packet routing
IP
Moves packets across networks on a best-effort path.
Transport
TCP or QUIC
Carries bytes or streams with different recovery, ordering, and multiplexing behavior.
Peer + privacy
TLS
Authenticates the peer and protects data in transit.
Application meaning
HTTP or MQTT
Defines requests, responses, topics, acknowledgements, and application metadata.
- Naming failure: DNS may return a stale address or no usable record; cache lifetime and resolver behavior shape recovery.
- Path failure: IP can drop, delay, duplicate, or reorder packets; it does not promise application delivery.
- Transport failure: TCP and QUIC recover lost data differently; UDP leaves recovery to the application.
- Application failure: A server can process a request even when the client never receives its response.
Select for traffic shape and delivery contract
Start with the direction of communication, who controls the endpoints, and whether every message must survive. The selector proposes a protocol role and makes its failure and operating cost explicit.
Choose the protocol role before the product name
Pick the traffic shape, endpoint environment, and delivery contract. The recommendation names a starting application protocol and the operational consequence you still own.
Starting point
HTTPS with HTTP/2 or HTTP/3
HTTPS is the broadly interoperable starting point for browser APIs, caching, authentication, and observability.
TCP for HTTP/2; QUIC for HTTP/3
Application and transport roles are separate decisions.
Recover or account for loss
The protocol does not replace product-level semantics.
Failure behavior
A response timeout can happen after the server commits a write. HTTP status codes alone do not make retries safe.
Operate it with evidence
Track p50/p95/p99 latency, status families, TLS failures, connection reuse, and cache behavior.
Compare the protocol families at their decision boundary
These are starting points, not universal replacements. A system can combine several of them across different paths.
HTTPS with HTTP/2 or HTTP/3
Use HTTPS for browser-facing request-response APIs, resource caching, authentication boundaries, and infrastructure that already understands HTTP methods and status codes.
- Protects: Confidentiality and peer authentication through TLS; explicit request, response, cache, and status semantics through HTTP.
- Watch: TLS failures, status-code families, p95 and p99 latency, connection reuse, cache hit rate, and requests that exhaust their deadline.
- Do not infer: A
POSTtimeout does not say whether the server made the change. Use an idempotency key for replayable writes.
Server-Sent Events and WebSocket
Use Server-Sent Events when the server mainly pushes updates to a browser. Use WebSocket when both sides need a persistent bidirectional session, such as collaboration or a live control surface.
- Protects: Lower per-update setup cost and a natural long-lived channel.
- Watch: Connection count, heartbeat failures, reconnect rate, proxy idle timeouts, backpressure, event lag, and per-session memory.
- Do not infer: Reconnecting a socket does not restore missed state. Define a cursor, replay window, snapshot, or resynchronization step.
gRPC over HTTP/2
Use gRPC when controlled services benefit from generated contracts, typed payloads, streaming, and explicit method deadlines. It is often a strong internal API choice, not an automatic browser API.
- Protects: A shared service contract and multiplexed RPCs over a persistent connection.
- Watch: Deadline-exceeded errors, retry volume, connection churn, method saturation, payload sizes, and error-code distributions.
- Do not infer: A typed schema does not validate a business invariant. Servers still validate authorization, state transitions, and idempotency.
MQTT and UDP
Use MQTT for lightweight brokered device telemetry and topic fan-out. Use UDP only when freshness can matter more than complete ordered delivery, and when the application can own sequencing and resynchronization.
- Protects: MQTT gives topic-oriented delivery controls; UDP avoids waiting for an obsolete datagram.
- Watch: Broker sessions, QoS acknowledgements, retained-message age, offline queues, loss, jitter, out-of-order drops, and resync rate.
- Do not infer: MQTT QoS can trade duplicates and latency for delivery. UDP provides no acknowledgement, ordering, or retry policy by itself.
Trace loss, latency, and retries separately
Loss can trigger transport recovery, timeout, reconnect, application replay, or duplicate side effects. The controls below show why a retry policy must be designed with the operation, not added after an incident.
See why a timeout is not a failed command
Adjust the network and retry budget for one request-response exchange. The model distinguishes a clean round trip, transport recovery, and the duplicate risk created by an application retry.
96.0%
Both directions cross once without loss.
99.84%
2 application attempts in this simplified model.
272 ms
Each failed attempt waits up to 160 ms before the next one.
Client
starts request
QUIC
recovery path
Server
may commit work
Retry has a named safety condition
The client can retry because the operation is read-only, naturally idempotent, or protected by a stable idempotency key that the server persists and reuses.
Model assumption: request and reply each cross a path with the selected independent loss rate. TCP and QUIC can recover lost packets below the application, so their real timing also depends on congestion control, retransmission timers, stream layout, and the configured deadline.
Never configure automatic retries for a non-idempotent write simply because it is slow. First define the operation key, where completion is recorded, how callers query an uncertain result, and which layer owns retrying.
Operate the contract at the boundary
Production incidents usually expose a missing boundary rather than a missing acronym. Make the owning team, signal, and safe response visible for each path.
- Set a deadline budget: Carry one end-to-end deadline. Give each downstream call only its remaining budget; avoid a chain of independent long timeouts.
- Classify retries: Mark reads, naturally idempotent writes, and idempotency-keyed writes separately. Bound attempts and add jitter so a shared outage does not become a retry storm.
- Apply backpressure: Cap queued work, streaming buffers, and per-connection memory. Shed or coalesce stale updates before latency becomes unbounded.
- Measure both sides of an exchange: Record client-visible timeout rate alongside server completion and duplicate-suppression counts. A timeout without server evidence is an uncertain outcome.
- Practice degraded behavior: Decide whether to serve a cached response, reconnect with a cursor, reject a command, or ask the user to check status. Do not silently repeat irreversible work.
For every protocol path, write one sentence in the runbook: "When this request times out, the caller knows ____, the server records ____, and the safe next action is ____." That sentence exposes whether the delivery contract is complete.
Continue learning
- HTTP/2 and HTTP/3: Compare multiplexed TCP and QUIC-based HTTP in more detail.
- WebSocket: Design a durable bidirectional session and reconnect behavior.
- Latency and Throughput: Relate request budgets, queues, and saturation to user-visible latency.
- Delivery Semantics: Design idempotency, acknowledgements, deduplication, and retries for asynchronous work.