尧图网页设计 
ZLMediaKit 协议选型实战指南TCP 还是 UDP10 秒定下来卡顿和延迟一起治【免费下载链接】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开会时看远端直播画面突然卡住两秒切到监控页端到端延迟已经叠到 8 秒。你的第一反应是网络慢多半不是——是 TCP 和 UDP 选错了。这篇文章围绕 ZLMediaKit 协议选型展开把判据、关键配置项和调优值一次摆出来你看完直接上手。结论先行10 秒敲定协议 不用先背原理记住下面 5 条能覆盖九成场景RTMP 推流或 HTTP-FLV 播放最常见的公网直播组合不用想天生 TCP选型问题不存在你要调的是服务器端的合并写参数。RTSP 播放观众在公网或弱网强制 TCPrtpTransportType0。丢包有重传兜底不用担心花屏。RTSP 播放两端在同一局域网摄像头、NVR、测试台强制 UDPrtpTransportType1。客户端非要走 TCP服务器回 461 逼它重新协商。WebRTC 这类互动场景UDP 打底内置 NACK 重传补可靠性是「UDP 低延迟 选择重传」的组合。客户端后面有严格 NAT 或防火墙UDP 明确不通退回 TCP。协议再好包过不去就是过不去。绝大多数播放端其实没有选择权真正的纠结只发生在 RTSP 和 WebRTC 这一层。原理拆解一个类比讲清 TCP 与 UDP这么理解TCP 像挂号信每一封都要收件人签收丢了会补寄按顺序送到UDP 像明信片寄出去就不管了没人回执丢了就是丢了但路上最省时间。差异摊开就四点到达保证TCP 有确认和重传保证「一个都到」UDP 不管丢包是常态。到达顺序TCP 保序后到的包会等前面缺的队头阻塞UDP 允许乱序上层靠 RTP 序列号自己拼。延迟代价TCP 的确认、重传、流控都是实时性开销UDP 控制环节少延迟天然低。头部开销TCP 拖着头部加控制信息同样码率下 UDP 把更多带宽留给真正的画面。换句话说TCP 买的是完整性UDP 买的是速度钱只有一份你只能选一个。ZLMediaKit 里RTP 负载可以走 TCPRTSP interleaved 模式或 UDP单播/组播RTMP 和 HTTP-FLV 天生走 TCP。RTSP 的 UDP 收发与端口复用逻辑在 src/Rtsp/UDPServer.cpp好奇可以直接看源码。场景拆解3 个真实场景怎么选场景一公网 / 弱网直播症状开播途中偶发 1~2 秒冻结或观看一段时间后连接被断开。选谁TCPRTMP / HTTP-FLV 默认如此RTSP 走公网时强制rtpTransportType0。为什么公网丢包率不可控只有重传能保证画面完整多花的那点时间比花屏值钱。动哪[rtmp]的keepAliveSecond默认 15 秒15 秒内收不到客户端数据或 TCP 发送缓存卡住就断连断连多就调到 30。场景二局域网实时预览症状局域网内看摄像头延迟照样 300ms 以上操作员点一下反应慢半拍。选谁UDP[rtsp]的rtpTransportType1。为什么局域网几乎不丢包重传机制纯属浪费UDP 逐帧发出去就走再叠加lowLatency1关掉 RTP 包缓存又能省一帧。动哪就这两个参数改完即可。场景三高码率大屏播放症状单路 4K 流 20Mbps 起步并发一多服务器发送队列开始堆积延迟持续上涨。选谁UDP 单播多台大屏在同一局域网时直接上组播rtpTransportType2。为什么高码率叠 TCP带宽一抖就队头阻塞所有人陪着等UDP 头部小、占用低组播还能让骨干网只传一份省下的带宽全留给画面。动哪[rtp_proxy]的udp_recv_socket_buffer默认 4194304 字节4MB高码率突发仍丢包就继续加大。配置清单可直接抄走以上参数都在配置文件里样例即 conf/config.ini。注意构建后进程实际加载的是 release 目录下的config.ini改错文件白忙一场。最小可用配置按段分组如下[general] mergeWriteMS0 # 合并写间隔(ms)0立即写socket不引入额外延迟 [rtsp] rtpTransportType-1 # 强制协商RTP传输 (0:TCP,1:UDP,2:MULTICAST,-1:不限制) lowLatency0 # 开启后RTSP转发不缓存rtp包可降一帧延迟 [rtmp] keepAliveSecond15 # 该秒数内收不到客户端数据即断开 handshakeSecond15 # 握手须在该秒数内完成否则断开 [rtp_proxy] udp_recv_socket_buffer4194304 # UDP接收socket缓冲(字节)4MB [rtc] nackMaxCount15 # WebRTC NACK最多请求重传次数改完重启 MediaServer 生效参数含义以conf/config.ini内的注释为准。进阶调优还是卡就看这里 按症状找参数一个一个改每次开播固定多 100~200ms 延迟→[general]的mergeWriteMS。设 10 时服务器攒够 10ms 数据再批量写同时关闭 TCP_NODELAY、开启 MSG_MORE吞吐上去了延迟也上去了延迟敏感就改回 0。RTSP 走 UDP 偶发花屏→ 高码率突发装不进系统接收队列加大[rtp_proxy]的udp_recv_socket_buffer从默认 4194304 调到 83886088MB。WebRTC 通话中花屏→ 看[rtc]的 NACK 组nackMaxCount默认 15 次nackMaxMS默认 3000ms丢包状态只保留 3 秒maxRtpCacheMS默认 5000ms重传追不上就把nackRtpSize默认 8调小让重传请求更灵敏。RTSP 转发并发高想再抠一帧延迟→[rtsp]的lowLatency1用包缓存换并发。H.264 一帧多个 slice想开低延迟→[rtp]的lowLatency默认关闭这种流开启后可能花屏先确认编码侧没有多 slice 再动。一句话收束网络可信选 UDP 换延迟网络不可信选 TCP 换完整两个都要就交给 WebRTC。更完整的特性说明见仓库内官方文档 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，10 秒定下来，卡顿和延迟一起治
ZLMediaKit 协议选型实战指南TCP 还是 UDP10 秒定下来卡顿和延迟一起治【免费下载链接】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开会时看远端直播画面突然卡住两秒切到监控页端到端延迟已经叠到 8 秒。你的第一反应是网络慢多半不是——是 TCP 和 UDP 选错了。这篇文章围绕 ZLMediaKit 协议选型展开把判据、关键配置项和调优值一次摆出来你看完直接上手。结论先行10 秒敲定协议 不用先背原理记住下面 5 条能覆盖九成场景RTMP 推流或 HTTP-FLV 播放最常见的公网直播组合不用想天生 TCP选型问题不存在你要调的是服务器端的合并写参数。RTSP 播放观众在公网或弱网强制 TCPrtpTransportType0。丢包有重传兜底不用担心花屏。RTSP 播放两端在同一局域网摄像头、NVR、测试台强制 UDPrtpTransportType1。客户端非要走 TCP服务器回 461 逼它重新协商。WebRTC 这类互动场景UDP 打底内置 NACK 重传补可靠性是「UDP 低延迟 选择重传」的组合。客户端后面有严格 NAT 或防火墙UDP 明确不通退回 TCP。协议再好包过不去就是过不去。绝大多数播放端其实没有选择权真正的纠结只发生在 RTSP 和 WebRTC 这一层。原理拆解一个类比讲清 TCP 与 UDP这么理解TCP 像挂号信每一封都要收件人签收丢了会补寄按顺序送到UDP 像明信片寄出去就不管了没人回执丢了就是丢了但路上最省时间。差异摊开就四点到达保证TCP 有确认和重传保证「一个都到」UDP 不管丢包是常态。到达顺序TCP 保序后到的包会等前面缺的队头阻塞UDP 允许乱序上层靠 RTP 序列号自己拼。延迟代价TCP 的确认、重传、流控都是实时性开销UDP 控制环节少延迟天然低。头部开销TCP 拖着头部加控制信息同样码率下 UDP 把更多带宽留给真正的画面。换句话说TCP 买的是完整性UDP 买的是速度钱只有一份你只能选一个。ZLMediaKit 里RTP 负载可以走 TCPRTSP interleaved 模式或 UDP单播/组播RTMP 和 HTTP-FLV 天生走 TCP。RTSP 的 UDP 收发与端口复用逻辑在 src/Rtsp/UDPServer.cpp好奇可以直接看源码。场景拆解3 个真实场景怎么选场景一公网 / 弱网直播症状开播途中偶发 1~2 秒冻结或观看一段时间后连接被断开。选谁TCPRTMP / HTTP-FLV 默认如此RTSP 走公网时强制rtpTransportType0。为什么公网丢包率不可控只有重传能保证画面完整多花的那点时间比花屏值钱。动哪[rtmp]的keepAliveSecond默认 15 秒15 秒内收不到客户端数据或 TCP 发送缓存卡住就断连断连多就调到 30。场景二局域网实时预览症状局域网内看摄像头延迟照样 300ms 以上操作员点一下反应慢半拍。选谁UDP[rtsp]的rtpTransportType1。为什么局域网几乎不丢包重传机制纯属浪费UDP 逐帧发出去就走再叠加lowLatency1关掉 RTP 包缓存又能省一帧。动哪就这两个参数改完即可。场景三高码率大屏播放症状单路 4K 流 20Mbps 起步并发一多服务器发送队列开始堆积延迟持续上涨。选谁UDP 单播多台大屏在同一局域网时直接上组播rtpTransportType2。为什么高码率叠 TCP带宽一抖就队头阻塞所有人陪着等UDP 头部小、占用低组播还能让骨干网只传一份省下的带宽全留给画面。动哪[rtp_proxy]的udp_recv_socket_buffer默认 4194304 字节4MB高码率突发仍丢包就继续加大。配置清单可直接抄走以上参数都在配置文件里样例即 conf/config.ini。注意构建后进程实际加载的是 release 目录下的config.ini改错文件白忙一场。最小可用配置按段分组如下[general] mergeWriteMS0 # 合并写间隔(ms)0立即写socket不引入额外延迟 [rtsp] rtpTransportType-1 # 强制协商RTP传输 (0:TCP,1:UDP,2:MULTICAST,-1:不限制) lowLatency0 # 开启后RTSP转发不缓存rtp包可降一帧延迟 [rtmp] keepAliveSecond15 # 该秒数内收不到客户端数据即断开 handshakeSecond15 # 握手须在该秒数内完成否则断开 [rtp_proxy] udp_recv_socket_buffer4194304 # UDP接收socket缓冲(字节)4MB [rtc] nackMaxCount15 # WebRTC NACK最多请求重传次数改完重启 MediaServer 生效参数含义以conf/config.ini内的注释为准。进阶调优还是卡就看这里 按症状找参数一个一个改每次开播固定多 100~200ms 延迟→[general]的mergeWriteMS。设 10 时服务器攒够 10ms 数据再批量写同时关闭 TCP_NODELAY、开启 MSG_MORE吞吐上去了延迟也上去了延迟敏感就改回 0。RTSP 走 UDP 偶发花屏→ 高码率突发装不进系统接收队列加大[rtp_proxy]的udp_recv_socket_buffer从默认 4194304 调到 83886088MB。WebRTC 通话中花屏→ 看[rtc]的 NACK 组nackMaxCount默认 15 次nackMaxMS默认 3000ms丢包状态只保留 3 秒maxRtpCacheMS默认 5000ms重传追不上就把nackRtpSize默认 8调小让重传请求更灵敏。RTSP 转发并发高想再抠一帧延迟→[rtsp]的lowLatency1用包缓存换并发。H.264 一帧多个 slice想开低延迟→[rtp]的lowLatency默认关闭这种流开启后可能花屏先确认编码侧没有多 slice 再动。一句话收束网络可信选 UDP 换延迟网络不可信选 TCP 换完整两个都要就交给 WebRTC。更完整的特性说明见仓库内官方文档 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），仅供参考