將tcp_max_tw_buckets設置爲非常小的值會產生什麼副作用？

Question

我知道這是很正常的設置tcp_max_tw_buckets到一個相對較小的數字，如30000或50000，以避免主機有很多時間等待狀態連接和應用程序無法打開新的情況。這是提到很多東西。諸如這樣的問題：How to reduce number of sockets in TIME_WAIT?

像以前一樣，我知道時間的等待是爲了避免TCP數據包out of order的狀態，並且它可以使用some other approach來應對它更好。如果你把它設置爲少數可能會出錯的東西。

我覺得我在想要將tcp_max_tw_buckets設置爲一個小數字的地方，並且不知道具體的場景，我會避免它。

所以我的問題是什麼是將tcp_max_tw_buckets設置爲一個非常小的值的副作用，我可以使用實驗室環境設置一個特定的方案，少量的tcp_max_tw_buckets會導致麻煩？

Answer 1

正如您在this Kernel source中看到的那樣，該選項可防止套接字的正常終止。就套接字狀態而言，您已將此連接的等待時間縮短爲零。

接下來會發生什麼？首先，您會在服務器上看到錯誤消息。其餘的則是客戶後續連接的競爭條件。 rfc 1337的第2部分涵蓋了您可能會看到的內容。總之，一些連接可能顯示以下症狀。

1. 數據流損壞（因爲套接字接受舊的傳輸）。
2. 無限ACK環路（由於舊的重複ACK被拾取）。
3. 丟棄的連接（由於舊數據在SYN-SENT狀態中出現）。

但是，證明這可能很難。正如在相同的RFC中指出的：

已經在模擬環境中運行的股票Sun OS 4.1.1 TCP上演示了三種危害H1，H2和H3，該模擬環境大量複製了段。這種環境比大多數真正的TCP必須應對的危險要嚴重得多，並且仔細調整了條件以便爲失敗創造必要的條件。

Answer 2

您的問題的真正答案是避免TIME_WAIT狀態的正確方法是接收第一次關閉的結束。

在服務器的情況下，這意味着在你發送了響應之後，你應該循環等待另一個請求在同一個套接字上，並且當然有一個讀取超時，所以它通常是客戶端，它會先關閉。這樣TIME_WAIT狀態就發生在客戶端，因爲客戶端沒有很多出站連接，所以在這種狀態下它是相當無害的。