websocket 延迟峰值的原因是什么？

Question

我在单个 AWS 实例上运行服务器（使用 Tornado python），并且我遇到了 websocket 延迟的峰值。

分析从 websocket 消息发送到客户端的往返时间，然后客户端立即将 ack 消息发送回服务器，到服务器收到 ack 消息时平均产生 <.1 秒，但是我有时注意到它最多 3 秒。注意：在本地运行服务器时没有峰值。

这可能是什么原因或解决方法？我查看了 CPU 使用率，最多只能达到 40%。峰值与高流量（通常是 2 或 3 个客户端）无关，并且客户端的互联网似乎很好。我发现很难相信实例会以如此低的使用率超出容量。

Answer 1

峰值为 3 秒这一事实实际上比您想象的要多得多，即问题的性质。

是丢包。

正如您可能知道的那样，据说 TCP 提供“可靠”传输，保证发送的有效载荷按发送顺序被远端接收，因为 TCP 在传送有效载荷之前以正确的顺序重新组装事物。实现这一点的一种重要方式是自动重传被认为已丢失的数据包。

您永远不会猜测丢失数据包重传的默认初始计时器值。或者，也许，现在，你会的。

在许多（如果不是大多数）实现中，它是 3 秒，基于几年前建立的标准，当时当今传输链路的带宽和延迟是闻所未闻的，也许是无法想象的。

您不会在 websocket 服务器或客户端软件上看到重传的证据，因为 TCP 屏蔽了更高层，使其不知道它发生了……但是 3 秒是一个致命的赠品，这正是问题所在。

如果您使用数据包嗅探器观察网络流量，您将看到流量的重新传输，但这只能用于确认这是问题所在。

它可能是从服务器到客户端的丢失，或从客户端到服务器的丢失。后者通常更有可能，因为客户端的可用上行带宽通常较少……但数据包丢失的方向性并不能清楚地表明它发生的物理位置。除非您的客户端跟踪本地时间，以便可以关联请求和响应启动时间，否则您不知道延迟是在消息中还是在确认中。

在相对较轻的负载下，问题似乎不太可能出在您的实例或您这边的 AWS 网络中，而且您显然无法将嗅探器连接到 Internet 上的任意点来查明问题。

鉴于这样的情况下，可能会更容易-并且令人惊讶的是可行的-证明问题出在哪里不是，而不是它是。

一种技术是通过位于其他地方的不同设备（例如不同的 AWS 区域或其他云提供商）为流量创建一个故意绕行的路线。

首先，当然，您需要学习使用wireshark 发现这些重传。

然后，在不同的位置配置代理服务器，使用简单的 TCP 连接代理——比如 HAProxy，甚至是一个简单的工具，比如redir或socat。

这样的配置将侦听来自客户端的连接，并且当一个连接建立时，将创建一个到目的地（您的 websocket 服务器）的新 TCP 连接，但——重要的是——它们只在有效负载级别将两个连接联系在一起——而不是TCP 级别，当然没有更低的级别 - 所以重传只会在这个中间服务器和具有丢包问题的连接结束之间的线路上看到。另一端不会显示重传的证据——只是比预期晚到达的数据。

为了让这个测试有意义，代理需要远离服务器和客户端，并且没有有意义的公共基础设施——因此建议将它放在不同的 AWS 区域。同一区域中的不同可用区可能在某种程度上共享公共 Internet 基础设施，因此对于此目的而言，距离还不够远。

如果client <--> proxy <--> server在代理和服务器之间的路径上而不是在客户端和代理之间的路径上显示 TCP 重传，则问题确实很可能出在您的服务器、其硬件、网络或 Internet 连接中，您必须相应地继续。

相反（并且，我建议，更有可能）如果代理和服务器之间的路径没有重传，但客户端和代理之间的路径仍然很脏，则您已经消除了服务器及其基础设施作为问题的根源。如何继续取决于您，但此时您确实知道问题所在……不是。

另外两种可能：

双方仍然肮脏，这是最不可能的情况。故障排除规则 1 是首先假设您只有一个问题，而不是两个。

或者，当流量使用此设置时，双方突然且未执行地干净，这表明您的测试设置已绕过 Internet 的一个损坏部分。您已经“解决”了它，但不知道如何解决。我们也希望这不是结果，但考虑到全球互联网的变幻莫测，您的堆栈可能包含这样的组件，以及基于地理定位 DNS 的中间端点选择，这并非不可想象。这看起来像一个卷积，但确实有它的位置。

这种策略实际上是S3 传输加速功能背后逻辑的一部分。内容并没有更接近最终用户，但是来自浏览器的 TCP 连接在 AWS 边缘网络中的设备上终止，位于通常更靠近浏览器的位置，并且返回到存储桶的第二个 TCP 连接是建立，有效载荷连接在一起......而且，是的，它更快，更稳定，随着距离和连接质量的变化，变化的重要性变得更加显着。