_abck、__cf_bm 与 JSESSIONID：服务端怎么用 Cookie 认出同一客户端
背景
HTTP 是无状态的，"身份"要靠额外机制维系，Cookie 是最基础的那一层。
在反爬/风控场景里，Cookie 已经不只是服务端下发的随机串，而是"客户端环境（浏览器指纹）+ 服务端标记行为"共同作用的唯一标识，业内称作 Cookie 指纹。
两类 Cookie 要分清
传统会话 Cookie
JSESSIONID、PHPSESSID 这类。登录或首次访问时由服务端随机生成，本身不含客户端信息，只用来关联服务端的 session 存储。
指纹 Cookie
__cf_bm（Cloudflare）、_abck / bm_sz / ak_bmsc（Akamai Bot Manager）、s_v_web_id、_alid 等。
其值通常是加密或编码字符串，内部可能包含：
- 时间戳（生成时间）
- 客户端信息摘要：UA、
Accept-Language、屏幕分辨率的哈希 - 浏览器/环境特征：JS 采集的 Canvas 指纹、WebGL 指纹、字体列表、插件列表哈希
- 服务端标记：全局唯一 ID，与客户端特征绑定后入库
- 行为签名：初期少量交互行为（鼠标轨迹、初始请求序列）编码
生命周期
- 生成：首次访问响应的
Set-Cookie，或执行特定前端脚本后由 JS 生成。 - 验证：后续每次请求携带该 Cookie，服务端解码、校验（时效性、签名）、关联查询。
- 关联：指纹 Cookie 可能绑设备指纹，也可能绑行为画像，形成立体追踪。
- 升级/刷新：检测到指纹异常（如地理突变）但行为正常时，刷新指纹而不是直接封禁，做平滑过渡。
服务端识别栈的工程要求
- 性能：指纹校验必须毫秒级完成，解码算法要高效；特征匹配多依赖 Redis 缓存"指纹—状态"映射。
- 可扩展：规则/模型支持热更新，快速响应新的爬虫策略。
- 抗篡改：Cookie 值签名或加密，常用 HMAC 或 AES，防客户端伪造。
- 隐私合规：GDPR 等法规下，需要提供用户清除/退出指纹追踪的机制。
解密校验：AES-256-GCM 片段（Node.js）
const crypto = require('crypto');
// authTag / encrypted 由 Cookie 值拆包得到
const decipher = crypto.createDecipheriv(
'aes-256-gcm',
Buffer.from(process.env.FP_KEY, 'hex'),
Buffer.from(process.env.FP_IV, 'hex')
);
decipher.setAuthTag(Buffer.from(authTag, 'base64'));
let decrypted = decipher.update(encrypted, 'base64', 'utf8');
decrypted += decipher.final('utf8');
const fpData = JSON.parse(decrypted);
// 时效性：例如指纹 7 天后需重新验证
if (Date.now() - fpData.ts > 7 * 24 * 60 * 60 * 1000) {
req.fingerprintStatus = 'expired';
req.oldFingerprintData = fpData;
} else {
// 其他校验：IP 地域突变、UA 不匹配等
const currentUaHash = crypto
.createHash('sha256')
.update(req.headers['user-agent'])
.digest('hex')
.substring(0, 8);
// 与 fpData 中的 UA 摘要比对
}
createDecipheriv 必须带 authTag，否则 GCM 的完整性校验形同虚设。
排障：站点用了哪家反爬
Akamai Bot Manager
_abck（Abnormal Cookie）：值是编码加密串，含浏览器指纹、时间戳、校验位，由 Akamai 的 JS 保护脚本生成并动态更新。bm_sz：存当前会话窗口 / 请求计数 / 页面加载标记。ak_bmsc：出现于初始阶段，随后与_abck配合做二次校验。
Cookie 不一定首次访问就给全。有的站点把生成放在后续 XHR 或页面内 JS 执行之后才写入，需要多轮请求观察。
响应头特征
Server: AkamaiGHost配合版本号X-Akamai-Edgescape
Akamai 还会看 TLS 指纹（JA3/JA4：ClientHello 的 TLS 版本、加密套件列表与顺序、扩展列表及顺序）与 HTTP/2 指纹（SETTINGS 帧参数），也会看请求头顺序——浏览器内核决定的顺序和 requests / curl 的默认顺序不一样。
打分优先级经验：Cookie > TLS > 响应头 > 行为。出现 _abck 先把嫌疑拉满；若 Server: AkamaiGHost + bm_sz 同时存在，基本可以确认。
抓包观察 TLS 指纹时，从"HTTP/2 连接前协商"看起。Akamai 对 HTTP/2 指纹的检测比 HTTP/1.1 更严格。
Cookie 指纹与浏览器指纹的区别和边界
- Cookie 可清可复制（所以有 Cookie 池），浏览器指纹难清除：Canvas/WebGL、AudioContext、
navigator属性、字体、屏幕分辨率组合成复合指纹，40+ bit 熵，即使换 IP 也能认出同一个浏览器。 - 风控会做关联分析：同一指纹频繁换 IP，或同一 IP 出现多个异常指纹，都判高风险。
- 只复制粘贴 Cookie 已难长期稳定；单纯旋转 IP 也不够，因为指纹能跨 IP 绑定。
- 隐私模式 / 清 Cookie 对 Cookie 指纹有效，对 Canvas/WebGL 指纹基本无效。
- 边界：Cookie 可被伪造、可被共享，单靠它不足以确认身份；行为节奏（访问频率、鼠标/滚动、时间间隔）常作为最终风险分的一部分。
关键词：Cookie识别 / Cookie指纹 / 反爬 / Akamai Bot Manager / TLS指纹 / JA3