🛰️ Protocols - TCP, UDP, & WebSockets
Networking is a series of trade-offs between speed and certainty. A Programmer 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)
Section titled “🏗️ 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)
Section titled “⚡ 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.
- 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)
Section titled “🔌 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: websocketheader. 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.
Challenges with WebSockets:
Section titled “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
Section titled “⚖️ Decision Framework”When to use WebSockets vs. SSE (Server-Sent Events)?
Section titled “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
Section titled “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.
- Solution: This is why the industry moved to QUIC/HTTP3. It uses UDP to allow packets to be processed independently, eliminating this bottleneck.
💡 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.