ZLMediaKit播放卡顿还是延迟高三问定下TCP或UDP选型【免费下载链接】ZLMediaKitWebRTC/RTSP/RTMP/HTTP/HLS/HTTP-FLV/WebSocket-FLV/HTTP-TS/HTTP-fMP4/WebSocket-TS/WebSocket-fMP4/GB28181/SRT/STUN/TURN server and client framework based on C11项目地址: https://gitcode.com/GitHub_Trending/zl/ZLMediaKitZLMediaKit支持RTSP/RTMP/HTTP-FLV/WebRTC等协议的流媒体框架播放画面卡住两秒、延迟拖到好几秒时先怀疑传输层TCP UDP选型常常是ZLMediaKit播放卡顿与高延迟的根源。本文先给结论、再讲清原理最后带你在配置里完成切换与初步调参读完能直接判断自己的环境该用哪个协议。先给结论ZLMediaKit传输协议选型速查表赶时间的话按下表对号入座即可后文会解释每条结论的依据。你的情况建议传输方式一句话理由播放器与服务器同局域网/同机房RTSP over UDP或 WebRTC链路可靠省掉重传开销延迟最低公网、跨运营商、手机网络观看RTMP、HTTP-FLV 等 TCP 类协议重传与流量控制能扛住丢包抖动实时互动双向语音视频、远程操控WebRTCUDP NACK 选择性重传延迟低且丢包有应用层恢复手段链路只有 80/443 能通代理或防火墙HTTP-FLVTCPUDP 在大多数企业防火墙上会被直接丢弃一个容易忽略的默认行为RTSP 的 RTP 传输方式默认是rtpTransportType-1不限制由客户端 SETUP 请求说了算。这意味着用 TCP 还是 UDP很可能不是你选的而是协商出来的。理解原理一通电话和一次街头喊话的区别把 TCP 想成打电话每句话都要对方嗯一声确认听不清就说请重复顺序也一定按说话的先后。代价是每句话都多了确认的往返且一旦线路拥塞后面的话全被压住。把 UDP 想成街头喊话话出口就没了不确认、不补发、也不保证按顺序到达。它快但喊丢了就是丢了。技术小结TCP 靠序号、确认与重传保证送达且有序UDP 只负责发送、不做任何恢复。直播视频是个特殊业务——晚了一帧基本就不值钱了所以媒体传输要么图稳走 TCP要么走 UDP 但自己在应用层补一套轻量重传WebRTC 的 NACK、SRT 协议都是这个思路SRT 底层也是 UDP。动手前自测先问自己这三个问题问题一播放器在哪里和服务器同局域网链路丢包率接近零直接用 UDPRTSP 或 WebRTC重传机制是纯开销。在公网、跨运营商或移动网络选 TCP 类协议RTMP、HTTP-FLV或 WebRTC。公网丢包、乱序、抖动是常态TCP 的重传和拥塞控制能避免画面直接卡死。问题二能容忍多大延迟要实时互动延迟以毫秒计选 WebRTC。它走 UDP 但带 NACK 选择性重传和拥塞控制兼顾了低延迟与抗丢包实现集中在 webrtc/ 目录。普通观看几百毫秒到一秒内延迟可接受TCP 类协议更省心出了问题也更好排查。问题三链路上 UDP 走得通吗中间有只放行 80/443 的代理或防火墙UDP 基本无解老老实实用 HTTP-FLV。要让 RTSP 走 UDPUDP 媒体端口是从port_range范围内分配的默认 30000-35000防火墙必须放行这个区间否则表现为信令通了、画面不出来。WebRTC 有个兜底UDP 不通时客户端可回落到 TCPrtc.tcpPort但延迟和稳定性都会打折扣。动手配置改哪个文件、改哪些参数⚠️ 先说一个新手常踩的坑MediaServer 实际加载的是可执行文件同目录下的config.ini即release/${系统}/${编译类型}/config.ini直接改仓库里的 conf/config.ini 不会生效除非启动时用-c参数显式指定。如何切换到 UDP 传输以 RTSP 为例[rtsp] # 强制协商RTP传输方式0TCP1UDP2MULTICAST-1不限制默认值 # 与客户端SETUP请求不一致时返回461迫使客户端重新协商 rtpTransportType1 # RTSP转发低延迟模式开启后不缓存RTP包可降低约一帧延迟 # 注意H264存在一帧多个slice时可能花屏默认0 lowLatency0[rtp_proxy] # UDP/TCP代理随机端口范围同时限制RTSP服务器的UDP端口范围 # 走UDP播放/推流时防火墙需放行该区间 port_range30000-35000 # UDP接收数据socket buffer默认4MB高并发收流丢包时可加大 udp_recv_socket_buffer4194304 # UDP收RTP的超时时间秒超时未收到数据则断开 timeoutSec15实现位置需要看代码时参考RTSP 的 UDP 接收在 src/Rtsp/UDPServer.cpp会话与传输协商在 src/Rtsp/RtspSession.cpp。如何调优 TCP 传输RTMP / HTTP-FLVRTMP 与 HTTP-FLV 天然走 TCP这里的选型其实是调参[general] # 合并写缓存时长毫秒服务器攒够数据再一次性写入socket # 0关闭延迟最低开启后会同时关闭TCP_NODELAY mergeWriteMS0[rtmp] # RTMP必须在此时间内完成握手否则服务器断开秒 handshakeSecond15 # RTMP保活超时该时间内未收到客户端数据、 # 或tcp发送缓存卡住超过该时间则断开连接秒 keepAliveSecond15 # 直接代理模式开启后支持任意编码格式直接转发 directProxy1WebRTCUDP 为主、TCP 兜底[rtc] # WebRTC的UDP监听端口服务器在NAT内做端口映射时 # 外网映射端口必须与该端口一致 port8000 # UDP不通时回退使用的TCP端口 tcpPort8000 # NACK最多请求重传次数丢包持续偏大时可适当上调 nackMaxCount15卡顿或掉线时该调什么排障速查表 按现象 → 大概率原因 → 该动的参数对照排查现象大概率原因该调的参数RTSP 走 UDP 无画面改 TCP 就正常防火墙拦了 UDP或媒体端口未放行放行 [rtp_proxy]port_range区间或把rtpTransportType改 0公网观看卡顿、音画不同步丢包乱序纯 UDP 无恢复改用 RTMP/HTTP-FLV 或 WebRTCWebRTC 可上调 [rtc]nackMaxCount、maxRtpCacheMS高并发 UDP 收流偶发丢包接收缓冲区不够加大 [rtp_proxy]udp_recv_socket_buffer同时确认系统net.core.rmem_max上限RTSP 拉流起播花屏或卡住directProxy1时 GOP 缓存无法定位 I 帧[rtsp]directProxy0H264/H265/AAC 拉流时能播但延迟偏高合并写缓存或转发缓存生效[general]mergeWriteMS0[rtsp]lowLatency1注意花屏风险RTSP 用 TCP 拉流后无法再走 UDP 代理直接代理下 RTP 超过 MTU关闭 [rtsp]directProxy或改用 TCP 代理收尾记住这三点传输层选择的原则局域网选 UDP、公网选 TCP、实时互动选 WebRTC默认值rtpTransportType-1意味着协议由客户端协商决定不要想当然。选型只是第一步真正决定体验的是rtpTransportType、mergeWriteMS、port_range这类参数且改的是运行目录下的config.ini不是conf/config.ini。动手前先确认网络环境UDP 能否通过、端口是否放行再谈调参顺序反了会浪费大量排查时间。更多协议细节与配置项说明参阅仓库内 README.md。【免费下载链接】ZLMediaKitWebRTC/RTSP/RTMP/HTTP/HLS/HTTP-FLV/WebSocket-FLV/HTTP-TS/HTTP-fMP4/WebSocket-TS/WebSocket-fMP4/GB28181/SRT/STUN/TURN server and client framework based on C11项目地址: https://gitcode.com/GitHub_Trending/zl/ZLMediaKit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ZLMediaKit播放卡顿还是延迟高？三问定下TCP或UDP选型
ZLMediaKit播放卡顿还是延迟高三问定下TCP或UDP选型【免费下载链接】ZLMediaKitWebRTC/RTSP/RTMP/HTTP/HLS/HTTP-FLV/WebSocket-FLV/HTTP-TS/HTTP-fMP4/WebSocket-TS/WebSocket-fMP4/GB28181/SRT/STUN/TURN server and client framework based on C11项目地址: https://gitcode.com/GitHub_Trending/zl/ZLMediaKitZLMediaKit支持RTSP/RTMP/HTTP-FLV/WebRTC等协议的流媒体框架播放画面卡住两秒、延迟拖到好几秒时先怀疑传输层TCP UDP选型常常是ZLMediaKit播放卡顿与高延迟的根源。本文先给结论、再讲清原理最后带你在配置里完成切换与初步调参读完能直接判断自己的环境该用哪个协议。先给结论ZLMediaKit传输协议选型速查表赶时间的话按下表对号入座即可后文会解释每条结论的依据。你的情况建议传输方式一句话理由播放器与服务器同局域网/同机房RTSP over UDP或 WebRTC链路可靠省掉重传开销延迟最低公网、跨运营商、手机网络观看RTMP、HTTP-FLV 等 TCP 类协议重传与流量控制能扛住丢包抖动实时互动双向语音视频、远程操控WebRTCUDP NACK 选择性重传延迟低且丢包有应用层恢复手段链路只有 80/443 能通代理或防火墙HTTP-FLVTCPUDP 在大多数企业防火墙上会被直接丢弃一个容易忽略的默认行为RTSP 的 RTP 传输方式默认是rtpTransportType-1不限制由客户端 SETUP 请求说了算。这意味着用 TCP 还是 UDP很可能不是你选的而是协商出来的。理解原理一通电话和一次街头喊话的区别把 TCP 想成打电话每句话都要对方嗯一声确认听不清就说请重复顺序也一定按说话的先后。代价是每句话都多了确认的往返且一旦线路拥塞后面的话全被压住。把 UDP 想成街头喊话话出口就没了不确认、不补发、也不保证按顺序到达。它快但喊丢了就是丢了。技术小结TCP 靠序号、确认与重传保证送达且有序UDP 只负责发送、不做任何恢复。直播视频是个特殊业务——晚了一帧基本就不值钱了所以媒体传输要么图稳走 TCP要么走 UDP 但自己在应用层补一套轻量重传WebRTC 的 NACK、SRT 协议都是这个思路SRT 底层也是 UDP。动手前自测先问自己这三个问题问题一播放器在哪里和服务器同局域网链路丢包率接近零直接用 UDPRTSP 或 WebRTC重传机制是纯开销。在公网、跨运营商或移动网络选 TCP 类协议RTMP、HTTP-FLV或 WebRTC。公网丢包、乱序、抖动是常态TCP 的重传和拥塞控制能避免画面直接卡死。问题二能容忍多大延迟要实时互动延迟以毫秒计选 WebRTC。它走 UDP 但带 NACK 选择性重传和拥塞控制兼顾了低延迟与抗丢包实现集中在 webrtc/ 目录。普通观看几百毫秒到一秒内延迟可接受TCP 类协议更省心出了问题也更好排查。问题三链路上 UDP 走得通吗中间有只放行 80/443 的代理或防火墙UDP 基本无解老老实实用 HTTP-FLV。要让 RTSP 走 UDPUDP 媒体端口是从port_range范围内分配的默认 30000-35000防火墙必须放行这个区间否则表现为信令通了、画面不出来。WebRTC 有个兜底UDP 不通时客户端可回落到 TCPrtc.tcpPort但延迟和稳定性都会打折扣。动手配置改哪个文件、改哪些参数⚠️ 先说一个新手常踩的坑MediaServer 实际加载的是可执行文件同目录下的config.ini即release/${系统}/${编译类型}/config.ini直接改仓库里的 conf/config.ini 不会生效除非启动时用-c参数显式指定。如何切换到 UDP 传输以 RTSP 为例[rtsp] # 强制协商RTP传输方式0TCP1UDP2MULTICAST-1不限制默认值 # 与客户端SETUP请求不一致时返回461迫使客户端重新协商 rtpTransportType1 # RTSP转发低延迟模式开启后不缓存RTP包可降低约一帧延迟 # 注意H264存在一帧多个slice时可能花屏默认0 lowLatency0[rtp_proxy] # UDP/TCP代理随机端口范围同时限制RTSP服务器的UDP端口范围 # 走UDP播放/推流时防火墙需放行该区间 port_range30000-35000 # UDP接收数据socket buffer默认4MB高并发收流丢包时可加大 udp_recv_socket_buffer4194304 # UDP收RTP的超时时间秒超时未收到数据则断开 timeoutSec15实现位置需要看代码时参考RTSP 的 UDP 接收在 src/Rtsp/UDPServer.cpp会话与传输协商在 src/Rtsp/RtspSession.cpp。如何调优 TCP 传输RTMP / HTTP-FLVRTMP 与 HTTP-FLV 天然走 TCP这里的选型其实是调参[general] # 合并写缓存时长毫秒服务器攒够数据再一次性写入socket # 0关闭延迟最低开启后会同时关闭TCP_NODELAY mergeWriteMS0[rtmp] # RTMP必须在此时间内完成握手否则服务器断开秒 handshakeSecond15 # RTMP保活超时该时间内未收到客户端数据、 # 或tcp发送缓存卡住超过该时间则断开连接秒 keepAliveSecond15 # 直接代理模式开启后支持任意编码格式直接转发 directProxy1WebRTCUDP 为主、TCP 兜底[rtc] # WebRTC的UDP监听端口服务器在NAT内做端口映射时 # 外网映射端口必须与该端口一致 port8000 # UDP不通时回退使用的TCP端口 tcpPort8000 # NACK最多请求重传次数丢包持续偏大时可适当上调 nackMaxCount15卡顿或掉线时该调什么排障速查表 按现象 → 大概率原因 → 该动的参数对照排查现象大概率原因该调的参数RTSP 走 UDP 无画面改 TCP 就正常防火墙拦了 UDP或媒体端口未放行放行 [rtp_proxy]port_range区间或把rtpTransportType改 0公网观看卡顿、音画不同步丢包乱序纯 UDP 无恢复改用 RTMP/HTTP-FLV 或 WebRTCWebRTC 可上调 [rtc]nackMaxCount、maxRtpCacheMS高并发 UDP 收流偶发丢包接收缓冲区不够加大 [rtp_proxy]udp_recv_socket_buffer同时确认系统net.core.rmem_max上限RTSP 拉流起播花屏或卡住directProxy1时 GOP 缓存无法定位 I 帧[rtsp]directProxy0H264/H265/AAC 拉流时能播但延迟偏高合并写缓存或转发缓存生效[general]mergeWriteMS0[rtsp]lowLatency1注意花屏风险RTSP 用 TCP 拉流后无法再走 UDP 代理直接代理下 RTP 超过 MTU关闭 [rtsp]directProxy或改用 TCP 代理收尾记住这三点传输层选择的原则局域网选 UDP、公网选 TCP、实时互动选 WebRTC默认值rtpTransportType-1意味着协议由客户端协商决定不要想当然。选型只是第一步真正决定体验的是rtpTransportType、mergeWriteMS、port_range这类参数且改的是运行目录下的config.ini不是conf/config.ini。动手前先确认网络环境UDP 能否通过、端口是否放行再谈调参顺序反了会浪费大量排查时间。更多协议细节与配置项说明参阅仓库内 README.md。【免费下载链接】ZLMediaKitWebRTC/RTSP/RTMP/HTTP/HLS/HTTP-FLV/WebSocket-FLV/HTTP-TS/HTTP-fMP4/WebSocket-TS/WebSocket-fMP4/GB28181/SRT/STUN/TURN server and client framework based on C11项目地址: https://gitcode.com/GitHub_Trending/zl/ZLMediaKit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考