音视频简单搭建livekit环境并初步认识

信令、TURN、编解码、自适应、网络探测、降噪、美颜、录制、合流、统计

前端：LiveKit Client SDK (JS/React/Vue)

后端：LiveKit Server (Go语言实现，可单机部署，也支持集群)

内置：SFU、E2EE、录制、SIP接入、分析、可插拔编解码

这里搭建环境做初步的了解，音视频的交互使用webrtc,带宽控制以及使用了自适应码率（客户端编码直接不同码率）；使用sfu(由服务器进行流的转换)；需要对浏览器中音频做相关处理；对视频做相关处理，从测试上看有美颜，换背景的功能。

1.简单汇总

2.直接部署，观察效果。

本来想要使用源码安装的方式进行测试，发现网络问题导致安装一直不顺，直接部署进行了解。

这里首先是安装，需要安装livekit-server服务端（启动服务） + lk (对应的客户端，用于生成密钥)

bash 复制代码

#直接用命令安装 安装livekit-server  
curl -sSL https://get.livekit.io | bash 
#查看安装目录
cd /usr/local/bin/
#默认启动 使用开发者模式
livekit-server --dev
#这里可以通过配置文件的方式进行设置，--dev也可以在配置文件中设置，
livekit-server --config livekit.yaml
#这是对应的简单的配置，本身目的是为了测试在宿主机上访问
hlp@ubuntu:/usr/local/bin$ cat livekit.yaml 
port: 7880
bind_addresses:
  - 192.168.40.146
rtc:
  port_range_start: 50000
  port_range_end: 60000

bash 复制代码

#看github的readme.md中入门指南测试时，有个创建访问令牌，以及模拟相关加入的动作，这里需要下载对应的客户端，也就是这里的lk指令
sudo apt install -y jq #需要安装依赖
curl -sSL https://get.livekit.io/cli | bash  #这里首先是下载再安装，但是遇到网络问题，我手动下载了
hlp@ubuntu:~/livekit$ ls
lk_2.13.1_linux_amd64.tar.gz   #按照上面的curl -sSL https://get.livekit.io/cli | bash下载路径手动下载
tar -zxf lk_2.13.1_linux_amd64.tar.gz #进行解压
#这里下载安装包后，实际上手动把他移动到对应的目录下
sudo mv lk /usr/local/bin/livekit
sudo chmod +x /usr/local/bin/livekit

启动服务，使用宿主机远端进行测试时，发现一直有disconnect，应该是浏览器（F12）请求后没有响应的问题，这个可能是浏览器安全策略，必须使用wss或者https的方式才行。

这里首先使用本机进行测试看看效果:

bash 复制代码

#终端1 需要启动server服务： （这里为了研究浏览器访问disconnect问题进行了尝试，测试时指令）
livekit-server --dev --config livekit.yaml 
#服务启动后，可以netstat -ano|grep 7880看看端口监听情况，可以排查问题
#终端2  这就可以参考官网，或者自由发挥了   这里使用客户端实际上默认内部已经生成了token 模拟加入房间，发布视频
#这里我执行过  sudo mv lk /usr/local/bin/livekit，所以下面的指令都是livekit
./livekit room join     --url ws://192.168.40.146:7880     --api-key devkey     --api-secret secret     --iden --publish-demo     test-room
#终端3   同样模拟加入，这个只接收了
/livekit room join     --url ws://192.168.40.146:7880     --api-key devkey     --api-secret secret     --identity subscriber     test-room

#实际上客户端能模拟客户的各种动作吧，内部的一个入口吧。
#另外一个关键是生成token，很重要，需要浏览器访问时填入。
./livekit token create --api-key devkey --api-secret secret --join --room my-first-room --identity user1 --valid-for 24h

#浏览器中要使用生成的token

====>这里抛开了浏览器安全认证相关，在终端上进行测试时只能通过日志观察相关信息。

3.考虑外部浏览器访问测试

3.1 以不安全的方式进行访问

浏览器https默认对不安全的网站是阻止的，第一种方案是直接修改网页设置，允许不安全网站（这里我在宿主机上同时用Edge和google chrome进行访问，使用客户端生成两个token也就是这里的user1和user11）：

token接入方式：

这里测试音频和视频都是ok，如果用多个客户端

那么个人理解，这里几个端的关系：

这个官网提供的https入口只是一个前端ui，内部以我的网络环境，浏览器所在环境为准，创建一个wss/ws的客户端，使用webrtc和livekit-server进行交互，这里可能内部创建的是wss安全的交互，所以我的ws交互无响应。

3.2 考虑代理的方式实现安全访问

可以考虑使用caddy进行反向代理之类的，直接把外部https的访问转到内部。

项目	配置复杂度	自动 HTTPS	语言/二进制	模块化/扩展性	2026 年流行度
Apache	高	手动	C	中等	传统企业
Nginx	中	手动	C	高	最主流
Caddy	极低	自动	Go	极高	快速上升

ws不需要证书，但是浏览器现在默认都是使用https或者wss安全交互。

