ZLMediaKit中WebRTC传输层MTU问题分析与解决方案

问题背景

在基于ZLMediaKit实现RTSP流转WebRTC的应用场景中，开发人员遇到了一个偶发的网络传输问题：WebRTC连接尚未开始播放时，系统会提示"mediakit::WebRtcSession on err: 255(message too long)"错误。这个问题在特定网络环境下（如通过加密隧道连接）更容易复现。

问题现象分析

通过日志分析，可以观察到以下关键现象：

1. DTLS握手过程正常完成，协商使用了SRTP_AEAD_AES_256_GCM加密套件
2. 在握手完成后，突然出现"message too long"错误
3. 错误代码255对应系统错误EMSGSIZE，表示消息长度超过了底层传输协议的限制

根本原因探究

经过深入分析，发现问题源于MTU（Maximum Transmission Unit）配置不当：

1. 默认配置中videoMtuSize设置为1400字节
2. 实际传输时，RTP报文增加了16字节的SRTP Auth Tag
3. 加上UDP/IP头部（约42字节），总包大小达到1458字节
4. Docker容器的默认MTU为1450字节，小于实际需要的1458字节
5. 系统尝试发送超过MTU限制的包，导致"message too long"错误

解决方案

针对这个问题，我们提供了两种解决方案：

方案一：调整系统MTU发现机制

通过修改系统参数关闭PMTU发现机制：

echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc

这种方法可以避免系统因MTU问题而报错，但可能掩盖潜在的网络配置问题。

方案二：优化ZLMediaKit配置

更推荐的解决方案是调整ZLMediaKit的配置参数：

1. 在配置文件中适当降低videoMtuSize值（如1300）
2. 确保计算后的总包大小（videoMtuSize + 58）小于网络MTU

技术原理深入

WebRTC传输层使用UDP作为基础协议，而UDP本身没有内置的分片机制。当应用层发送的数据包加上各种头部（UDP/IP头、DTLS头、SRTP头等）超过路径MTU时，就会触发EMSGSIZE错误。

在ZLMediaKit的实现中：

1. DTLS握手消息可能较大（如证书传输）
2. 媒体数据包需要额外空间存放加密认证信息
3. 容器网络环境可能有特殊的MTU限制

最佳实践建议

1. 在生产环境中，建议将videoMtuSize设置为1200-1300之间的值
2. 对于容器化部署，需要同时考虑宿主机和容器的MTU设置
3. 可以通过tcpdump等工具监控实际传输的包大小
4. 在复杂网络环境中，建议启用适当的MTU发现机制

总结

ZLMediaKit作为优秀的流媒体服务器，其WebRTC实现需要考虑各种网络环境的兼容性。通过合理配置MTU相关参数，可以有效避免"message too long"类错误的出现，提升系统的稳定性和兼容性。这个问题也提醒我们，在网络编程中，MTU的设置和计算是需要特别关注的细节。