Google Compute Engine 上的 Websocket 连接正在关闭

Question

我在 Docker 容器中部署了一组应用程序，这些应用程序使用 websocket 进行通信。一个是后端，一个是前端。

我在实例组中都有两个 VM 实例，并通过负载均衡器提供服务，以便我可以将它们托管在 https 域中。

我遇到的问题是，在 Google Compute Engine 中，websocket 连接在 30 秒后关闭。

在本地运行时，websockets 不会超时。我已经搜索了问题并找到了这些可能的原因，但我找不到解决方案：

1. 如果您不传递“保持活动”消息以使其保持活动状态，Websocket 可能会自行超时。所以我从前端向后端传递一个保持活动状态，并让后端每 10 秒响应一次前端。

2. 根据GCE websocket support docs，需要在后端和前端之间进行某种类型的“升级”握手，以使 websocket 连接保持活动状态。但是according to MDN，“如果您使用 WebSocket API 或任何执行 WebSockets 的库打开新连接，那么大部分或所有这些都是为您完成的。”我正在使用该 API，实际上，当我检查标头时，我看到了这些字段：

1. GCE background service timeout docs 说：

对于外部 HTTP(S) 负载平衡器和内部 HTTP(S) 负载 平衡器，如果 HTTP 连接升级到 WebSocket，则 后端服务超时定义了一个最大的时间量 WebSocket 可以打开，不管是否空闲。

这似乎与GCE websocket support docs 的说法相冲突：

当负载均衡器识别出来自 HTTP(S) 客户端，然后是来自客户端的成功升级响应 后端实例，负载均衡器代理双向流量 当前连接的持续时间。

它是什么？我想在它们建立后保持套接字打开，但是如果初始化 websocket 连接的请求超过 30 秒，它们应该仍然超时。而且我也不想让其他标准 REST 调用永远阻塞。

我该怎么办？我是否必须将后端服务的超时设置为永远，并处理其他非 websocket REST 调用可能永远不会超时的事实？还是有更好的办法？

Answer 1

正如this GCP doc 中提到的“当负载均衡器识别出来自 HTTP(S) 客户端的 WebSocket 升级请求，然后是来自后端实例的成功升级响应时，负载均衡器会在当前连接期间代理双向流量. 如果后端实例没有返回成功的升级响应，负载均衡器将关闭连接。”

另外，websocket 超时是 LB 超时和 bakckend 超时的组合。我了解到您已经修改了后端超时。因此您也可以根据需要调整负载均衡器的超时时间，请记住默认值为 30 秒。

Answer 2

我们在 GCP 中遇到了一个类似的奇怪问题，但这甚至没有使用负载均衡器。我们有一个 WSS 服务器，我们可以很好地连接到它，它会随机停止提要，没有断开消息，只是停止向客户端发送 WSS 提要。可能会在 2-3 分钟后，也可能会在 15-20 分钟后，但通常不会超过断开连接之前的时间。

我们采用完全相同的代码、完全相同的构建（全部容器化）并将其放到 AWS 上，WSS 的问题就神奇地消失了。

毫无疑问，这个问题与 GCP 相关。