是否listen（）積壓會影響已建立的TCP連接？

Question

創建一個將偵聽積壓設置為最小的TCP套接字作為速率限制新傳入連接的方式是否天真？ 有問題的服務器工作負載不會在任何時候期望有很多新連接，但是會花費大量時間來維護長期開放的持久連接。 似乎新的傳入連接不會影響已建立的連接，盡管我一直無法在任何文本中找到任何確定的答案。 失敗的新入站連接是否有可能在服務器及其接收的數據包上造成某種TCP流量擁塞，或者它們的丟棄速度足夠快，從而對任何緩沖區或網絡堆棧的其他部分都沒有影響？

具體來說，使用的平台是Linux，盡管在不同的操作系統中可能會以不同的方式進行處理，但我希望它們的行為大致相同。

編輯我的意思是“相同”是指積壓不會影響已建立的連接，盡管我確實知道Linux在Windows發送重置時會丟棄它們。

Answer 1

是否listen（）積壓會影響已建立的TCP連接？

它影響服務器尚未通過accept(),已建立連接accept(),僅是在某種意義上，它限制了可以存在的此類連接的數量。

創建一個將偵聽積壓設置為最小的TCP套接字作為速率限制新傳入連接的方式是否天真？

它所要做的就是不必要地使某些連接的客戶端失敗。 他們將無法獲得任何服務，直到您的服務器無論如何都可以使用它，並且一旦積壓隊列填滿，它們就會受到您的服務代碼的限制。 沒有特別的理由可以縮短隊列，從而產生任何有益的效果。 這個想法的另一個問題是，無法輕易確定實際的最小值，或者您是否成功將其設置為積壓隊列長度。

似乎新的傳入連接不會影響已建立的連接，盡管我一直無法在任何文本中找到任何確定的答案。

那是對的。 沒有理由為什么它應該影響他們：這就是為什么你不會找到它寫在任何地方，任何超過一個事實，即月亮的相位並不影響它或者更多。

失敗的新傳入連接是否有可能在服務器及其接收到的數據包上造成某種TCP流量擁塞

沒有。

還是它們掉落得足夠快而對網絡堆棧的任何緩沖區或其他部分沒有影響？

他們沒有被丟棄。 如果它們不適合積壓隊列，則根本不會創建它們。 因此，他們在服務器上的資源消耗為零。

具體來說，使用的平台是Linux，盡管在不同的操作系統中可能會以不同的方式進行處理，但我希望它們的行為大致相同。

他們沒有。 在Windows上，當積壓隊列已滿時，傳入連接會導致發出RST。 在其他平台上，它只是被忽略。

Answer 2

您所描述的是幾種類型的攻擊，例如泛洪，同步攻擊和其他導致拒絕服務的攻擊。

這個主題並不容易，因為必須在所有層（包括TCP）中實施保護。 例如，SYN攻擊，擺弄了序列號...。 到那時，所討論的數據包已經走了很長一段路，通過以太網層和ip層，最重要的是它正在占用資源。 因此，如果您的系統受到攻擊，則攻擊數據包就像好數據包一樣存在於數據流中。 您可以更快地檢測到數據包有故障並丟棄它的情況越好。 通常，受到攻擊的系統會變慢。 至少我曾經使用過的系統。

某些攻擊試圖利用漏洞來使系統永久處於故障狀態。 例如，TCP有一個接收隊列，如果數據包不斷亂序到達，它們將存儲在該接收隊列中。 如果丟失的數據包永遠不會到達，則該接收隊列可能會繼續增長。 如果沒有適當的防御，這將導致系統完全耗盡資源。

有專門的工具（例如，codenumicon）來檢查TCP堆棧實現的漏洞。 您可以假定已使用類似工具正確測試了Linux上的一個。

在應用程序層上也可能發生攻擊。 如果您有TCP服務器，並且它僅允許有限數量的會話。 惡意用戶只需建立所有連接，然后對其不執行任何操作，就可以簡單地建立所有連接。 因此，您還必須創建一些防御措施。 無論您是否設置此限制為非常低或很高，天氣都不會改變。 惡意用戶會嘗試采取任何措施使您的系統癱瘓。 無論如何，您都需要內置防御。 您可以簡單地使用telnet連接到Web服務器（HTTP）。 如果您不發送任何消息，則服務器的防御將發揮作用並關閉連接。

因此，將可能的連接數量降低到一個低值，並認為這本身就是一種保護形式，這確實是幼稚的。

失敗的新入站連接是否有可能在服務器及其接收的數據包上造成某種TCP流量擁塞，或者它們的丟棄速度足夠快，從而對任何緩沖區或網絡堆棧的其他部分都沒有影響？

他們正在使用您計算機的資源，這會使您的系統運行緩慢。

似乎新的傳入連接不會影響已建立的連接，盡管我一直無法在任何文本中找到任何確定的答案。

如果正常的用戶嘗試建立連接，即使他正在連續進行連接，則在失敗時重試。 影響將是最小的，幾乎沒有。 但是，泛濫連接嘗試的惡意用戶將對系統性能產生影響，因為系統必須花費時間來識別那些有缺陷的數據包並將其盡快丟棄。