企业官网建设流程全解析

前言

最近在看 B 站直播时，我发现电脑的网络占用有时比较高，打游戏时也会遇到延迟升高的情况。即使没有主动上传文件，电脑仍然可能存在较明显的上行流量。

查找原因时，我开始关注 B 站网页端直播是否使用了 P2P（点对点）技术。部分 P2P 内容分发方案会让用户设备参与数据传输，因此可能产生额外的上行流量。不过，网络发送速率偏高也可能来自其他软件或后台任务，不能仅凭这一现象就确定流量来源。

为了验证这个问题，我尝试使用 AdGuard 的nowebrtc规则和 WebRTC Control 浏览器扩展，限制网页使用 WebRTC 相关接口，再对比拦截前后的控制台表现与网络占用变化。

本文主要记录这两种方法的配置过程、控制台验证方式，以及我在实际测试中观察到的结果。

技术原理

WebRTC 是一套支持浏览器实时通信的技术，其中的RTCPeerConnection接口用于建立和管理点对点连接。

如果网页中的 P2P 组件依赖 WebRTC 建立连接，那么限制相关接口就可能导致该组件无法正常工作，进而影响它产生的网络流量。

简单来说，部分网页应用可以通过 WebRTC 建立点对点连接。在内容分发场景中，如果采用这种机制，用户设备可能参与数据传输，而不只是接收服务器发送的内容。

不过，WebRTC 不等于 P2P，P2P 也不一定依赖 WebRTC。目前不能仅凭网络占用变化就认定 B 站所有直播间都使用同一种传输机制，也不能断言禁用 WebRTC 后所有 P2P 流量都会被阻断。

因此，这次测试的思路是：限制网页使用 WebRTC 相关接口，再观察接口状态和网络占用是否发生变化。

方法一：AdGuard 用户过滤器

打开 AdGuard 设置，进入支持自定义规则的过滤器区域，添加以下规则：

live.bilibili.com##+js(nowebrtc)

这条规则使用 AdGuard 原生 scriptlet 语法，针对 B 站直播域名注入nowebrtc脚本，以限制网页使用相关 WebRTC 功能。

如果希望同时覆盖 B 站主站及其子域名，可以尝试：

bilibili.com##+js(nowebrtc)

具体匹配范围和生效情况取决于规则引擎及 AdGuard 版本。添加规则后，建议刷新直播页面，再进行验证。

另外，以下是AdGuard原生 scriptlet 语法：

live.bilibili.com#%#//scriptlet('nowebrtc') bilibili.com#%#//scriptlet('nowebrtc')

规则语法说明：

本文实际使用的是bilibili.com##+js(nowebrtc)，属于 uBlock Origin 风格的 scriptlet 语法。部分 AdGuard 产品和版本支持该写法，具体取决于过滤规则引擎。

由于本文已通过控制台对比观察到RTCPeerConnection返回结果发生变化，因此保留实际测试成功的配置，不再额外更换规则语法。

方法二：WebRTC Control 插件

在 Chrome、Edge 或 Firefox 的扩展商店中搜索WebRTC Control，确认扩展来源及实际支持的浏览器后安装。

基本使用方法：

• 点击浏览器工具栏中的扩展图标。

• 根据扩展当前的图标状态及说明，确认 WebRTC 控制功能是否启用。

• 打开或刷新 B 站直播页面，再检查效果。

WebRTC Control 会限制部分 WebRTC 相关 API。项目说明中涉及的接口包括：

• navigator.getUserMedia

• window.MediaStreamTrack

• window.RTCPeerConnection

• window.RTCSessionDescription

具体实现和不同版本的行为可能存在差异。限制这些接口后，依赖它们的网页功能可能受到影响，但不能据此断言所有 P2P 连接都会被阻断。

需要注意，全局禁用 WebRTC 可能影响其他网站的视频会议、网页通话或屏幕共享等功能。如果这些功能无法正常使用，可以关闭扩展或调整相关设置。

验证效果

控制台验证

在 B 站直播页面按F12打开开发者工具，切换到 Console（控制台），输入：

new window.RTCPeerConnection()

对比拦截前后的返回结果：

拦截前：返回正常的RTCPeerConnection对象，可以看到localDescription、remoteDescription等相关属性。

