當(dāng)前位置:首頁 > 公眾號精選 > 小林coding
[導(dǎo)讀]每日英語,每天進(jìn)步一點(diǎn)點(diǎn): 前言 網(wǎng)上許多博客針對增大 TCP 半連接隊(duì)列和全連接隊(duì)列的方式如下: 增大 TCP 半連接隊(duì)列方式是增大 tcp_max_syn_backlog; 增大 TCP 全連接隊(duì)列方式是增大 listen() 函數(shù)中的 backlog; 這里先跟大家說下,上面的方式都是不準(zhǔn)確

每日英語,每天進(jìn)步一點(diǎn)點(diǎn):

前言

網(wǎng)上許多博客針對增大 TCP 半連接隊(duì)列和全連接隊(duì)列的方式如下:

  • 增大 TCP 半連接隊(duì)列方式是增大 tcp_max_syn_backlog;

  • 增大 TCP 全連接隊(duì)列方式是增大 listen() 函數(shù)中的 backlog;

這里先跟大家說下,上面的方式都是不準(zhǔn)確的。

“你怎么知道不準(zhǔn)確?”

很簡單呀,因?yàn)槲易隽藢?shí)驗(yàn)和看了 TCP 協(xié)議棧的內(nèi)核源碼,發(fā)現(xiàn)要增大這兩個(gè)隊(duì)列長度,不是簡簡單單增大某一個(gè)參數(shù)就可以的。

接下來,就會(huì)以實(shí)戰(zhàn) + 源碼分析,帶大家解密 TCP 半連接隊(duì)列和全連接隊(duì)列。

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

放心,本文的源碼分析不會(huì)涉及很深的知識(shí),因?yàn)槎急晃覄h減了,你只需要會(huì)條件判斷語句 if、左移右移操作符、加減法等基本語法,就可以看懂。

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

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

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

本文提綱

正文

什么是 TCP 半連接隊(duì)列和全連接隊(duì)列?

在 TCP 三次握手的時(shí)候,Linux 內(nèi)核會(huì)維護(hù)兩個(gè)隊(duì)列,分別是:

  • 半連接隊(duì)列,也稱 SYN 隊(duì)列;

  • 全連接隊(duì)列,也稱 accepet 隊(duì)列;

服務(wù)端收到客戶端發(fā)起的 SYN 請求后,內(nèi)核會(huì)把該連接存儲(chǔ)到半連接隊(duì)列,并向客戶端響應(yīng) SYN+ACK,接著客戶端會(huì)返回 ACK,服務(wù)端收到第三次握手的 ACK 后,內(nèi)核會(huì)把連接從半連接隊(duì)列移除,然后創(chuàng)建新的完全的連接,并將其添加到 accept 隊(duì)列,等待進(jìn)程調(diào)用 accept 函數(shù)時(shí)把連接取出來。

半連接隊(duì)列與全連接隊(duì)列

不管是半連接隊(duì)列還是全連接隊(duì)列,都有最大長度限制,超過限制時(shí),內(nèi)核會(huì)直接丟棄,或返回 RST 包。


實(shí)戰(zhàn) - TCP 全連接隊(duì)列溢出

如何知道應(yīng)用程序的 TCP 全連接隊(duì)列大???

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

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

在「LISTEN 狀態(tài)」時(shí),Recv-Q/Send-Q 表示的含義如下:


  • Recv-Q:當(dāng)前全連接隊(duì)列的大小,也就是當(dāng)前已完成三次握手并等待服務(wù)端 accept() 的 TCP 連接個(gè)數(shù);

  • Send-Q:當(dāng)前全連接最大隊(duì)列長度,上面的輸出結(jié)果說明監(jiān)聽 8088 端口的 TCP 服務(wù)進(jìn)程,最大全連接長度為 128;

在「非 LISTEN 狀態(tài)」時(shí),Recv-Q/Send-Q 表示的含義如下:


  • Recv-Q:已收到但未被應(yīng)用進(jìn)程讀取的字節(jié)數(shù);

  • Send-Q:已發(fā)送但未收到確認(rèn)的字節(jié)數(shù);


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

