我有一个 WebSocket 服务器端应用程序，它由 Nginx 反向代理运行，一切运行良好。WS 应用程序和 Nginx 一样在容器中运行，然后两者作为服务一起工作。
现在，我正在考虑 WS 应用程序的扩展规则，这些规则或多或少很简单。但我很好奇我是否还需要扩展服务的 Nginx 部分。连接将以相对较低的速率建立，因此扩展部分实际上是为了维护许多已连接的（即长寿命的）WS 连接。我知道我可以用负载测试自己测试其中的一些，但我想我也会在这里问：一旦 Nginx 反向代理到 WS 后端（通过升级和连接标头）并且套接字在客户端和我的 WS 应用程序之间连接，Nginx 是否会在持续的通信中发挥作用，或者 Nginx 现在是否“脱离了循环”？即，将来发送/接收的数据包（在任一方向）是否会被 Nginx 进程以任何方式读取或处理？
如果不是，那么我可以扩大 WS 容器，而不需要在 Nginx 容器中以“锁步”方式扩大。
谢谢您的见解！
答案1
我认为答案从根本上是，一旦 Nginx 代理（通过协议升级标头）和套接字建立，Nginx做维护套接字两端的打开文件描述符，但除此之外，它仅充当 NOP 过滤器（直通）。这允许仅使用适度的 Nginx 资源实现相当令人印象深刻的扩展，如演示所示这里尤其对于长连接来说，因为 CPU 负载应该可以忽略不计（因为新创建的套接字的数量很低），并且保持这些文件描述符打开的内存成本也相当低，并且可以随着套接字数量的变化而可预测地扩展。