Mediasoup项目中WebRtcServer关闭时TCP连接导致的崩溃问题分析

问题背景

在Mediasoup的WebRTC实现中，当存在活跃TCP连接时关闭WebRtcServer会导致工作进程崩溃。这个问题在3.14.4版本中被发现，影响macOS和Linux平台。核心表现为SIGSEGV段错误，发生在DTLS数据传输过程中。

技术细节

问题复现路径

1. 浏览器通过forceTcp参数建立WebRtcTransport连接
2. 初始连接会创建两个TCP连接（ICE候选对协商的正常行为）
3. 其中一个TCP连接被正常关闭
4. 当调用webRtcServer.close()时
   • 触发TcpServer析构
   • 尝试发送DTLS关闭警报(Close Alert)
   • 访问已释放的WebRtcTransport内存空间
   • 最终导致段错误

崩溃调用栈分析

从核心转储可以看出关键调用路径：

uv_try_write → TcpConnectionHandle::Write → 
WebRtcTransport::OnDtlsTransportSendData → 
DtlsTransport::SendDtlsData → 
SSL层处理 → 
DtlsTransport析构 → 
WebRtcTransport析构 → 
WebRtcServer析构

根本原因

问题的本质是对象生命周期管理问题。当WebRtcServer关闭时：

1. 它持有的所有Transport需要被销毁
2. Transport销毁时会触发DTLS关闭流程
3. 但此时底层TCP连接可能已经被释放
4. 导致在已释放的传输对象上尝试发送DTLS数据

解决方案

正确的处理方式应该是：

1. 在关闭WebRtcServer时
2. 首先优雅关闭所有活跃Transport
3. 确保所有DTLS关闭警报已发送完成
4. 再释放底层网络资源

技术启示

这个案例展示了在实时通信系统中几个重要原则：

1. 对象销毁顺序的重要性 - 必须先关闭高层协议再释放底层资源
2. DTLS安全关闭的必要性 - 必须正确发送关闭警报
3. 异步操作中的生命周期管理 - 网络IO和对象销毁的时序问题

影响范围

该问题不仅影响TCP连接，同样会影响UDP连接场景。这验证了问题本质在于传输层之上的DTLS协议处理逻辑，而非特定的传输协议实现。

总结

Mediasoup的这个崩溃案例展示了实时通信系统中复杂的资源管理挑战。正确处理协议栈各层的关闭顺序，确保安全关闭所有连接，是保证系统稳定性的关键。开发者在实现类似的多层网络协议栈时，需要特别注意对象生命周期管理和异步操作时序问题。