很多TIME_WAIT可以關閉服務器嗎？

What is the cost of many TIME_WAIT on the server side?

但我還是輸了。我們有兩臺應用程序服務器和一臺數據庫服務器（全部都是由雲服務提供的虛擬機）。今天數據庫服務器只是完全關閉，沒有任何警告。我們設法讓雲服務供應商在線恢復，並將我們的應用程序重新恢復到工作狀態。

當被問及這樣做的原因，雲服務供應商與一羣TCP統計（約1500線），看起來像這樣（屏蔽隱私）返回：

ipv4  2 tcp  6 98 TIME_WAIT src=x.x.x.x dst=y.y.y.y sport=z dport=5432 packets=p bytes=b src=y.y.y.y dst=x.x.x.x sport=5432 dport=z packets=p bytes=b [ASSURED] mark=0 secmark=0 use=2

的銷售商聲稱，服務器出現問題，並且由於連接數過多而自行關閉，如連接數量過多所證明的那樣。

然而，沒有跡象顯示收集統計數據的時間框架。如果他們被收集在長時間的時間範圍中，則統計數據不能用於聲稱有大量此類連接。

這樣的權利要求只能有效用於在特定時間點（未時間範圍），其中顯而易見的是，有大量的連接是在TIME_WAIT狀態在給定完成的快照統計時間點。 對嗎？

即使我們承認確有在快照時間點大量TIME_WAIT連接的可能性，這是有損於服務器和將它關閉服務器嘎然而止？這是怎麼發生的一個拒絕服務攻擊？

來源

2014-03-12 ADTC

我不是網絡人。我們的網絡人員說，供應商試圖通過聲稱我們超載服務器來推卸責任。統計數據顯示這是否發生？ – ADTC

如果您已經閱讀我的答案，請再閱讀一次。我添加了一個編輯，這是一個重要的警告。 –

沒有任何壓力來接受答案（我不再關心SO遊戲了）......只是不想讓你在沒有這些知識的情況下與你的供應商作鬥爭。 –

每個TIME_WAIT狀態都必須被跟蹤，很簡單。當數據包在TIME_WAIT連接中恢復時，這種狀態維護（認爲：每個連接使用的物理內存）允許TCP堆棧將傳入數據包與已關閉的連接相關聯。如果它不是SYN，則數據包將被忽略。如果它是一個SYN，那麼一些（大多數？）實現允許進行TIME_WAIT暗殺。

因此，簡單地說，是的，可能會由於同時關閉的連接數過多而導致系統過載，因爲TIME_WAIT會持續數分鐘。

關於這種攻擊的可能性，是的，這當然是可能的。但是，它可能必須是分佈式拒絕服務（DDOS）而不是普通的DOS。這是因爲要將連接置於TIME_WAIT中，連接必須完全打開（SYN + SYN/ACK + ACK），然後關閉（FIN + FIN/ACK + ACK），並且只有少數機器不會能夠以這種方式淹沒服務器。但考慮到打開TCP連接需要幾毫秒，而TIME_WAIT通常會持續幾分鐘，所以存在潛在的問題。

但是，這大部分會導致您的供應商的TCP實施。 1500聽起來不像TIME_WAIT狀態豐富，這似乎不相關。如果服務器由於太多併發連接而斷開連接，那麼您需要了解當時的活動負載，而不是TIME_WAIT。現代TCP實現（服務器端）甚至不會創建TCP連接，直到看到SYN/ACK（使用TCP SYN cookie來防止DOS）。所以，這裏有一些缺失的信息。

編輯：

雖然更多地考慮這一點，缺乏TCP層面的問題並不一定意味着你的供應商偏轉的指責。 1500個TCP連接非常低，但對於這個特定的數據庫，可能不是。一些RDMS只允許相對較少數量的連接（相對於TCP堆棧可支持的數量）。該值完全取決於RDMS，通常可以進行配置。

例如，我曾經超過了MySQL服務器允許的併發連接數量，並且服務器拒絕處理更多的數據（你可以稱之爲戛然而止），因爲我沒有正確地關閉與MySQL的連接。這可能是因爲你的數據庫完全能夠支持超過你投入的數據，但是你無法有效地使用連接。

來源

2014-03-12 13:02:00

很多TIME_WAIT可以關閉服務器嗎？

回答

相關問題