coturn UDP/TCP/TLS/DTLS 传输协议选型三步定下你的 WebRTC TURN 服务器传输方式【免费下载链接】coturncoturn TURN server project项目地址: https://gitcode.com/GitHub_Trending/co/coturn先说结论再给判断依据最后落到配置和上线前检查。这篇文章面向刚接触 coturn 的新手和轻量运维把 coturn 的 UDP/TCP/TLS/DTLS 四种传输协议当作“四个选项”而不是“四份说明书”用延迟、可靠性、安全边界三个问题把 WebRTC TURN 服务器协议选择做完最后只改真正需要改的 coturn TLS 配置项。结论先行你的业务目标决定选哪条传输选型不是看“哪个协议更先进”而是看客户端要过什么样的网络、要达成什么效果。按下面四个目标对号入座目标是最低首包延迟、稳定的实时音视频客户端连接选 UDPrelay中转通道也用 UDP。coturn 默认就是 UDPsrc/apps/uclient/ 的客户端工具不带参数时也是按 UDP 发起的这条路径是最省事的一条。目标是“必须送达、顺序不乱”或客户端所在网络封了 UDP走 TCP。TCP 会替你把丢包和乱序收拾干净代价是延迟被排队和重传放大。流量经过公网、合规要求加密UDP 对应 DTLSTCP 对应 TLS。WebRTC 场景里 DTLS 是浏览器生态里最常见的安全组合浏览器媒体流本来就建立在 DTLS 之上让 TURN 控制通道也走 DTLS整条链路的安全模型是统一的。只想少开端口、少管配置保持 coturn 默认端口方案即可UDP/TCP 共用 3478TLS/DTLS 共用 5349后面配置一节细说。一个容易混的点TURN 的“客户端到服务器的连接传输”和“中转通道传输”是两回事可以分别选择比如客户端走 TCP/TLS、relay 走 TCP客户端走 UDP/DTLS、relay 走 UDP。大多数实时场景两者保持一致最省心。三个维度判断延迟、可靠性、安全边界延迟谁先到达、谁在等UDP 是“无连接”的大白话讲就是发数据前不需要先和对方“握一次手”包直接发出去。丢包后它也不会原地等重传所以延迟最平。TCP 要先建连接还会“堵车减速”它自带拥塞控制通俗说就是发现路上堵了会主动降速防止把路彻底堵死。这在公网很健康但对实时流意味着延迟抖动。TLS 建立在 TCP 之上DTLS 建立在 UDP 之上DTLS 保留了 UDP 的低延迟特性只是建会话时要多一轮握手TLS 则是 TCP 的所有特性再加上加密握手的开销。可靠性谁保证数据不丢、不乱TCP 承诺“按序、完整送达”适合把丢包当事故的场景。UDP 什么都不承诺——但这不是缺陷实时音视频的 RTP 层自己做了重传、前向纠错和抖动缓冲丢一帧旧数据不如丢得干脆。coturn 里 UDP relay 是 RFC 5766 的标准形态TCP relay 是 RFC 6062 的补充两者默认都开着。安全边界谁在保护什么明文 UDP/TCP认证信息和流量内容在链路上是明文内网测试可以公网不行。TLS 保护 TCP 连接DTLS 保护 UDP 连接两者都用证书做身份验证防止中间人偷看和篡改。加密的代价是 coturn 这台机器上的 CPU每个包都要加解密握手阶段更明显。具体掉多少性能官方文档没有给固定比例参考 docs/Performance.md 指向的性能调优说明并以你自己环境的压测为准。coturn 配置里真正要改的几项大部分场景下默认值就够用了。真正要动的是这几处可对照仓库里的示例配置 docker/coturn/turnserver.conf端口listening-port默认 3478UDP 和 TCP 共用与tls-listening-port默认 5349TLS 和 DTLS 共用。不改的话客户端按标准端口连即可。DTLS 要显式打开按 README.turnserver 的说明DTLS 监听器默认不启动需要用dtls选项开启老版本行为可能不同以你所用版本的 man 页为准。这是新手最常踩的坑以为 5349 端口开着就能收 DTLS。只保留需要的传输用no-udp、no-tcp、no-tls、no-dtls关闭不需要的监听器能缩小攻击面也省得运维多维护一套证书之外的暴露面。证书与加密套件cert和pkey指向 PEM 格式的证书和私钥cipher-list控制 TLS/DTLS 允许的加密套件默认 DEFAULT。证书怎么签、OpenSSL 版本要求见 docs/OpenSSL.md。最小可用的关键配置大概长这样其余保持默认listening-port3478 tls-listening-port5349 dtls cert/etc/ssl/certs/turn_server_cert.pem pkey/etc/ssl/private/turn_server_pkey.pem常见误判UDP 一定快TLS/DTLS 一定拖慢“UDP 一定比 TCP 快”——只在延迟意义上对。UDP 赢在延迟和没有重传等待在丢包严重的链路上UDP 的画面/声音质量可能崩得比 TCP 更快。实时业务选 UDP不是因为 UDP 不丢包而是上层的 RTP 机制已经接管了丢包处理。“开了 TLS/DTLS 性能一定大幅下降”——没有固定答案。加密开销取决于 CPU 型号、套件选择和并发数现代服务器跑 ECDHE AES-GCM 这类套件通常能扛住相当并发。别引用“固定损失百分比”上线前用自己的真实流量压一次看 CPU 余量再决定扩容。“浏览器只会走 UDPTCP/TLS 用不上”——恰恰相反。公司网、校园网、部分公共 Wi‑Fi 会封 UDP这时客户端只能退回 TCP/TLS 完成 TURN。把 TLS 监听留着当兜底成本很低体验差别很大。“端口号决定协议”——在 coturn 上不成立。配置注释里写得很清楚coturn 会自动识别流量类型明文 TCP/UDP 和 TLS/DTLS 会话在允许的情况下可以互相访问对方的端口。排查问题时别只盯端口要看出站日志里实际的传输类型。一页速查场景、推荐组合、注意事项场景客户端连接传输Relay 传输注意事项浏览器 WebRTC 实时音视频主流UDP/DTLSUDP确认dtls已开、证书有效客户端网络封 UDP / NAT 不友好TCP/TLSTCP延迟偏高属正常做好预期管理内网测试、临时联调UDP 明文UDP仅内网使用公网禁用控制类、非实时的可靠数据TCP/TLSTCP把“不丢”当硬需求时才值得判断顺序很简单先问“客户端能不能走 UDP”再问“内容要不要加密”最后才是性能微调。落地清单上线前检查这几项确认监听器真的在跑启动日志会明确提示 DTLS 未启动提示使用--dtls看到这条就回去补dtls配置。证书可用cert/pkey路径存在、私钥匹配、有效期覆盖上线周期DTLS WebRTC 安全场景下客户端会校验证书链。防火墙一次开全UDP/TCP 3478、TLS/DTLS 5349以及 relay 端口范围min-port/max-port默认 49152–65535的 UDP 放行。公网实例必须有认证至少启用长时凭证lt-cred-mech或 REST API 密钥认证不要裸奔。用客户端逐条验证仓库自带的 src/apps/uclient/ 可以分别测——默认 UDP、-t切 TCP、-S走安全连接TCP 对应 TLS、UDP 对应 DTLS四种组合都通再上线。压测留证据用真实业务流量测 coturn 性能影响重点看 CPU 和延迟分布结果留档调优方向参考 docs/Performance.md。变更有回滚点改完配置先小范围灰度观察日志里401、错误码和会话建立成功率再全量推开。做完这一轮你得到的不只是一个“选好的协议”而是一套能解释每个配置为什么这么写的决策记录——下次网络环境变了改起来也有依据。【免费下载链接】coturncoturn TURN server project项目地址: https://gitcode.com/GitHub_Trending/co/coturn创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考