Communications of the ACM

WebRTC is a user-space networking stack. Unlike HTTP, which is dependent on TCP for transfer, WebRTC has its roots in a much older protocol—Stream Control Transmission Protocol (SCTP)—and encapsulates this in User Datagram Protocol (UDP). This allows for much lower latency transfer, removes head-of-line blocking, and, as a separate network stack, allows WebRTC to use significantly more bandwidth than HTTP alone.

SCTP is a little like the third wheel of the transport layer of the Open Systems Interconnection (OSI) model— we often forget it’s there but it has some very powerful features. Originally introduced to support signaling in IP networks, 22 SCTP quickly found adoption in next-generation networks (IMS and LTE).

WebRTC leverages SCTP to provide a reliable, message-oriented delivery transport (encapsulated in UDP or TCP, depending on the implementation5). Alongside SCTP, WebRTC leverages two additional major protocols: Datagram Transport Layer Security (DTLS) for security (a derivative of SSL) and Interactive Connectivity Establishment (ICE) to allow for support in network address translation (NAT) environments, for example, firewall traversal.

The details of the ICE protocol and how it works with signaling servers— for example, STUN and TURN—are beyond the scope of this article, but suffice it to say that WebRTC has all the necessary plumbing to enable real peer-to-peer networking.

A simple example is a WebRTC Golang implementation by Serene Han. 21 Han’s chat demo allows you to pass the SDP (Session Description Protocol) details between two machines (copy paste signaling) to enable P2P chat. To run this yourself (assuming you have a Docker instance locally), simply do the following:

docker run –it golang bash

Then in the Docker instance, this one-liner will get you set up:

apt-get update && apt-get install libx11-dev -y && \ go get github.com/keroserene/ go-webrtc && \

cd /go/src/ github.com/kerose-rene/go-webrtc && \ go run demo/chat/chat.go

If you prefer a browser-native starting point, look at simple-peer module, 20 originally from Feross Aboukhadijeh’s work with WebTor-rent ( https://webtorrent.io).

Storing data: Browser storage op-
tions and asset interception. The next
step is finding a method both to inter-
cept standard HTTP requests and to
develop a system for storing peer-to-
peer delivered assets. For the request-
intercept problem, you have to look no
further than the service worker. 18 The
service worker is a new feature avail-
able in most browsers that allows for
a background process to run in the
browser. Like a Web worker, which can
be used as a proxy for threads, a service
worker has restrictions on how it can
interact and exchange data with the
Document Object Model (DOM).

The service worker does, however, have a powerful feature that was originally developed to support offline page loads: the Fetch API. 16 The Fetch API allows a service worker to intercept request and response calls, similar to an HTTP proxy.