Transport and Connectivity

P2P systems must establish direct connections between peers that are often behind NATs, firewalls, and heterogeneous networks. The transport layer is where the idealism of decentralization meets the messy reality of the internet.

Transport Protocols

TCP: reliable, ordered, widely supported. But head-of-line blocking (one lost packet stalls all streams), slow three-way handshakes, and difficulty with NAT traversal limit its appeal for modern P2P. Still the fallback when all else fails.

UDP: low overhead, no connection state. The substrate for QUIC, uTP, and most hole-punching techniques. Essential for P2P because NAT mappings for UDP are generally more permissive than for TCP.

QUIC: multiplexed streams over UDP with built-in TLS 1.3, 0-RTT handshakes, connection migration between network addresses, and no head-of-line blocking across streams. Increasingly the default transport in libp2p and modern P2P stacks. QUIC's connection migration is particularly valuable for mobile P2P where IP addresses change frequently.

uTP/LEDBAT: UDP-based transport with delay-sensitive, low-priority congestion control that yields to interactive traffic. Designed so BitTorrent bulk transfers don't ruin your video call. LEDBAT (Low Extra Delay Background Transport) measures one-way delay to detect congestion earlier and back off more aggressively than loss-based algorithms.

WebRTC data channels: browser-native P2P via ICE/DTLS/SCTP. Enables P2P in web applications without plugins. Used by WebTorrent (browser BitTorrent), js-libp2p, and experimental P2P Matrix clients.

WebTransport: an emerging alternative to WebRTC for browser P2P, based on HTTP/3 and QUIC. Simpler setup than WebRTC's SDP negotiation; supported in libp2p js and go implementations.

NAT Traversal

Most peers sit behind Network Address Translators, which rewrite packet headers and create asymmetric reachability. NAT traversal is often the single hardest practical problem in P2P engineering.

NAT Types

NAT behavior varies widely. The classic taxonomy:

Full cone: any external host can send to the mapped port. Easiest to traverse.

Address-restricted cone: only hosts the internal peer has contacted can send back.

Port-restricted cone: as above, but also restricted by source port.

Symmetric: each destination gets a different external mapping. Hardest to traverse; hole punching often fails. Testing and Operations recommends building a NAT lab matrix covering all types.

The ICE Framework

ICE (Interactive Connectivity Establishment, RFC 8445) orchestrates traversal:

Candidate gathering: collect host candidates (local IPs), server-reflexive candidates (via STUN), and relay candidates (via TURN).

STUN (Session Traversal Utilities for NAT, RFC 5389): discovers the peer's public address and NAT type by sending a request to a known STUN server.

Connectivity checks: try all candidate pairs simultaneously; pick the best working path.

Hole punching: both peers send packets simultaneously to create NAT mappings. Works well for cone NATs, poorly for symmetric NATs.

TURN (Traversal Using Relays around NAT, RFC 5766): relay fallback when direct connectivity fails. Guarantees connectivity at the cost of latency and relay resources.

UDP hole punching is preferred for efficiency. QUIC hole punching is gaining support in libp2p via the AutoNAT (automatic reachability detection) and DCUtR (Direct Connection Upgrade through Relay) protocols.

Relays

When direct connections fail, application-level relay nodes forward traffic. Relays are a pragmatic concession—they introduce a trusted intermediary but preserve the P2P model at the application layer. Good relay designs:

Multiplex many peers over few relay connections to conserve resources.

Limit bandwidth and duration to prevent abuse and manage costs.

Attempt direct upgrade (DCUtR) as soon as possible—use the relay only as a bootstrap.

Rotate relay assignments to avoid creating permanent superpeer bottlenecks.

Secure Scuttlebutt rooms and Syncthing relay servers are examples of application-level relays. Tor relays serve a different purpose—anonymity rather than connectivity—but share some operational characteristics.

Transport Security

Every P2P connection should be authenticated and encrypted:

Noise Protocol Framework: used by libp2p, WireGuard, and Hyperswarm. Lightweight, flexible handshake patterns (XX, IK, etc.) that bind the connection to peer identity keys.

TLS 1.3: standard web encryption; used by libp2p's QUIC transport and WebTransport.

Secret handshake (SHS): SSB's custom authenticated key exchange that also hides the server's identity from unauthenticated clients.

Transport security prevents eavesdropping and ensures you're talking to the peer you think you are—critical when the DHT could return addresses for malicious nodes.

Multiplexing

P2P nodes run many protocols simultaneously (DHT queries, block exchange, PubSub, etc.). Multiplexing shares a single connection across multiple logical streams:

yamux/mplex: stream multiplexers in libp2p.

QUIC native multiplexing: QUIC has built-in stream multiplexing, eliminating the need for a separate layer.

Protocol negotiation: libp2p's multistream-select lets peers negotiate which application protocol to use on each stream, enabling rolling upgrades.

Congestion Control

CUBIC/BBR: standard TCP congestion control algorithms. BBR (Bottleneck Bandwidth and RTT) optimizes for bandwidth estimation and works better on high-bandwidth, high-latency links.

LEDBAT: delay-based, yields to other traffic; ideal for Storage and Distribution bulk transfers.

QUIC CC: QUIC carries its own congestion control (often BBR or Reno-family) with per-stream flow control, allowing independent backpressure per protocol.

How Transport Connects to Everything Else

Transport sits below Overlay Networks and DHTs (which decide whom to connect to) and above the application protocols that perform Content Addressing, State Sync, and PubSub. Privacy and Anonymity overlays like Tor add their own transport wrapping for unlinkability. Identity authenticates transport connections. Security Threats like connection flooding target this layer directly. The Design Patterns document describes the layered architecture in which transport is the bottom layer. Compliance applies to relay operators who may carry third-party traffic.