設置TIME_WAIT TCP

我們正試圖調整一個應用程序，該應用程序通過TCP接受消息，並且還使用TCP進行一些內部消息傳遞。在進行負載測試時，我們注意到響應時間顯着降低（然後完全停止），因爲系統會同時發出更多請求。在這段時間裏，我們看到了很多的TCP連接的TIME_WAIT狀態，並有人建議降低TIME_WAIT環境變量從它的默認60秒30設置TIME_WAIT TCP

從what I understand，該TIME_WAIT設置基本設置一個TCP資源可用時在連接關閉後再次連接到系統。

我不是一個「網絡人」，對這些事情知之甚少。我需要很多鏈接文章中的內容，但「稍微沉迷一點」。

我想我明白爲什麼TIME_WAIT值不能設置爲0，但可以安全地設置爲5嗎？什麼10？什麼決定了這個值的「安全」設置？
爲什麼這個值的默認值是60？我猜測，比我聰明的人有很好的理由選擇這個作爲合理的默認值。
我還應該知道重寫此值的潛在風險和好處嗎？

來源

2008-12-03 Vinnie

你也不想將它設置爲過高：http://stackoverflow.com/questions/1803566/what-is-the-cost-of-many-time-wait-on-the-server-端 – Pacerier 2016-01-23 04:04:45

TCP連接由元組（源IP，源端口，目標IP，目標端口）指定。

會話關閉後出現TIME_WAIT狀態的原因是因爲在向您（或來自您的方式）請求某種響應的途中，網絡中可能仍有活動數據包。如果您要重新創建相同的元組並且其中一個數據包出現了，它將被視爲您的連接的有效數據包（並且可能由於排序而導致錯誤）。

因此，TIME_WAIT時間通常設置爲數據包最大年齡的兩倍。該值是數據包在網絡丟棄之前允許達到的最大時間。

這樣可以保證，在允許使用同一個元組創建連接之前，屬於該元組以前化身的所有數據包將會死亡。

這通常會決定您應該使用的最小值。數據包的最大使用時間取決於網絡屬性，例如衛星的使用壽命高於LAN使用壽命，因爲數據包有更多的要求。

來源

2008-12-03 13:46:17 paxdiablo

如何確定「最大包時限」？這個集合是操作系統，網絡上的東西還是一些軟件設置？順便說一句，「生成」大多數這些連接的代碼是我們沒有源代碼的第三方平臺。非常感謝！ – Vinnie 2008-12-03 16:33:18

它的真實名稱是最大段壽命，即MSL。不確定你可以在Windows中更改它，或者即使你應該 - 它的意圖是根據網絡特徵設置。我認爲，Windows將它設置爲120秒。所有TCP參數位於HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters中。 – paxdiablo 2008-12-03 22:19:13

`不確定你可以在Windows中更改它，或者即使你應該 - 它的意思是根據網絡特徵設置。我認爲Windows將其設置爲120s。「您可以肯定地[在Linux中更改它]（http://serverfault.com/a/23529/14019），並且120 *方式*太長。我沒有經過測試證實，但它看起來像這麼長的延遲會導致不必要的大多數路由器上的P2P地獄。 – Synetech 2013-03-24 00:41:29

Pax對於TIME_WAIT的原因是正確的，爲什麼你應該小心降低默認設置。

更好的解決方案是改變用於套接字始發端的端口號。一旦你這樣做，你就不會真正關心時間等待個別套接字。

對於偵聽套接字，您可以使用SO_REUSEADDR來允許偵聽套接字綁定，儘管TIME_WAIT套接字位於附近。

來源

2008-12-03 14:05:28 Darron

+10

我將upvote任何以「Pax是正確的」開頭的答案。 :-) – paxdiablo 2008-12-04 03:29:47

通常，只有發出「主動關閉」的端點纔會進入TIME_WAIT狀態。所以，如果可能的話，讓你的客戶發出主動關閉，這會將TIME_WAIT留在客戶端而不在服務器上。

在這裏看到：http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html和 http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/的詳細信息（後來也解釋了爲什麼它並不總是可能的，因爲協議的設計，沒有考慮TIME_WAIT考慮）。

來源

2008-12-03 15:40:34

-1

TIME_WAIT可能不是罪魁禍首。

int listen(int sockfd, int backlog);

根據Unix網絡編程卷1，積壓被定義爲完成連接隊列和不完整連接隊列的總和。

比方說，積壓5.如果你有3個完成的連接（ESTABLISHED狀態），和2個不完整的連接（SYN_RCVD狀態），並且存在與另一個SYN連接請求。 TCP堆棧忽略了SYN數據包，知道它會在其他時間重新傳輸。這可能會導致退化。

至少這是我一直在閱讀。 ;）

來源

2008-12-03 18:04:41 yogman

在Windows中，你can change它through the registry：

; Set the TIME_WAIT delay to 30 seconds (0x1E) 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters] 
"TcpTimedWaitDelay"=dword:0000001E

來源

2013-03-24 00:47:03 Synetech

我一直負荷使用測試程序和20個線程測試服務器應用程序（在Linux上）。

在959000連接/關循環我有44000個失敗的連接和成千上萬的TIME_WAIT套接字。

我SO_LINGER設置爲0千鈞一髮之前並在隨後的測試程序的運行沒有連接故障，並在TIME_WAIT不到20座。

來源

2016-04-28 06:54:48

設置tcp_reuse比改變time_wait更有用，只要你有參數（內核3.2及以上版本，不幸的是不符合所有版本的RHEL和XenServer）。

掉落值，特別是對於VPN連接的用戶，能導致所述出站連接上代理隧道的恆定娛樂。使用低於默認Linux配置的默認Netscaler（XenServer）配置，Chrome有時必須重新創建代理隧道多達十次才能檢索一個網頁。不重試的應用程序（如Maven和Eclipse P2）只會失敗。

原動機爲參數（避免重複）通過TCP RFC指定所有TCP請求時間戳包含冗餘。

來源

2016-06-02 19:38:10

設置TIME_WAIT TCP

回答

相關問題