TCP 半連接隊列和全連接隊列滿了會發生什麼?又該如何應對?_網頁設計

2{icon} {views}

※推薦評價好的iphone維修中心

擁有專業的維修技術團隊,同時聘請資深iphone手機維修專家,現場說明手機問題,快速修理,沒修好不收錢

前言

網上許多博客針對增大 TCP 半連接隊列和全連接隊列的方式如下:

  • 增大 TCP 半連接隊列的方式是增大 /proc/sys/net/ipv4/tcp_max_syn_backlog;
  • 增大 TCP 全連接隊列的方式是增大 listen() 函數中的 backlog;

這裏先跟大家說下,上面的方式都是不準確的。

“你怎麼知道不準確?”

很簡單呀,因為我做了實驗和看了 TCP 協議棧的內核源碼,發現要增大這兩個隊列長度,不是簡簡單單增大某一個參數就可以的。

接下來,就會以實戰 + 源碼分析,帶大家解密 TCP 半連接隊列和全連接隊列。

“源碼分析,那不是勸退嗎?我們搞 Java 的看不懂呀”

放心,本文的源碼分析不會涉及很深的知識,因為都被我刪減了,你只需要會條件判斷語句 if、左移右移操作符、加減法等基本語法,就可以看懂。

另外,不僅有源碼分析,還會介紹 Linux 排查半連接隊列和全連接隊列的命令。

“哦?似乎很有看頭,那我姑且看一下吧!”

行,沒有被勸退的小夥伴,值得鼓勵,下面這圖是本文的提綱:

本文提綱

正文

什麼是 TCP 半連接隊列和全連接隊列?

在 TCP 三次握手的時候,Linux 內核會維護兩個隊列,分別是:

  • 半連接隊列,也稱 SYN 隊列;
  • 全連接隊列,也稱 accepet 隊列;

服務端收到客戶端發起的 SYN 請求后,內核會把該連接存儲到半連接隊列,並向客戶端響應 SYN+ACK,接着客戶端會返回 ACK,服務端收到第三次握手的 ACK 后,內核會把連接從半連接隊列移除,然後創建新的完全的連接,並將其添加到 accept 隊列,等待進程調用 accept 函數時把連接取出來。

半連接隊列與全連接隊列

不管是半連接隊列還是全連接隊列,都有最大長度限制,超過限制時,內核會直接丟棄,或返回 RST 包。

實戰 – TCP 全連接隊列溢出

如何知道應用程序的 TCP 全連接隊列大小?

在服務端可以使用 ss 命令,來查看 TCP 全連接隊列的情況:

但需要注意的是 ss 命令獲取的 Recv-Q/Send-Q 在「LISTEN 狀態」和「非 LISTEN 狀態」所表達的含義是不同的。從下面的內核代碼可以看出區別:

在「LISTEN 狀態」時,Recv-Q/Send-Q 表示的含義如下:

  • Recv-Q:當前全連接隊列的大小,也就是當前已完成三次握手並等待服務端 accept() 的 TCP 連接;
  • Send-Q:當前全連接最大隊列長度,上面的輸出結果說明監聽 8088 端口的 TCP 服務,最大全連接長度為 128;

在「非 LISTEN 狀態」時,Recv-Q/Send-Q 表示的含義如下:

  • Recv-Q:已收到但未被應用進程讀取的字節數;
  • Send-Q:已發送但未收到確認的字節數;

如何模擬 TCP 全連接隊列溢出的場景?

測試環境

實驗環境:

  • 客戶端和服務端都是 CentOs 6.5 ,Linux 內核版本 2.6.32
  • 服務端 IP 192.168.3.200,客戶端 IP 192.168.3.100
  • 服務端是 Nginx 服務,端口為 8088

這裏先介紹下 wrk 工具,它是一款簡單的 HTTP 壓測工具,它能夠在單機多核 CPU 的條件下,使用系統自帶的高性能 I/O 機制,通過多線程和事件模式,對目標機器產生大量的負載。

本次模擬實驗就使用 wrk 工具來壓力測試服務端,發起大量的請求,一起看看服務端 TCP 全連接隊列滿了會發生什麼?有什麼觀察指標?

