LiveKit 实时音视频服务器入门3 步跑通免费的 WebRTC SFU【免费下载链接】livekitEnd-to-end realtime stack for connecting humans and AI项目地址: https://gitcode.com/GitHub_Trending/li/livekitLiveKit 是一个用 Go 编写的开源实时音视频栈核心是一台高性能的 WebRTC 媒体服务器SFU负责把多个参与者的音视频流转给彼此。它免费、无使用量限制自带 JWT 鉴权和分布式能力适合想自建实时通话、连麦或 AI 语音应用的人。一个典型的卡点媒体流到底怎么转发先说清楚 LiveKit 解决什么问题。两个人要互相看到视频最笨的办法是客户端两两直连P2P10 个人的房间就需要 45 条连接每个人的上行带宽还要乘以 9 倍——基本不可行。LiveKit 的做法是引入一个分发中心术语叫 SFUSelective Forwarding Unit。你可以把它想象成电视台的中转站每个人只把视频上传一份到服务器服务器再按需转发给每个观众。上传流量恒定为 1 份和房间人数无关而且服务器可以根据每个观众的网速挑选不同清晰度的流转发。这套逻辑的实现在 pkg/sfu/ 下包括码率自适应bwe、 simulcast 层选择、丢包重传NACK/RTX等都是围绕转发这一件事做的深度优化。三步跑通最小环境LiveKit 官方提供了安装脚本 install-livekit.shLinux 上一条命令装好单二进制文件curl -sSL https://get.livekit.io | bash第二步启动开发模式它会自动加载一套占位密钥devkey / secretlivekit-server --dev第三步让一个假人进房推流验证服务器活着lk room join ws://localhost:7880 \ --api-key devkey --api-secret secret \ --identity bot-user1 --publish-demo my-first-room能连上就说明信令端口默认 7880工作正常。想从源码构建仓库里也备好了 bootstrap.sh装好 Go 1.23 后运行./bootstrap.sh mage即可。看懂配置文件比装好更重要生产部署前建议通读一遍 config-sample.yaml这个文件注释极全覆盖了 90% 的决策点。挑几个真正关键的密钥keys所有房间访问令牌JWT都由 API Key/Secret 签发。生产环境务必换成livekit-server generate-keys生成的强密钥别用 devkey。Redis只要配置了 Redis 地址LiveKit 就自动进入分布式模式客户端连到任意节点都会被路由到同一个房间。单机跑可以完全不配。RTC 端口port_range_start/end示例中 50000-60000是客户端媒体流量的 UDP 端口段必须在防火墙放通入站tcp_port用于 UDP 不通时的 TCP 兜底。TURN 服务器在强 NAT 环境下部分企业网、移动端UDP 和 TCP 直连都可能失败需要中继。LiveKit 内置了 TURNpkg/service/turn.go在turn段开启即可不用另起 coturn。节点选择器node_selector分布式部署时决定新房间落在哪台节点支持sysload按系统负载、cpuload、regionaware按地域就近实现在 pkg/routing/selector/。多机房部署时选 regionaware把房间调度到离用户最近的区域。可观测性prometheus_port打开后在 6789 暴露指标仓库自带 Grafana 大盘 deploy/grafana/livekit-server-overview.json导入即可监控房间数、码率、丢包等。从开发到上线最容易踩的坑7880 端口别放裸奔这是信令 RoomService 的主端口生产环境应置于负载均衡器之后并终止 TLS。媒体 UDP 流量本身带 DTLS 加密不需要额外套 TLS但 7881 这类 TCP 兜底端口不能放在负载均衡后面必须直接暴露在节点上配置文件里有明确注释。云服务器公网 IP 发现AWS/阿里云机器通常只有一个内网 IP 弹性公网 IP 映射需要开use_external_ip: true让服务器通过 STUN 发现自己的公网地址并告诉客户端发现错误时用node_ip手动指定。开发模式的绑定陷阱--dev且未提供密钥时服务器只绑定 127.0.0.1见 cmd/server/main.go这是刻意的安全设计。别在开发机上跑通后以为上线也只需改个端口。UDP 端口段要够宽官方建议端口数量不少于 vCPU 数太少会限制并发连接能力。房间默认会自动创建默认auto_create: true任何人持有效 token 连一个不存在的房间名就会创建它。对外暴露前建议关掉或配好max_participants上限。什么场景合适什么场景要三思适合多人会议、连麦直播、在线教育、以及人在房间 AI 也在房间的实时语音 Agent 应用pkg/agent/ 就是 Agent 工作进程的调度与任务分发层。需要录制、拉取 RTMP/WHIP 外部流时配套生态有 Egress录制/转推和 Ingress外部流接入两个独立组件。要三思的小规模一对一通话两端直连 P2P 就能解决中间放一台 SFU 属于杀鸡用牛刀还多了媒体服务器的带宽和运维成本。超大规模纯直播万人级单向观看场景专门的 CDN 推流方案在成本上通常更优LiveKit 更擅长可交互的房间模型。单机扛不住SFU 是 CPU/带宽密集型服务节点容量参考值约为每 CPU 400 条轨道见limit段注释。用户量大时要么横向加节点加 Redis 即可要么做跨区域调度。一句话总结LiveKit 的价值在于把 SFU 最难的部分——转发效率、拥塞控制、分布式路由、TURN 兜底——都替你做好了你只需要管好密钥、端口和 Redis 三件事就能把实时音视频能力嵌进自己的产品里。【免费下载链接】livekitEnd-to-end realtime stack for connecting humans and AI项目地址: https://gitcode.com/GitHub_Trending/li/livekit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LiveKit 实时音视频服务器入门：3 步跑通免费的 WebRTC SFU
LiveKit 实时音视频服务器入门3 步跑通免费的 WebRTC SFU【免费下载链接】livekitEnd-to-end realtime stack for connecting humans and AI项目地址: https://gitcode.com/GitHub_Trending/li/livekitLiveKit 是一个用 Go 编写的开源实时音视频栈核心是一台高性能的 WebRTC 媒体服务器SFU负责把多个参与者的音视频流转给彼此。它免费、无使用量限制自带 JWT 鉴权和分布式能力适合想自建实时通话、连麦或 AI 语音应用的人。一个典型的卡点媒体流到底怎么转发先说清楚 LiveKit 解决什么问题。两个人要互相看到视频最笨的办法是客户端两两直连P2P10 个人的房间就需要 45 条连接每个人的上行带宽还要乘以 9 倍——基本不可行。LiveKit 的做法是引入一个分发中心术语叫 SFUSelective Forwarding Unit。你可以把它想象成电视台的中转站每个人只把视频上传一份到服务器服务器再按需转发给每个观众。上传流量恒定为 1 份和房间人数无关而且服务器可以根据每个观众的网速挑选不同清晰度的流转发。这套逻辑的实现在 pkg/sfu/ 下包括码率自适应bwe、 simulcast 层选择、丢包重传NACK/RTX等都是围绕转发这一件事做的深度优化。三步跑通最小环境LiveKit 官方提供了安装脚本 install-livekit.shLinux 上一条命令装好单二进制文件curl -sSL https://get.livekit.io | bash第二步启动开发模式它会自动加载一套占位密钥devkey / secretlivekit-server --dev第三步让一个假人进房推流验证服务器活着lk room join ws://localhost:7880 \ --api-key devkey --api-secret secret \ --identity bot-user1 --publish-demo my-first-room能连上就说明信令端口默认 7880工作正常。想从源码构建仓库里也备好了 bootstrap.sh装好 Go 1.23 后运行./bootstrap.sh mage即可。看懂配置文件比装好更重要生产部署前建议通读一遍 config-sample.yaml这个文件注释极全覆盖了 90% 的决策点。挑几个真正关键的密钥keys所有房间访问令牌JWT都由 API Key/Secret 签发。生产环境务必换成livekit-server generate-keys生成的强密钥别用 devkey。Redis只要配置了 Redis 地址LiveKit 就自动进入分布式模式客户端连到任意节点都会被路由到同一个房间。单机跑可以完全不配。RTC 端口port_range_start/end示例中 50000-60000是客户端媒体流量的 UDP 端口段必须在防火墙放通入站tcp_port用于 UDP 不通时的 TCP 兜底。TURN 服务器在强 NAT 环境下部分企业网、移动端UDP 和 TCP 直连都可能失败需要中继。LiveKit 内置了 TURNpkg/service/turn.go在turn段开启即可不用另起 coturn。节点选择器node_selector分布式部署时决定新房间落在哪台节点支持sysload按系统负载、cpuload、regionaware按地域就近实现在 pkg/routing/selector/。多机房部署时选 regionaware把房间调度到离用户最近的区域。可观测性prometheus_port打开后在 6789 暴露指标仓库自带 Grafana 大盘 deploy/grafana/livekit-server-overview.json导入即可监控房间数、码率、丢包等。从开发到上线最容易踩的坑7880 端口别放裸奔这是信令 RoomService 的主端口生产环境应置于负载均衡器之后并终止 TLS。媒体 UDP 流量本身带 DTLS 加密不需要额外套 TLS但 7881 这类 TCP 兜底端口不能放在负载均衡后面必须直接暴露在节点上配置文件里有明确注释。云服务器公网 IP 发现AWS/阿里云机器通常只有一个内网 IP 弹性公网 IP 映射需要开use_external_ip: true让服务器通过 STUN 发现自己的公网地址并告诉客户端发现错误时用node_ip手动指定。开发模式的绑定陷阱--dev且未提供密钥时服务器只绑定 127.0.0.1见 cmd/server/main.go这是刻意的安全设计。别在开发机上跑通后以为上线也只需改个端口。UDP 端口段要够宽官方建议端口数量不少于 vCPU 数太少会限制并发连接能力。房间默认会自动创建默认auto_create: true任何人持有效 token 连一个不存在的房间名就会创建它。对外暴露前建议关掉或配好max_participants上限。什么场景合适什么场景要三思适合多人会议、连麦直播、在线教育、以及人在房间 AI 也在房间的实时语音 Agent 应用pkg/agent/ 就是 Agent 工作进程的调度与任务分发层。需要录制、拉取 RTMP/WHIP 外部流时配套生态有 Egress录制/转推和 Ingress外部流接入两个独立组件。要三思的小规模一对一通话两端直连 P2P 就能解决中间放一台 SFU 属于杀鸡用牛刀还多了媒体服务器的带宽和运维成本。超大规模纯直播万人级单向观看场景专门的 CDN 推流方案在成本上通常更优LiveKit 更擅长可交互的房间模型。单机扛不住SFU 是 CPU/带宽密集型服务节点容量参考值约为每 CPU 400 条轨道见limit段注释。用户量大时要么横向加节点加 Redis 即可要么做跨区域调度。一句话总结LiveKit 的价值在于把 SFU 最难的部分——转发效率、拥塞控制、分布式路由、TURN 兜底——都替你做好了你只需要管好密钥、端口和 Redis 三件事就能把实时音视频能力嵌进自己的产品里。【免费下载链接】livekitEnd-to-end realtime stack for connecting humans and AI项目地址: https://gitcode.com/GitHub_Trending/li/livekit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考