當MySQL數據庫遇到Syn Flooding

Syn攻擊是最常見又最容易被利用的一種攻擊手法,利用TCP協議的缺陷,發送大量偽造TCP連接請求,常用假冒的IP發來海量的SYN包,被攻擊的服務器回應SYN+ACK,因為對方是假冒的IP,永遠收不到包并且不會回應,導致被攻擊服務器保持大量SYN_RECV狀態的半連接,并且會重試默認5次回應握手包,塞滿TCP等待連接隊列,資源耗盡,讓正常的業務請求連接不進來。

Syn攻擊常見于應用服務器,而數據庫服務器在內網中,應該很難碰到類似的攻擊,但有時候應用程序如果和數據庫建連姿勢不正確,在數據庫端,也會被認為是Syn攻擊,并拒絕連接建立。

【問題描述】

數據庫突發的拒絕鏈接,應用報錯,出問題的時間點上,數據庫服務器的操作系統日志里,即/var/log/messages,可看到如下報錯信息:

kernel: possible SYN flooding on port 3306. Sending cookies.

【問題分析】

出問題的點上,從數據庫的監控指標來看,Threads Connected 這個指標有增長。這個也是很明顯,因為對數據庫來說,Syn Flooding就是應用程序突發的對數據庫發起建連,操作系統處理不過來,所以報Syn Flooding, 從數據庫的性能指標來看,連接數肯定是會有一個突發的增長。應對方案就是需要分析這些突發的增長是怎么來的,削峰填谷,讓連接更平穩。

【解決方案】

在數據庫服務端,做如下調整:這個調整的意思是說:增加TCP半連接的緩沖,默認值是2048,我們調整到8192,讓系統的抗突發壓力增大一些。Tcp_syn_retires和Tcp_synack_retires默認是5,也就是服務器端要發送五次包,才會終止重試,我們把這個參數調整為2. 只重試一次,讓出錯的包盡量提早出錯,以減少緩存的連接數。

echo 8192 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 2 > /proc/sys/net/ipv4/tcp_syn_retries
echo 2 > /proc/sys/net/ipv4/tcp_synack_retries

這個參數調整,即時生效,無需重啟。當然服務器重啟后,這些參數也會回退到默認值。經此調整,數據庫端的抗壓能力得到加強,但并沒有完全解決問題。

我們在客戶端也做相應調整:

為減少數據庫的連接數壓力,通常我們建議連接池做如下配置:

testWhileIdle="false"。空閑時不檢測連接串健康
minIdle="0"。連接池里面空閑連接的最小個數
maxAge="30000"。一個鏈接超過多少毫秒就可以回收掉。
initialSize="1"。連接池里面初始連接的最小個數
timeBetweenEvictionRunsMillis="5000"。回收線程的運行間隔(毫秒)

對于現在的場景,我們建議調高minIdle這個參數,從0調整到5. 讓連接池平時有5個空閑連接存在,這樣,發起對數據庫請求的時候,會先使用這5個空閑連接。達到削峰填谷的作用。當然,副作用就是數據庫平時的連接數會增長。具體調整到多少合適,需要結合實際的數據庫連接負載情況。對于.NET程序,也有相應的連接池參數可以調整:可以適當修改minPoolSize這個參數,也調整到5.

經此調整,基本上大部分的數據庫Syn Flooding問題都能解決。

當然,這些都是調優的手段,只能是微微的改善系統。提高抗壓能力。最終的分析,還是要看連接壓力從何而來。以及為何需要突發建立大量連接到數據庫。對于此種突發場景,用數據庫是否合適。替代方案是前面用Redis加一層緩沖。避免突發的對數據庫發起建連請求。這個就涉及到應用的改造了。

posted @ 2019-06-17 10:49 攜程DBA 閱讀(...) 評論(...) 編輯 收藏
四川金7乐历史开奖号码查询