我目前正在处理高延迟（100-400 毫秒）互联网链接的网络问题。我运行一个 Minecraft 网络，最近我将其移至一个单独的数据中心，以获得具有更好 CPU 和更多内存的服务器。该服务器的用户遍布世界各地。在切换之前，服务器位于蒙特利尔，欧洲用户的延迟约为 100-200 毫秒，澳大利亚用户的延迟约为 200-300 毫秒。切换后，服务器位于德国，北美用户的延迟约为 100-200 毫秒，南美和澳大利亚用户的延迟为 200-400 毫秒。总体而言，延迟非常相似，但谁的延迟很大，谁的延迟可以容忍，这一点各不相同（请注意，Minecraft 通常对延迟不太敏感，尤其是与大多数视频游戏相比）。根据 MTR 和 ping 工具的测量，也没有出现任何明显的数据包丢失。此外，两台服务器上的软件几乎相同。两台服务器都运行 Debian 10，我把所有不在 APT 存储库中的软件和配置都打包发送过去，同时通过 apt 重新安装完全相同的软件包。因此，软件配置应该基本相同。
然而，许多用户都遇到了连接问题。这种情况似乎只发生在美国东部时间下午 6:00 左右（± 几个小时）。连接问题具体表现为所有 TCP 连接的吞吐量极低。使用 SSH+SOCKS 代理，它需要分钟加载普通网页（Gmail）和游戏内，如果当前正在传输几 MB 的世界数据，即使是一条简单的聊天消息也经常需要几分钟才能发送。当任何数据通过 TCP 连接时，TCP 连接的有效延迟（例如，聊天消息发送所需的时间）会不合理地大幅增加。仅使用终端的普通 SSH 会话基本上没问题，如果没有太多事情发生，游戏也基本没问题，但是一旦任何大尺寸的内容通过 TCP 发送并且在上述时间内，吞吐量就会下降，TCP 上的延迟（但不是通过 ping）就会变得不合理，在最坏的情况下甚至会达到几分钟。当这个问题第一次出现时，有大量的数据包丢失（~25%），我认为这是罪魁祸首，但是，数据包丢失不再发生（根据 ping 等），但问题仍然存在。在我向新主机报告了有关数据包丢失的一般性情况后，数据包丢失（而不是问题症状）消失了，但在我能够按照他们在对该报告的回复中所要求的那样向他们提供更详细的 MTR 数据之前。主机给我的印象是他们没有改变任何东西，但谁知道呢。
因此，在这一点上，我怀疑服务器之间的相关差异在于旧主机（OVH）对其操作系统映像进行了某种调整（我知道是这种情况），而新主机（Hetnzer）则没有。
我怀疑这种调整与 TCP 窗口大小有关，但当我尝试操纵这些设置进行更改时，这些设置似乎并没有按照预期执行。具体来说，当我通过 sysctl 设置我在互联网上找到的各种设置时，选择的窗口大小net.ipv4.mem（或使用该选项时允许选择的最大值）似乎采用随机值，与我通过 sysctl 设置的值没有任何关系，而不是按照我预期的方式运行，其中最大值只是我通过 sysctl 设置的值。请注意，即使在客户端连接到它之前，它也会表现不佳，因此未能在客户端上进行相同的更改不是一个合理的解释。net.core.memiperf-wiperf -s
因此，我想知道两件事：
1）我如何修复我的服务器，并允许 TCP 连接中的延迟与链路上的实际延迟相似，即使在高峰时段和中等负载（几 mbps）下？
2)如何可靠且可预测地更改所有应用程序的 TCP 窗口大小？（或者，同样地，以看似随机的方式应用 sysctl 设置是怎么回事？/我缺少什么模式？）
答案1
互联网瞬息万变，没有服务保障，并且跨越许多第三方传输网络。仅查看服务器的 IP 堆栈无法解决问题，您需要完成根本原因调查。
调查用户可以使用哪种类型的连接。当带宽有限时，增加带宽有时会有所帮助。还要测量从用户到其他互联网目的地的延迟。考虑到 Google 对速度的痴迷，Google POP 的极高延迟可能是可疑的。
不断从客户端到服务器收集mtr和服务器到客户端。跨代表您用户群的多个 ISP 进行测试。查找丢失和非常高的延迟。确定哪个 ISP 拥有问题跳数。
对应用程序的流量进行数据包捕获。同样，客户端和服务器和服务器到客户端。使用 Wireshark 分析 TCP，查找问题。我认为没有完整的 Minecraft 解析器，但这对于 TCP/IP 性能来说并不是必需的。
在世界不同地区的不同提供商上启动更多服务器。测试这些服务器的性能特征，看看是服务器端更多还是客户端更多。如果这是可接受的性能所需的，请考虑永久在世界不同地区使用多台服务器（或代理？）。