DNS entirely. This is a fantastic wholesale change, but the tradeoff is that it
will require users to dramatically modify how they access content.
Since a P2P design is dependent
on the total network size, this model
has difficulty growing until it reaches
critical mass. At Edgemesh, we want-
ed to focus on enhancing existing
Web-content delivery transparently
(for example, in the browser) without
requiring any changes to the user ex-
perience. This means ensuring that
the technology abides by the following
three restrictions:
˲ For users, the solution should be
transparent.
˲ For developers, the solution should
require zero infrastructure changes.
˲ For operations, the solution should
be self-managing.
The next question is where exactly
to focus.
Fully enabling peer-enhanced delivery of all content is difficult and
dangerous, especially allowing for
peer-delivered JavaScript to be executed. Is there an 80% solution? Trends
posted by HTTP Archive reveal that
static components (images/video/
fonts/CSS) make up roughly 81% of the
total page weight. 9
Given these details, let’s narrow
the focus to enabling/enhancing edge
delivery of these more traditional
CDN assets and the associated chal-
lenges of moving and storing data.
Moving data: Building a new net-
work (overlay). To support P2P distribu-
tion, an overlay network needs to be de-
veloped to allow the P2P connections
to operate within the larger existing
Internet infrastructure. Luckily, such
a stack is available: WebRTC (Real-
Time Communications19). Started in
earnest in 2011 by Google, WebRTC is
an in-browser networking stack that
enables peer-to-peer communication.
WebRTC is primarily employed by
voice and video applications (Google
Hangouts/Dua/Allo, Slack, Snapchat,
Amazon Chime, WhatsApp, Facebook
Messenger) to facilitate peer-to-peer
video- and audioconferencing.
WebRTC is a big deal; in June 2016
Google provided several key milestones7
from stats it collected, with some additional updates six months later: 25
˲ Two billion Chrome browsers with
WebRTC.
˲ One billion WebRTC audio/video
minutes per week on Chrome.
˲ One petabyte of DataChannel traffic per week on Chrome (0.1% of all
Web traffic).
˲ 1,200 WebRTC-based companies
and projects (it was 950 in June).
˲ Five billion mobile app downloads
that include WebRTC.
WebRTC support exists in the major browsers—Chrome, Firefox, Edge,
and now Safari, 2 Comparing WebR TC’s
five-year adoption against other VoIP-style protocols shows the scale. 8
Figure 6. Performance increased by routing preference.
100
80
60
40
20
0
Cum
u
lati
v
ePe
rce
nt
o
fS
amp
le
s
Latency Buckets (Ms)
cross_asintra_as
180-199,
0.490317052
380-399,
0.464235869
20–39 80–99140–159200–219260–279320–339380–399440–459500–519560–579620–639680–689740–759800–819880–899940–959
Figure 5. Flow diagram for WebRTC Enhanced asset delivery.
origin or CDN edge origin or CDN edge
client DOM
first client GET subsequent client GETs
signal server
provides WebRTC signaling
and STUN services
0. GET H TML
for Page
1. Traditional GET
of image:
img1.jpg
14. WebRTC img1.webp
(chunked and compressed)
to peer
12. websocket
response:
img1.jpg @peer1
img1.webp @peer1
11. websocket request
asset locate
img1.jpg and
img1.webp
8. GET HTML
for page
2. traditional render
of image: img1.jpg
service worker
3. EM prepare image
(web worker)
calc MD5, prepare
to register on mesh
4. image conversion
(web worker)
create img1.webp
from img1.jpg
5. compress and chunk
image(s) (web worker)
6. register new assets
with mesh (web
socket)
7. register’s new assets
includes MD5 for both
assets and format
service worker
9. EM client (web
worker) sees img1.jpg
is in future GET
request queue
10. request both
img1.jpg or
img1.webp from
mesh (locate asset)
NOTE: request
includes all assets
on page
16. traditional render
of image:
img1.webp
13. request optimal
image (img1.webp)
from peer
15. deflate img1.webp,
check MDS, insert in
DOM for render
client DOM