问题
我为 20-50 个用户运行 IRC 服务器。我们有时会遇到消息没有及时到达或根本没有到达的问题。在一些数据包捕获之后,我们确定消息位于服务器的“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 适配器有关。每台机器手动安装似乎可以解决问题。