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.
With the service worker online, you
can now intercept traditional HTTP
Figure 7. Effect of P2P enhanced background caching on load time.
accelerated
4249
page views
4248
visitors
2.568
average load time (seconds)
55.658
max load time (seconds)
0.403
average net time (seconds)
9.361
max net time (seconds)
803
views over 4 seconds
1779
views over 2 seconds
standard
7674
page views
4235
visitors
4.838
average load time (seconds)
56.775
max load time (seconds)
0.852
average net time (seconds)
36.465
max net time (seconds)
3524
views over 4 seconds
5912
views over 2 seconds
Figure 8. Page load time components: Accelerated vs. standard.
accelerated
1 0 2 3 4 56
Page Load Time (Seconds)
standard
total
DNS
time
TCP
time
request
time
response
time
DOM
loading
time
DOM
interactive
time
DOM
complete
time