云录制收流网关：AIoT 时代的其中一把钥匙

五月一
4 阅读7分钟

引言

传统IoT→AIoT的转变：视频流成为新的数据入口。

完整链路：设备推流 → 云端录制 → AI分析 → 业务回调。

本文基于SRS，为中小企业提供一个可快速落地的云录制收流网关设计方案。

需要防止什么

收流网关是视频链路的入口，必须在第一道防线挡住两类问题：

1. 非法接入

设备没有经过平台授权，直接用伪造的推流地址或盗用的凭证发起推流。这类攻击的目的是绕过鉴权，占用推流通道或消耗平台资源。

2. 合法接入，但异常推流

设备本身是合法的，凭证也是有效的，但推流行为不符合预期。这类攻击更难防范，因为攻击者可以通过合法途径采购设备、逆向App和设备的交互逻辑，用脚本模拟设备行为。

完整攻防可参考这个专栏：7年打磨全球宠物IoT平台

常见异常模式包括：

  • 推流码率远超正常设备（消耗AI token或存储资源）

  • 推流时长异常（远超正常录制窗口）

  • 非正常触发推流（设备无任何抓取内容）

  • 同一设备短时间内频繁推流

这类问题的本质是：设备是合法的，但行为不是平台期望的。

3. 正常推流被挤下线

设备本身是合法的，推流行为也是正常的，但正在进行的推流会话被另一台设备（或脚本）用同一设备编号挤占。

网关设计

第一步：入口控制

设备需要推流时，先向平台申请推流地址和短效凭证。

平台收到请求后，利用 Redis 记录该设备的申请记录，并做窗口期缓存——同一设备在短时间内重复申请，直接拒绝或限流。这一步不是为了挡攻击，是为了防止设备端异常重试，也起到一定的限流作用。

Redis窗口期缓存的实现逻辑：

用设备编号作为 Key，记录上次申请时间。如果当前时间与上次申请时间的间隔小于设定的阈值（比如 30 秒），直接返回“请求过于频繁”。

对于正常设备，推流结束后，该缓存记录早已失效，允许下一次正常申请。

第二步：凭证生成与下发

平台校验通过后，生成一个短效凭证，包含以下信息（推荐用HS256签名或加密Payload）：

  • 设备编号

  • 推流会话ID（唯一标识本次推流）

  • 有效期（例如30秒）

  • 推流地址中的StreamKey

  • 推流时长

凭证有效期覆盖“申请 → 推流开始”的时间窗口，不覆盖整个推流过程——设备拿到凭证后需要在30秒内发起推流，超时失效。凭证仅在推流建立阶段校验。推流建立后，会话状态由SRS维护，不再依赖凭证有效期。这样做可以防止凭证被截获后长时间有效。

平台将推流地址（含StreamKey）和凭证一起返回给设备。

第三步：推流发起与校验

设备拿到推流地址和凭证后，发起推流。推流地址示例：

rtmp://srs-gateway.yourdomain.com:1935/live/{stream_key}?token={凭证}

SRS 收到推流请求时，触发 on_publish 回调，将 token 等信息传给本机部署的 FastAPI 中间人。 FastAPI 根据内置密钥验签，并执行以下校验：

校验项说明
Payload 中的 StreamKey 与推流地址中的 StreamKey 是否一致防止凭证被复制到其他推流地址使用
推流码率是否正常异步校验，见下文
推流时长是否正常异步校验，见下文
推流是否重放、重入校验方式，见下文

具体实现：基于 Redis 的校验机制

所有校验依赖 Redis 缓存配合逻辑判断，具体实现如下：

  1. 窗口期频率限制（防高频请求）

    使用 Redis 的 ZSET 进行轻量级窗口频率限制，限制对象包含凭证、IP和设备编号：

    # 清理窗口外的旧记录
ZREMRANGEBYSCORE key 0 (now - window_time)
# 统计窗口内请求数
ZCARD key
# 若未超限，记录当前请求
ZADD key now

  2. 凭证与 IP 绑定（防重放） 设备推流时，缓存凭证与 IP 的对应关系。查询缓存时检查 token 是否已被其他 IP 使用，若已被使用则拒绝当前推流请求——防止同一凭证被截获后在不同网络环境中重放。

  3. 设备编号与推流会话绑定（防重入和挤占）

    缓存设备编号与 SRS 内部 stream_id 的对应关系。设备推流时，检查缓存中是否已存在 stream_id，若存在则调用 SRS API 查询该流是否仍在正常推流：

    • 若仍在推流，拒绝新推流请求（防止同一设备重复推流）

    • 若已断开，允许新推流请求并更新缓存

  4. 推流码率异常检测（防资源滥用）

    将 SRS 内部 stream_id 插入 Redis 队列，异步程序定期拉取并调用 SRS API 检查推流码率：

    码率超过正常阈值 → 主动中断推流，记录一次警告（KEY是IP+ 设备编号）

    同一设备半小时内累计触发 3 次告警 → 拉黑设备编号 24 小时

    注意：拉黑操作针对设备编号，不拉黑 IP，避免误伤同一小区或 NAT 网络下的其他正常设备。

  5. 推流时长异常检测

    缓存 stream_id 与推流开始时间的关系，异步检查推流时长是否超过正常录制窗口。异常处理方式与码率异常一致——中断推流、记录警告、累计触发拉黑。

校验全部通过，允许推流；任意一项失败，则拒绝推流，或调用 SRS API 主动断开连接，设备推流失败。

第四步：推流结束清理

设备主动断开推流时，SRS 触发 on_unpublish 回调，通知 FastAPI 中间人推流已结束。平台清理本次推流的会话缓存，释放资源。

如果设备异常断开（网络超时、断电等），SRS 也会在一定超时后触发 on_unpublish，平台同样需要清理状态，防止推流会话残留。

清理内容包括：

  • 设备编号与 stream_id 的绑定关系

  • 凭证与 IP 的绑定关系

  • 推流会话相关的临时缓存

第五步：业务回调

  • 视频录制完成后，SRS 触发 on_dvr 回调，通知 FastAPI 中间人：

    两种处理路径：

    1. 直传 OSS：FastAPI 中间人直接上传视频文件到 OSS

    2. 异步处理：FastAPI 中间人将录制信息推到 MQ，消费者异步下载视频并上传 OSS

    上传完成后，OSS 发送事件通知，云函数或平台触发 AI 分析任务。

    注意：object_key 内需要包含推流会话 ID，方便平台将分析结果与对应的推流会话关联

  • 平台侧校验（防盗刷AI）：

    平台收到 AI 分析结果后，需要校验分析内容与设备申请推流时上报的推流类型是否相关（如移动侦测、计划推流等）。

    如果分析结果与推流类型不相关，处理方式与第四步的异常检测一致：

    • 记录一次警告（KEY是IP+ 设备编号）

    • 1天内累计触发2次后拉黑设备编号

    • 24 小时内不允许该设备申请推流

总结

一套组合拳打下来，可以在网关层有效防止 AI 服务被非法调用或滥用，降低盗刷风险。

这是 AIoT 时代，中小企业脱离云厂商闭源服务的其中一把钥匙。

avatar
文章
阅读
粉丝