JWT解码分块音频请求的CPU开销及优化方案问询

我通过HTTP 206部分内容实现了多请求音频流式传输（比如7MB歌曲分7次请求，每次返回1MB分片），核心代码如下：

const contentLength = end - start + 1;
const headers = {
  'Content-Range': `bytes ${start}-${end}`,
  'Accept-Ranges': 'bytes',
  'Content-Length': contentLength,
  'Content-Type': contentTypeHeader,
};

res.writeHead(206, headers);
const audioStream = fs.createReadStream(songPath, { start, end });
audioStream.pipe(res);

系统要求 #

• 流式传输音频的用户必须经过身份认证；
• 用户不得知晓文件系统中的音频URL。

现有实现方案 #

设计了两个路由：

1. 第一个路由完成用户认证，返回包含音频文件URL的JWT；
2. 第二个路由接收该JWT，解码后获取音频文件URL并执行流式传输。

问题 #

针对每个音频分片请求都解码JWT，是否会给CPU带来较大负担？有没有更优的实现方案？

关于JWT解码的CPU负担 #

JWT的纯解码（Base64解析+JSON反序列化）是非常轻量的操作，现代CPU完全可以轻松应对频繁的分片请求。但如果涉及签名验证，开销取决于加密算法：

• 用HS256这类对称加密算法时，签名验证的开销极低，几乎可以忽略；
• 用RS256这类非对称加密算法时，频繁验证会产生一定CPU开销，但只要QPS不是极端高，一般也不会成为瓶颈。

更优实现方案 #

1. 会话缓存（适合有状态服务）

• 用户认证通过后，生成一个会话ID，将音频文件路径关联到会话ID，存储在Redis或内存缓存中（设置合理过期时间，比如音频时长+5分钟缓冲时间）；
• 分片请求携带会话ID，服务端直接从缓存取文件路径，无需重复处理JWT；
• 优势：缓存查询开销远低于JWT解码/验证，会话ID有效期可控，安全性更高。

2. JWT载荷优化+缓存

• 不在JWT中存明文文件路径，改用加密后的文件标识（比如用AES加密文件ID），避免JWT泄露后直接暴露文件位置；
• 服务端第一次验证JWT签名后，将解析后的载荷缓存到Redis（键可以用JWT的哈希值），后续分片请求直接读取缓存，跳过重复的签名验证步骤。

3. 临时授权URL

• 认证通过后生成一个带签名的临时URL（包含文件标识、有效期），客户端用这个URL请求所有分片；
• 服务端验证URL的签名和有效期，通过后直接流式传输；
• 优势：无需客户端携带JWT，临时URL本身就是授权凭证，签名验证可以缓存结果，降低重复开销。

4. 连接级认证（HTTP/2/WebSocket）

• 如果用HTTP/2，在建立连接时完成一次认证，后续所有分片请求复用该连接，服务端在连接层面维护认证状态，无需每次请求验证；
• 或者用WebSocket传输分片，连接建立时完成认证，后续传输无需重复验证。

内容的提问来源于stack exchange，提问作者cyclonejet