gRPC and UDP: Transport Options for Agent Communication

What Transport Does gRPC Use?

Standard gRPC uses HTTP/2 over TCP, commonly protected with TLS. Unary and streaming calls are carried as HTTP/2 frames, while Protocol Buffers commonly define the payload contract.

This matters for three reasons.

Connection establishment. A cold connection may include TCP setup, a TLS handshake when configured, and HTTP/2 negotiation. Warm connection reuse changes the result substantially. Our benchmarking guide shows how to measure cold and warm paths separately.

NAT traversal. TCP connections require a listener on one end. If an agent is behind a NAT or firewall, it cannot accept inbound TCP connections without a relay, a reverse proxy, or a VPN. gRPC has no built-in mechanism for this. Every gRPC deployment that spans NAT boundaries requires additional infrastructure — a service mesh, a Cloudflare Tunnel, an ngrok endpoint, or a relay proxy — each adding latency and operational complexity.

Head-of-line blocking. HTTP/2 multiplexes multiple streams over a single TCP connection, but TCP guarantees in-order delivery. If one packet is lost, all subsequent streams stall until the retransmitted packet arrives. For lossy networks — wireless, long-haul intercontinental links — this hurts all streams sharing the connection, not just the one that lost a packet.

gRPC over QUIC: The Closest You Get to gRPC over UDP

QUIC is a transport protocol built on UDP. It was designed to fix TCP's head-of-line blocking problem and reduce connection establishment latency. HTTP/3 runs over QUIC. And gRPC can, in theory, run over HTTP/3 — which means it can run over QUIC, which means it runs over UDP.

Some implementations and adjacent proxies experiment with HTTP/3 or QUIC, but this is not the standard, portable gRPC deployment model across supported language runtimes. Verify the exact client, server, load balancer, and observability path before treating it as a production option.

Reachability remains separate. QUIC changes transport behavior, but it does not automatically publish a route to a service behind NAT or a firewall. The deployment still needs an allowed path, proxy, tunnel, coordinated traversal, or relay.

Infrastructure requirements. Running gRPC over QUIC means your load balancers, ingress gateways, and service meshes must all support HTTP/3. Envoy has QUIC support. NGINX has experimental QUIC support. But the operational maturity of QUIC at the mesh layer is uneven, and most organizations running gRPC today are doing so over TCP with no plan to switch.

The bottom line: evaluate any gRPC-over-QUIC option as an implementation-specific choice. Standard gRPC interoperability remains centered on HTTP/2 over TCP.

Why TCP Matters for Agent Communication

Setting aside the gRPC-specific question for a moment, the transport choice — TCP vs. UDP — has structural implications for how agents communicate.

TCP is connection-oriented. This means state. The kernel tracks sequence numbers, window sizes, congestion state, and timers for every connection. On a server with thousands of agent connections, this memory adds up. More importantly, a connection that sits idle consumes resources. TCP keepalives, NAT mapping refresh timers, and path MTU discovery all need periodic maintenance. For agents that communicate infrequently — submit a task, wait minutes for LLM processing, receive results — maintaining hundreds of idle TCP connections is wasteful.

TCP requires a listener. This is the most consequential limitation for agent systems. An agent that only makes outbound TCP connections can never receive unsolicited messages. It must poll, or maintain a long-lived outbound connection to a broker (NATS, MQTT), or have a publicly addressable endpoint. None of these are ideal: polling adds latency, a broker is infrastructure you must operate, and public endpoints require certificates, DNS, and firewall rules.

TCP multiplexing has limits. HTTP/2 multiplexes streams over one TCP connection, which helps with connection overhead. But as noted above, it introduces head-of-line blocking at the transport layer. QUIC fixes this, but QUIC is not yet the default transport for any major RPC framework outside of Google's internal infrastructure.

The UDP Overlay Alternative: Agent-Native Networking

An alternative approach is to side-step the TCP/UDP transport question entirely by using an overlay network that handles reachability, encryption, and peer discovery for you. The overlay gives agents a virtual network interface — they send and receive messages over it, and the overlay handles the messy reality of NAT traversal, connection mobility, and encryption underneath.

