直播框架：基础知识点

1 直播系统

1.1 直播系统基本架构

作为一个流媒体而言 其实我们重点关注的是直播集群和nginx那一块。

SRS 直播集群
SRS（Simple Realtime Streaming Server）是一个用 C++ 开发的开源实时流媒体服务器，专注于直播领域。

• 功能特性
  • 多协议支持：支持 RTMP（Real Time Messaging Protocol）、HTTP - FLV、HLS（HTTP Live Streaming）、WebRTC 等多种直播协议 。例如，RTMP 常用于推流，能低延迟地将直播流从主播端推送到服务器；HLS 则是苹果提出的基于 HTTP 的流媒体传输协议，适合在移动端播放，通过切片的方式实现直播流分发。
  • 集群部署：通过集群方式部署，可实现负载均衡和水平扩展。比如 SRS Edge 集群，用于解决大量用户观看直播流的问题，能支持众多用户同时观看 。但 SRS Edge 有一定限制，它只支持直播流协议（如 RTMP 或 HTTP - FLV ），不支持 HLS 或 DASH 等切片的直播流（因其本质是文件分发而非流），也不支持 WebRTC 的流分发（WebRTC 有自己独立的集群方式 ）。
  • 高效性能：采用高效的网络 I/O 模型和内存管理机制，能处理大量并发连接，降低服务器资源消耗，保障直播服务的流畅性。
• 工作流程：主播端使用 OBS 等推流工具，基于 RTMP 协议将直播流推送到 SRS 直播集群中的源站服务器 。源站服务器接收推流后，可根据配置进行转码、录制等处理，再通过集群内的边缘服务器，以合适的协议（如 HLS 协议将直播流切片成 m3u8 索引文件和 ts 视频片段 ）分发给不同终端的观众。

源服务器和边缘服务器的之间的交互

• 缓存预热与内容推送
  源服务器可主动将热门直播内容、重要配置文件等推送到边缘服务器 。比如一场备受期待的大型直播活动前，源服务器提前把直播预告素材、主播介绍等静态资源推送到边缘服务器进行缓存，方便用户后续快速访问。
• 缓存拉取与更新
  缓存拉取：当用户请求某直播内容，边缘服务器发现本地缓存未命中（没有该内容 ）时，会向源服务器发起请求拉取内容。例如新上线的小众直播节目，首次有用户请求观看，边缘服务器就从源服务器获取直播流数据 。
  缓存更新：若源服务器上的直播内容更新（如直播过程中切换场景、画质调整 ），边缘服务器缓存内容过时，源服务器会根据配置策略（如定时检查、内容变更触发 ）通知边缘服务器更新，或者边缘服务器主动向源服务器请求最新内容 。
• 负载均衡与请求转发
  架构中的负载均衡组件（如 nginx ）可根据边缘服务器负载情况，将部分用户请求转发到源服务器。比如直播高峰期，边缘服务器负载过高，负载均衡器把部分请求导向源服务器，由源服务器直接处理 。

CDN
CDN 的核心是通过在各地部署边缘节点缓存内容，让用户能就近获取数据。这里的边缘服务器分布在靠近用户端的位置，缓存直播相关内容，如视频流片段等，实现快速向用户分发内容，减少延迟，提升直播观看体验，类似于 CDN 通过边缘节点加速内容传输的原理 。

Nginx 反向代理
Nginx 是一款高性能的 HTTP 和反向代理服务器。

• 反向代理原理：处于客户端和目标服务器之间，客户端发送请求到 Nginx，Nginx 代替客户端向目标服务器发起请求，获取响应后再转发给客户端。客户端感知不到目标服务器存在，以为是 Nginx 提供的服务 。
• 作用
  • 负载均衡：可将大量客户端请求按特定算法（如轮询、加权轮询、IP 哈希等 ）分发给多个后端服务器处理。例如轮询算法，依次将请求分配给不同后端服务器，使各服务器负载相对均衡，避免单个服务器过载。
    缓存加速：能缓存静态资源（如图片、CSS、JavaScript 文件等 ）和部分动态资源。当有相同请求时，Nginx 直接从缓存返回内容，减少后端服务器压力，提升响应速度。
  • 安全性：隐藏后端服务器真实 IP 地址，减少被攻击风险。还可配置安全策略，如设置黑白名单、过滤恶意请求等 。
  • 统一接入：作为统一入口，管理不同后端服务的访问。通过配置不同 location 规则，将特定请求转发到对应的后端服务器，便于对复杂业务系统进行管理和维护 。
