Mediamtx项目中WHEP源连接死锁问题分析与解决

问题背景

在Mediamtx流媒体服务器项目中，当使用WHEP(WebRTC HTTP Egress Protocol)作为源时，在某些网络状况不佳的情况下会出现连接死锁问题。具体表现为当WHEP源连接中断或不可达时，Mediamtx实例会陷入无法重新连接的状态，必须重启服务才能恢复。

问题现象

该问题在v1.5.1版本中被发现，主要出现在以下环境：

• Linux amd64 Docker环境
• macOS amd64 Docker环境
• macOS arm64标准环境

当配置了WHEP源的Mediamtx实例与远程WHEP源(另一个Mediamtx实例提供的RTSP流转换而来)连接出现问题时，系统会进入死锁状态，无法自动恢复连接。

技术分析

通过分析goroutine堆栈信息，可以清晰地看到死锁发生的调用链：

1. 主线程阻塞在ICE Agent的关闭操作上：

github.com/pion/ice/v2.(*Agent).Close
github.com/pion/webrtc/v3.(*ICEGatherer).Close
github.com/pion/webrtc/v3.(*ICETransport).Stop
github.com/pion/webrtc/v3.(*PeerConnection).Close
github.com/bluenviron/mediamtx/internal/protocols/webrtc.(*PeerConnection).Close
github.com/bluenviron/mediamtx/internal/protocols/webrtc.(*WHIPClient).Read
github.com/bluenviron/mediamtx/internal/staticsources/webrtc.(*Source).Run

2. 同时另一个goroutine阻塞在ICE候选收集的回调处理上：

github.com/bluenviron/mediamtx/internal/protocols/webrtc.(*PeerConnection).Start.func3
github.com/pion/webrtc/v3.(*ICEGatherer).Gather.func1
github.com/pion/ice/v2.(*Agent).onCandidate
github.com/pion/ice/v2.(*Agent).candidateRoutine

这种死锁情况与Pion WebRTC库中已知的一个问题类似，即在WebRTC回调中阻塞可能导致死锁。具体来说，当WHIPClient.Read方法在调用pc.Start()后发生任何失败(特别是PostOffer调用失败)，并在进入主循环前调用pc.Close()时，就会触发这种死锁。

解决方案

该问题已在Mediamtx v1.7.0版本中得到修复。修复的核心思路是：

1. 确保PeerConnection的关闭操作不会与ICE候选收集过程产生竞争条件
2. 优化WHIPClient.Read方法中的错误处理流程，避免在特定时序条件下触发死锁
3. 改进WebRTC连接状态管理，使连接中断后能够正常恢复

技术启示

这个案例为我们提供了几个重要的技术启示：

1. 在使用WebRTC协议栈时，需要特别注意异步操作和回调处理可能带来的线程安全问题
2. 连接管理逻辑中，关闭操作与建立操作的时序关系需要精心设计
3. 网络不稳定的环境会暴露出许多在稳定网络中难以发现的问题，因此在设计流媒体系统时需要充分考虑各种异常情况
4. 使用goroutine分析工具可以有效地定位复杂的并发问题

总结

Mediamtx项目中的这个WHEP源连接死锁问题展示了在复杂网络协议栈实现中可能遇到的典型并发问题。通过对问题的深入分析和修复，不仅解决了特定场景下的稳定性问题，也为项目后续的WebRTC相关功能开发积累了宝贵经验。开发者在使用类似技术栈时，应当特别注意异步操作和资源清理的时序问题，以避免类似的死锁情况发生。