客戶端執行 wrk 命令對服務端發起壓力測試,併發 3 萬個連接:

在服務端可以使用 ss 命令,來查看當前 TCP 全連接隊列的情況:

其間共執行了兩次 ss 命令,從上面的輸出結果,可以發現當前 TCP 全連接隊列上升到了 129 大小,超過了最大 TCP 全連接隊列。

當超過了 TCP 最大全連接隊列,服務端則會丟掉後續進來的 TCP 連接,丟掉的 TCP 連接的個數會被統計起來,我們可以使用 netstat -s 命令來查看:

上面看到的 41150 times ,表示全連接隊列溢出的次數,注意這個是累計值。可以隔幾秒鐘執行下,如果這個数字一直在增加的話肯定全連接隊列偶爾滿了。

從上面的模擬結果,可以得知,當服務端併發處理大量請求時,如果 TCP 全連接隊列過小,就容易溢出。發生 TCP 全連接隊溢出的時候,後續的請求就會被丟棄,這樣就會出現服務端請求數量上不去的現象。

全連接隊列溢出

Linux 有個參數可以指定當 TCP 全連接隊列滿了會使用什麼策略來回應客戶端。

實際上,丟棄連接只是 Linux 的默認行為,我們還可以選擇向客戶端發送 RST 複位報文,告訴客戶端連接已經建立失敗。

tcp_abort_on_overflow 共有兩個值分別是 0 和 1,其分別表示:

  • 0 :如果全連接隊列滿了,那麼 server 扔掉 client 發過來的 ack ;
  • 1 :如果全連接隊列滿了,server 發送一個 reset 包給 client,表示廢掉這個握手過程和這個連接;

如果要想知道客戶端連接不上服務端,是不是服務端 TCP 全連接隊列滿的原因,那麼可以把 tcp_abort_on_overflow 設置為 1,這時如果在客戶端異常中可以看到很多 connection reset by peer 的錯誤,那麼就可以證明是由於服務端 TCP 全連接隊列溢出的問題。

通常情況下,應當把 tcp_abort_on_overflow 設置為 0,因為這樣更有利於應對突發流量。

舉個例子,當 TCP 全連接隊列滿導致服務器丟掉了 ACK,與此同時,客戶端的連接狀態卻是 ESTABLISHED,進程就在建立好的連接上發送請求。只要服務器沒有為請求回復 ACK,請求就會被多次重發。如果服務器上的進程只是短暫的繁忙造成 accept 隊列滿,那麼當 TCP 全連接隊列有空位時,再次接收到的請求報文由於含有 ACK,仍然會觸發服務器端成功建立連接。

所以,tcp_abort_on_overflow 設為 0 可以提高連接建立的成功率,只有你非常肯定 TCP 全連接隊列會長期溢出時,才能設置為 1 以儘快通知客戶端。

如何增大 TCP 全連接隊列呢?

是的,當發現 TCP 全連接隊列發生溢出的時候,我們就需要增大該隊列的大小,以便可以應對客戶端大量的請求。

TCP 全連接隊列足最大值取決於 somaxconn 和 backlog 之間的最小值,也就是 min(somaxconn, backlog)。從下面的 Linux 內核代碼可以得知:

  • somaxconn 是 Linux 內核的參數,默認值是 128,可以通過 /proc/sys/net/core/somaxconn 來設置其值;
  • backloglisten(int sockfd, int backlog) 函數中的 backlog 大小,Nginx 默認值是 511,可以通過修改配置文件設置其長度;

前面模擬測試中,我的測試環境:

  • somaxconn 是默認值 128;
  • Nginx 的 backlog 是默認值 511

所以測試環境的 TCP 全連接隊列最大值為 min(128, 511),也就是 128,可以執行 ss 命令查看:

現在我們重新壓測,把 TCP 全連接隊列搞大,把 somaxconn 設置成 5000:

接着把 Nginx 的 backlog 也同樣設置成 5000:

最後要重啟 Nginx 服務,因為只有重新調用 listen() 函數 TCP 全連接隊列才會重新初始化。

