UDP, WebSockets, gRPC & QUIC

UDP — Unreliable but Fast

UDP (User Datagram Protocol) sends packets with no handshake, no delivery guarantee, no ordering. Each packet is independent. Why would you want that?

• Latency: No connection setup, no head-of-line blocking, no retransmission wait.
• Control: You implement only the reliability you need. Games don’t care about old position updates — a dropped packet is better than a delayed one.
• Multicast: UDP supports one-to-many delivery; TCP is point-to-point only.

UDP use cases: DNS, video streaming, game state updates, WebRTC, QUIC (which builds its own reliability on UDP).

The tradeoff: you implement everything yourself — ordering, deduplication, congestion control. Most applications that “use UDP” are actually using a protocol built on UDP (QUIC, WebRTC, DTLS).

WebSockets — Full-Duplex over HTTP

WebSocket upgrades an HTTP/1.1 connection to a persistent, full-duplex channel. The upgrade handshake:

Client → Server:
  GET /chat HTTP/1.1
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

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

After the upgrade, both sides can send frames at any time. No polling, no long-polling hacks. The TCP connection stays open.

WebSocket limitations:

• HTTP/1.1 only (WebSocket over HTTP/2 exists but is rarely used)
• Proxies can be finicky about long-lived connections
• No built-in message ordering guarantees beyond TCP’s

When to use: Chat, live dashboards, collaborative editing, game servers where the client needs server-initiated messages.

gRPC — High-Performance RPC

gRPC uses HTTP/2 as transport and Protocol Buffers for serialisation. The combination gives:

• Multiplexing: many RPCs over one connection (no connection overhead per call)
• Binary serialisation: Protobuf is ~3–10× smaller and faster to parse than JSON
• Streaming: unary (request/response), server streaming, client streaming, and bidirectional streaming modes
• Code generation: .proto files generate typed client/server stubs in every major language

service OrderService {
  rpc GetOrder (OrderRequest) returns (OrderResponse);
  rpc StreamOrders (OrderRequest) returns (stream OrderEvent);
}

gRPC-Web is required for browser clients (browsers can’t use raw HTTP/2 framing). A proxy (Envoy, grpc-gateway) translates. For browser-to-service communication, REST or GraphQL is often simpler.

When to use: Internal microservice communication where you control both client and server, streaming data pipelines, mobile apps where binary wire size matters.

QUIC — TCP Reimagined on UDP

QUIC builds reliability, multiplexing, and congestion control on top of UDP, with TLS 1.3 built in. It’s the transport for HTTP/3 but can carry other protocols too.

Why reimplement TCP in userspace?

• OS TCP stacks evolve slowly (kernel changes require OS updates). QUIC updates ship with applications.
• QUIC streams are independent: a lost packet only blocks the stream it belongs to, not all streams.
• Connection migration: QUIC connections are identified by a random connection ID, not IP:port. Switching networks (Wi-Fi to 4G) doesn’t break the connection.
• 0-RTT: reconnections to known servers skip the handshake.

Current adoption: HTTP/3 (QUIC) is deployed by Cloudflare, Google, Facebook, and most major CDNs. ~30% of web traffic uses HTTP/3 as of 2025.

Protocol Selection Guide