最近闹得很大的B站CPU分流,被拦截插件拦截上千条技术分析辟谣

最近闹得很大的B站CPU分流,被拦截插件拦截上千条技术分析辟谣

首先解释一下什么是cpu分流跟流量分流

定义

一、CPU分流(也叫“计算分流”)

定义:
CPU分流是指将大量的计算任务合理地分配给多个CPU核心或多个处理器上,以避免某一个CPU核心负载过重,提高整体计算效率和响应速度。

常见应用场景:

  • 多线程程序中,将任务均衡分配到各线程,借助多核CPU提高执行效率。
  • 操作系统层面调度任务到不同的核心(负载均衡)。
  • Web服务器或高并发应用中,后台逻辑用线程池或协程分摊CPU运算压力。

二、流量分流(网络层面的“流量调度”或“流量路由”)

定义:
流量分流是指将大量的网络请求(或数据流)根据一定策略(如IP、URL、用户ID等)分发到不同的服务器、节点或处理模块,以提升系统性能、扩展性和可靠性。

常见应用场景:

  • CDN(内容分发网络)中根据用户位置选择最近的节点。
  • 微服务架构中按接口路由到不同服务模块。
  • 大型网站将用户访问按地理、业务类型分流至不同服务器。
  • 灰度发布中,将一部分用户请求导向新版本服务。

举例:
比如抖音、淘宝为了避免某个节点压力过大,会将访问流量按地域或用户ID hash 值,分配到多个服务器,这就是流量分流。

开始辟谣

cpu分流??网页如何做到cpu分流???

相信大家看完这些解释后就可以发现一个问题。

网页(前端)本身几乎不可能真正进行“CPU分流”,原因如下:

  1. 网页运行在浏览器中,受限于 JavaScript 的单线程模型
  • JavaScript 是单线程的(除了 Web Worker 之外),也就是说主线程里只能一次做一件事。
  • 所以大部分网页代码默认都只用到一个CPU核心的主线程,无法自动进行“多核并发处理”。

  1. 浏览器可以在后台做多线程,但这不是网页控制的
  • 浏览器自身的行为,比如渲染、视频解码、资源加载,可能用多线程、并行处理(这是浏览器的“CPU分流”行为)。
  • 前端开发者控制不到这些“分流”的细节。
  • 即使你打开 10 个网页标签页,这些可能分别被分配给不同的线程或进程,但那是浏览器在做,不是网页在做。

所以说这个就是我们辟谣的第一个视频

image-20250508103624984

这个无法做到cpu分流

关于博主所说的流媒体分流

流媒体分流技术本身不会导致你耗费“额外流量”

B站这种视频网站,为了保证全国范围的视频播放流畅,肯定使用了流媒体的各种分流技术。具体包括:

  1. 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好像根本影响不了什么东西

image-20250508104410903

之后来查看他可能分流的地方

image-20250508104535151

x-cache:这是一个常见的 CDN 缓存命中状态字段,可能值如:

server:通常标明当前响应是由哪个服务器软件(或 CDN)返回的,比如 bilibili-cdn

还是那句话,这个跟CPU有什么关系,我是想不明白的。

用拦截插件跟不用拦截插件对比

我看帖子里面用的是这个

image-20250508104732961

用了之后的cpu占用

平均下来是2~8之间

image-20250508104843276

image-20250508104817787

之后我们关闭这个插件换一个视频

可以看到并没有什么明显的区别。

image-20250508104934116

所以视频帖子中所演示的东西均为假的。

拦截插件究竟拦截了什么?

image-20250508105109720

看到这里的时候我不由的笑出了声。

给记录用户行为的日志log拦截了。

这个为什么会一直在拦截?

这个接口通常由前端 JS 脚本自动发送,用于:

  • 上报用户行为日志(如点击、播放、拖动进度条等)
  • 上报性能指标(如网页加载时间、卡顿、错误信息)
  • 收集前端系统健康数据(如视频缓冲次数、帧率、CDN 状态)
  • 上报 A/B 测试行为或打点结果

你可以理解为,因为被插件所拦截,所以就会不断的去请求这个。所以实际上

你开了拦截后,会更加的卡

我们来看看这个里面发送的是什么东西?

image-20250508105614468

就是一些记录用户操作的。

这个有什么用?

可以给你这个用户添加一些用户行为,更好的去推荐。

总结

我分析了快俩个小时,也没有发现帖子和视频中所说的一些东西。

为什么要写这个文章?就是因为好奇网页端是如何操作用户的cpu进行分流的。这在技术上是一个基本不可能的事件。

当然如果这篇文章有什么技术上的错误欢迎来讨论。

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值