我目前正在與一些蹩腳的（自訂）伺服器軟體作鬥爭，該軟體無法正確接受其連接（由 PHP 程式設計師用 Java 編寫，他以前從未接觸過套接字，更不用說線程了）。我的猜測是，在客戶端線程中正確接受套接字之前，線程正在死亡。我不能確定，實際上這並不重要，因為該軟體目前已重新實現；舊版本必須保持運行直到新版本上線，盡可能可靠，但無需花費任何時間和金錢來調試舊程式碼庫。
此錯誤在以下 netstat 輸出中顯現出來；有些連結永遠不會從核心轉移到使用空間（這就是我的解釋方式，歡迎更好的解釋）：
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp6 228 0 192.0.2.105:1988 46.23.248.10:7925 ESTABLISHED -
tcp6 0 0 192.0.2.105:1988 221.130.33.37:9826 ESTABLISHED 14741/java
tcp6 0 0 192.0.2.105:1988 46.23.248.2:5867 ESTABLISHED 14741/java
tcp6 2677 0 192.0.2.105:1988 221.130.33.37:15688 ESTABLISHED -
tcp6 3375 0 192.0.2.105:1988 221.130.33.36:3045 ESTABLISHED -
tcp6 14742 0 192.0.2.105:1988 46.23.248.17:4679 ESTABLISHED -
tcp6 774 0 192.0.2.105:1988 212.9.19.73:36064 ESTABLISHED -
tcp6 92 0 192.0.2.105:1988 46.23.248.19:7164 ESTABLISHED -
tcp6 0 0 192.0.2.105:1988 46.23.248.21:6322 ESTABLISHED 14741/java
tcp6 0 0 192.0.2.105:1988 221.130.39.216:13937 ESTABLISHED 14741/java
tcp6 3051 0 192.0.2.105:1988 211.139.145.104:31239 ESTABLISHED -
tcp6 246 0 192.0.2.105:1988 46.23.248.10:5458 ESTABLISHED -
tcp6 618 0 192.0.2.105:1988 212.9.19.73:20209 ESTABLISHED -
tcp6 1041 0 192.0.2.105:1988 46.23.248.18:7424 ESTABLISHED -
tcp6 0 0 192.0.2.105:1988 46.23.248.10:5065 ESTABLISHED 14741/java
當這種情況發生並且客戶重新連接時，他們往往會工作。但它們不會自行重新連接，直到遇到相當長的超時。由於當前版本中的自訂全雙工協議不會確認客戶端發送的任何數據，並且客戶端也不會期望來自伺服器的任何定期傳入請求，因此從客戶端愉快地發送其數據到內核的回應可能需要幾天的時間。在伺服器（核心）端，應該能夠檢測到過時的套接字，因為客戶端定期發送資料。
所以，假設我對這個問題的解釋是正確的，我想知道是否有一個我可以調整的核心參數，如果用戶空間沒有及時讀取它們，那麼核心會透過 RST 刪除/關閉 TCP 連接方式。
也歡迎對這裡發生的事情做更好的解釋。
答案1
你可以嘗試調優TCP保活更短的值。預設情況下，在保持連線生效之前，連線可以空閒兩個小時。
確切地說，您應該使用什麼值實際上取決於您的應用程式的功能以及用戶的期望或他們如何與之互動。
答案2
我想答案是否定的。
透過更換有問題的軟體解決了這個問題，但仍然歡迎提出想法。