我试图在发布实时流时诊断OBS 中报告的 RTMP 流比特率下降约 45 秒（至 0 Kbps）。我一直在使用 Apple 推荐的设置运行 tcpdump 来捕获数据包跟踪。

这是所有数据包的图表

我想尝试确定这种中断是由于我的台式计算机和云中的摄取节点之间的连接问题引起的，还是因为我的台式计算机本身在从相机。

这是飞行中的字节图：

您可以看到传输中的字节被打乱了。我假设，如果摄取节点以某种方式脱机，传输中的字节将保持一致，甚至随着它流式传输越来越多的数据而没有得到 ACK 时开始累积。

使用这篇博文，我通过查看以下内容对“Bad TCP”进行了分析：

(tcp.analysis.flags && !tcp.analysis.window_update)

并发现了这个：

这似乎表明 TCP 错误激增，因此这可能确实表明台式 PC 和云摄取节点之间存在连接问题。但是，当我查看 Wireshark 中的原始数据包捕获并按 过滤时(tcp.analysis.flags && !tcp.analysis.window_update)，我在此时间窗口中看到的只是 TCP 重传和 TCP Dup ACK。

我还查看了tcp.analysis.ack_rtt，假设如果存在连接问题，往返时间可能会增加。但是，它似乎遵循与传输中的字节相同的模式。

（对 x 轴的差异表示歉意；Wireshark 在制作这些图表时经常崩溃）。

根据这些图表，这是否表明问题出在我的桌面和云摄取节点之间的连接上，还是表明问题出在桌面计算机本身上？

我仍然拥有 600+ MB 的完整 pcap 文件，因此我可以根据需要轻松提取或生成其他图形。

更新

谢谢大家 - 我将在两端、桌面和摄取节点上使用 tcpdump 重新运行此测试，并更新更多详细信息。FWIW，现在看来，事件开始于 Ingest 节点将 TCP 窗口大小从 4096 削减到 1383 时。