• 在直播框架中的应用：在直播场景中，Nginx 可接收来自不同终端（PC、移动端等 ）的直播请求，将其转发到对应的 SRS 直播集群服务器或其他业务服务器。同时，利用缓存功能缓存直播相关的静态资源（如直播间封面图片 ），加速用户访问。

1.2 直播基本逻辑

• 采集阶段
  音频采集：通过麦克风等设备收集声音信号，获取原始音频数据，并记录采集时间戳，为后续音视频同步提供依据 。
• 视频采集：利用摄像头采集画面信息，得到原始视频数据，同样记录采集时间戳。
• 处理阶段
  音频处理：对采集的原始音频进行混音（将多个音频流混合 ）、降噪（去除背景噪音 ）、添加声音特效（如回声、变声等 ）等操作，优化音频质量。
  视频处理：对原始视频添加水印（标识版权等信息 ）、进行美颜（磨皮、瘦脸等 ）、应用滤镜（改变画面色彩风格 ）等处理，提升视觉效果。
• 编码阶段
  音频编码：将处理后的音频数据通过特定编码算法（如 AAC ）进行压缩编码，减少数据量，便于网络传输。
  视频编码：运用编码算法（如 H.264、H.265 ）对处理后的视频进行压缩编码，降低视频大小，提高传输效率。
• 推流阶段
  将编码后的音频和视频数据组合成流媒体，通过推流技术（常用 RTMP 等协议 ）发送到流媒体服务器。
• 流媒体服务器阶段
  作为存储和转发中心，接收推流过来的音视频流，进行缓存、管理，并为拉流提供支持。
  拉流阶段
• 客户端（如手机、电脑 ）向流媒体服务器发起拉流请求，获取音视频流数据。
• 解码与播放阶段
  音频解码：将拉取的编码音频数据还原为原始音频信号。
  视频解码：把拉取的编码视频数据还原为原始视频画面。
  音频播放：通过扬声器等设备播放解码后的音频。
  视频播放：在屏幕上展示解码后的视频画面，同时依据采集时间戳等信息保证音视频同步播放。

1.3 采集端逻辑

• 创建房间：采集端就像主人（主播），主人跟业务服务器这个 “管家” 说，我要开个聚会（创建房间） 。管家会看看主人有没有资格办聚会，比如有没有注册、是不是遵守规定等。
• 创建直播流：管家（业务服务器）跟流媒体服务器这个 “仓库” 说，主人要办聚会啦，你准备个地方放聚会的东西（创建直播流） 。仓库就收拾出一块地儿（准备直播流通道） 。
• 返回直播流：仓库（流媒体服务器）收拾好地儿后，就跟管家（业务服务器）说，地方准备好了，这是相关信息。
• 返回直播流地址：管家（业务服务器）把仓库（流媒体服务器）准备好的地方地址（直播流地址） ，告诉主人（采集端） ，说你可以往这个地址送聚会的东西啦。
• 推流到直播流地址：主人（采集端）拿到地址后，就把聚会要用的各种东西（音视频流 ），按照地址送到仓库（流媒体服务器） 。这样，其他想来参加聚会（看直播） 的客人（观众），就能从仓库拿到东西，参与这场线上聚会啦。

1.4 播放端

• 查询房间列表：播放端就像想来参加聚会的客人 。客人跟管家（业务服务器）说，我想看看都有哪些聚会（查询房间列表） ，也就是想知道有哪些直播房间可以进。
• 返回房间列表及播放地址：管家（业务服务器）就把目前正在举办的聚会（直播房间） 列表，以及每个聚会的具体位置（播放地址 ）都告诉客人（播放端） ，让客人知道能去哪些聚会，以及怎么去。
• 拉流播放：客人（播放端）拿到这些聚会（直播房间） 的位置（播放地址） 后，就可以直接到对应的仓库（流媒体服务器） 那里，把聚会的东西（直播流 ）拿过来，开始参与聚会（观看直播） 啦。 这样，客人就能顺利看到各个直播房间的内容了。

2 技术细节

2.1 推流拉流技术点

推流技术点

• 音视频采集：利用麦克风采集音频信号，摄像头采集视频信号，获取原始音视频数据 。像常见直播场景中，主播通过麦克风收音、摄像头摄像来获取直播素材。
• 音视频处理
  音频：进行混音（合并多个音频流 ）、降噪（去除环境噪音 ）、添加声音特效（如变声、回声 ）等操作，优化音频质量。
  视频：添加水印（保护版权等 ）、美颜（磨皮、瘦脸 ）、应用滤镜（改变画面色彩风格 ）等，提升视觉效果。
