tcp state TIME_WAIT & HTTP keep-alive的關係
HTTP 請求上的保持活動與 TIME_WAIT 中的 tcp 套接字之間有什麼關係 - 它們是否應該相關？
此外，系統和 Web 伺服器設置是否應該對齊，例如
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 如何保持連接處於活動狀態？$$ closed $$觸及這個問題，但沒有完全回答我。
TCP 是第 4 層，HTTP 是第 7 層。
在 HTTP 1.0 中，HTTP Keep-Alive 用於第 7 層，以使用
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