AWS/ALB、http/2 和 GOAWAY

Question

我们最近从 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 出现问题。

Answer 1

关于GOAWAY

GOAWAY 框架包含三个信息，可以帮助您解决问题：

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

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

试图正常关闭连接的服务器 应该发送带有最后一个流标识符的初始 GOAWAY 帧 设置为 2^31-1 和 NO_ERROR 代码。这向客户发出信号 关闭迫在眉睫，发起进一步的请求是 禁止。在为任何进行中的流创建留出时间之后 （至少一个往返时间），服务器可以发送另一个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...我不确定，您能否提供更多详细信息？

Answer 2

@frederik-deweerdt 的答案应该被接受为答案，特别是关于应用程序负载均衡器，这里是 AWS 论坛帖子中类似问题的答案，https://forums.aws.amazon.com/thread.jspa?messageID=771883&#771883

您的客户端收到的 HTTP/2 GOAWAY 响应是由 Application Load Balancer 正常关闭的连接。应用程序负载均衡器通常允许空闲连接持续到配置的空闲超时，默认为 60 秒。但是，有一些条件可以触发空闲连接的关闭。在 HTTP/1.1 连接上，允许完成未完成的请求，然后 TCP 连接被正常断开。在 HTTP/2 连接上，负载均衡器通过发送 HTTP/2 GOAWAY 来优雅地关闭这些连接。根据 RFC 7540 “GOAWAY 允许端点优雅地停止接受新流，同时仍完成对先前建立的流的处理”。客户端应通过完成正在进行的请求、关闭连接并在需要时重新连接来响应。 Application Load Balancer 将在访问日志中记录每个请求的 HTTP 状态，而不是连接状态关闭信号。

应检查因收到 HTTP/2 GOAWAY 而遇到错误的客户端，以确保它们完全符合 HTTP/2 RFC。

您可以在 RFC 7540 的第 6.8 节中阅读有关 HTTP/2 GOAWAY 方法的更多信息。 https://www.rfc-editor.org/rfc/rfc7540#section-6.8

如果您对弹性负载均衡器的这种行为或其他行为有任何其他问题，请告诉我们。