网络繁忙时的极高延迟、TCP、libevent

Question

在我们基于 C/S 的网络游戏项目中，我们使用 TCP 进行网络传输。我们包括Libevent，为每个连接使用一个bufferevent来自动处理网络I/O。

以前效果不错，最近卡顿问题浮出水面。当我做一些压力测试以使网络更繁忙时，延迟变得非常高，几秒钟或更长时间。服务器陷入混乱状态：

• 平均 CPU 使用率下降（0%-60%-0%-60% 重复，等待什么？）
• 净流量减少 (nethogs)
• 连接到服务器的客户端仍然存在（netstat 和 tcpdump）

看起来有些东西神奇地减慢了所有系统的速度，但与服务器的新连接及时响应退出。

当我将协议更改为 UDP 时，它在相同的情况下运行良好：没有明显的延迟，系统运行速度很快。净流量在 3M/S 左右。

项目正在 Intranet 上运行。我还测试了最大下载速度，接近 18M/S。

我研究了 Libevent 的部分头文件和文档，试图为所有连接设置速率限制。它做了一些改进，但即使我尝试了几种不同的配置，也没有完全解决问题。这是我的参数：read_rate 163840、read_burst 163840、write_rate 163840、write_burst 163840、tick_len 500ms。

感谢您的帮助！

Answer 1

TCP = 传输控制协议。它通过在延迟后重新传输未确认的数据包来响应数据包丢失。在反复丢失的情况下，它将以指数方式回退。看看这个试图打开没有响应的主机连接的网络捕获：

它发送初始的 SYN，然后在 1s 没有收到 ack 后再次尝试。在没有收到 ack 后，它会在 ~2s、~4s、~8s 后发送另一个，以此类推。所以你可以看到，面对重复的丢包，你会得到一些严重的延迟。

既然你说你故意给网络施加压力，而且CPU使用率不一致，一种可能的解释是TCP正在等待重传丢失的数据包。

查看正在发生的事情的最佳方法是获取实际传输内容的网络捕获。如果您的主机连接到单个交换机，您可以将感兴趣的端口“跨越”到可以进行捕获的另一台主机的端口。

如果您的交换机不具备此功能，或者您没有交换机的管理控制权，那么您将不得不从您的在线游戏中涉及的主机之一获取捕获。这样做的缺点是捕获可能会改变发生的情况，并且它看不到线上的实际情况。例如，您可能为您的接口启用了 TCP 分段卸载，在这种情况下，捕获将看到将被网络接口分解的大数据包。

我建议安装wireshark 来分析网络捕获（您也可以使用wireshark 进行实时捕获）。每当您使用网络系统时，我都建议您使用wireshark，这样您就可以了解网络上实际发生的情况。我建议您使用的第一个过滤器是tcp.analysis.flags，它将向您显示提示问题的数据包。

我还建议先关闭速率限制以尝试查看发生了什么（速率限制增加了另一个不发送数据包的原因，这可能会使诊断变得更加困难到底是怎么回事）。此外，500 毫秒可能会比较长tick_len，具体取决于您的游戏运行方式。如果您的突发配置允许速率在 100 毫秒内用完，那么您最终将等待 400 毫秒才能再次传输。 IO Graph 在这方面是 Wireshark 的一个非常有用的特性。它可以帮助您查看传输速率，尽管默认的滴答间隔和单位在这方面不是很有帮助。以下是速率限制为 200mbit/s 的突发流示例：

注意tick的间隔是1ms，单位是bits/tick，这使得图表顶部为1gb/s，即有问题的接口速度。