測試環(huán)境

實(shí)驗(yàn)環(huán)境:

  • 客戶端和服務(wù)端都是 CentOs 6.5 ,Linux 內(nèi)核版本 2.6.32

  • 服務(wù)端 IP 192.168.3.200,客戶端 IP 192.168.3.100

  • 服務(wù)端是 Nginx 服務(wù),端口為 8088

這里先介紹下 wrk 工具,它是一款簡單的 HTTP 壓測工具,它能夠在單機(jī)多核 CPU 的條件下,使用系統(tǒng)自帶的高性能 I/O 機(jī)制,通過多線程和事件模式,對目標(biāo)機(jī)器產(chǎn)生大量的負(fù)載。

本次模擬實(shí)驗(yàn)就使用 wrk 工具來壓力測試服務(wù)端,發(fā)起大量的請求,一起看看服務(wù)端 TCP 全連接隊(duì)列滿了會(huì)發(fā)生什么?有什么觀察指標(biāo)?

客戶端執(zhí)行 wrk 命令對服務(wù)端發(fā)起壓力測試,并發(fā) 3 萬個(gè)連接:

在服務(wù)端可以使用 ss 命令,來查看當(dāng)前 TCP 全連接隊(duì)列的情況:

其間共執(zhí)行了兩次 ss 命令,從上面的輸出結(jié)果,可以發(fā)現(xiàn)當(dāng)前 TCP 全連接隊(duì)列上升到了 129 大小,超過了最大 TCP 全連接隊(duì)列。

當(dāng)超過了 TCP 最大全連接隊(duì)列,服務(wù)端則會(huì)丟掉后續(xù)進(jìn)來的 TCP 連接,丟掉的 TCP 連接的個(gè)數(shù)會(huì)被統(tǒng)計(jì)起來,我們可以使用 netstat -s 命令來查看:

上面看到的 41150 times ,表示全連接隊(duì)列溢出的次數(shù),注意這個(gè)是累計(jì)值??梢愿魩酌腌妶?zhí)行下,如果這個(gè)數(shù)字一直在增加的話肯定全連接隊(duì)列偶爾滿了。

從上面的模擬結(jié)果,可以得知,當(dāng)服務(wù)端并發(fā)處理大量請求時(shí),如果 TCP 全連接隊(duì)列過小,就容易溢出。發(fā)生 TCP 全連接隊(duì)溢出的時(shí)候,后續(xù)的請求就會(huì)被丟棄,這樣就會(huì)出現(xiàn)服務(wù)端請求數(shù)量上不去的現(xiàn)象。

全連接隊(duì)列溢出

全連接隊(duì)列滿了,就只會(huì)丟棄連接嗎?

實(shí)際上,丟棄連接只是 Linux 的默認(rèn)行為,我們還可以選擇向客戶端發(fā)送 RST 復(fù)位報(bào)文,告訴客戶端連接已經(jīng)建立失敗。

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

  • 0 :表示如果全連接隊(duì)列滿了,那么 server 扔掉 client  發(fā)過來的 ack ;

  • 1 :表示如果全連接隊(duì)列滿了,那么 server 發(fā)送一個(gè) reset 包給 client,表示廢掉這個(gè)握手過程和這個(gè)連接;

如果要想知道客戶端連接不上服務(wù)端,是不是服務(wù)端 TCP 全連接隊(duì)列滿的原因,那么可以把 tcp_abort_on_overflow 設(shè)置為 1,這時(shí)如果在客戶端異常中可以看到很多 connection reset by peer 的錯(cuò)誤,那么就可以證明是由于服務(wù)端 TCP 全連接隊(duì)列溢出的問題。

通常情況下,應(yīng)當(dāng)把 tcp_abort_on_overflow 設(shè)置為 0,因?yàn)檫@樣更有利于應(yīng)對突發(fā)流量。

