ala*_*and 3 http tcp keepalive time-wait
HTTP 请求上的 keep-alive 和 TIME_WAIT 中的 tcp 套接字之间有什么关系 - 它们应该相关吗？
此外，系统和网络服务器设置是否应该保持一致，例如server.max-keep-alive-idle = 60？根据如何减少 TIME_WAIT 中的套接字数量？在 Linux 中，TIME_WAIT 状态被硬编码为 60 秒（至少对于 Linux 的 Ubuntu/Debain 值）。
在 lighttpd 中是默认值server.max-keep-alive-idle = 5，他们建议在高负载时甚至更低。如果 tcp 套接字可用，则在 5 秒后关闭 http 请求似乎是一种浪费——当然，假设设置按照net.ipv4.tcp_tw_reuse = 1它在锡上所说的进行。
这个相关的问题 - tcp 如何保持连接有效？[关闭]触及了这个问题，但没有为我完全回答。
TCP 是第 4 层，HTTP 是第 7 层。
在 HTTP 1.0 中，第 7 层使用 HTTP Keep-Alive 来模拟使用Connection标头的持久连接。
在 HTTP 1.1 中，默认情况下假设连接是持久的，然后只依赖 TCP 来完成这项工作。请求可以在同一个 TCP 连接中流水线化，然后一方会Connection: close在最后一个请求或响应头中设置，这样双方都知道不能再交换 HTTP 请求，然后连接将关闭。
通常在Web服务器的情况下，TIME_WAIT状态将是之后的状态，一旦决定主动关闭连接，它收到客户端的FIN数据包并ACK在四路拆卸中将最后一个发送回来。在此之后，它等待2 * MSL：这是确保连接关闭的一种方式。这就是60s内核中编译的来源。通过这种方式，我们确信我们不会在新连接中使用相同的 4 元组接收来自前一个连接的乱序数据包。
你不想改变它。
另一方面server.max-keep-alive-idle是超时，ESTABLISHED如果没有 HTTP 请求进入，连接将被认为是空闲的，并将被 Web 服务器主动关闭。当做出这个决定时，正如您现在所理解的，TCP 拆除将发生。
非常小心tcp_tw_recycle，如果您的访问者来自一个广泛的 NATed 网络后面，那么它可能会导致多个 TCP 连接与相同的 4 元组发生，并且时间戳乱序，导致在服务器端静默丢弃客户端连接尝试。
所以最好的选择是调整你在lighttpd中看到的参数。全系统，你可以放心地降低FIN_WAIT2状态，提高水桶在插座TIME_WAIT状态net.ipv4.tcp_fin_timeout和net.ipv4.tcp_max_tw_buckets。