Web P2P Live Streaming Architecture and Implementation Using WebRTC

Introduction

In the 2021 Internet era, live streaming programs have proliferated. Browsers, as a primary access channel, gather massive concurrent viewers, causing server load, playback stutter, latency, and high bandwidth costs.

The article introduces a Web P2P solution that reduces server load and bandwidth while maintaining user experience.

1. The Evolution of Web P2P

In 2010 Adobe released RTMFP in Flash Player 10.0, enabling P2P between Flash Players. After browsers dropped Flash support, WebRTC, launched in 2011 and backed by major vendors, became the H5 standard for P2P communication.

From now on, the term “H5 P2P” refers to HTML5 P2P built on WebRTC.

2. WebRTC Overview

The overall WebRTC architecture is shown in the figure (browser‑side Web API is the focus for P2P implementation).

H5 P2P relies on RTCPeerConnection and RTCDataChannel for data‑only P2P, without audio/video streams.

3. Overall Architecture

3.1 H5 P2P Client

The client consists of communication, transport, node management, scheduling, storage, and statistics modules.

Communication module: signaling with backend services (Index, CPS, Tracker).

Transport module: HTTPClient and RTCClient (upload & download) based on RTCDataChannel.

Node management: peer connection, disconnection, eviction, and resource sync.

Scheduling module: CDN/P2P decision based on buffer level, chunk info, node quality, and scale.

Storage module: media data storage, ordering, and eviction.

Statistics module: implementation of runtime telemetry.

3.2 H5 P2P Server

The server side includes Index, CPS, Tracker, MQTT (signaling), and STUN services.

Index: provides addresses of other services.

CPS: converts live stream URLs to Resource IDs (RID).

Tracker: stores user‑resource index relationships.

MQTT: forwards offer/answer/candidate SDP for P2P signaling.

STUN: deployed via coturn for UDP NAT traversal.

4. Process Flow

The diagram (omitted) shows the stages:

Step 1: Browser requests service addresses from Index.

Step 2: Client sends live request to CPS to obtain RID.

Step 3: Client starts HTTPClient for fast start, then:

Requests peer addresses from Tracker.

Publishes its own address to Tracker.

Step 4: Establish connections with peers obtained from Tracker and share data.

5. Connection Establishment

WebRTC uses the ICE framework (STUN & TURN) for peer‑to‑peer connections.

5.1 ICE

ICE provides a unified P2P connectivity framework, handling NAT traversal via STUN and TURN, using the offer/answer/candidate exchange.

5.2 STUN

STUN lets a client behind NAT discover its public IP/port and NAT type (RFC 5389).

5.3 TURN

TURN acts as a relay when direct STUN traversal fails. In this project, only STUN is used to keep bandwidth costs low.

6. Data Download

6.1 Resource Encoding

Each live stream is identified by a unique Resource ID (RID) generated by MD5 hashing the StreamId, ensuring identical content at different qualities gets distinct RIDs while the same content across URL changes retains the same RID.

6.2 Download Scheduling

Because the playable buffer is small (usually ≤10 s), the system decides between CDN and P2P:

If buffered playable data falls below a threshold (e.g., 5 s), switch to CDN.

If a future chunk has no nearby peers, switch to CDN and also trigger a proportion of peers (e.g., 15 %) to switch, accelerating overall distribution.

6.3 P2P Task Allocation

Each chunk is identified by (RID, sn, chunk_index). Allocation follows a “card‑dealing” style: peers with the needed chunk and higher quality receive priority for chunks near the playback point.

6.4 Memory Control

Only a sliding window around the current playback point is kept in memory. Red, yellow, and green blocks in the illustration represent current, past, and future chunks respectively; as playback advances, old chunks are evicted and new ones are cached.

7. Engineering Practices

7.1 FlatBuffers

Both server‑side signaling and P2P data transfer use Google FlatBuffers for cross‑platform, low‑memory, high‑performance serialization.

7.2 Multi‑Browser Compatibility

WebRTC adapter.js is employed to smooth differences among browsers that support WebRTC.

7.3 Memory Pool

A custom memory pool on the client side achieves near‑100 % memory reuse, reducing GC overhead in the single‑threaded browser environment.

8. Technical Results

Bandwidth statistics from a large‑scale live event show that Web P2P consistently provides significant bandwidth savings without degrading user experience, reducing server load and bandwidth cost.

9. Reflections

The solution is now widely deployed, but challenges remain:

Performance of coturn and MQTT services limits quality at massive scale.

Integrating edge networks and multi‑path routing could further offload CDN bandwidth.