linux – 为什么数据位于Send-Q？ TCP会话冻结

我为20-50个用户运行IRC服务器.我们有时会遇到没有及时到达或根本没有到达的消息的问题.在一些数据包捕获后,我们确定消息位于服务器的“Send-Q”中.当消息没有到达时,我将查看“netstat -ct”输出并看到如下内容：

Proto Recv-Q Send-Q本地地址外部地址状态
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 ms,最大值= 273.4 ms,平均值= 32.3 ms

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

谢谢,任何帮助理解“发送Q”或有关此问题的更具体的想法将不胜感激.如果我能在这里提供更多信息,请告诉我.

更新

发现我实际上有大量数据包丢失.来自客户端> VPN的ping没有显示这一点,但是当使用来自VPN->客户端的fping时非常明显.我注意到它只是Windows客户端,重新安装最新的OpenVPN客户端似乎已经修复了损失.它可能与通过磁盘映像安装的OpenVPN TAP适配器有关.每台机器手动安装似乎可以解决问题.