重啟完后 Nginx 服務后,服務端執行 ss 命令,查看 TCP 全連接隊列大小:

從執行結果,可以發現 TCP 全連接最大值為 5000。

增大 TCP 全連接隊列后,繼續壓測

客戶端同樣以 3 萬個連接併發發送請求給服務端:

服務端執行 ss 命令,查看 TCP 全連接隊列使用情況:

從上面的執行結果,可以發現全連接隊列使用增長的很快,但是一直都沒有超過最大值,所以就不會溢出,那麼 netstat -s 就不會有 TCP 全連接隊列溢出個數的显示:

說明 TCP 全連接隊列最大值從 128 增大到 5000 后,服務端抗住了 3 萬連接併發請求,也沒有發生全連接隊列溢出的現象了。

如果持續不斷地有連接因為 TCP 全連接隊列溢出被丟棄,就應該調大 backlog 以及 somaxconn 參數。

實戰 – TCP 半連接隊列溢出

如何查看 TCP 半連接隊列長度?

很遺憾,TCP 半連接隊列長度的長度,沒有像全連接隊列那樣可以用 ss 命令查看。

但是我們可以抓住 TCP 半連接的特點,就是服務端處於 SYN_RECV 狀態的 TCP 連接,就是在 TCP 半連接隊列。

於是,我們可以使用如下命令計算當前 TCP 半連接隊列長度:

如何模擬 TCP 半連接隊列溢出場景?

模擬 TCP 半連接溢出場景不難,實際上就是對服務端一直發送 TCP SYN 包,但是不回第三次握手 ACK,這樣就會使得服務端有大量的處於 SYN_RECV 狀態的 TCP 連接。

這其實也就是所謂的 SYN 洪泛、SYN 攻擊、DDos 攻擊。

測試環境

實驗環境:

  • 客戶端和服務端都是 CentOs 6.5 ,Linux 內核版本 2.6.32
  • 服務端 IP 192.168.3.200,客戶端 IP 192.168.3.100
  • 服務端是 Nginx 服務,端口為 8088

注意:本次模擬實驗是沒有開啟 tcp_syncookies,關於 tcp_syncookies 的作用,後續會說明。

台北網頁設計公司這麼多該如何選擇?

網動是一群專業、熱情、向前行的工作團隊,我們擁有靈活的組織與溝通的能力,能傾聽客戶聲音,激發創意的火花,呈現完美的作品

本次實驗使用 hping3 工具模擬 SYN 攻擊:

當服務端受到 SYN 攻擊后,連接服務端 ssh 就會斷開了,無法再連上。只能在服務端主機上執行查看當前 TCP 半連接隊列大小:

同時,還可以通過 netstat -s 觀察半連接隊列溢出的情況:

上面輸出的數值是累計值,表示共有多少個 TCP 連接因為半連接隊列溢出而被丟棄。隔幾秒執行幾次,如果有上升的趨勢,說明當前存在半連接隊列溢出的現象

大部分人都說 tcp_max_syn_backlog 是指定半連接隊列的大小,是真的嗎?

很遺憾,半連接隊列的大小並不單單隻跟 tcp_max_syn_backlog 有關係。

上面模擬 SYN 攻擊場景時,服務端的 tcp_max_syn_backlog 的默認值如下:

但是在測試的時候發現,服務端最多只有 256 個半連接隊列,而不是 512,所以半連接隊列的最大長度不一定由 tcp_max_syn_backlog 值決定的

接下來,走進 Linux 內核的源碼,來分析 TCP 半連接隊列的最大值是如何決定的。

TCP 第一次握手(收到 SYN 包)的 Linux 內核代碼如下,其中縮減了大量的代碼,只需要重點關注 TCP 半連接隊列溢出的處理邏輯:

從源碼中,我可以得出共有三個條件因隊列長度的關係而被丟棄的:

  1. 如果半連接隊列滿了,並且沒有開啟 tcp_syncookies,則會丟棄;
  2. 若全連接隊列滿了,且沒有重傳 SYN+ACK 包的連接請求多於 1 個,則會丟棄;
  3. 如果沒有開啟 tcp_syncookies,並且 max_syn_backlog 減去 當前半連接隊列長度小於 (max_syn_backlog >> 2),則會丟棄;

