最近闹得很大的B站CPU分流,被拦截插件拦截上千条技术分析辟谣
首先解释一下什么是cpu分流跟流量分流
定义
一、CPU分流(也叫“计算分流”)
定义:
CPU分流是指将大量的计算任务合理地分配给多个CPU核心或多个处理器上,以避免某一个CPU核心负载过重,提高整体计算效率和响应速度。
常见应用场景:
- 多线程程序中,将任务均衡分配到各线程,借助多核CPU提高执行效率。
- 操作系统层面调度任务到不同的核心(负载均衡)。
- Web服务器或高并发应用中,后台逻辑用线程池或协程分摊CPU运算压力。
二、流量分流(网络层面的“流量调度”或“流量路由”)
定义:
流量分流是指将大量的网络请求(或数据流)根据一定策略(如IP、URL、用户ID等)分发到不同的服务器、节点或处理模块,以提升系统性能、扩展性和可靠性。
常见应用场景:
- CDN(内容分发网络)中根据用户位置选择最近的节点。
- 微服务架构中按接口路由到不同服务模块。
- 大型网站将用户访问按地理、业务类型分流至不同服务器。
- 灰度发布中,将一部分用户请求导向新版本服务。
举例:
比如抖音、淘宝为了避免某个节点压力过大,会将访问流量按地域或用户ID hash 值,分配到多个服务器,这就是流量分流。
开始辟谣
cpu分流??网页如何做到cpu分流???
相信大家看完这些解释后就可以发现一个问题。
网页(前端)本身几乎不可能真正进行“CPU分流”,原因如下:
- 网页运行在浏览器中,受限于 JavaScript 的单线程模型
- JavaScript 是单线程的(除了 Web Worker 之外),也就是说主线程里只能一次做一件事。
- 所以大部分网页代码默认都只用到一个CPU核心的主线程,无法自动进行“多核并发处理”。
- 浏览器可以在后台做多线程,但这不是网页控制的
- 浏览器自身的行为,比如渲染、视频解码、资源加载,可能用多线程、并行处理(这是浏览器的“CPU分流”行为)。
- 但前端开发者控制不到这些“分流”的细节。
- 即使你打开 10 个网页标签页,这些可能分别被分配给不同的线程或进程,但那是浏览器在做,不是网页在做。
所以说这个就是我们辟谣的第一个视频
这个无法做到cpu分流
关于博主所说的流媒体分流
流媒体分流技术本身不会导致你耗费“额外流量”
B站这种视频网站,为了保证全国范围的视频播放流畅,肯定使用了流媒体的各种分流技术。具体包括:
- CDN 流量分流(内容分发网络)
- B站的视频资源分布在全国各地、甚至海外的 CDN 节点 上。
- 当你播放视频时,B站会通过 DNS调度 或 HTTP重定向,把你导向离你最近的 CDN 节点。
- 同一部视频,你在北京和在深圳看到的地址可能完全不同,甚至来自不同运营商的 CDN。
例子:
你请求视频地址时,可能获取到如下地址:
bash复制编辑https://upos-sz-mirrorakam.akamaized.net/...
https://cn-hbyc2-cmcc-v-01.bilivideo.com/...
这些域名中包含了:
- 地区代码(如
sz
代表深圳、hbyc
代表湖北宜昌) - 节点信息(如
cmcc
代表中国移动)
🎯 2. 分段式视频(流媒体切片)分流
- B站使用的是 HLS(m3u8)或 DASH(MPD)协议,将视频分成多个
.ts
或.m4s
小片段。 - 每个片段可能来自不同的节点/CDN服务器,提高播放稳定性。
🎯 3. 并行/备用线路
B站在设置中提供了“播放线路切换”功能,你可以选择:
- 主线路(电信/联通/移动)
- 备用线路(比如 B站海外CDN)
- 高画质服务区(部分画质/清晰度只在特定地区可用)
🎯 4. 多域名/负载均衡分流
- B站使用多个视频域名(如
upos-hz-mirrorali
,upos-sz-mirrorcos
,upos-bstar-mirrorakam
), - 这些代表了阿里云、腾讯云、百度云、Akamai 等多个 CDN 供应商,分流压力、规避单点失败。
所以说这个跟分流又有什么关系呢???
正常的流媒体分流不会显著提高用户 CPU 占用
“流媒体分流”的本质是网络层面的资源分配(如从不同 CDN 节点获取视频片段),它主要影响的是网络 IO,而不是 CPU 使用率。
插件检测
这里我自己写了一个插件来检测一下分流的时候cpu是否真的会有问题
// ==UserScript==
// @name 网站分流检测工具
// @namespace http://tampermonkey.net/
// @version 1.0
// @description 检测网站是否使用了流量分流或CDN节点等信息
// @author Xiaou61
// @match *://*/*
// @grant GM_xmlhttpRequest
// @connect *
// ==/UserScript==
(function () {
'use strict';
function createButton() {
const btn = document.createElement("button");
btn.textContent = "检测是否分流";
btn.style.position = "fixed";
btn.style.top = "20px";
btn.style.right = "20px";
btn.style.zIndex = 9999;
btn.style.padding = "10px";
btn.style.background = "#007bff";
btn.style.color = "#fff";
btn.style.border = "none";
btn.style.borderRadius = "5px";
btn.onclick = detectSplitting;
document.body.appendChild(btn);
}
function detectSplitting() {
const url = location.origin + '/'; // 当前网站根地址
console.log("开始发送请求以检测分流...");
for (let i = 0; i < 5; i++) {
GM_xmlhttpRequest({
method: "GET",
url: url + "?ts=" + Date.now() + "&r=" + Math.random(),
headers: {
"Cache-Control": "no-cache"
},
onload: function (response) {
console.log("响应头信息:", response.responseHeaders);
let headers = response.responseHeaders.toLowerCase();
let serverInfo = [
"server", "via", "x-cache", "cf-ray", "x-amz-cf", "x-edge-location"
].filter(h => headers.includes(h));
if (serverInfo.length > 0) {
alert("检测到可能的流量分流/CDN信息:\n" + serverInfo.join(", "));
} else {
console.log("未检测到明显的CDN/分流头部字段");
}
}
});
}
// 检测JS执行时间,简单测CPU压力情况
let start = performance.now();
let count = 0;
for (let i = 0; i < 1e7; i++) {
count += i;
}
let duration = performance.now() - start;
console.log("模拟计算耗时(ms):", duration.toFixed(2));
alert("模拟CPU计算耗时:" + duration.toFixed(2) + "ms");
}
createButton();
})();
首先是一个cpu的模拟检测5ms好像根本影响不了什么东西
之后来查看他可能分流的地方
x-cache
:这是一个常见的 CDN 缓存命中状态字段,可能值如:
server
:通常标明当前响应是由哪个服务器软件(或 CDN)返回的,比如 bilibili-cdn
等
还是那句话,这个跟CPU有什么关系,我是想不明白的。
用拦截插件跟不用拦截插件对比
我看帖子里面用的是这个
用了之后的cpu占用
平均下来是2~8之间
之后我们关闭这个插件换一个视频
可以看到并没有什么明显的区别。
所以视频帖子中所演示的东西均为假的。
拦截插件究竟拦截了什么?
看到这里的时候我不由的笑出了声。
给记录用户行为的日志log拦截了。
这个为什么会一直在拦截?
这个接口通常由前端 JS 脚本自动发送,用于:
- 上报用户行为日志(如点击、播放、拖动进度条等)
- 上报性能指标(如网页加载时间、卡顿、错误信息)
- 收集前端系统健康数据(如视频缓冲次数、帧率、CDN 状态)
- 上报 A/B 测试行为或打点结果
你可以理解为,因为被插件所拦截,所以就会不断的去请求这个。所以实际上
你开了拦截后,会更加的卡
我们来看看这个里面发送的是什么东西?
就是一些记录用户操作的。
这个有什么用?
可以给你这个用户添加一些用户行为,更好的去推荐。
总结
我分析了快俩个小时,也没有发现帖子和视频中所说的一些东西。
为什么要写这个文章?就是因为好奇网页端是如何操作用户的cpu进行分流的。这在技术上是一个基本不可能的事件。
当然如果这篇文章有什么技术上的错误欢迎来讨论。