1、TCP常用內核參數優化

上一篇我們介紹了服務器上有大量的TIME_WAIT等待，可能造成的危害，以及給web服務器帶來負擔。如何解決這個問題呢，其實，解決思路很簡單，就是讓服務器能夠快速回收和重用那些TIME_WAIT的資源即可。這就是對tcp調優。

在linux系統上，對tcp調優主要是通過調整Linux內核參數來實現的，其實主要是對/proc文件系統進行設置，/proc文件系統是一種內核和內核模塊用來向進程(process) 發送信息的機制(所以叫做/proc)。通過這個偽文件系統我們可以和內核內部數據結構進行交互，在運行中改變內核參數。 與其他文件系統不同，/proc存在于內存之中而不是硬盤上。proc文件系統以文件的形式向用戶空間提供了訪問接口，這些接口可以用于在運行時獲取相關信息或者修改參數配置，因而它是非常方便的一個接口。

/proc目錄下存放著大多數的內核參數，并且可以在系統運行的同時進行更改, 但是，重新啟動機器后就會失效，怎么解決呢，我們可以通過將更改的內核參數寫入 /etc/sysctl.conf文件中實現永久更改，在/etc/sysctl.conf文件中添加或者修改如何設置：

#對于一個新建連接，內核要發送多少個SYN連接請求才決定放棄,不應該大于255，默認值是5，這里設置為2.

net.ipv4.tcp_syn_retries=2

#表示當keepalive啟用的時候，TCP發送keepalive消息的頻度。缺省是7200秒，改為300秒

net.ipv4.tcp_keepalive_time=300

#表示孤兒socket廢棄前重試的次數，重負載web服務器建議調小。

net.ipv4.tcp_orphan_retries=1

#表示如果套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間

net.ipv4.tcp_fin_timeout=30

#表示SYN隊列的長度，默認為1024，加大隊列長度為8192，可以容納更多等待連接的網絡連接數。

net.ipv4.tcp_max_syn_backlog = 8192 (注意：這個隊列大小除了系統設置外，程序里面也要設置)

#表示開啟SYN Cookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN攻 擊，默認為0，表示關閉

net.ipv4.tcp_syncookies = 1

#表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認為0，表示關閉

net.ipv4.tcp_tw_reuse = 1

#表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉

net.ipv4.tcp_tw_recycle = 1

修改完之后執行/sbin/sysctl -p讓參數生效。

其實TIME-WAIT的問題還是比較好處理的，可以通過調節服務器參數實現，有時候還會出現CLOSE_WAIT很多的情況，CLOSE_WAIT是在對方關閉連接之后服務器程序自己沒有進一步發出ACK信號。換句話說，就是在對方連接關閉之后，程序里沒有檢測到，或者程序壓根就忘記了這個時候需要關閉連接，于是這個資源就一直被程序占著。所以解決CLOSE_WAIT過多的方法還需要檢查程序，檢查代碼，因為問題很大程度上出在服務器程序中。

到此為止，TCP優化到一段落。

2、TCP洪水攻 擊(SYN Flood)的診斷和處理

SYN Flood是當前最流行的DoS(拒絕服務)與DDoS(分布式拒絕服務)的方式之一，這是一種利用TCP協議缺陷，發送大量偽造的TCP連接請求，常用假冒的IP或IP號段發來海量的請求連接第一個握手包(SYN包)，被攻 擊服務器回應第二個握手包(SYN+ACK包)，因為對方是假冒IP，對方永遠收不到包且不會回應第三個握手包。導致被攻 擊服務器保持大量SYN_RECV狀態的“半連接”，并且會重試默認5次回應第二個握手包，直到塞滿TCP等待連接隊列，資源耗盡(CPU滿負荷或內存不足)，讓正常的業務請求連接不進來。

那么如何診斷SYN Flood問題呢，一般情況下如果發現網站打開緩慢、CPU負載高、ssh登陸慢甚至登陸不上，同時在系統日志中發現如下信息：

[root@test ~]# tail -f /var/log/messages

Mar 12 02:38:03 test kernel: possible SYN flooding on port 80. Sending cookies.

Mar 12 02:39:04 test kernel: possible SYN flooding on port 80. Sending cookies.

Mar 12 02:40:04 test kernel: possible SYN flooding on port 80. Sending cookies.

如果出現類似這種情況，那可能就是遭遇了TCP洪水***。

此時，通過如下命令檢查TCP連接狀態：

[root@localhost ~]# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

TIMEWAIT 7807

FINWAIT1 59

ESTABLISHED 8112

FINWAIT2 809

SYNRECV 198098

CLOSING 27

LASTACK 36

檢查發現，SYNRECV連接數會非常多。

針對這個問題，首先要做應急處理，那就是找到請求數請最多的IP地址，查找攻 擊來源，使用如下命令組合：

[root@localhost ~]# netstat -anlp|grep 80|grep tcp|awk '{print $5}'|awk -F: '{print $1}'|sort|uniq -c|sort -nr|head -n3

36.171.242

149.130.152

149.130.18

查到可疑的IP后，利用iptables臨時封掉最大嫌疑攻 擊的IP或IP號段。

接著，還需要調整系統內核參數，來抵擋這種攻 擊，根據上面對SYN Flood攻 擊的特點，我們只需修改操作系統內核參數即可有效緩解。主要參數如下：

net.ipv4.tcpsyncookies = 1

net.ipv4.tcpmaxsynbacklog = 81920

net.ipv4.tcpsynackretries = 2

三個參數的含義分別為啟用SYN Cookie、設置SYN最大隊列長度以及設置SYN+ACK最大重試次數。

SYN Cookie的作用是緩解服務器資源壓力。啟用之前，服務器在接到SYN數據包后，會立即分配存儲空間，并隨機化一個數字作為SYN號發送SYN+ACK數據包。然后保存連接的狀態信息等待客戶端確認。而在啟用SYN Cookie之后，服務器不再馬上分配存儲空間，而且通過基于時間種子的隨機數算法設置一個SYN號，替代完全隨機的SYN號。發送完SYN+ACK確認報文之后，清空資源不保存任何狀態信息。直到服務器接到客戶端的最終ACK包。同時，通過Cookie檢驗算法鑒定是否與發出去的SYN+ACK報文序列號匹配，匹配則通過完成握手，失敗則丟棄。

tcpmaxsynbacklog則是使用服務器的內存資源，換取更大的等待隊列長度，讓攻 擊數據包不至于占滿所有連接而導致正常用戶無法完成握手。

net.ipv4.tcpsynackretries是降低服務器SYN+ACK報文重試次數(默認是5次)，盡快釋放等待資源。

這三種措施與攻 擊的三種危害一一對應，完完全全是對癥下藥。但這些措施也是雙刃劍，設置過大可能消耗服務器更多的內存資源，甚至影響正常用戶建立TCP連接，因此，需要評估服務器硬件資源和大小謹慎設置。

總結

以上是生活随笔為你收集整理的linux内核关闭tcp校验,linux内核tcp调优规范与方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。