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

Question

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

server.undertow.buffer-size=32768

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

我还从 Undertow 文档中偶然发现了这条不祥的线（重点是我的）：

对于服务器来说，理想的大小通常是 16k，因为这通常是可以通过 write() 操作写出的最大数据量（取决于操作系统的网络设置） .

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

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

Answer 1

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

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

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

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