WebRTC二进制数据通道消息偶发未接收问题排查求助

问题场景 #

• 测试架构：基于JUnit+Selenium启动多浏览器（本地或BrowserStack环境，支持无头/有头模式），每个浏览器通过HTML页面向同一服务器推送WebRTC流，所有发布者使用相同数据通道标签。Java测试通过Selenium调用页面JS函数收发消息，预期同标签下其他发布者能收到消息，多数场景表现正常。
• 异常现象：Chrome浏览器中偶发消息未被接收，且未向服务器上报TSN gap。

已完成的排查动作 #

• 服务器侧全链路验证：100%发送的消息已被服务器接收，且按预期分发给各接收端发布者，数据报已生成并交付至接收端网络层。
• TSN gap触发测试：主动在服务器分包时丢弃块制造TSN gap，Chrome能正常上报并触发补包，说明Chrome的TSN gap检测与补包逻辑本身正常。
• Chrome日志深度排查：开启详细日志（启动参数--enable-logging、--v=1、--log-file=<logFilePath>，无头模式追加--headless=new），未找到丢失消息的相关错误日志，但能看到正常消息的原始字节；结合text_pcap_packet_observer.cc独立日志，排除接收端JS处理函数的问题。
• 消息参数调整测试：将消息大小缩减至单块（当前为1024字节），尝试多种数据速率（低至2000字节/秒），问题仍复现。
• 正在推进的测试：开发仅基于TCP的测试用例，排除UDP丢包的影响因素。

核心疑问 #

1. 若为UDP丢包导致消息丢失，为何服务器未收到Chrome的TSN gap补包请求？
2. 若服务器已将数据块交付至接收端网络层，为何后续未被text_pcap_packet_observer.cc记录，也未交付至JS处理函数？

可尝试的排查方向 #

• 查看Chrome WebRTC内部统计：通过chrome://webrtc-internals/页面，重点关注数据通道的SCTP相关统计项（如unacknowledgedData、lostPackets、receivedPackets），对比丢失消息发生时的统计波动。
• 验证服务器端SCTP分片重组逻辑：确认服务器分发消息时，SCTP的TSN序列号是否连续，是否存在重组错误导致Chrome端无法识别完整消息（虽然主动丢包时补包正常，但可交叉验证极端场景下的重组逻辑）。
• 排查Selenium与Chrome的交互时机：确认测试中JS消息监听函数的绑定时机是否在数据通道完全建立之后，避免因监听不及时导致消息漏处理（虽然日志已排除JS问题，但可做二次确认）。
• 调整Chrome SCTP缓冲区参数：尝试修改Chrome的SCTP接收缓冲区大小（如通过启动参数--sctp-max-receive-buffer设置更大值），验证是否因缓冲区溢出导致消息被丢弃。
• 接收端网络抓包验证：在Chrome所在机器进行网络抓包，确认服务器发送的数据报是否真的到达网卡；若已到达但未被Chrome的SCTP栈处理，大概率是Chrome内部SCTP逻辑存在偶发bug。

内容的提问来源于stack exchange，提问作者Narfp