舉個(gè)例子,當(dāng) TCP 全連接隊(duì)列滿導(dǎo)致服務(wù)器丟掉了 ACK,與此同時(shí),客戶端的連接狀態(tài)卻是 ESTABLISHED,進(jìn)程就在建立好的連接上發(fā)送請求。只要服務(wù)器沒有為請求回復(fù) ACK,請求就會(huì)被多次重發(fā)。如果服務(wù)器上的進(jìn)程只是短暫的繁忙造成 accept 隊(duì)列滿,那么當(dāng) TCP 全連接隊(duì)列有空位時(shí),再次接收到的請求報(bào)文由于含有 ACK,仍然會(huì)觸發(fā)服務(wù)器端成功建立連接。

所以,tcp_abort_on_overflow 設(shè)為 0 可以提高連接建立的成功率,只有你非??隙?TCP 全連接隊(duì)列會(huì)長期溢出時(shí),才能設(shè)置為 1 以盡快通知客戶端。

如何增大 TCP 全連接隊(duì)列呢?

是的,當(dāng)發(fā)現(xiàn) TCP 全連接隊(duì)列發(fā)生溢出的時(shí)候,我們就需要增大該隊(duì)列的大小,以便可以應(yīng)對客戶端大量的請求。

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


  • somaxconn 是 Linux 內(nèi)核的參數(shù),默認(rèn)值是 128,可以通過 /proc/sys/net/core/somaxconn 來設(shè)置其值;

  • backloglisten(int sockfd, int backlog) 函數(shù)中的 backlog 大小,Nginx 默認(rèn)值是 511,可以通過修改配置文件設(shè)置其長度;

前面模擬測試中,我的測試環(huán)境:

  • somaxconn 是默認(rèn)值 128;

  • Nginx 的 backlog 是默認(rèn)值 511

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

現(xiàn)在我們重新壓測,把 TCP 全連接隊(duì)列搞大,把 somaxconn 設(shè)置成 5000:

接著把 Nginx 的 backlog 也同樣設(shè)置成 5000:

最后要重啟 Nginx 服務(wù),因?yàn)橹挥兄匦抡{(diào)用 listen() 函數(shù), TCP 全連接隊(duì)列才會(huì)重新初始化。

重啟完后 Nginx 服務(wù)后,服務(wù)端執(zhí)行 ss 命令,查看 TCP 全連接隊(duì)列大?。?/p>

從執(zhí)行結(jié)果,可以發(fā)現(xiàn) TCP 全連接最大值為 5000。

增大 TCP 全連接隊(duì)列后,繼續(xù)壓測

客戶端同樣以 3 萬個(gè)連接并發(fā)發(fā)送請求給服務(wù)端:

服務(wù)端執(zhí)行 ss 命令,查看 TCP 全連接隊(duì)列使用情況:

從上面的執(zhí)行結(jié)果,可以發(fā)現(xiàn)全連接隊(duì)列使用增長的很快,但是一直都沒有超過最大值,所以就不會(huì)溢出,那么 netstat -s 就不會(huì)有 TCP 全連接隊(duì)列溢出個(gè)數(shù)的顯示:

說明 TCP 全連接隊(duì)列最大值從 128 增大到 5000 后,服務(wù)端抗住了 3 萬連接并發(fā)請求,也沒有發(fā)生全連接隊(duì)列溢出的現(xiàn)象了。

如果持續(xù)不斷地有連接因?yàn)?TCP 全連接隊(duì)列溢出被丟棄,就應(yīng)該調(diào)大 backlog 以及 somaxconn 參數(shù)。


實(shí)戰(zhàn) - TCP 半連接隊(duì)列溢出

如何查看 TCP 半連接隊(duì)列長度?

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

但是我們可以抓住 TCP 半連接的特點(diǎn),就是服務(wù)端處于 SYN_RECV 狀態(tài)的 TCP 連接,就是在 TCP 半連接隊(duì)列。

于是,我們可以使用如下命令計(jì)算當(dāng)前 TCP 半連接隊(duì)列長度:


如何模擬 TCP 半連接隊(duì)列溢出場景?