關於 tcp_syncookies 的設置,後面在詳細說明,可以先給大家說一下,開啟 tcp_syncookies 是緩解 SYN 攻擊其中一個手段。

接下來,我們繼續跟一下檢測半連接隊列是否滿的函數 inet_csk_reqsk_queue_is_full 和 檢測全連接隊列是否滿的函數 sk_acceptq_is_full :

從上面源碼,可以得知:

  • 連接隊列的最大值是 sk_max_ack_backlog 變量,sk_max_ack_backlog 實際上是在 listen() 源碼里指定的,也就是 min(somaxconn, backlog)
  • 連接隊列的最大值是 max_qlen_log 變量,max_qlen_log 是在哪指定的呢?現在暫時還不知道,我們繼續跟進;

我們繼續跟進代碼,看一下是哪裡初始化了半連接隊列的最大值 max_qlen_log:

從上面的代碼中,我們可以算出 max_qlen_log 是 8,於是代入到 檢測半連接隊列是否滿的函數 reqsk_queue_is_full :

也就是 qlen >> 8 什麼時候為 1 就代表半連接隊列滿了。這計算這不難,很明顯是當 qlen 為 256 時,256 >> 8 = 1

至此,總算知道為什麼上面模擬測試 SYN 攻擊的時候,服務端處於 SYN_RECV 連接最大隻有 256 個。

可見,半連接隊列最大值不是單單由 max_syn_backlog 決定,還跟 somaxconn 和 backlog 有關係。

在 Linux 2.6.32 內核版本,它們之間的關係,總體可以概況為:

  • 當 max_syn_backlog > min(somaxconn, backlog) 時, 半連接隊列最大值 max_qlen_log = min(somaxconn, backlog) * 2;
  • 當 max_syn_backlog < min(somaxconn, backlog) 時, 半連接隊列最大值 max_qlen_log = max_syn_backlog * 2;

半連接隊列最大值 max_qlen_log 就表示服務端處於 SYN_REVC 狀態的最大個數嗎?

依然很遺憾,並不是。

max_qlen_log 是理論半連接隊列最大值,並不一定代表服務端處於 SYN_REVC 狀態的最大個數。

在前面我們在分析 TCP 第一次握手(收到 SYN 包)時會被丟棄的三種條件:

  1. 如果半連接隊列滿了,並且沒有開啟 tcp_syncookies,則會丟棄;
  2. 若全連接隊列滿了,且沒有重傳 SYN+ACK 包的連接請求多於 1 個,則會丟棄;
  3. 如果沒有開啟 tcp_syncookies,並且 max_syn_backlog 減去 當前半連接隊列長度小於 (max_syn_backlog >> 2),則會丟棄;

假設條件 1 當前半連接隊列的長度 「沒有超過」理論的半連接隊列最大值 max_qlen_log,那麼如果條件 3 成立,則依然會丟棄 SYN 包,也就會使得服務端處於 SYN_REVC 狀態的最大個數不會是理論值 max_qlen_log。

似乎很難理解,我們繼續接着做實驗,實驗見真知。

服務端環境如下:

配置完后,服務端要重啟 Nginx,因為全連接隊列最大和半連接隊列最大值是在 listen() 函數初始化。

根據前面的源碼分析,我們可以計算出半連接隊列 max_qlen_log 的最大值為 256:

客戶端執行 hping3 發起 SYN 攻擊:

服務端執行如下命令,查看處於 SYN_RECV 狀態的最大個數:

可以發現,服務端處於 SYN_RECV 狀態的最大個數並不是 max_qlen_log 變量的值。

這就是前面所說的原因:如果當前半連接隊列的長度 「沒有超過」理論半連接隊列最大值 max_qlen_log,那麼如果條件 3 成立,則依然會丟棄 SYN 包,也就會使得服務端處於 SYN_REVC 狀態的最大個數不會是理論值 max_qlen_log。

我們來分析一波條件 3 :

