我已經將 Apache 設定為 Java 應用程式伺服器 (GlassFish) 的反向代理，並且我注意到即使在空閒的開發系統上也有大約 100 個處於 CLOSE_WAIT 狀態的連線：
sudo netstat -n -e -p -a -t | grep httpd | grep CLOSE_WAIT | wc -l
我正在使用以下 HTTP 代理設定：
ProxyPass /myapp http://localhost:8080/myapp ttl=20 max=1 smax=0
ProxyPassReverse /myapp http://localhost:8080/myapp
為什麼所有這些連接都懸而未決？我設定了“ttl=20 max=1 smax=0”，所以我認為所有連線都會在空閒系統上被清理。應用程式伺服器是否沒有盡自己的職責來清理連線？
答案1
這是一個mod_proxy 的已知問題，自 2011 年起。
ttl 需要比應用程式的 keepalive 短，以便 apache 始終第一個發送 FIN。
另一個困難是沒有定義連接實際關閉的時間點。
ttl - 非活動連接和關聯連接池條目的生存時間（以秒為單位）。一旦達到此限制，連線將不會再次使用；它將關閉於稍後一段時間。
答案2
我遇到了類似的問題，我正在尋找有關 Apache 的推理。我懷疑 Apache 的 prefork。
至於解決方案，我使用 Nginx 解決了 CLOSE_WAIT 問題。然而，TIME_WAIT 的數量（約 20,000）顯示 Java 應用程式處理連線的方式有問題。有了Nginx，伺服器和應用程式的效能就會好得多。
我希望有人能夠透過技術深度來改進這個答案。
答案3
這些 CLOSE_WAIT 連線已失效，只是伺服器將它們保留在 tcp 堆疊中，以防更多資料包到達它們。在「過去的美好時光」中，如果檔案描述符太大，Solaris 伺服器就會用完檔案描述符，系統就會崩潰。我們必須增加核心中允許的檔案描述符總數，並減少 CLOSE_WAIT 連接的清理間隔。
如今，檔案描述符的預設數量通常足夠大，可以忽略這一點。但可以減少cleanup配置，因此CLOSE_WAIT連線數會減少。
這些（Glassfish、Tomcat、JBoss 等）的本質是使用「大量」連接而不重複使用它們。在大多數情況下，您可以安全地忽略。