前言最近在看 B 站直播时我发现电脑的网络占用有时比较高打游戏时也会遇到延迟升高的情况。即使没有主动上传文件电脑仍然可能存在较明显的上行流量。查找原因时我开始关注 B 站网页端直播是否使用了 P2P点对点技术。部分 P2P 内容分发方案会让用户设备参与数据传输因此可能产生额外的上行流量。不过网络发送速率偏高也可能来自其他软件或后台任务不能仅凭这一现象就确定流量来源。为了验证这个问题我尝试使用 AdGuard 的nowebrtc规则和 WebRTC Control 浏览器扩展限制网页使用 WebRTC 相关接口再对比拦截前后的控制台表现与网络占用变化。本文主要记录这两种方法的配置过程、控制台验证方式以及我在实际测试中观察到的结果。技术原理WebRTC 是一套支持浏览器实时通信的技术其中的RTCPeerConnection接口用于建立和管理点对点连接。如果网页中的 P2P 组件依赖 WebRTC 建立连接那么限制相关接口就可能导致该组件无法正常工作进而影响它产生的网络流量。简单来说部分网页应用可以通过 WebRTC 建立点对点连接。在内容分发场景中如果采用这种机制用户设备可能参与数据传输而不只是接收服务器发送的内容。不过WebRTC 不等于 P2PP2P 也不一定依赖 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.getUserMediawindow.MediaStreamTrackwindow.RTCPeerConnectionwindow.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 nowebrtcWebRTC Control实现方式通过过滤规则注入脚本通过浏览器扩展限制相关接口作用范围可按域名配置通常影响较广具体取决于扩展设置配置难度需要添加规则安装后通过扩展界面控制适合人群已使用 AdGuard希望精确控制网站范围的用户希望通过浏览器扩展快速测试的用户对其他网站的影响可通过域名规则缩小影响范围可能影响其他依赖 WebRTC 的网站恢复方式删除或停用规则并刷新页面关闭扩展或调整设置并刷新页面如果已经在使用 AdGuard可以先尝试添加nowebrtc规则不必额外安装扩展。如果不熟悉过滤规则也可以使用 WebRTC Control 进行测试但需要留意其他网站的视频通话、会议和屏幕共享功能是否受到影响。注意事项配置完成后刷新页面。如果直播页面在启用规则或扩展之前就已经加载已有的连接可能不会立即受到影响。可以使用Ctrl F5强制刷新后再测试。区分发送速率与总网络占用。任务管理器中的 Wi-Fi 性能页面会分别显示发送和接收速率其他位置显示的网络占用可能是总量不能直接混用。确认 AdGuard 规则语法。本文使用的是 AdGuard 原生 scriptlet 写法。不同产品、版本和规则引擎的兼容情况可能不同不能认为所有过滤工具都支持同一种语法。正确理解控制台结果。new window.RTCPeerConnection()可以辅助判断接口是否受到限制但不能单独证明所有 P2P 连接都已停止。测试结论以实际环境为准。网络发送速率会随时间波动其他应用也可能产生上行流量。单次截图只能说明当时观察到的现象不能保证所有设备和直播间都有相同结果。总结这次尝试使用 AdGuard 的nowebrtc规则和 WebRTC Control 浏览器扩展观察限制 WebRTC 相关接口后B 站直播期间的网络活动是否发生变化。在本次测试中网卡发送速率从约 11.3 Mbps 降至约 88 Kbps下降约 99.2%而接收速率没有同步下降。这是一个值得进一步验证的现象但由于数据来自整个 Wi-Fi 网卡目前还不能将全部变化直接归因于 B 站 P2P。两种方案都可以作为排查 WebRTC 相关网络活动的尝试。建议优先选择作用范围清晰、便于恢复的配置并在实际使用中确认直播播放及其他网页功能是否受到影响。如果你也遇到 B 站直播期间上行发送速率异常偏高的情况可以尝试上述方法再结合自己的实际测试结果判断是否有效。