拦截后：返回rtcReplacement {}，表明相关接口很可能已被脚本替换。

这一变化与 WebRTC 接口被替换或限制的表现相符，可以作为拦截生效的辅助证据。但它不能单独证明所有 WebRTC 功能或 P2P 连接均已停止，具体效果仍需结合实际测试判断。

如果控制台结果与预期不符，可以先确认规则语法、扩展状态以及页面是否已经刷新。

网络占用实测

为了观察限制 WebRTC 相关功能后的网络变化，我在同一直播间【环境：400+人数，1080原画（高帧率）】进行了前后对比。以下为 Windows 任务管理器中 Wi-Fi 网卡的性能截图。

拦截前	拦截后

图注：左图为拦截前，右图为拦截后。截图中的发送速率由约 11.3 Mbps 降至约 88 Kbps。

从本次截图来看，网卡发送速率出现了明显下降，发送速率的虚线几乎消失了，而接收速率仍处于相近的水平。按截图读数计算，发送速率下降约 99.2%。

这说明本次测试中，上行发送活动明显减少。不过，数据反映的是整个 Wi-Fi 网卡的网络活动，并非 B 站直播单独产生的流量。因此，目前还不能将全部变化直接归因于 B 站 P2P，也不能保证其他直播间会出现相同结果。

禁用后对正常观看直播有影响吗？

在本次测试中，禁用相关功能后，直播播放基本正常，且我本人体验明显改善。

一般来说，网页直播的视频播放、弹幕和互动功能可能分别依赖不同的传输机制，并不一定全部依赖 WebRTC。因此，限制 WebRTC 后，部分直播功能仍然可能正常运行。

实际效果仍取决于播放器的实现方式和具体直播间，不能保证所有场景都不受影响。如果遇到视频无法播放、互动异常或其他网页功能故障，可以关闭相关规则或扩展，刷新页面后重新测试。

另外，直播播放仍然正常，并不代表 P2P 功能一定完全停止；同样，网络占用下降也不等于所有下降的流量都来自 P2P。

两种方案对比

如果已经在使用 AdGuard，可以先尝试添加nowebrtc规则，不必额外安装扩展。

如果不熟悉过滤规则，也可以使用 WebRTC Control 进行测试，但需要留意其他网站的视频通话、会议和屏幕共享功能是否受到影响。

注意事项

1. 配置完成后刷新页面。如果直播页面在启用规则或扩展之前就已经加载，已有的连接可能不会立即受到影响。可以使用Ctrl + F5强制刷新后再测试。

2. 区分发送速率与总网络占用。任务管理器中的 Wi-Fi 性能页面会分别显示发送和接收速率；其他位置显示的网络占用可能是总量，不能直接混用。

3. 确认 AdGuard 规则语法。本文使用的是 AdGuard 原生 scriptlet 写法。不同产品、版本和规则引擎的兼容情况可能不同，不能认为所有过滤工具都支持同一种语法。

4. 正确理解控制台结果。new window.RTCPeerConnection()可以辅助判断接口是否受到限制，但不能单独证明所有 P2P 连接都已停止。

5. 测试结论以实际环境为准。网络发送速率会随时间波动，其他应用也可能产生上行流量。单次截图只能说明当时观察到的现象，不能保证所有设备和直播间都有相同结果。

总结

这次尝试使用 AdGuard 的nowebrtc规则和 WebRTC Control 浏览器扩展，观察限制 WebRTC 相关接口后，B 站直播期间的网络活动是否发生变化。

在本次测试中，网卡发送速率从约 11.3 Mbps 降至约 88 Kbps，下降约 99.2%，而接收速率没有同步下降。这是一个值得进一步验证的现象，但由于数据来自整个 Wi-Fi 网卡，目前还不能将全部变化直接归因于 B 站 P2P。

两种方案都可以作为排查 WebRTC 相关网络活动的尝试。建议优先选择作用范围清晰、便于恢复的配置，并在实际使用中确认直播播放及其他网页功能是否受到影响。

如果你也遇到 B 站直播期间上行发送速率异常偏高的情况，可以尝试上述方法，再结合自己的实际测试结果判断是否有效。