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 拉流播放卡顿不知道该上 TCP 还是 UDP它是一套支持 RTSP/RTMP/WebRTC 等多协议的 C 框架传输协议选型直接决定播放体验。三分钟做出决定改好 config.ini 即完事。⚡ 15 秒速选场景对号入座速查表选型前先弄清两者差别一句话版本TCP先建连接三次握手两端互发 3 个包打招呼把连接敲定每发一段数据要等对方回执等不到就重发重传把没确认的包再发一遍。稳但每次确认都费时间。UDP不建连接、不等回执、不重发发完就忘。快但丢了的包就是丢了。所以你的网络环境 / 业务场景推荐协议一句话理由公网、弱网、直播分发TCP重传补上丢的包画面可能等一等但不会花视频监控、视频会议等实时互动GB28181UDP实时性优先偶尔一帧失真可以忍局域网、专线、机房互联UDP网络本来就稳省掉确认和重传的开销点播、重要录像分发TCP完整性比速度重要结论先行公网选 TCP局域网选 UDP互动选 UDP分发选 TCP。️ 求稳路线config.ini 里如何把 TCP 用好TCP 的可靠靠三件事连接、确认、重传。发送方没收到回执就不算送达超时就把同一个包再发一遍接收方缓冲快满时TCP 还会自动让发送方降速流量控制。这套机制把丢包变成了等待画面会卡但数据是完整的。代价就是延迟每次确认都要等一个来回遇到重传超时卡顿更明显。什么时候用它RTMP、HTTP-FLV 在 ZLMediaKit 里天然走 TCP没有得选。RTSP 播放时RTP 部分可以选 TCP。服务器把 RTP 包封装进 TCP 流每两个包配一对编号Transport 头里的 interleaved直白说就是给包编个序号让接收端按序拼回协商逻辑在 src/Rtsp/RtspSession.cpp。两个关键参数[general] mergeWriteMS默认0表示数据一到就写 socket纯实时改成10是攒够 10ms 再批量写性能更好但多 10ms 延迟。开启后还会关闭 TCP_NODELAY小包立即发模式并启用 MSG_MORE 批量发送提示。[rtmp] handshakeSecond、[rtmp] keepAliveSecond默认都是 15 秒。弱网下握手或空闲偏慢放宽到30能少被服务器断连。 求快路线config.ini 里一行参数强制 UDPUDP 的原理正好相反无连接、无确认、无重传。延迟天然低协议头部开销小。但丢包即丢公网环境会变成花屏、撕裂。适合局域网监控、专线、机房互联GB28181、视频会议这类实时互动实时性比偶尔一帧失真重要4K 等高带宽场景头部开销小省的是真金白银的带宽。ZLMediaKit 的 UDP 接收端实现在 src/Rtsp/UDPServer.cpp配合三个参数[rtsp] rtpTransportType强制协商开关0TCP、1UDP、2多播、-1不限制默认。[rtsp] lowLatency置1后转发不缓存 RTP 包延迟降一帧并发也更好。[rtp_proxy] udp_recv_socket_bufferUDP 接收缓冲区默认 41943044MB收大流时加大可防溢出丢包。补一句WebRTC 底层其实也是 UDP但多打了补丁——NACK接收方主动上报哪个序号丢了要求补发等于在 UDP 之上叠了一层重传。细节见 webrtc/readme.md。动手三步ZLMediaKit TCP/UDP 配置 3 行改完全部改动都在 conf/config.ini。第 1 步定 RTSP 传输方向——找[rtsp]段的rtpTransportType改成1或0。[rtsp] # 强制协商rtp传输方式 (0:TCP,1:UDP,2:MULTICAST,-1:不限制) rtpTransportType1效果客户端请求了不对的传输方式时服务器回 461 Unsupported transport客户端目前支持 FFmpeg 和 VLC会重新 SETUP 切到你指定的协议。第 2 步UDP 路线降延迟——找[rtsp]段的lowLatency改成1。效果转发时不再缓存 RTP 包延迟降一帧左右网络好的时候体感立竿见影。第 3 步TCP 路线提吞吐——找[general]段的mergeWriteMS改成10。效果数据攒够 10ms 批量写 socket系统调用变少、并发更好代价是延迟多 10ms。追求极致实时就保持默认0。出问题自检清单症状、原因、参数逐条对症状RTSP 客户端播不了报 461 → 可能原因强制协商的传输类型和客户端请求的不一致 → 该调[rtsp] rtpTransportType改回-1不限制症状UDP 播放花屏、撕裂 → 可能原因公网丢包UDP 没有重传兜底 → 该调切rtpTransportType0走 TCP或改用 WebRTCNACK 重传[rtc] nackMaxCount控制最多重传请求次数默认 15症状RTMP 连接频繁断开 → 可能原因默认 15 秒超时对弱网太苛刻 → 该调[rtmp] handshakeSecond、[rtmp] keepAliveSecond改到30症状UDP 大流偶发卡顿 → 可能原因接收缓冲区溢出 → 该调[rtp_proxy] udp_recv_socket_buffer从默认 4194304 往上加症状整体延迟偏高 → 可能原因低延迟/即时发送未配置 → 该调UDP 路线开[rtsp] lowLatency1TCP 路线保[general] mergeWriteMS0即发即走下一步往哪走UDP 的身子 重传的补丁让 WebRTC 正在成为实时互动场景的主流答案业务要往双向互动走就提前关注。完整参数见 README.mdUDP 接收与 RTSP 协商的源码在 src/Rtsp/。【免费下载链接】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 拉流播放卡顿不知道该上 TCP 还是 UDP它是一套支持 RTSP/RTMP/WebRTC 等多协议的 C 框架传输协议选型直接决定播放体验。三分钟做出决定改好 config.ini 即完事。⚡ 15 秒速选场景对号入座速查表选型前先弄清两者差别一句话版本TCP先建连接三次握手两端互发 3 个包打招呼把连接敲定每发一段数据要等对方回执等不到就重发重传把没确认的包再发一遍。稳但每次确认都费时间。UDP不建连接、不等回执、不重发发完就忘。快但丢了的包就是丢了。所以你的网络环境 / 业务场景推荐协议一句话理由公网、弱网、直播分发TCP重传补上丢的包画面可能等一等但不会花视频监控、视频会议等实时互动GB28181UDP实时性优先偶尔一帧失真可以忍局域网、专线、机房互联UDP网络本来就稳省掉确认和重传的开销点播、重要录像分发TCP完整性比速度重要结论先行公网选 TCP局域网选 UDP互动选 UDP分发选 TCP。️ 求稳路线config.ini 里如何把 TCP 用好TCP 的可靠靠三件事连接、确认、重传。发送方没收到回执就不算送达超时就把同一个包再发一遍接收方缓冲快满时TCP 还会自动让发送方降速流量控制。这套机制把丢包变成了等待画面会卡但数据是完整的。代价就是延迟每次确认都要等一个来回遇到重传超时卡顿更明显。什么时候用它RTMP、HTTP-FLV 在 ZLMediaKit 里天然走 TCP没有得选。RTSP 播放时RTP 部分可以选 TCP。服务器把 RTP 包封装进 TCP 流每两个包配一对编号Transport 头里的 interleaved直白说就是给包编个序号让接收端按序拼回协商逻辑在 src/Rtsp/RtspSession.cpp。两个关键参数[general] mergeWriteMS默认0表示数据一到就写 socket纯实时改成10是攒够 10ms 再批量写性能更好但多 10ms 延迟。开启后还会关闭 TCP_NODELAY小包立即发模式并启用 MSG_MORE 批量发送提示。[rtmp] handshakeSecond、[rtmp] keepAliveSecond默认都是 15 秒。弱网下握手或空闲偏慢放宽到30能少被服务器断连。 求快路线config.ini 里一行参数强制 UDPUDP 的原理正好相反无连接、无确认、无重传。延迟天然低协议头部开销小。但丢包即丢公网环境会变成花屏、撕裂。适合局域网监控、专线、机房互联GB28181、视频会议这类实时互动实时性比偶尔一帧失真重要4K 等高带宽场景头部开销小省的是真金白银的带宽。ZLMediaKit 的 UDP 接收端实现在 src/Rtsp/UDPServer.cpp配合三个参数[rtsp] rtpTransportType强制协商开关0TCP、1UDP、2多播、-1不限制默认。[rtsp] lowLatency置1后转发不缓存 RTP 包延迟降一帧并发也更好。[rtp_proxy] udp_recv_socket_bufferUDP 接收缓冲区默认 41943044MB收大流时加大可防溢出丢包。补一句WebRTC 底层其实也是 UDP但多打了补丁——NACK接收方主动上报哪个序号丢了要求补发等于在 UDP 之上叠了一层重传。细节见 webrtc/readme.md。动手三步ZLMediaKit TCP/UDP 配置 3 行改完全部改动都在 conf/config.ini。第 1 步定 RTSP 传输方向——找[rtsp]段的rtpTransportType改成1或0。[rtsp] # 强制协商rtp传输方式 (0:TCP,1:UDP,2:MULTICAST,-1:不限制) rtpTransportType1效果客户端请求了不对的传输方式时服务器回 461 Unsupported transport客户端目前支持 FFmpeg 和 VLC会重新 SETUP 切到你指定的协议。第 2 步UDP 路线降延迟——找[rtsp]段的lowLatency改成1。效果转发时不再缓存 RTP 包延迟降一帧左右网络好的时候体感立竿见影。第 3 步TCP 路线提吞吐——找[general]段的mergeWriteMS改成10。效果数据攒够 10ms 批量写 socket系统调用变少、并发更好代价是延迟多 10ms。追求极致实时就保持默认0。出问题自检清单症状、原因、参数逐条对症状RTSP 客户端播不了报 461 → 可能原因强制协商的传输类型和客户端请求的不一致 → 该调[rtsp] rtpTransportType改回-1不限制症状UDP 播放花屏、撕裂 → 可能原因公网丢包UDP 没有重传兜底 → 该调切rtpTransportType0走 TCP或改用 WebRTCNACK 重传[rtc] nackMaxCount控制最多重传请求次数默认 15症状RTMP 连接频繁断开 → 可能原因默认 15 秒超时对弱网太苛刻 → 该调[rtmp] handshakeSecond、[rtmp] keepAliveSecond改到30症状UDP 大流偶发卡顿 → 可能原因接收缓冲区溢出 → 该调[rtp_proxy] udp_recv_socket_buffer从默认 4194304 往上加症状整体延迟偏高 → 可能原因低延迟/即时发送未配置 → 该调UDP 路线开[rtsp] lowLatency1TCP 路线保[general] mergeWriteMS0即发即走下一步往哪走UDP 的身子 重传的补丁让 WebRTC 正在成为实时互动场景的主流答案业务要往双向互动走就提前关注。完整参数见 README.mdUDP 接收与 RTSP 协商的源码在 src/Rtsp/。【免费下载链接】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），仅供参考