☰

为什么数据停留在 Send-Q 中？TCP 会话冻结

tag-icon • tag-icon linux networking openvpn tcp irc
为什么数据停留在 Send-Q 中？TCP 会话冻结

问题

我运行一个 IRC 服务器，可供 20-50 位用户使用。我们有时会遇到消息无法及时到达或根本无法到达的问题。在捕获一些数据包后，我们确定消息位于服务器的“Send-Q”中。当消息未到达时，我会查看“netstat -ct”输出并看到类似以下内容：

Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 1756 ubuntu:ircd 10.8.1.7:63602 ESTABLISHED

有时，如果我等待几分钟，Send-Q 会变为 0，消息就会被发送，而其他时候客户端会超时。我的问题是，为什么它不直接发送消息？是什么原因导致它们在 Send-Q 中停留这么久？

sshd 也表现出类似的行为，我的 ssh 会话冻结，有时会恢复，有时会超时。

背景

不确定这里的基础设施是否与问题有关，所以它看起来是这样的：这些客户端在 Windows 7 上与 OpenVPN 连接。OpenVPN 服务器在 PFSense 上，IRC 服务器在连接到 PFSense 的本地 (NAT'd) LAN 上。我设置了防火墙规则，允许客户端与服务器上的 6667 通信。

正在调查...

延迟/丢失- 看起来还不错。虽然不是最好的链接，但我认为这对于 IRC 和 SSH 来说还不错。这是我的客户端到服务器的 ping，此时我的 IRC 和 SSH 正在间歇性挂起：

Ping statistics for 10.8.5.2:
    Packets: Sent = 4478, Received = 4460, Lost = 18 (0% loss)

近似往返时间（毫秒）：最小 = 17.2 毫秒，最大 = 273.4 毫秒，平均 = 32.3 毫秒

MSS/MTU 问题- MTU 似乎没问题。我的客户端上的 OpenVPN mtu-test 显示：

Thu Dec 03 12:41:21 2015 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1589,1589] remote->local=[1589,1589]

...这是我的手动测试：

> ping -f -l 1472 10.8.5.2

Pinging 10.8.5.2 with 1472 bytes of data:
Reply from 10.8.5.2: bytes=1472 time=23ms TTL=63

> ping -f -l 1473 10.8.5.2

Pinging 10.8.5.2 with 1473 bytes of data:
Packet needs to be fragmented but DF set.

带宽/吞吐量- 进行了一些 iperf 测试，以确保不存在吞吐量问题。同样，看起来还不错：

iperf -c 10.8.5.2
------------------------------------------------------------
Client connecting to 10.8.5.2, TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  3] local 10.8.0.23 port 18587 connected with 10.8.5.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  26.0 MBytes  21.8 Mbits/sec

谢谢，如果您能帮助我理解“Send-Q”或对这个问题有更具体的想法，我将不胜感激。如果我能在这里提供更多信息，请告诉我。

更新

发现我实际上有大量数据包丢失。从客户端->VPN 执行 ping 操作没有显示此问题，但从 VPN->客户端使用 fping 时非常明显。我注意到只有 Windows 客户端才会出现这种情况，重新安装最新的 OpenVPN 客户端似乎已经解决了丢失问题。这可能与通过磁盘映像安装的 OpenVPN TAP 适配器有关。手动为每台机器安装它似乎可以解决问题。

答案1

当应用程序将数据写入其本地内核 TCP 堆栈时，数据将进入发送队列。当另一方的 TCP 堆栈确认收到数据时，数据将从发送队列中删除。如果它们位于发送队列中，则意味着您的 IRC 服务器代码已将它们发送到您的内核，但连接的另一端尚未确认它们。这可能是因为它们尚未发送。这可能是由于服务器带宽限制或服务器性能限制造成的，但最常见的原因是另一方接收数据的速度不如服务器发送数据的速度快。

答案2

我遇到了类似的问题：

  • ssh 连接保持 ESTABLISHED
  • 终端反复冻结和解除冻结
    • 终端冻结时，数据包在 SEND-Q 中可见
    • 冷冻时间约2-4分钟
    • 解冻约30秒

原来我的路由器的固件已经过时了！

  • 修复固件更新问题

相关内容