模擬 TCP 半連接溢出場景不難,實(shí)際上就是對服務(wù)端一直發(fā)送 TCP SYN 包,但是不回第三次握手 ACK,這樣就會(huì)使得服務(wù)端有大量的處于 SYN_RECV 狀態(tài)的 TCP 連接。

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

測試環(huán)境

實(shí)驗(yàn)環(huán)境:

  • 客戶端和服務(wù)端都是 CentOs 6.5 ,Linux 內(nèi)核版本 2.6.32

  • 服務(wù)端 IP 192.168.3.200,客戶端 IP 192.168.3.100

  • 服務(wù)端是 Nginx 服務(wù),端口為 8088

注意:本次模擬實(shí)驗(yàn)是沒有開啟 tcp_syncookies,關(guān)于 tcp_syncookies 的作用,后續(xù)會(huì)說明。

本次實(shí)驗(yàn)使用 hping3 工具模擬 SYN 攻擊:

當(dāng)服務(wù)端受到 SYN 攻擊后,連接服務(wù)端 ssh 就會(huì)斷開了,無法再連上。只能在服務(wù)端主機(jī)上執(zhí)行查看當(dāng)前 TCP 半連接隊(duì)列大小:

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

上面輸出的數(shù)值是累計(jì)值,表示共有多少個(gè) TCP 連接因?yàn)榘脒B接隊(duì)列溢出而被丟棄。隔幾秒執(zhí)行幾次,如果有上升的趨勢,說明當(dāng)前存在半連接隊(duì)列溢出的現(xiàn)象

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

很遺憾,半連接隊(duì)列的大小并不單單只跟 tcp_max_syn_backlog 有關(guān)系。

上面模擬 SYN 攻擊場景時(shí),服務(wù)端的 tcp_max_syn_backlog 的默認(rèn)值如下:

但是在測試的時(shí)候發(fā)現(xiàn),服務(wù)端最多只有 256 個(gè)半連接隊(duì)列,而不是 512,所以半連接隊(duì)列的最大長度不一定由 tcp_max_syn_backlog 值決定的。

接下來,走進(jìn) Linux 內(nèi)核的源碼,來分析 TCP 半連接隊(duì)列的最大值是如何決定的。

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

從源碼中,我可以得出共有三個(gè)條件因隊(duì)列長度的關(guān)系而被丟棄的:


  1. 如果半連接隊(duì)列滿了,并且沒有開啟 tcp_syncookies,則會(huì)丟棄;

  2. 若全連接隊(duì)列滿了,且沒有重傳 SYN+ACK 包的連接請求多于 1 個(gè),則會(huì)丟棄;

  3. 如果沒有開啟 tcp_syncookies,并且 max_syn_backlog 減去 當(dāng)前半連接隊(duì)列長度小于 (max_syn_backlog >> 2),則會(huì)丟棄;

關(guān)于 tcp_syncookies 的設(shè)置,后面在詳細(xì)說明,可以先給大家說一下,開啟 tcp_syncookies 是緩解 SYN 攻擊其中一個(gè)手段。

接下來,我們繼續(xù)跟一下檢測半連接隊(duì)列是否滿的函數(shù) inet_csk_reqsk_queue_is_full 和 檢測全連接隊(duì)列是否滿的函數(shù) sk_acceptq_is_full :

從上面源碼,可以得知:

  • 連接隊(duì)列的最大值是 sk_max_ack_backlog 變量,sk_max_ack_backlog 實(shí)際上是在 listen() 源碼里指定的,也就是 min(somaxconn, backlog);

  • 連接隊(duì)列的最大值是 max_qlen_log 變量,max_qlen_log 是在哪指定的呢?現(xiàn)在暫時(shí)還不知道,我們繼續(xù)跟進(jìn);

我們繼續(xù)跟進(jìn)代碼,看一下是哪里初始化了半連接隊(duì)列的最大值 max_qlen_log:

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

也就是 qlen >> 8 什么時(shí)候?yàn)?1 就代表半連接隊(duì)列滿了。這計(jì)算這不難,很明顯是當(dāng) qlen 為 256 時(shí),256 >> 8 = 1

