如何调试涉及 TCP 中继的慢速 TCP 连接

Posted 2023-03-23

【中文标题】如何调试涉及 TCP 中继的慢速 TCP 连接

【英文标题】：How to debug a slow TCP connection involving a TCP relay

【发布时间】：2021-11-24 19:37:33

【问题描述】：

我有一个需要在服务器和客户端之间传输数据的应用程序。两端都在公司防火墙后面，但它们需要安全通信。我写了一个 TCP 中继服务器，它可以在 2 个应用程序之间建立通信。

我的问题是 TCP 流的性能现在急剧下降，我想找出原因。我将服务器、客户端和中继的 TCP 接收和发送缓冲区大小设置为 10 MB。性能问题在较大的 RTT 中最为明显，因此我当前的 RTT 为 60 毫秒。进行初始握手后，中继在服务器和客户端之间通过管道传输原始 TCP 流，而无需额外的帧。

我检查了 TCP 窗口大小比例并且设置正确。尝试在wireshark中搜索tcp.analysis.flags查看接收窗口是否已满，但从未产生过此类警告。

我该怎么做才能弄清楚为什么性能会这样下降？提前谢谢！

以下是我使用 Wireshark 收集的一些数据：

上传对等体： [计算的窗口大小：10485504] [iRTT：0.062404000 秒] [飞行中的字节数：163200]（就在速度下降之前） [自上次 PSH 标志后发送的字节数：217600]（就在速度下降之前） 下载对等点： [计算的窗口大小：10485760] [iRTT：0.061190000 秒]

捕获显示速度下降时的点（黄色=下载对等，青色=上传对等）

上传peer的吞吐量图

正在下载peer的吞吐量图

【问题讨论】：

上传对等体吞吐量看起来像行为拥塞控制。在您的跟踪中，从蓝色开始读取，您有 4 个数据包标记为“TCP dup ack”，然后数据包标记为“TCP 快速重传”。我认为这表明拥塞控制即将启动。我不确定所有这些“tcp out-of-order”是什么意思，但它们可能是正常的“快速重传”操作。 RTT 越高，拥塞控制肯定会越差。

因此，您首先需要调查为什么您有重复的确认。如果存在真正的丢包，那么您所看到的就是预期的行为。如果不是这样，您应该检查您的继电器。如果丢弃是真实的，则中继机器上的网络堆栈可能会丢弃段。在 linux 上，您可以检查接口队列上的参数，即 qdisc 层的某个位置。否则，除非您可以在其间的交换机/路由器上配置队列大小，否则我认为您无能为力。这应该是这样的。

【参考方案1】：

原来这是由我用来模拟长途连接的 *** 连接引起的。一旦我能够与世界另一端的真人一起测试系统，问题就消失了，我得到了漂亮的波形而不是尖峰。