Pilot Protocol is one such overlay, built specifically for AI agents. It runs entirely over UDP — the daemon establishes encrypted tunnels using X25519 key exchange and AES-256-GCM. STUN and hole-punching create direct P2P paths through NATs. A relay fallback handles symmetric NAT where hole-punching fails.

The key difference from running gRPC over QUIC is that Pilot is not a transport for an RPC framework — it is the communication layer itself. Agents speak to each other over the overlay using the protocol that makes sense for their interaction (JSON messages, structured RPC, streaming file transfers). The overlay provides:

• Virtual addressing: An agent can retain its 48-bit address across restarts and IP changes when its identity is retained.
• Encrypted by default: All tunnel traffic is encrypted at the overlay level. No per-service TLS configuration.
• NAT traversal built in: The daemon handles STUN, hole-punching, and relay fallback automatically. Agents behind home routers, corporate firewalls, and cloud NAT gateways are all reachable with the same code.
• Socket multiplexing: The daemon can carry multiple peer relationships over one UDP socket instead of exposing a public listener per service.

Our HTTP and UDP overlay benchmarking guide explains how to compare these paths without confusing transport overhead with topology, connection reuse, or security settings.

When to Use gRPC vs. a UDP Overlay

The choice is not absolute. The right decision depends on your deployment topology and workload characteristics.

gRPC (over TCP) is the right choice when:

• All agents are on the same network, Kubernetes cluster, or VPN.
• You already have a service mesh (Istio, Linkerd) handling mTLS and routing.
• Your interaction patterns are contract-defined and benefit from Protocol Buffer code generation.
• You need bidirectional streaming for real-time agent coordination.
• gRPC's interceptor ecosystem (auth, tracing, rate limiting) is a requirement.

A UDP overlay (Pilot Protocol) is the right choice when:

• Agents span different networks, clouds, or administrative domains.
• Some agents run behind NAT or corporate firewalls.
• You do not want to operate a message broker, service mesh, or VPN infrastructure.
• Agents need to discover each other dynamically without hardcoded addresses.
• Connection overhead matters — you are running agents on resource-constrained devices.

These are not mutually exclusive. gRPC can run over Pilot's overlay tunnel. The overlay handles connectivity and encryption; gRPC handles the structured RPC layer. Several teams using Pilot do exactly this: they install the daemon for reachability, then run gRPC calls over the tunnel for typed service definitions.

Frequently Asked Questions

Does gRPC use UDP?

Standard gRPC uses HTTP/2 over TCP. Implementation-specific experiments may use HTTP/3 or QUIC, but teams should not assume portable support across runtimes and infrastructure.

Can gRPC run over QUIC?

Some implementations and adjacent proxies experiment with HTTP/3 or QUIC, but it is not the standard portable gRPC deployment model. Verify support across the exact client, server, proxy, and observability path you intend to operate.

What is the difference between gRPC over QUIC and a UDP overlay?

QUIC is a transport protocol — it replaces TCP with a UDP-based reliable, encrypted stream. A UDP overlay like Pilot Protocol is a networking layer that provides virtual addressing, NAT traversal, and peer discovery, with the tunnel itself running over UDP. They operate at different levels of the stack: QUIC replaces TCP, while an overlay replaces the network topology. They can be complementary — you could run gRPC over QUIC over a UDP overlay tunnel, though the layered overhead would need to make sense for your workload.

Why does TCP cause problems for agent communication?

TCP services need a reachable listener, so deployments behind NAT or restrictive firewall policy need an allowed route or intermediary. Per-connection sockets, buffers, and optional TLS state also need to be included in capacity tests at the fleet's expected concurrency.

Is Pilot Protocol a replacement for gRPC?

No. Pilot Protocol is an overlay network that provides connectivity, encryption, and peer discovery. gRPC is an RPC framework that provides typed service definitions, code generation, and streaming semantics. They operate at different layers. You can use Pilot to connect agents and run gRPC (or any other protocol) over the tunnel. Pilot replaces the network infrastructure — VPNs, service meshes, reverse proxies — not the application protocol.