至此,總算知道為什么上面模擬測試 SYN 攻擊的時(shí)候,服務(wù)端處于 SYN_RECV 連接最大只有 256 個(gè)。

可見,半連接隊(duì)列最大值不是單單由 max_syn_backlog 決定,還跟 somaxconn 和 backlog 有關(guān)系。

在 Linux 2.6.32 內(nèi)核版本,它們之間的關(guān)系,總體可以概況為:


1. 當(dāng) max_syn_backlog > min(somaxconn, backlog) 時(shí), 半連接隊(duì)列最大值 max_qlen_log = min(somaxconn, backlog) * 2;


2. 當(dāng) max_syn_backlog < min(somaxconn, backlog) 時(shí), 半連接隊(duì)列最大值 max_qlen_log = max_syn_backlog * 2;


半連接隊(duì)列最大值 max_qlen_log 就表示服務(wù)端處于 SYN_REVC 狀態(tài)的最大個(gè)數(shù)嗎?

依然很遺憾,并不是。

max_qlen_log 是理論半連接隊(duì)列最大值,并不一定代表服務(wù)端處于 SYN_REVC 狀態(tài)的最大個(gè)數(shù)。

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

  1. 如果半連接隊(duì)列滿了,并且沒有開啟 tcp_syncookies,則會(huì)丟棄;

  2. 若全連接隊(duì)列滿了,且沒有重傳 SYN+ACK 包的連接請求多于 1 個(gè),則會(huì)丟棄;

  3. 如果沒有開啟 tcp_syncookies,并且 max_syn_backlog 減去 當(dāng)前半連接隊(duì)列長度小于 (max_syn_backlog >> 2),則會(huì)丟棄;

假設(shè)條件 1 當(dāng)前半連接隊(duì)列的長度 「沒有超過」理論的半連接隊(duì)列最大值  max_qlen_log,那么如果條件 3 成立,則依然會(huì)丟棄 SYN 包,也就會(huì)使得服務(wù)端處于 SYN_REVC 狀態(tài)的最大個(gè)數(shù)不會(huì)是理論值 max_qlen_log。

似乎很難理解,我們繼續(xù)接著做實(shí)驗(yàn),實(shí)驗(yàn)見真知。

服務(wù)端環(huán)境如下:

配置完后,服務(wù)端要重啟 Nginx,因?yàn)槿B接隊(duì)列最大和半連接隊(duì)列最大值是在 listen() 函數(shù)初始化。

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

客戶端執(zhí)行 hping3 發(fā)起 SYN 攻擊:

服務(wù)端執(zhí)行如下命令,查看處于 SYN_RECV 狀態(tài)的最大個(gè)數(shù):

可以發(fā)現(xiàn),服務(wù)端處于 SYN_RECV 狀態(tài)的最大個(gè)數(shù)并不是 max_qlen_log 變量的值。

這就是前面所說的原因:如果當(dāng)前半連接隊(duì)列的長度 「沒有超過」理論半連接隊(duì)列最大值  max_qlen_log,那么如果條件 3 成立,則依然會(huì)丟棄 SYN 包,也就會(huì)使得服務(wù)端處于 SYN_REVC 狀態(tài)的最大個(gè)數(shù)不會(huì)是理論值 max_qlen_log。

我們來分析一波條件 3 :

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

在前面我們測試的結(jié)果,服務(wù)端處于 SYN_RECV 狀態(tài)的最大個(gè)數(shù)是 193,正好是觸發(fā)了條件 3,所以處于 SYN_RECV 狀態(tài)的個(gè)數(shù)還沒到「理論半連接隊(duì)列最大值 256」,就已經(jīng)把 SYN 包丟棄了。

所以,服務(wù)端處于 SYN_RECV 狀態(tài)的最大個(gè)數(shù)分為如下兩種情況:

