amazon-web-services - AWS/ALB、http/2 和 GOAWAY

我们最近从 ELB 切换到 ELB2/ALB，偶尔我们的 go http/2 客户端会看到来自我们的应用程序负载均衡器的 GOAWAY 消息，我无法解释。目标组服务器仅支持 http/1.1，我们的负载均衡器应始终轮换至少一台健康的服务器。

在 ALB 中注册新实例时，我可以可靠地重现 GOAWAY。当目标处于“初始”状态时，ALB 返回 GOAWAY。此外，即使 ALB 以 GOAWAY 响应，该请求也会成功地将其发送到在目标组中注册的另一个实例。因此，给定实例 web0 和 web1，如果我取消注册 web0 并重新注册该目标，如果我在 web0 处于“初始”状态时发出请求，我可以可靠地重现 GOAWAY。但是我们的日志显示 web1 成功处理了请求。

我们的客户端是一个使用 http.DefaultClient 的 Go 程序。我可以使用 Go 1.7 和 1.8beta2 重现这种行为。

发生这种情况时，我们的客户端会记录有关 HTTP/2 响应的更多详细信息:

http2: server sent GOAWAY and closed the connection; LastStreamID=1, ErrCode=NO_ERROR, debug=""

我想更好地了解这里发生了什么。 go http2 包或我们的代码是否应该通过重试请求来自动处理 GOAWAY？我对 http2 不够熟悉，不知道是否需要 GOAWAY，这意味着我们的 Go 客户端不应将其作为错误条件处理，或者这是否表明 ALB 出现问题。

最佳答案

关于GOWAY
GOAWAY 框架包含三条信息，可以帮助您解决问题:

 +-+-------------------------------------------------------------+
 |R|                  Last-Stream-ID (31)                        |
 +-+-------------------------------------------------------------+
 |                      Error Code (32)                          |
 +---------------------------------------------------------------+
 |                  Additional Debug Data (*)                    |
 +---------------------------------------------------------------+

Last-stream-ID 是最后一个被正确处理的 ID。这可能有助于理解正在发生的事情:RFC 有一些关于如何实现优雅关闭的建议:首先使用 GOAWAY 和 Last-Stream-ID 发送 NO_ERROR 帧，让客户端知道关闭即将到来，然后在一段时间后，发送另一个 GOAWAY 帧，Last-Stream-ID 设置为实际最后处理的 ID。这样客户就知道传递了什么。这是相关的摘录，来自 RFC7540, 6.8 GOAWAY

错误代码和附加调试数据(字符串)将包含解释正在发生的事情的附加信息。 RFC 7540, 7. Error Codes 有可能的错误代码列表。然后，根据服务器实现，您可能有一个字符串来缩小错误的范围。 For example in H2O, the server sends found an upper-case letter in header name 当在标题名称中发现大写字母时。

这个特别的GOAWAY
http2: server sent GOAWAY and closed the connection; LastStreamID=1, ErrCode=NO_ERROR, debug=""
由于服务器正在发送 NO_ERROR ，您的客户端应该简单地尝试重新连接，而不是将消息视为错误。

至于为什么 ALB 发送 GOAWAYs ......我不确定，你能告诉我们更多细节吗？

关于amazon-web-services - AWS/ALB、http/2 和 GOAWAY，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/41592929/