從上面的分析,可以得知如果觸發「當前半連接隊列長度 > 192」條件,TCP 第一次握手的 SYN 包是會被丟棄的。

在前面我們測試的結果,服務端處於 SYN_RECV 狀態的最大個數是 193,正好是觸發了條件 3,所以處於 SYN_RECV 狀態的個數還沒到「理論半連接隊列最大值 256」,就已經把 SYN 包丟棄了。

所以,服務端處於 SYN_RECV 狀態的最大個數分為如下兩種情況:

  • 如果「當前半連接隊列」沒超過「理論半連接隊列最大值」,但是超過 max_syn_backlog – (max_syn_backlog >> 2),那麼處於 SYN_RECV 狀態的最大個數就是 max_syn_backlog – (max_syn_backlog >> 2);
  • 如果「當前半連接隊列」超過「理論半連接隊列最大值」,那麼處於 SYN_RECV 狀態的最大個數就是「理論半連接隊列最大值」;

每個 Linux 內核版本「理論」半連接最大值計算方式會不同。

在上面我們是針對 Linux 2.6.32 版本分析的「理論」半連接最大值的算法,可能每個版本有些不同。

比如在 Linux 5.0.0 的時候,「理論」半連接最大值就是全連接隊列最大值,但依然還是有隊列溢出的三個條件:

如果 SYN 半連接隊列已滿,只能丟棄連接嗎?

並不是這樣,開啟 syncookies 功能就可以在不使用 SYN 半連接隊列的情況下成功建立連接,在前面我們源碼分析也可以看到這點,當開啟了 syncookies 功能就不會丟棄連接。

syncookies 是這麼做的:服務器根據當前狀態計算出一個值,放在己方發出的 SYN+ACK 報文中發出,當客戶端返回 ACK 報文時,取出該值驗證,如果合法,就認為連接建立成功,如下圖所示。

開啟 syncookies 功能

syncookies 參數主要有以下三個值:

  • 0 值,表示關閉該功能;
  • 1 值,表示僅當 SYN 半連接隊列放不下時,再啟用它;
  • 2 值,表示無條件開啟功能;

那麼在應對 SYN 攻擊時,只需要設置為 1 即可:

如何防禦 SYN 攻擊?

這裏給出幾種防禦 SYN 攻擊的方法:

  • 增大半連接隊列;
  • 開啟 tcp_syncookies 功能
  • 減少 SYN+ACK 重傳次數

方式一:增大半連接隊列

在前面源碼和實驗中,得知要想增大半連接隊列,我們得知不能只單純增大 tcp_max_syn_backlog 的值,還需一同增大 somaxconn 和 backlog,也就是增大全連接隊列。否則,只單純增大 tcp_max_syn_backlog 是無效的。

增大 tcp_max_syn_backlog 和 somaxconn 的方法是修改 Linux 內核參數:

增大 backlog 的方式,每個 Web 服務都不同,比如 Nginx 增大 backlog 的方法如下:

最後,改變了如上這些參數后,要重啟 Nginx 服務,因為半連接隊列和全連接隊列都是在 listen() 初始化的。

方式二:開啟 tcp_syncookies 功能

開啟 tcp_syncookies 功能的方式也很簡單,修改 Linux 內核參數:

方式三:減少 SYN+ACK 重傳次數

當服務端受到 SYN 攻擊時,就會有大量處於 SYN_REVC 狀態的 TCP 連接,處於這個狀態的 TCP 會重傳 SYN+ACK ,當重傳超過次數達到上限后,就會斷開連接。

那麼針對 SYN 攻擊的場景,我們可以減少 SYN+ACK 的重傳次數,以加快處於 SYN_REVC 狀態的 TCP 連接斷開。

巨人的肩膀

[1] 系統性能調優必知必會.陶輝.極客時間.

[2] https://www.cnblogs.com/zengkefu/p/5606696.html

[3] https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

小林是專為大家圖解的工具人,Goodbye,我們下次見!

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

網頁設計最專業,超強功能平台可客製化

窩窩以「數位行銷」「品牌經營」「網站與應用程式」「印刷品設計」等四大主軸,為每一位客戶客製建立行銷脈絡及洞燭市場先機。