使用caddy反向代理尝试测试：

bash 复制代码

 #首先需要安装caddy
 sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl gnupg
  curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
 curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
 sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
 sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
 sudo apt update
 sudo apt install caddy
 #创建证书文件
 sudo mkdir -p /etc/caddy/certs
 cd /etc/caddy/certs
 sudo openssl req -x509 -newkey rsa:2048 -nodes -keyout livekit.key -out livekit.crt -days 365 -subj "/CN=192.168.40.144"   #这里我原先用的时146 然后浏览器都绕过了校验能测试通过，和配置中和访问要一致。
 
 #需要关注生成的证书的权限，不然访问依然有问题，会在livekit-server端报错的。
ls -l /etc/caddy/certs
sudo chown -R caddy:caddy /etc/caddy/certs
sudo chmod 600 /etc/caddy/certs/livekit.key
sudo chmod 644 /etc/caddy/certs/livekit.crt

#给caddy做好配置后，让配置生效。
 hlp@ubuntu:/etc/caddy/certs$ sudo cat /etc/caddy/Caddyfile
https://192.168.40.144 {
    tls /etc/caddy/certs/livekit.crt /etc/caddy/certs/livekit.key

    reverse_proxy 192.168.40.146:7880
}
#默认的我随便改了个端口
:81 {
	root * /usr/share/caddy

	# Enable the static file server.
	file_server
}
sudo systemctl restart caddy
sudo systemctl status caddy
#如果配置文件有问题，就得关注日志
sudo journalctl -u caddy -n 50 --no-pager

安装好之后，首先需要尝试访问https://192.168.40.144/，点高级，点击继续访问，让证书生效，让测试通过。

然后我分别在edge和chrom，上测试，因为这里是虚拟机，宿主机上直接测试，nat模式我用手机没进行继续测试了。

会发现使用wss进行访问已经正常（两个网页使用同一个摄像头，所以一个是黑屏）：

这里实际上是用的caddy的反向代理，接收外部https或者wss的数据，然后tls进行终止，反向代理到内部的特定端口上（http或者ws）。

4.总结

这里接下来就是处理网络的问题，比如配置turn服务器等让互联网链路通，使用推流、拉流、录制等。

4.1 个人理解简单汇总

这里在测试时想过一个问题，为什么这个链接下输入ws+token能正常加入及交互：

简单个人理解：

LiveKit 的核心是 SFU（媒体流转发、带宽控制、同步等）。

LiveKit 内置了信令、房间管理、权限、节点调度等"基础设施层"。

"上层业务"的是 UI、用户系统、业务逻辑、房间生命周期管理等按需扩展(聊天，传输文件、美颜、背景虚化、声音处理,token生成、房间管理、用户系统、hook事件,负载均衡、健康检查、宕机恢复等)。

livekit只支持SFU,所有的流量通过中心节点转发，webrtc自带的网络拥塞控制算法控制网络（GCC ）。

Simulcast 是多路独立编码，SFU 在多条流之间切换； **SVC 是单路分层编码，SFU 在层之间切换；**Simulcast 兼容性最好，SVC 性能最好； LiveKit 同时支持两者，并根据网络和设备自动选择最优策略。

=====》不同的编码方式而已，都是客户端编码，编了多个流。

=====》转码时根据需要，网络带宽按需转发，录制时需要做混流。

貌似这里的负载均衡，是以房间为单位，一个房间肯定在一个节点中，就不涉及复杂负载均衡的节点之间流的交互了。

4.2 AI总结 LiveKit 提供的核心能力

LiveKit 是一个"实时音视频基础设施（Real‑Time Media Infrastructure）"，提供 WebRTC/SFU/媒体处理/负载均衡等核心能力，但它不是一个完整应用。 类似 SRS、Janus、mediasoup，它提供底层能力，上层业务（UI、用户系统、房间管理、美颜、聊天等）需要自己实现。
"livekit 是一个实现了核心库，上层得自己实现和扩展"

LiveKit 的核心能力可以分为 6 大类：

① SFU（核心）

多人实时音视频路由
RTP/RTCP
Simulcast / SVC
带宽控制（GCC）
抖动缓冲
音视频同步

② 信令（WebSocket）

加入房间
发布/订阅 Track
ICE 协商
设备状态同步

③ TURN / NAT 穿透

内置 TURN（可启用）
或外部 coturn
支持 UDP/TCP/TLS
公网环境必备。

④ 媒体处理（Egress / Ingress / Recording）

✔ Egress（服务端转码）

推流 RTMP（抖音、B站、YouTube）
合流录制（九宫格、画中画）
单路录制
输出 MP4 / HLS

✔ Ingress（拉流）

RTMP 拉流进房间
SRT 拉流
文件推流

✔ Recording（录制）

房间录制
单人录制
自定义布局

⑤ 多节点负载均衡

Redis 协调
节点发现
房间分配
自动负载均衡
节点健康检查

⑥ 权限系统 + Token：通过token管理了权限。

RoomJoin
CanPublish
CanSubscribe
CanPublishData
RoomAdmin