距离 UDP Stream 上一个版本发布已经过去了一段时间。
在 v1.0 版本中,我们解决了最让人头疼的 udpxy 后台重启导致播放器断开的问题,实现了“断流自动续命”。
但是发现有个bug:家里三台电视同时看同一个节目,设备会建立了三个连接去拉流,因此做了更新一版。
为了解决这个bug,更新了UDP Stream v2.0 (及后续 v2.2 NetMon 版本) ,对核心代码进行重构,带来了共享缓存机制和可视化监控面板。
在旧版本中,如果有 3 个客户端(电视/手机)同时播放同一个频道(URL),容器会开启 3 个下载线程,占用 3 份带宽。
v2.0 引入了单例广播模式:
不管有多少个客户端连接同一个 URL,容器只建立 1 个下载线程,向源头拉取 1 份 数据,然后在内存中“广播”分发给所有观众。
效果立竿见影:
udpxy 服务不被高并发冲垮。👇 看图说话: 如下图所示,“在线观众”显示为 2 人,但左上角的“活跃流数量”仅为 1。这意味着 2 个人在共享这 1 条下载通道,极大地节省了入站带宽!
告别枯燥的 JSON 接口,现在访问 http://ip:端口/status,你将看到科技感十足的实时监控面板。
↓ 下载速度 (RX):容器从源头拉取数据的速度。↑ 上传速度 (TX):容器分发给所有客户端的总速度。👇 多路并发也能清晰展示:
在 v2.0 中,我们优化了数据发送逻辑。当新用户连接时,程序不会急着立刻转发数据,而是强制在队列里积攒够 2MB 数据后,再开始向播放器发送。
这有什么用? 虽然这可能会让起播速度慢 0.5~1 秒,但这 2MB 的“安全垫”能有效防止因起播时网络波动导致的画面卡顿,让播放体验更丝滑。
很多朋友对这两个概念有误解,这里特别说明一下本工具的能力边界:
❌ 无法解决“卡顿”
✅ 专治“断流”
udpxy)重启、崩溃,或者是 Session 超时。镜像已推送到 GitHub Container Registry,支持 x86 和 ARM64。
Docker Run 命令(推荐):
由于国内网络环境原因,直接拉取 ghcr.io 可能会非常慢或失败。强烈建议使用南京大学的镜像加速服务:
docker run -d \
--name udp-stream \
--restart=always \
-p 5000:5000 \
ghcr.nju.edu.cn/cqshushu/udp-stream:latest
注意:如果你之前有安装版本,请先停止并删除镜像和旧容器,然后使用上面的命令拉取新镜像。
架构:NAS/软路由部署容器 ➡ 家里电视/手机观看。
评价:⭐⭐⭐⭐⭐
理由:
架构:NAS 部署容器 ➡ 路由器端口映射/FRP ➡ 外部(公司/朋友家)观看。
评价:⭐
理由:
光猫 -> NAS -> 路由器NAT -> 运营商公网 -> 朋友设备。经过了多次路由转发和封装,每一跳都会增加延迟和丢包风险。结语: v2.0 是一个里程碑式的版本,不仅让内网分发更高效,更让一切状态看得见、摸得着。
View Comments