This article analyzes WebRTC's GCC congestion control mechanism and records measurement data to build a quantitative understanding of its congestion control behavior.
1. Test Version M126
<img src="https://img.pixpark.net/image-20240715150724441.png" alt="image-20240715150724441" style="zoom:50%;" />2. Bandwidth Capacity Limit — Link Limit
In bandwidth capacity limit scenarios, WebRTC's bandwidth estimation is quite accurate. At 1000 kbps, 500 kbps, and 200 kbps, it can typically estimate above 90% and largely fill the available bandwidth. The performance is very good, with little room for improvement.
3. Bandwidth Contention — UDP vs TCP
This test covers bandwidth contention between WebRTC and TCP only. Total bandwidth is capped at 800 kbps. During a video call, file uploads over TCP are used to simulate bandwidth contention.
Once TCP traffic is introduced, UDP bandwidth drops quickly and is essentially overwhelmed. After the file upload stops, UDP bandwidth gradually recovers.
The test platform is macOS. The macOS kernel's TCP congestion control algorithm may handle contention well, giving TCP strong bandwidth-grabbing ability. WebRTC performs poorly in this scenario and loses decisively.
This result also shows why you should not upload files during a video call, or send large files via WeChat or other upload-heavy operations.
For WebRTC to compete for bandwidth, the cost is also high: it must retransmit a large number of lost packets caused by bandwidth contention. Being able to survive 10–15% packet loss may allow it to compete with TCP.
However, WebRTC treats any noticeable packet loss as a sign of network congestion and appropriately reduces the send bitrate to relieve it. Distinguishing true congestion from bandwidth contention is difficult, so this area is hard to handle well.
4. Packet Loss Scenarios
With bandwidth capped at 800 kbps and random packet loss added, GCC essentially collapses at around 15% loss. This validates WebRTC's basic approach to network congestion: once packet loss reaches a certain level, the network is considered congested and the send bitrate is reduced to ease congestion.
The maximum packet loss tolerance in the WebRTC source code is 10%.
5. Network Congestion Optimization Suggestions
In my view, WebRTC's network congestion handling strategy and performance are already very good, and it can estimate network capacity with good accuracy. One reason bandwidth utilization may be lower than TCP is that its transmitted data comes from an encoder and changes in real time—you cannot simply send as much data as you want whenever you want.
Its handling of packet loss is also very reasonable. Pure packet loss with sufficient bandwidth is, in my opinion, quite rare; most loss comes from insufficient network bandwidth capacity.
So when RTC vendors claim they can stay smooth at 70% packet loss or even higher, that claim is largely meaningless. Their anti-loss performance is measured when network bandwidth is not constrained. Once bandwidth is insufficient, aggressively retransmitting lost packets only makes congestion much worse.
That kind of number is mostly marketing. In real production environments, performance is often poor because the optimization direction is wrong.
You can test Tencent Meeting at 200 kbps bandwidth—it is basically unusable. Tencent Meeting's congestion control still leans toward anti-loss behavior.
6. Something Interesting
During testing, when an iPhone is connected to a Mac via a data cable, network data is transferred over the cable. The phone and Mac create a virtual network interface, and the IP address is even a U.S. IP address.
Packet Capture
