Tunnel Transports

The agent-to-engine transport layer and its configuration.

Written by uartnet

@uartnet

rstream separates two concerns: the public tunnel protocol exposed by the engine, and the transport used between an agent and the engine. The tunnel protocol describes the traffic served to downstream clients. The tunnel transport describes how the agent reaches the edge network.

This separation makes tunnel behavior predictable. An application can expose HTTP or datagram traffic while using the same hardened transport layer to reach the engine.

Transport protocols

The current rstream client transport implementations support TLS and QUIC for agent-to-engine connectivity.

QUIC typically provides better behavior on unstable networks and for datagram-heavy workloads. TLS is widely compatible and less likely to be blocked in restrictive environments.

Transport configuration

The CLI and SDKs support transport configuration that affects how the agent reaches the engine. This includes binding to a specific local address or network interface, forcing IPv4 or IPv6, overriding DNS resolution for engine hostname lookup, enabling multipath TCP when supported by the host, and routing through an HTTP CONNECT proxy with optional proxy authentication.

These settings are configured in the CLI context or through SDK transport options.

A minimal context transport example looks like this:

transport:
  ipFamily: ipv4
  dns:
    override: "8.8.8.8:53"
  proxy:
    http: "http://proxy.local:3128"

Private Tunnels Authentication