Design and Implementation of Bilibili's Live P2P Streaming System Using WebRTC

With continuous hardware improvements, viewers now have faster CPUs, larger and higher‑resolution displays, and widespread fiber broadband. These conditions enable higher‑quality live video, but also increase the bandwidth cost for streaming platforms.

Because network bandwidth accounts for the largest portion of technical costs, many live‑streaming services adopt peer‑to‑peer (P2P) technology to reduce server bandwidth. Cloud providers also offer turnkey P2P solutions for platforms lacking in‑house development capabilities.

Bilibili has completed its own HLS‑based live streaming stack, providing the prerequisite for a self‑developed P2P solution. HLS delivers video as segmented files; by allowing different viewers to download different segments and then exchange them via P2P, the server only needs to send each segment once, dramatically lowering bandwidth consumption.

02 Using WebRTC for Communication

WebRTC originated from Global IP Solutions, was open‑sourced by Google, and is now standardized by IETF and W3C. Since Chrome 28 it has been built into browsers, and other browsers have followed suit.

WebRTC is the only browser‑native data‑transfer method that does not rely on a traditional client‑server model, making it ideal for P2P live streaming where the majority of users are browser‑based.

2.1 WebRTC Connection Flow

The connection is negotiated via the Session Description Protocol (SDP). An SDP Offer is created by the initiator, and an SDP Answer is returned by the responder. The relevant WebRTC APIs are CreateOffer , SetLocalDescription , CreateAnswer , and SetRemoteDescription . In Bilibili’s case only the data channel is used, so audio/video tracks are omitted.

Before an Offer can be generated, the application specifies the desired transport (data channel). After the Offer/Answer exchange, both peers set their local and remote descriptions, completing the handshake.

A Tracker server (implemented with WebSocket) mediates the initial Offer/Answer exchange between viewers watching the same live stream, enabling them to discover each other and establish direct WebRTC connections.

2.2 Application‑Layer Protocol

After the WebRTC DataChannel is established, binary messages are exchanged. JSON is convenient but not binary‑friendly; Base64 encoding inflates payload size. Bilibili therefore adopts MessagePack, a self‑describing binary format with low overhead and native binary support.

The DataChannel uses SCTP. Although the specification permits fragmenting large messages, browser implementations vary. Empirical testing showed that 64 KB is a safe upper bound; Bilibili caps the maximum payload at 60 KB to leave room for protocol overhead.

To improve throughput, the system allows pipelined requests: a client may send a new request before receiving a response to the previous one. Each request carries a unique request ID, enabling out‑of‑order responses.

The protocol is stateless: a peer only sends data when it receives an explicit request, reducing the load on the serving side.

Because HLS segments (M4S files) often exceed 60 KB, each segment is split into multiple 60 KB blocks for P2P transfer. An auxiliary API reports per‑block download status (downloaded, downloading, not downloaded).

03 Peer Division and Task Allocation

3.1 The Allocation Problem

After establishing connections, the client creates a set of PeerConnection objects, generates Offers, sends them via the Tracker, receives Answers, and attempts to connect to other viewers. Connection success varies due to network topology and NAT types.

Once connections are in place, peers exchange data blocks according to the protocol described above. However, the system must avoid a “deadlock” where every peer waits for others to upload data that no one possesses.

To break the deadlock, some peers must initially download original data from the CDN. These “seeders” then distribute the data to others. The system limits each peer’s upload to no more than its total download to prevent network abuse.

3.2 A Free‑Market Mechanism

Because the audience constantly joins and leaves, a static allocation strategy fails. Bilibili models the peer network as a free market: data blocks that are in high demand (supply < demand) are prioritized for initial seeding, while over‑supplied blocks are deprioritized.

Each peer independently decides whether to switch roles (seed vs. leech) based on a probabilistic “dice roll”. If the role change does not sufficiently rebalance supply and demand, another roll occurs later. This decentralized approach eliminates the need for a central scheduler and adapts to churn.

04 Conclusion

A simple yet efficient live P2P system has been built. By constraining each peer’s upload to be no greater than its download and by orchestrating cooperative task allocation, the solution supports massive concurrent viewers while keeping bandwidth costs within budget.

We welcome comments and questions; if you enjoyed this content, please give us a like!