HTTP请求上的keep-alive和TIME_WAIT中的一个tcp套接字之间的关系是什么？
此外，如果系统和Web服务器设置是alignment的，例如server.max-keep-alive-idle = 60 ？ 根据如何减lessTIME_WAIT中的套接字数量？ 在Linux中，TIME_WAIT状态在60秒内硬编码（至less对于Linux的Ubuntu / Debain值）。
在lighttpd中，默认值server.max-keep-alive-idle = 5 ，对于高负载他们build议更低。 如果tcp套接字可用，在5秒后closures一个http请求似乎是一种浪费 – 当然假设net.ipv4.tcp_tw_reuse = 1的设置完成了它所说的话。
这个相关的问题 – tcp如何保持连接活着？ [closures]涉及到这个问题，但并没有完全回答我。
TCP是第4层，HTTP层7。
在HTTP 1.0中，在第7层使用HTTP Keep-Alive来使用Connection头来模拟持久连接。
在HTTP 1.1中，连接默认是持久的，然后依靠TCP来完成这项工作。 请求可以在相同的TCP连接中stream水线化，然后一方将在最后一个请求或响应头中设置Connection: close ，这样双方都知道没有更多的HTTP请求可以交换，连接将被closures。
通常在一个Web服务器的情况下， TIME_WAIT状态将在这个状态之后，一旦决定主动closures连接，它就会收到客户端的FIN数据包，并且在四路拆卸中发回最后一个ACK 。 在此之后，它等待2 * MSL ：这是确保连接closures的一种方法。 这就是内核编译的60s的起源。 通过这种方式，我们确信我们将不会收到一个新的连接，使用相同的4元组，从前一个连接中产生的序列无序。
你不想改变它 。
在另一端server.max-keep-alive-idle是超时之后，如果没有HTTP请求进入， ESTABLISHED连接将被视为空闲，并且将被Web服务器主动closures。 当你做出这个决定时，就像你现在所理解的那样，TCP拆除将会发生。
对于tcp_tw_recycle ，要非常小心，如果你的访问者来自广泛的NATnetworking，那么它可能会导致多个TCP连接，同一个4元组发生乱序时间戳，从而导致在服务器端悄悄丢弃客户端连接尝试。
所以最好的select是调整你在lighttpd中看到的参数。 在系统范围内，可以安全地降低FIN_WAIT2状态，并使用net.ipv4.tcp_fin_timeout和net.ipv4.tcp_max_tw_buckets提升处于TIME_WAIT状态的套接字的存储桶。