gRPC and UDP: Transport Options for Agent Communication

What Transport Does gRPC Use?

gRPC is Google's RPC framework, and at its core it is HTTP/2 over TCP with TLS. Every gRPC call — unary, server-streaming, client-streaming, bidirectional — is framed as HTTP/2 data frames over a single TCP connection. The Protocol Buffer serialization handles the payload format, but the transport is firmly in the TCP + TLS camp.

This matters for three reasons.

Connection establishment. A new gRPC connection requires a TCP three-way handshake (1 RTT), a TLS 1.3 handshake (1 RTT), and HTTP/2 SETTINGS frame exchange. That is two round trips, minimum, before any application data flows. For a workload that opens many short-lived connections — an orchestrator dispatching tasks to 50 agents, for example — this overhead adds up quickly. Our benchmarking post measures this in detail, showing that connection setup dominates for small payloads.

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.

This is not hypothetical. The gRPC project has had an experimental HTTP/3 transport since 2022. Google's internal gRPC traffic increasingly uses QUIC. The grpc-go library has an xds credentials package that supports QUIC, and the gRPC-Web transport can negotiate HTTP/3 through a browser.

But the practical reality for agent communication today is more limited.

Ecosystem maturity. The HTTP/3 transport in gRPC is not the default and is not stable across all language runtimes. The C-core based gRPC implementations (C++, Python, Ruby, PHP, Objective-C) have QUIC support lagging behind gRPC-Go. If your agent fleet uses multiple languages — and most do — you will struggle to find a uniform QUIC transport that works everywhere.

NAT traversal still missing. QUIC eliminates TCP's head-of-line blocking and cuts connection setup to 0 RTT in the best case. What it does not do is solve the reachability problem. An agent behind a NAT still cannot accept inbound QUIC connections without a relay or STUN-based hole-punching. QUIC packets are just UDP packets — they still need a return path through the NAT mapping, and short of hole-punching, that mapping only exists if the agent initiated the outbound flow.

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: gRPC over QUIC is technically feasible and will become more common over time. For the purpose of agent communication in 2026, it is not a practical alternative for most deployments.

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: Every agent gets a permanent 48-bit address that survives restarts, IP changes, and cloud migrations. No DNS, no reconnection logic.
• 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.
• Shared tunnel, not per-connection: A single UDP tunnel carries traffic to all peers. Adding the 50th peer adds minimal memory — no new TCP sockets, no new TLS sessions.

This is the approach benchmarked in depth in our HTTP vs. UDP overlay comparison. The headline finding: for the payload sizes agents typically send (1 KB to 100 KB of JSON), the UDP overlay matches gRPC over TCP on raw latency while adding reachability that gRPC cannot provide without extra infrastructure.

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?

No, standard gRPC uses HTTP/2 over TCP. gRPC can experimentally run over HTTP/3 (which uses QUIC over UDP), but this is not the default configuration and has uneven support across language runtimes. Most gRPC deployments in production today use TCP.

Can gRPC run over QUIC?

Yes, gRPC can run over QUIC via HTTP/3, and Google uses this internally. The gRPC project has experimental HTTP/3 support, but it is not enabled by default. For multi-language agent fleets, QUIC support varies by runtime — gRPC-Go has the most mature support, while C-core based implementations lag behind.

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?

Two reasons. First, TCP requires a listener — an agent behind NAT cannot accept inbound TCP connections without additional infrastructure. Second, TCP connection overhead scales with the number of peers: each connection has its own socket, buffer, and TLS session. For agent swarms with dozens of peers, this memory cost adds up. Our benchmarking post shows Pilot using 10 MB RSS for a single peer vs. 45 MB for an HTTP/2 server, and only 24 MB at 100 peers versus 240 MB.

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.