java - 如何使用 Spring WebSockets 和 Undertow 接收大于 16kB 的 WebSocket 消息

Question

我在使用 Spring Boot、Spring WebSocket 和 Undertow 接收大型子协议(protocol)消息时遇到了一些问题。消息在 16kB 后被截断。在做了一些挖掘之后，我发现了以下配置属性，它似乎可以满足我的要求:

server.undertow.buffer-size=32768

在检查/configprops 执行器端点时，此配置属性似乎被正确拾取。不幸的是，这似乎对接收大于 16kB 的消息没有帮助。

我也从 Undertow 文档中偶然发现了这条不祥的线(重点是我的):

For servers the ideal size is generally 16k, as this is usually the maximum amount of data that can be written out via a write() operation (depending on the network setting of the operating system).

这证实了我一直遇到的情况，即设置 server.undertow.buffer-size 没有任何效果，因为它受到操作系统级别设置的限制。当我使用 Ubuntu Linux 时，我一直在摆弄 net.core.rmem_* 和 net.core.wmem_* 设置，但这些设置似乎没有任何效果要么。无法在 macOS 上重现此问题。

有谁知道如何配置 Undertow、Spring Boot 和/或 Spring WebSocket 来支持这些消息？

Answer 1

我直接回答了上面的问题。我在 Spring Boot 中建议的设置可以工作!我们遇到的问题是负载均衡器，在我们的例子中是 haproxy，在它前面正在切割 16kB 之后的消息。调整 haproxy 以允许更大的消息解决了这个问题。与此同时，我们调整了我们使用的协议(protocol)以提高效率，因此我们不再需要这些大消息，因此我们的 haproxy 解决方案未在生产环境中进行测试 (YMMV)。

因为开发人员都在 macOS 和 Windows 上工作，而且问题只发生在运行 Ubuntu 的验收和生产环境中，我们错误地认为这是原因。

经验教训(这些都是非常愚蠢和基本的，但我们还是犯了这些错误):

• 一定要验证您的所有假设!如果我们认为 Ubuntu 是问题所在，我们应该早点在测试中挑出 Ubuntu。例如，通过使用带有 Ubuntu 的虚拟机来验证我们在隔离区的假设。
• 确保您的开发环境与您的生产环境相匹配!在我们的开发环境中，我们没有运行 haproxy。作为“高级”开发人员，我们倾向于将负载均衡器和 Web 服务器放在一边，将其视为商品基础设施，但此示例再次表明这些“商品”可以非常直接地影响您的应用程序的运行。