Go Transport 中的 keep-alive TTL 从不关闭连接答案

【问题标题】：keep-alive TTL in Go Transport never closes connectionsGo Transport 中的 keep-alive TTL 从不关闭连接
【发布时间】：2019-05-11 08:45:30
【问题描述】：

我有一个托管在 AWS 上的应用程序，它在生产环境中运行，它创建了一个 http 服务器，如下面的示例代码中所述。 Go 库中的默认超时时间为 180 秒。因此，理想情况下，未使用的连接应在 180 秒后关闭。

myMux := http.NewServeMux()
myMux.Handle("/SOME_PATH", appHandler{myHandler})
err = http.ListenAndServe(viper.GetString("handler.port"), myMux)

问题是当应用程序的流量增加时，连接数会增加。但是当流量下降时，连接数保持不变。

我正在使用go version go1.10 linux/amd64，此应用程序位于 Amazon ALB 后面。

已编辑的问题：

正如您所见，当应用程序落后于 ALB 时，连接减少的速度非常慢。那么，可能是什么问题

【问题讨论】：

在 ALB 之后，它们可能不会在 180 秒内处于空闲保持活动状态，它们可能会处于活动状态，例如健康检查。尝试在没有负载均衡器的情况下使用直接指向服务的负载生成器运行它，看看它做了什么。
我试过没有 ALB 连接在 time_wait 状态后关闭，但与 ALB 一样，它没有表现出相同的行为
听起来不错，原因在我原来的评论中已经说明。没什么错，这就是负载平衡器的工作方式。
@Adrian 但是应该只有很少的连接用于健康检查，而不是成千上万的连接，对吧？正如我在图表中提到的，连接需要很长时间才能恢复正常
不仅用于健康检查，还用于实际流量。负载平衡器将保持与后备服务器的保持连接以路由流量，它保持打开的连接数将基于流量。

标签： go tcp httpserver keep-alive aws-alb

【解决方案1】：

当您设置服务器时，您应该添加适合您的应用程序的超时，例如

srv := &http.Server{
    ReadTimeout:  5 * time.Second,
    WriteTimeout: 20 * time.Second,
    IdleTimeout:  180 * time.Second,
    Handler:      myMux,
}

这样，空闲连接应该被关闭。如果是上游负载均衡器在这么多连接上发送运行状况检查，则解决方案会有所不同。

【讨论】：