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

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

server.undertow.buffer-size=32768

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

我还偶然发现了《海底航行》文档中的这句不祥的话（我的重点）：

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

这证实了我所经历的设置

server.undertow.buffer size

没有任何效果，因为它被操作系统级别设置所限制。在使用Ubuntu Linux时，我一直在摆弄

net.core.rmem.*

和

net.core.wmem.*

设置，但这些设置似乎也没有任何效果。不可能在macOS上重现此问题

---

有人知道如何配置牵引、弹簧引导和/或弹簧WebSocket来支持这些消息吗？我直接回答了上面的问题。我在Spring Boot中建议的设置确实有效！我们遇到的问题是，它前面的负载平衡器haproxy在16kB之后剪切消息。调整haproxy以允许更大的消息解决了该问题。与此同时，我们调整了我们使用的协议以提高效率，因此我们不再需要这些大消息，因此我们的haproxy解决方案没有在生产中进行测试（YMMV）

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

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

• 确保验证所有假设如果我们认为Ubuntu是问题所在，那么我们应该在前面的测试中选择Ubuntu。例如，使用一个带有Ubuntu的VM来验证我们在quarantaine中的假设
• 确保您的开发环境与生产环境匹配在我们的开发环境中，我们没有运行haproxy。作为“高级”开发人员，我们倾向于将负载平衡器和web服务器作为商品基础设施放在一边，但本例再次表明，这些“商品”可以非常直接地影响应用程序的工作