libp2p Connectivity

libp2p enables universal connectivity between nodes across different network positions by supporting a wide range of transport protocols.

A primary goal of the libp2p project is universal connectivity. However, libp2p nodes may run on host machines or in browsers; they may be publically reachable or private. Thus, connectivity across these barriers has been historically out of reach.

Support for new transport protocols and our own advancements in libp2p helped us overcome these hurdles.

For developers using libp2p to build an application, we hope this site will help you learn about the transports that enable universal connectivity, how libp2p will improve in the future, and how you can get involved! 🚀

Standalone Node Connectivity

Standalone nodes are libp2p nodes that run directly on a host machine, without being constrained by a browser environment. Examples are applications using go-libp2p, rust-libp2p, or js-libp2p (when using Node.js).

If a node is on a dedicated connection, or running in a data center, without a router/NAT/ firewall in between, we call it a "public node". Public standalone nodes can use two types of transport protocols, TCP or QUIC, to connect to each with other.

TCP

Standalone ⇄ Standalone

The Transmission Control Protocol (TCP) is the one of the foundations of the Internet protocol suite and was developed in the 1970s. TCP carried, up to the introduction of QUIC, the vast majority of traffic on the internet. It was also the first transport that was adopted in libp2p. To learn why it is not supported in browsers, see the Browser Node Connectivity section further below.

Support

Possible

  • go-libp2p
  • rust-libp2p
  • node.js-libp2p

Not Possible

  • Chrome
  • Firefox
  • Safari

QUIC

Standalone ⇄ Standalone

QUIC is a new UDP-based transport protocol. QUIC connections are always encrypted (using TLS 1.3) and provides native stream multiplexing.

Whenever possible, QUIC should be preferred over TCP. Not only is it faster, it also increases the chances of a successful holepunch in case of firewalls (see next section).

However: UDP is blocked in ~5-10% of networks, especially in corporate networks, so running a node exclusively with QUIC is usually not an option.

Support

Possible

  • go-libp2p

Not Possible

  • Chrome
  • Firefox
  • Safari

Work In Progress

Work Not Started

  • node.js-libp2p

Hole Punching

Public Node ⇄ Private Node

TCP and QUIC transports are enough for establishing communication between public nodes; however, not all nodes are located in publicly reachable positions.

Nodes in home or corporate networks are private and usually separated from the public internet by a network address translation (NAT) mapping or a firewall. Mobile phones are also usually behind a so-called "carrier-grade NATs".

These private nodes behind firewalls/NATs can dial any node on the public internet, but they cannot receive incoming connections from outside their local network.

Therefore, we introduced a novel decentralized hole punching mechanism in libp2p to enable connectivity between public and private nodes.

Support

Possible

  • go-libp2p
  • rust-libp2p

Work In Progress

  • js-libp2p

Browser Node Connectivity

Enabling users and app developers to run fully functioning nodes in the browser has been a goal of the libp2p project for some time. Yet seamless connectivity had been out of reach until recent changes in libp2p and in browsers. Here we outline transports, existing and bleeding-edge, that enable browser to standalone node and browser to browser connectivity.

Streams vs. Request-Response

Advantages of libp2p over HTTP

Browsers are built on top of HTTP(S), a stateless request-response protocol. The client (browser) sends a request, and then waits for a response. This unidirectional, synchronous model results in slow data transfer.

libp2p is built on top of a stream abstraction. A stream is more flexible than a request-response scheme: it allows continuous bidirectional communication, both parties can send and receive data at any time.

Security

Why browsers do not support raw TCP or QUIC transports

Connections are handled at the transport layer and not by HTTP(S). An underlying TCP connection is used by HTTP/1.1 and HTTP/2, or a QUIC connection for HTTP/3. To keep users secure, browsers enforce strict rules, like certificate requirements and blocking cross-origin policies.

For security reasons, it's not possible for a browser to dial a raw TCP or QUIC connection from within the browser, as all connections have to meet Secure Context requirements such as for messages delivered over TLS.

WebSocket

Browser → Standalone

The WebSocket Protocol allows “hijacking” of a HTTP/1.1 connection. Later on, it was later also standardized for HTTP/2.

After an HTTP-based "Upgrade request", the browser gains access to the underlying TCP connection.

Support

Possible

  • go-libp2p
  • rust-libp2p
  • js-libp2p (both node.js and browser)
  • Chrome
  • Firefox
  • Safari

Get Involved

There are solutions to assign certificates to a fleet of nodes, see an example.

Another option would be using IP certificates. They’re quite rare, and not a lot of CAs support generating them, but this might be worth investigating.

WebTransport

Browser → Standalone

While WebSocket allows the browser to “hijack” a TCP connection, WebTransport does the same thing with a QUIC connection.

The protocol is brand-new, in fact, there’s not even an RFC yet: It’s still under development by the IETF WebTransport Working Group and the W3C WebTransport Working Group.

WebTransport is interesting for libp2p, because in contrast with WebSocket, there's a way around the strict certificate requirements, allowing its use in a p2p setting.

Support

Possible

  • go-libp2p
  • Chrome

Work In Progress

Work Not Started

  • rust-libp2p
  • node.js-libp2p

Get Involved

This is a very new protocol, and we can use your help.

Specification

Go implementation

WebRTC

Browser → Standalone and Browser ⇄ Browser

Usually used for video conferencing, Web Real-Time Communication (WebRTC) is a suite of protocols that allows browsers to connect to servers, and to other browsers, and even punch through NATs.

In addition to enabling audio and video communication (for which packets are sent using an unreliable transport), WebRTC also establishes stream-based communication and exposes reliable streams, called WebRTC Data Channels.

Support

Possible

  • Chrome
  • Firefox
  • Safari

Work In Progress

Browser → Standalone

Work Not Started

Browser ⇄ Browser

Get Involved

Specification