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 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.
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.
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.
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.
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.
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.
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.
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.
While WebSocket allows the browser to “hijack” a TCP connection, WebTransport does the same thing with a QUIC connection.
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.
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.