🛰️ Protocols - TCP, UDP, & WebSockets

The Senior Mindset: Networking is a series of trade-offs between speed and certainty. A senior engineer understands that the “overhead” of a protocol isn’t just bytes on the wire—it’s the time spent waiting for acknowledgments and the impact of packet loss on the user experience.

🏗️ TCP (Transmission Control Protocol)

TCP is the “Reliable” protocol. It ensures that every packet sent arrives in the correct order and without errors.

Three-Way Handshake: SYN → SYN-ACK → ACK. This establishes a connection before any data flows.
Flow Control & Congestion Control: TCP dynamically slows down if the network is congested to prevent “packet storms.”
Error Correction: If a packet is lost, TCP retransmits it.
The Cost: This reliability comes at the price of latency (the overhead of the handshake and potential retransmissions).

⚡ UDP (User Datagram Protocol)

UDP is the “Fast” protocol. It sends packets (“datagrams”) without establishing a connection or checking if they arrived.

Fire and Forget: There is no handshake and no acknowledgment.
Low Latency: Minimum overhead makes it ideal for time-sensitive data.
Senior Insight: If you need reliability over UDP (like HTTP/3 does with QUIC), you must implement it yourself at the Application Layer.

Feature	TCP	UDP
Reliability	Guaranteed	Best-effort
Ordering	Guaranteed	Not guaranteed
Speed	Slower (due to overhead)	Extremely Fast
Use Case	Web, Email, SSH, Databases	Gaming, VoIP, Video Streaming, DNS

🔌 WebSockets (Full-Duplex Communication)

While standard HTTP is a “Pull” protocol (client asks, server answers), WebSockets allow for a persistent, “Push” connection.

The Upgrade: Starts as an HTTP request with an Upgrade: websocket header. Once accepted, the connection switches from HTTP to a binary, bi-directional stream.
Low Overhead: Unlike HTTP polling, WebSockets don’t send heavy headers with every message.
Stateful: The server must keep the connection open in memory.

Senior Challenges with WebSockets:

Scaling: Load balancers must support “Sticky Sessions” or use a Pub/Sub (like Redis) to sync messages across multiple server instances.
Zombie Connections: You must implement Heartbeats (Ping/Pong) to detect and close dead connections that haven’t been properly terminated.

⚖️ Decision Framework (The Senior Perspective)

When to use WebSockets vs. SSE (Server-Sent Events)?

WebSockets: Use when you need bi-directional real-time data (e.g., a Chat app or a Collaborative Editor).
SSE: Use when you only need one-way updates from server to client (e.g., a Stock ticker or a Live news feed). SSE is simpler, works over standard HTTP, and has automatic reconnection.

The “Head-of-Line” Blocking Problem

In TCP, if packet #1 is lost, packets #2 and #3 must wait in the buffer until #1 is retransmitted, even if they arrived perfectly.

Senior Solution: This is why the industry moved to QUIC/HTTP3. It uses UDP to allow packets to be processed independently, eliminating this bottleneck.

💡 Seniority Note: Before reaching for WebSockets, ask: “Can this be solved with Long Polling or SSE?” WebSockets introduce significant complexity in infrastructure (connection limits, load balancing, and state management). Don’t pay that complexity tax unless you truly need two-way real-time communication.

[[Networks-HTTP-Evolution]]
[[Backend-WebSockets-Implementation]]
[[Systems-Operating-IO-Models]]