我在单个 AWS 实例上运行服务器（使用 tornado python），并且遇到了 websocket 延迟峰值。
分析从将 websocket 消息发送到客户端（然后客户端立即将 ack 消息发送回服务器）到服务器接收到 ack 消息的往返时间平均为 <.1>
这可能是什么原因或解决方法？我查看了 CPU 使用率，它最多只能达到 40%。峰值与大量流量（通常是 2 或 3 个客户端）无关，并且客户端的互联网似乎很好。我很难相信实例在如此低的使用率下会超出容量。
【问题讨论】：
标签： amazon-web-services websocket tornado
峰值为 3 秒这一事实实际上比您想象的更多地告诉您问题的性质。
这是丢包。
您可能知道，TCP 被称为提供“可靠”传输，保证发送的有效负载按照发送的顺序被远端接收，因为 TCP 在发送有效负载之前以正确的顺序重新组装事物.实现这一点的一种重要方法是自动重新传输被认为已丢失的数据包。
您永远猜不到重新传输丢失数据包的默认初始计时器值。或者，也许，现在，你会的。
根据几年前制定的标准，在许多（如果不是大多数）实施中，它是 3 秒，当时当今传输链路的带宽和延迟是闻所未闻的，也许是无法想象的。
您不会在 websocket 服务器或客户端软件上看到重新传输的证据，因为 TCP 会屏蔽更高层，使其不知道它发生了......但是 3 秒是一个死的赠品，这正是问题所在。
如果您使用数据包嗅探器观察网络流量，您会看到重新传输的流量，但这仅用于确认这是问题所在。
它可能是从服务器到客户端的丢失，或者从客户端到服务器的丢失。后者通常更有可能，因为客户端通常具有较少量的可用上行带宽......但是数据包丢失的方向性并不能清楚地表明它发生的物理位置。除非您的客户端跟踪本地时间，以便可以关联请求和响应启动时间，否则您不知道延迟是在消息中还是在确认中。
在相对较轻的负载下，问题似乎不太可能出在您的实例或您身边的 AWS 网络中，而且您显然无法将嗅探器连接到 Internet 上的任意点来查明问题。
鉴于这样的情况，证明问题不是的位置，而不是的位置可能更容易——而且令人惊讶地可行。
为此，一种技术是通过位于其他地方的不同设备（例如不同的 AWS 区域或其他云提供商）故意绕道。
首先，当然，您需要学习使用wireshark 发现这些重传。
然后，在不同的位置配置代理服务器，使用简单的 TCP 连接代理 - 例如 HAProxy，甚至是像 redir 或 socat 这样的简单工具。
这样的配置会监听来自客户端的连接，当一个连接建立后，会创建一个到目的地（你的 websocket 服务器）的新 TCP 连接，但是——重要的是——它们只在有效负载级别将两个连接绑定在一起-- 不是 TCP 级别，当然也没有更低的级别 -- 所以重传只会出现在这个中间服务器和连接结束之间的线路上，并存在丢包问题。另一端不会显示重传的证据——只是数据到达的时间比预期的晚。
为了使这个测试有意义，代理需要远离服务器和客户端，并且没有有意义的公共基础设施——因此建议将其放置在不同的 AWS 区域。同一区域中的不同可用区可能会在一定程度上共享公共互联网基础设施，因此距离远不足以实现此目的。
如果client <--> proxy <--> server 在代理和服务器之间的路径上显示 TCP 重新传输，而不是在客户端和代理之间，那么问题很可能出在您的服务器、它的硬件、网络或 Internet 连接上，您将遇到进行相应的操作。
相反（我建议，更有可能）如果代理和服务器之间的路径没有重传，但客户端和代理之间的路径仍然很脏，那么您已经消除了服务器及其基础架构作为问题的根源.如何继续取决于您，但此时您确实知道问题所在......不是。
另外两种可能性：
双方仍然脏，这是最不可能的情况。故障排除的规则 1 是最初假设您只有一个问题，而不是两个。
或者，当流量使用此设置时，双方突然且不经意地干净，这表明您的测试设置已绕过 Internet 的一个损坏部分。您已经“解决”了它，但不知道如何解决。我们也希望这不是结果，但考虑到全球互联网的变幻莫测，您的堆栈可能包含这样的组件并不是不可想象的，其中包含基于地理位置-DNS 的中间端点选择。这看起来像一个卷积，但确实有它的位置。
这种策略实际上是S3 transfer acceleration 功能背后逻辑的一部分。内容不再靠近最终用户，但是来自浏览器的 TCP 连接正在 AWS 边缘网络中的设备上终止，该位置通常更靠近浏览器，并且返回到存储桶的第二个 TCP 连接是建立，有效载荷连接在一起......而且，是的，它更快，更稳定，随着距离和连接质量的变化，变化的重要性变得更加明显。
【讨论】：