哪些tcpdump度量显示服务器连接问题与客户端问题？

Question

我正在尝试诊断OBS中报告的RTMP流比特率在发布活动流时下降了45秒(降至0 Kbps)。我一直在使用苹果推荐的捕获数据包跟踪设置来运行tcpdump。

以下是所有数据包的图表

我想尝试确定这种中断是因为我的桌面计算机和云中的摄取节点之间的连接问题，还是因为我的桌面计算机本身在从摄像机捕获和编码视频流时出现了故障、缺陷或电源不足。

以下是飞行中的字节图：

你可以看到飞行中的字节被打乱了。我假设，如果摄取节点以某种方式脱机，那么在运行中的字节将是一致的，甚至会开始累积，因为它流了越来越多的数据，并且没有得到一个ACK。

使用这篇博客文章，我对“不好的TCP”进行了分析，方法是：

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

并发现：

这似乎表明TCP错误激增，因此这可能确实表明桌面PC和云吞食节点之间存在连接问题。然而，当我查看Wireshark中的原始数据包捕获和(tcp.analysis.flags && !tcp.analysis.window_update)的过滤器时，我在这个时间窗口中看到的只是TCP重传和TCP。

我还研究了tcp.analysis.ack_rtt，假设如果存在连接问题，往返时间可能会增加。然而，它似乎遵循与飞行中的字节相同的模式。

(对x轴上的差异表示歉意；Wireshark在绘制这些图时经常崩溃)。

基于这些图表，这是否表明问题在于我的桌面和云吞食节点之间的连接，或者这是否表明问题在桌面计算机本身上？

我仍然有完整的600+ MB pcap，因此我可以随时提取或生成必要的附加图。

更新

谢谢大家-我将重新运行这个测试与tcpdump在两端，桌面和吞食节点，并更新更多的细节。FWIW，现在看来，这个事件是从吞食的节点将TCP窗口大小从4096削减到1383开始的。

Answer 1

欢迎来到网络工程。根据您拥有的数据，很难说问题出在哪里。数据可能从客户端丢失到服务器，或者从服务器丢失到客户端，并且看起来是一样的。

您需要在每个端点(客户机和服务器)捕获数据，并比较数据包，以查看实际丢失了什么。例如，服务器可能向客户端发送数据，但在此过程中丢失了数据。或者，客户端接收到数据，但是返回ACK丢失了。你需要看到双方，才能确定。

Answer 2

一种建议是测量从桌面生成通信量的进程，其中一个症状是该进程在问题期间消耗了大量的CPU或内存，这可能表明管理通信的程序在实现过程中可能会出现问题。然而，正如另一位用户在另一篇文章中提到的那样，测量双方是一个好主意，如果可能的话也可以监视机器。