• 音视频编码：采用特定算法压缩数据，降低数据量以便网络传输。视频常用编码格式如 H.264、H.265 ，音频常见如 AAC 。编码过程通过降低帧率、分辨率，以及去除冗余信息来实现压缩。
• 同步处理：确保音频和视频在时间上保持一致，避免声画不同步。通过采集时间戳等技术手段，对音视频流进行时间校准。
• 帧缓冲（Frame Buffer）：临时存储编码后的音视频帧，平滑数据传输，应对网络波动。比如网络不稳定时，可从帧缓冲中读取数据继续播放，减少卡顿。
• 推流协议：常用 RTMP（Real - Time Messaging Protocol ），能实现低延迟的音视频传输，广泛应用于直播推流；还有 SRT（Secure Reliable Transport ），具备更好的抗丢包和加密性能 。推流设备（如电脑、手机 ）通过这些协议将处理编码后的音视频流发送到流媒体服务器。
• 网络传输：推流对网络要求高，需稳定且足够带宽的网络。网络带宽不足会导致推流卡顿、丢帧；网络不稳定可能使连接中断。同时要考虑网络延迟、抖动等因素对推流质量的影响。
  拉流技术点
• 拉流协议：常见有 HTTP - FLV（基于 HTTP 协议传输，低延迟 ）、HLS（HTTP Live Streaming，苹果提出，兼容性好，尤其适用于移动设备 ） 等。播放端（如手机、电脑 ）根据设备和网络情况选择合适协议从服务器拉取直播流。
• 接收与解复用（Demux）：播放端接收服务器发送的流媒体数据后，将其中混合的音频、视频流分离出来，以便后续分别解码处理。
• 音视频解码：把编码压缩后的音视频数据还原为原始可播放的信号。如将 H.264 编码的视频流解码成视频帧，AAC 编码的音频流解码成音频信号。
  显示与播放：视频帧在显示器上按顺序显示，音频信号通过扬声器播放。同时要保证音视频同步播放，给用户良好观看体验。
• 帧缓冲（Frame Buffer）：和推流类似，用于缓存拉取的音视频数据，应对网络波动和数据传输延迟，防止播放卡顿。
• 客户端性能：播放设备性能影响拉流体验。若设备处理器性能弱、内存不足，可能无法及时解码和播放数据，导致画面卡顿、声音不同步等问题 。
• CDN（内容分发网络）：拉流常借助 CDN 加速。CDN 通过分布在各地的边缘节点缓存直播内容，使用户能从就近节点拉取数据，减少延迟，提升观看体验 。

2.2 一些技术点

延迟

• 定义：指实时采集画面与播放展示画面的时间差 。比如主播端已经展示了一个动作，但观众端过了几秒才看到，这中间的时间间隔就是延迟。
• 产生原因：主要源于节点网络抖动（网络不稳定，数据传输时断时续 ）以及数据堆积导致 GOP（Group of Pictures，图像组，是视频编码中一组连续的帧 ）缓存过多。网络抖动时，数据传输速度不稳定，接收端接收数据不均匀，容易造成缓存堆积，进而产生延迟。
• 解决方法：采用 X264 编码中的 zerolatency（无延时编码）模式 ，它能控制码率波动，减少编码过程中引入的延迟，使视频数据能更及时地被处理和传输。

首屏

• 定义：从用户点击播放按钮到画面出现的时间 。比如在直播 APP 上点击进入直播间，到看到直播画面所花费的时间。
• 影响因素：节点级数越多耗时越长 。直播内容从源服务器经过多个中间节点（如 CDN 的各级节点 ）到达用户端，每经过一个节点都可能产生一定延迟。此外，直播 CDN 的组网方式（节点如何连接、数据如何分发 ）、网络覆盖率（网络覆盖范围和信号强度 ）和传输协议的优化程度（如协议是否高效、能否快速传输数据 ）都会影响首屏时间。

卡顿

• 定义：播放过程中出现卡顿的次数或时长 。比如直播过程中画面突然静止、声音中断，过一会儿又恢复正常，这就是卡顿现象。
• 产生原因：主播推流卡顿（主播网络不好、设备性能不足导致推流不稳定 ）、CDN 内部网络卡顿（CDN 节点间数据传输出现问题 ）、客户终端网络（用户自身网络不稳定，如 Wi - Fi 信号弱 ）等情况都会引发卡顿。
  策略方面
• 预热：提前拉取热门直播的相关数据，在直播开始前就把可能用到的部分内容缓存好，这样当用户点击进入直播间时，能更快地开始播放，减少首屏时间和卡顿情况。
• 集群：采用就近共享数据的方式 。利用 CDN 分布在各地的边缘节点，让用户从距离最近的节点获取数据，降低网络传输延迟，提升数据获取速度，从而减少延迟、首屏时间和卡顿现象。