1. 如果「當(dāng)前半連接隊(duì)列」沒超過「理論半連接隊(duì)列最大值」,但是超過 max_syn_backlog - (max_syn_backlog >> 2),那么處于 SYN_RECV 狀態(tài)的最大個(gè)數(shù)就是 max_syn_backlog - (max_syn_backlog >> 2);


2. 如果「當(dāng)前半連接隊(duì)列」超過「理論半連接隊(duì)列最大值」,那么處于 SYN_RECV 狀態(tài)的最大個(gè)數(shù)就是「理論半連接隊(duì)列最大值」;


每個(gè) Linux 內(nèi)核版本「理論」半連接最大值計(jì)算方式會(huì)不同。

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

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


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

并不是這樣,開啟 syncookies 功能就可以在不使用 SYN 半連接隊(duì)列的情況下成功建立連接,在前面我們源碼分析也可以看到這點(diǎn),當(dāng)開啟了  syncookies 功能就不會(huì)丟棄連接。

syncookies 是這么做的:服務(wù)器根據(jù)當(dāng)前狀態(tài)計(jì)算出一個(gè)值,放在己方發(fā)出的 SYN+ACK 報(bào)文中發(fā)出,當(dāng)客戶端返回 ACK 報(bào)文時(shí),取出該值驗(yàn)證,如果合法,就認(rèn)為連接建立成功,如下圖所示。

開啟 syncookies 功能

syncookies 參數(shù)主要有以下三個(gè)值:

  • 0 值,表示關(guān)閉該功能;

  • 1 值,表示僅當(dāng) SYN 半連接隊(duì)列放不下時(shí),再啟用它;

  • 2 值,表示無條件開啟功能;

那么在應(yīng)對 SYN 攻擊時(shí),只需要設(shè)置為 1 即可:


如何防御 SYN 攻擊?

這里給出幾種防御 SYN 攻擊的方法:

  • 增大半連接隊(duì)列;

  • 開啟 tcp_syncookies 功能

  • 減少 SYN+ACK 重傳次數(shù)

方式一:增大半連接隊(duì)列

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

增大 tcp_max_syn_backlog 和 somaxconn 的方法是修改 Linux 內(nèi)核參數(shù):

增大 backlog 的方式,每個(gè) Web 服務(wù)都不同,比如 Nginx 增大 backlog 的方法如下:

最后,改變了如上這些參數(shù)后,要重啟 Nginx 服務(wù),因?yàn)榘脒B接隊(duì)列和全連接隊(duì)列都是在 listen() 初始化的。

方式二:開啟 tcp_syncookies 功能

開啟 tcp_syncookies 功能的方式也很簡單,修改 Linux 內(nèi)核參數(shù):

方式三:減少 SYN+ACK 重傳次數(shù)

當(dāng)服務(wù)端受到 SYN 攻擊時(shí),就會(huì)有大量處于 SYN_REVC 狀態(tài)的 TCP 連接,處于這個(gè)狀態(tài)的 TCP 會(huì)重傳 SYN+ACK ,當(dāng)重傳超過次數(shù)達(dá)到上限后,就會(huì)斷開連接。

那么針對 SYN 攻擊的場景,我們可以減少 SYN+ACK 的重傳次數(shù),以加快處于 SYN_REVC 狀態(tài)的 TCP 連接斷開。


巨人的肩膀

[1] 系統(tǒng)性能調(diào)優(yōu)必知必會(huì).陶輝.極客時(shí)間.

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


往期好文

實(shí)戰(zhàn)!我用“大白鯊”讓你看見 TCP

硬不硬你說了算!近 40 張圖解被問千百遍的 TCP 三次握手和四次揮手面試題

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


免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場,如有問題,請聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時(shí)1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動(dòng) BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時(shí)企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險(xiǎn),如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報(bào)道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實(shí)提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅(jiān)持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運(yùn)營商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺(tái)與中國電影電視技術(shù)學(xué)會(huì)聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會(huì)上宣布正式成立。 活動(dòng)現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會(huì)上,軟通動(dòng)力信息技術(shù)(集團(tuán))股份有限公司(以下簡稱"軟通動(dòng)力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