这个问题的核心是我们的应用程序使用 websocket 作为实时接口。我们正在新环境中测试我们的应用程序，但奇怪的是，我们注意到 TCP websocket 数据包的延迟随着 websocket 活动的增加而增加。
例如，如果在 1 分钟内没有任何其他活动的情况下发生一个 websocket 事件，则服务器会立即做出响应。但是，如果我们缓慢增加客户端活动，服务器响应的延迟会呈线性关系增加（活动越多，每个数据包到达客户端所需的时间就越长）。
对于那些想知道这与应用程序无关的人来说，因为我们的日志显示我们的服务器正在运行，并按预期在 100 毫秒内响应请求。一旦服务器处理请求并创建 TCP 数据包并将其发送到客户端（而不是相反），延迟就会开始。
建筑学这个新环境使用虚拟 IP 地址运行，并在负载均衡器上使用 keepalived 来平衡实例之间的流量。两个盒子位于平衡器后面，所有流量都通过它。我们的主机提供商管理平衡器，我们无法控制架构的这一部分。
理论这是否与新环境中缓冲数据包的某些东西有关？
感谢您的帮助。
答案1
缓冲听起来是个合理的理论。我会从您的应用服务器中捕获数据包，以确保您不会在 TCP 流中看到任何类似重新传输或其他可能异常的行为（即 TCP 窗口归零？）。 Wireshark使用客户端 IP 的捕获过滤器就可以实现这一点。
如果您验证数据包捕获看起来干净，那么要求您的提供商在其负载均衡器上运行数据包捕获以便您可以进行分析是一个合理的要求。
最后，您是否从多个位置和不同的机器进行了测试？也许缓冲位于客户端和提供商之间的某个地方，或者客户端发生了一些奇怪的事情（同时在客户端和服务器上运行数据包捕获也可以有所启发）。
答案2
这其实是一种预期行为。随着数据量的增加，传输窗口的大小也会增加，在某种程度上，这将增加发送的数据包的大小。数据包越大意味着效率越高（开销和确认时间越少），但也意味着延迟越大。这是在延迟和带宽差异很大的网络中，在保持可靠传输的同时保持任何吞吐量的权衡。
检查 PSH 标志以使 TCP 更快地刷新缓冲区。在某些情况下，这可能会产生微小的差异。但是，如果您希望大量小消息的延迟始终较低，则最好查看 UDP - 这意味着您必须自己考虑确保交付，但您可能会发现一致性更高。