本报告目标是评估一台位于韩国、走 CN2 路由的 VPS 在视频直播场景下的真实表现:延迟、丢包、稳定性、并发拉流能力及服务器资源占用。
总体思路:在同一 VPS 上部署 RTMP/HLS 服务,使用 ffmpeg/OBS 作为推流端,使用 iperf3、ping、mtr 做网络基线测试,使用并发拉流脚本和 wrk/ab 模拟观众并记录指标。
推荐系统:Ubuntu 20.04/22.04。示例规格:2vCPU/4GB 内存/50GB SSD。先更新系统:
命令:sudo apt update && sudo apt -y upgrade && sudo reboot
安装常用工具:sudo apt install -y git curl wget build-essential vim
安装并运行基础检测工具:
sudo apt install -y iperf3 mtr traceroute speedtest-cli
操作示例:ping -c 20 8.8.8.8(观测平均时延);mtr -c 100 -r 8.8.8.8(路径丢包);iperf3 -s 在 VPS 上启动服务,客户端运行 iperf3 -c
安装依赖并编译 nginx-rtmp 模块(或使用 apt 的 nginx):
sudo apt install -y libpcre3 libpcre3-dev zlib1g zlib1g-dev libssl-dev build-essential
示例编译命令(简略):git clone https://github.com/arut/nginx-rtmp-module.git; wget http://nginx.org/download/nginx-1.20.2.tar.gz; ./configure --add-module=../nginx-rtmp-module ...; make; sudo make install
配置 /usr/local/nginx/conf/nginx.conf 最关键段:
rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; # HLS配置 hls on; hls_path /tmp/hls; hls_fragment 3; } } }
启动 nginx:sudo /usr/local/nginx/sbin/nginx
使用 ffmpeg 进行命令行推流(示例 720p):
ffmpeg -re -stream_loop -1 -i sample.mp4 -c:v libx264 -preset veryfast -b:v 1500k -maxrate 1800k -bufsize 3000k -c:a aac -ar 44100 -b:a 128k -f flv rtmp://
OBS 配置:输出->流->服务选择“自定义”,填入 RTMP 地址 rtmp://
即时查看:ffplay rtmp://
HLS 测试:浏览器或 ffplay http://
记录首帧时间:在播放器上记录从推流开始到首帧显示的秒数,多个重复测试取平均。
方法一:用 wrk 并发请求 HLS 列表(适合短片段拉流压力):wrk -t12 -c200 -d60 http://
方法二:用并发 ffmpeg 下载 TS 分片模拟真实播放器:写 bash 循环并发 wget,每个进程循环下载最近的片段 URL(从 m3u8 解析),例如使用 xargs -P。
示例并发脚本(简化):
for i in $(seq 1 200); do (while true; do curl -sO http://
服务器端监控:sudo apt install -y sysstat dstat bmon
实时观测:top 或 htop;网络流量 bmon;磁盘 I/O iostat;长期记录使用 sar。
流媒体层日志:查看 nginx/error.log 与 nginx-rtmp 的统计,ffmpeg 可以加 -report 生成详细日志,记录编码丢帧信息。
步骤1:baseline 网络:在推流端和 VPS 分别运行 ping/mtr 与 iperf3 测试并保存结果(保存为 txt 文件)。
步骤2:部署服务并本地推流,检查首帧时间(重复 10 次),记录平均值。
步骤3:单用户稳定测试 10 分钟,观察 CPU/内存、bitrate、丢帧数。
步骤4:并发爬取 HLS(从 50 -> 200 -> 500 并发),在每一档位运行 60s,记录 95/99 延迟、成功率、错误码(5xx/4xx)、服务器负载。
步骤5:网络劣化模拟(可选)在测试机上使用 tc netem 模拟丢包/延迟,验证在丢包 1%/3%/5% 情况下播放恢复能力。
答:测量方案包括:1) 使用 ping -c 100 目标收集平均/抖动/丢包;2) 使用 mtr -c 1000 -r 目标查看每跳丢包与时延;3) 用 iperf3 在不同时间段(白天/夜晚)测吞吐并发能力;4) 在直播实际推拉流程中记录首帧时间、RTT 与播放器缓冲切换次数,综合判断稳定性。
答:先看网络层:iperf3 高并发下带宽是否饱和,bmon 观察速率是否达到上限;若网络正常,则查看服务器资源(CPU、IO、内存),使用 top、iostat、sar 定位是否为编码或磁盘写入成为瓶颈;同时查看 nginx 连接数与错误日志,若出现大量 5xx 则可能为服务崩溃或文件句柄不足需调整 ulimit 与 nginx worker_connections。
答:优化建议包括:1) 根据并发量调整 nginx worker_processes 与 worker_connections;2) 启用 HLS 小片段(2-3s)并使用 keepalive 减少 TCP 握手;3) 使用硬件/快速编码或调整 x264 preset 到 faster 以降低 CPU;4) 使用 CDN 做全球分发,把韩国 VPS 作为源站以减少跨国观众负担;5) 调整 TCP 参数(tcp_tw_reuse、tcp_fin_timeout)和文件句柄以应对高并发。