coturn 传输协议速查UDP、TCP、TLS、DTLS 到底差在哪一张表讲清楚【免费下载链接】coturncoturn TURN server project项目地址: https://gitcode.com/GitHub_Trending/co/coturn在 coturn 里配置 coturn 传输协议最容易踩的坑是把客户端怎么连上来和数据怎么转发给对端当成同一件事。这两个选择相互独立而大多数文档只讲其一。本文用一张速查表对比四种 coturn 传输协议的性能与代价解释 UDP 为什么快、加密又贵在哪最后给出一套可以直接照抄的最小配置和避坑清单。协议选择速查表只想要答案的话看这张表就够了。左边是客户端 ↔ TURN 服务器的控制连接右边是TURN 服务器 ↔ 对端的中继端点两者分开选你的情况控制连接建议中继端点建议一句话理由WebRTC浏览器DTLS5349UDP relay浏览器只认 DTLS-SRTP 这条路UDP 中继延迟最低自有 App、追求低延迟UDP3478UDP relay无连接、无重排队丢包不阻塞后续数据客户端被防火墙挡住 UDPTCP 或 TLSTCP relayRFC 6062UDP 出不去时TCP 通道是唯一能穿 NAT 的方案内网 / 私有网络、只追求吞吐UDPUDP relay没有威胁模型时加密纯属浪费 CPU合规要求加密TLS / DTLS按上面两种选加密解决的是窃听与篡改不是性能两个容易混淆的点先说清coturn 默认在 3478 上同时监听 UDP 和 TCP在 5349 上同时监听 TLS 和 DTLS。更特别的是服务器会自动识别端口上跑的是什么流量——按 RFC 5766 的设计明文端口和加密端口在功能上是等价的保留两套只是为兼容规范。所以你不需要为每种协议单独开一个端口。用 TCP有两层含义客户端到服务器走 TCP 控制通道以及对端数据走 TCP 中继端点。前者靠 README.turnserver 里的no-udp/no-tcp控制后者靠no-udp-relay/no-tcp-relay控制互不影响。四种传输方式为什么快代价是什么不逐个罗列特性直接讲机制。理解机制后性能结论自己就出来了。传输方式监听默认端口快在哪代价是什么UDP3478无握手、无确认、无重传调度包到即转丢包就丢乱序就到可靠性全甩给上层如 RTP/DTLS-SRTPTCP3478可靠、有序穿过绝大多数防火墙队头阻塞一个包丢了后面全部排队实时流会整体卡顿TLS5349加密 服务器证书校验防中间人一次完整握手约 1-2 个 RTT 每包加解密的 CPU 开销DTLS5349既有 UDP 的低延迟又有 TLS 级别的加密握手比 TLS 更啰嗦要防乱序且弱网下握手包丢了要等超时重传UDP 的快不是玄学它没有连接状态服务器收到 ALLOCATE 就立刻处理不排队等 ACK。代价是弱网下表现取决于上层协议——所以 WebRTC 在 UDP 之上又叠了 DTLS-SRTP把可靠性问题在应用层解决而不是指望传输层兜底。TCP 的可靠在实时场景反而是负资产。RTP 里一个 20ms 的音频帧丢了等待重传重排期间后面所有帧都被压住用户听到的是整体卡顿而不是单帧噪声。这就是为什么网络不稳定就用 TCP 更稳这个直觉在 TURN 语境下是错的——网络不稳定时TCP 中继的抖动通常比 UDP 更难看。TLS/DTLS 的开销是真实存在的握手阶段的 CPU 消耗集中在 RSA/ECDHE 运算上稳态传输则是每包一次加解密。coturn 的 docs/OpenSSL.md 给了完整的证书与协商参数说明但官方 docs/Performance.md 本身把调优细节指向了社区 wiki没有给出加密损失 X%的固定数字——不同 CPU、不同密码套件差异很大上线前自己压测一次比背任何比例都靠谱。什么时候该开 TCP 中继单独拎出来讲因为这是最常配错的一项默认保持 UDP 中继RFC 5766 行为。只要客户端能收发 UDP就永远优先选它。客户端在严格企业网 / 移动网络里 UDP 被封导致 P2P 失败、只能走 TURN——此时客户端会请求 TCP 中继端点RFC 6062coturn 默认支持无需额外配置。想在服务器侧直接封死某类端点用no-udp-relay只留 TCP 中继或no-tcp-relay只留 UDP 中继开关定义见 src/apps/relay/mainrelay.c。红线no-udp-relay和no-tcp-relay不能同时开两个中继端点全关服务器就没法转发任何数据启动时会直接报 CONFIG ERROR。最小配置落地coturn 开箱即听四种协议默认配置已经覆盖了上表的全部行。你真正要做的只有三件事确认端口、放证书、按威胁模型砍监听。第一端口。这是 docker/coturn/turnserver.conf 里的默认值确认没被改就行listening-port3478 tls-listening-port5349白话解释3478 一个端口同时接 UDP 和 TCP 控制连接5349 同时接 TLS 和 DTLS不用为每种协议单开端口。第二加密证书。只要 5349 上有流量WebRTC 场景一定有这两项必须有效cert/etc/ssl/certs/cert.pem pkey/etc/ssl/private/privkey.pem白话解释cert 是服务器证书、pkey 是私钥PEM 格式证书域名和客户端实际访问的域名不一致时DTLS 握手会直接失败这是连不上 5349的第一大原因。第三按需砍监听。如果策略是只接受加密连接no-udp no-tcp no-udp-relay白话解释前两行关掉 3478 上的明文 UDP/TCP 控制监听第三行禁止 UDP 形态的中继端点强制对端走 TCP 中继。注意别顺手把no-tcp-relay也加上理由见上一节的红线。常见坑客户端连 3478 报 437/拒绝多半是服务端被no-udp/no-tls这类开关砍掉了监听而不是客户端写错协议。先ss -ulnp/ss -tlntp看 3478、5349 到底监听了几种协议。中继端点默认落在min-port49152到max-port65535之间防火墙只放行了 TURN 控制端口、忘了放行这段中继端口范围现象是控制连接成功、通话建起来就断。想收紧 TLS 版本可以开no-tlsv1_2把最低版本提到 TLS 1.3 / DTLS 1.2反过来老客户端如某些 Android 软电话只支持 DTLS 1.0 时不要动这个开关。别用加密端口当安全开关用。coturn 允许明文流量连 5349、加密流量连 3478端口不等于安全边界真正的边界是客户端自己的 ICE/DTLS 策略。一页速查清单coturn 默认四协议全开3478 收 UDPTCP5349 收 TLSDTLS自动识别流量类型。控制连接选 UDP 图延迟、选 TCP 图穿网、选 DTLS/TLS 图加密没有第四种理由。中继端点默认 UDPRFC 5766客户端 UDP 被封才轮到 TCP 中继RFC 6062。no-udp-relay与no-tcp-relay互斥同开即启动失败。5349 握手失败90% 是证书域名不匹配或中继端口段49152-65535没放行。加密的性能损耗没有官方定值上线前在目标硬件上压测。【免费下载链接】coturncoturn TURN server project项目地址: https://gitcode.com/GitHub_Trending/co/coturn创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考