LINUX TCP套接字詳細配置

時間 2019-11-13

標籤 linux tcp 詳細配置欄目 Linux 简体版

原文原文鏈接

提升服務器的負載能力，是一個永恆的話題。在一臺服務器CPU和內存資源額定有限的狀況下，最大的壓榨服務器的性能，是最終的目的。要提升 Linux系統下的負載能力，能夠先啓用Apache的Worker模式，來提升單位時間內的併發量。可是即便這麼作了，當網站發展起來以後，鏈接數過多的問題就會日益明顯。在節省成本的狀況下，能夠考慮修改Linux的內核TCP/IP參數，來最大的壓榨服務器的性能。固然，若是經過修改內核參數也沒法解決的負載問題，也只能考慮升級服務器了，這是硬件所限，沒有辦法的事。html

Linux系統下，TCP/IP鏈接斷開後，會以TIME_WAIT狀態保留必定的時間，而後纔會釋放端口。當併發請求過多的時候，就會產生大量的 TIME_WAIT狀態的鏈接，沒法及時斷開的話，會佔用大量的端口資源和服務器資源（由於關閉後進程纔會退出）。這個時候咱們能夠考慮優化TCP/IP 的內核參數，來及時將TIME_WAIT狀態的端口清理掉。
本文介紹的方法只對擁有大量TIME_WAIT狀態的鏈接致使系統資源消耗有效，不是這個緣由的狀況下，效果可能不明顯。那麼，到哪兒去查 TIME_WAIT狀態的鏈接呢？那就是使用netstat命令。咱們能夠輸入一個複覈命令，去查看當前TCP/IP鏈接的狀態和對應的個數：linux

#netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’web

這個命令會顯示出相似下面的結果：算法

LAST_ACK 14
SYN_RECV 348
ESTABLISHED 70
FIN_WAIT1 229
FIN_WAIT2 30
CLOSING 33
TIME_WAIT 18122apache

咱們只用關心TIME_WAIT的個數，在這裏能夠看到，有18000多個TIME_WAIT，這樣就佔用了18000多個端口。要知道端口的數量只有65535個，佔用一個少一個，會嚴重的影響到後繼的新鏈接。這種狀況下，咱們就有必要調整下Linux的TCP/IP內核參數，讓系統更快的釋放 TIME_WAIT鏈接。vim

咱們用vim打開配置文件：緩存

#vim /etc/sysctl.conf安全

而後，在這個文件中，加入下面的幾行內容：服務器

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30cookie

最後輸入下面的命令，讓內核參數生效：

#/sbin/sysctl -p

簡單的說明下，上面的參數的含義：

net.ipv4.tcp_syncookies = 1 表示開啓SYN Cookies。當出現SYN等待隊列溢出時，啓用cookies來處理，可防範少許SYN攻擊，默認爲0，表示關閉；
net.ipv4.tcp_tw_reuse = 1 表示開啓重用。容許將TIME-WAIT sockets從新用於新的TCP鏈接，默認爲0，表示關閉；
net.ipv4.tcp_tw_recycle = 1 表示開啓TCP鏈接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉；
net.ipv4.tcp_fin_timeout 修改系統默認的 TIMEOUT 時間。

在通過這樣的調整以後，除了會進一步提高服務器的負載能力以外，還可以防護必定程度的DDoS、CC和SYN攻擊，是個一箭雙鵰的作法。

此外，若是你的鏈接數自己就不少，咱們能夠再優化一下TCP/IP的可以使用端口範圍，進一步提高服務器的併發能力。依然是往上面的參數文件中，加入下面這些配置：

net.ipv4.tcp_keepalive_time = 1200
net.ipv4.ip_local_port_range = 10000 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000

這幾個參數，建議只在流量很是大的服務器上開啓，會有顯著的效果。通常的流量小的服務器上，沒有必要去設置這幾個參數。這幾個參數的含義以下：

net.ipv4.tcp_keepalive_time = 1200 表示當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時，改成20分鐘。
net.ipv4.ip_local_port_range = 10000 65000 表示用於向外鏈接的端口範圍。缺省狀況下很小：32768到61000，改成10000到65000。（注意：這裏不要將最低值設的過低，不然可能會佔用掉正常的端口！）
net.ipv4.tcp_max_syn_backlog = 8192 表示SYN隊列的長度，默認爲1024，加大隊列長度爲8192，能夠容納更多等待鏈接的網絡鏈接數。
net.ipv4.tcp_max_tw_buckets = 5000 表示系統同時保持TIME_WAIT的最大數量，若是超過這個數字，TIME_WAIT將馬上被清除並打印警告信息。默認爲180000，改成5000。對於Apache、Nginx等服務器，上幾行的參數能夠很好地減小TIME_WAIT套接字數量，可是對於 Squid，效果卻不大。此項參數能夠控制TIME_WAIT的最大數量，避免Squid服務器被大量的TIME_WAIT拖死。

通過這樣的配置以後，你的服務器的TCP/IP併發能力又會上一個新臺階。

們這裏應用的是CentOS5.3，並內核使用的是2.6.18-128.el5PAE #1 SMP 。修改部分TCP ，有的是爲了提升性能與負載，可是存在下降穩定性的風險。有的則是安全方面的配置，則有可能犧牲了性能。

1.TCP keepalive TCP鏈接保鮮設置

echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 15 > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes

keepalive是TCP保鮮定時器。當網絡兩端創建了TCP鏈接以後，閒置idle（雙方沒有任何數據流發送往來）了tcp_keepalive_time後，服務器內核就會嘗試向客戶端發送偵測包，來判斷TCP鏈接情況(有可能客戶端崩潰、強制關閉了應用、主機不可達等等)。若是沒有收到對方的回答(ack包)，則會在tcp_keepalive_intvl後再次嘗試發送偵測包，直到收到對對方的ack,若是一直沒有收到對方的ack,一共會嘗試tcp_keepalive_probes次，每次的間隔時間在這裏分別是15s, 30s, 45s, 60s, 75s。若是嘗試tcp_keepalive_probes,依然沒有收到對方的ack包，則會丟棄該TCP鏈接。

2. syn cookies設置

echo 0 > /proc/sys/net/ipv4/tcp_syncookies

在CentOS5.3中，該選項默認值是1，即啓用syn cookies功能。咱們建議先關閉，直到肯定受到syn flood攻擊的時候再開啓syn cookies功能，有效地防止syn flood攻擊。也能夠經過iptables規則拒絕syn flood攻擊。

3.TCP 鏈接創建設置

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

tcp_max_syn_backlog SYN隊列的長度，時常稱之爲未創建鏈接隊列。系統內核維護着這樣的一個隊列，用於容納狀態爲SYN_RESC的TCP鏈接(half-open connection),即那些依然還沒有獲得客戶端確認(ack)的TCP鏈接請求。加大該值，能夠容納更多的等待鏈接的網絡鏈接數。

tcp_syn_retries 新建TCP鏈接請求，須要發送一個SYN包，該值決定內核須要嘗試發送多少次syn鏈接請求才決定放棄創建鏈接。默認值是5. 對於高負責且通訊良好的物理網絡而言，調整爲2

tcp_synack_retries 對於遠端SYN鏈接請求，內核會發送SYN+ACK數據包來確認收到了上一個SYN鏈接請求包，而後等待遠端的確認(ack數據包）。該值則指定了內核會向遠端發送tcp_synack_retires次SYN+ACK數據包。默認設定值是5，能夠調整爲2

4. TCP 鏈接斷開相關設置

echo 30 >  /proc/sys/net/ipv4/tcp_fin_timeout
echo 15000 > /proc/sys/net/ipv4/tcp_max_tw_buckets
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
echo 1 >  /proc/sys/net/ipv4/tcp_tw_recycle

tcp_fin_timeout 對於由本端主動斷開鏈接的TCP鏈接，本端會主動發送一個FIN數據報，在收到遠端ACK後,且並無收到遠端FIN包以前，該TCP鏈接的狀態是FIN_WAIT_2狀態，此時當遠端關閉了應用，網絡不可達（拔網張），程序不可斷僵死等等，本端會一直保留狀態爲FIN_WAIT_2狀態的TCP鏈接，該值tcp_fin_timeout則指定了狀態爲FIN_WAIT_2的TCP鏈接保存多長時間，一個FIN_WAIT_2的TCP鏈接最多佔1.5k內存。系統默認值是60秒，能夠將此值調整爲30秒，甚至10秒。

tcp_max_tw_buckets 系統同時處理TIME_WAIT sockets數目。若是一旦TIME_WAIT tcp鏈接數超過了這個數目，系統會強制清除而且顯示警告消息。設立該限制，主要是防止那些簡單的DoS攻擊，加大該值有可能消耗更多的內存資源。若是TIME_WAIT socket過多，則有可能耗盡內存資源。默認值是18w,能夠將此值設置爲5000~30000
tcp_tw_resue 是否可使用TIME_WAIT tcp鏈接用於創建新的tcp鏈接。

tcp_tw_recycle 是否開啓快帶回收TIME_WAIT tcp鏈接的功能。

5. tcp 內存資源使用相參數設定

echo 16777216 > /proc/sys/net/core/rmem_max
echo 16777216 > /proc/sys/net/core/wmem_max
cat /proc/sys/net/ipv4/tcp_mem
echo 「4096 65536 16777216″ > /proc/sys/net/ipv4/tcp_rmem
echo 「4096 87380 16777216″ > /proc/sys/net/ipv4/tcp_wmem

rmem_max 定義了接收窗口可使用的最大值，能夠根據BDP值進行調節。
wmem_max 定義了發送窗口可使用的最大值，能夠根據BDP什值進行調整。
tcp_mem [low, pressure, high] TCP用這三個值來跟蹤內存使用狀況，來限定資源佔用。一般狀況下，在系統boot之時，內核會根據可用內存總數計算出這些值。若是出現了Out of socket memory,則能夠試着修改這個參數。
1)low: 當TCP使用了低於該值的內存頁面數時，TCP不會考濾釋放內存。
2)pressure: 當TCP使用了超過該值的內存頁面數量，TCP試圖穩定其對內存的佔用，進入pressure模式,直到內存消耗達於low值，退出該模式。
3)hight:容許全部tcp sockets用於排隊緩衝數據報的內存頁數。
tcp_rmem [min, default, max]
1)min 爲每一個TCP鏈接(tcp socket)預留用於接收緩衝的內存數量，即便在內存出現緊張狀況下TCP socket都至少會有這麼多數量的內存用於接收緩衝。
2)default 爲TCP socket預留用於接收緩衝的內存數量，默認狀況下該值影響其它協議使用的 rmem_default的值，因此有可能被rmem_default覆蓋。
3)max 該值爲每一個tcp鏈接(tcp socket)用於接收緩衝的內存最大值。該值不會影響wmem_max的值，設置了選項參數 SO_SNDBUF則不受該值影響。
tcp_wmem [min, default, max] 如上(tcp_rmen)只不過用於發送緩存。

注:
1)能夠經過sysctl -w 或者寫入/etc/sysctl.conf永久保存
2)性能調優僅在於須要的時候進行調整，調整之後須要採集數據與基準測試數據進行比較。建議，不須要盲從地調整這些參數。

CLOSE_WAIT，TCP的癌症，TCP的朋友。
CLOSE_WAIT狀態的生成緣由
首先咱們知道，若是咱們的服務器程序APACHE處於CLOSE_WAIT狀態的話，說明套接字是被動關閉的！
由於若是是CLIENT端主動斷掉當前鏈接的話，那麼雙方關閉這個TCP鏈接共須要四個packet：
      Client —>  FIN  —>  Server
      Client <—  ACK  <—  Server
這時候Client端處於FIN_WAIT_2狀態；而Server 程序處於CLOSE_WAIT狀態。
      Client <—  FIN  <—  Server
這時Server 發送FIN給Client，Server 就置爲LAST_ACK狀態。
       Client —>  ACK  —>  Server
Client迴應了ACK，那麼Server 的套接字纔會真正置爲CLOSED狀態。
Server 程序處於CLOSE_WAIT狀態，而不是LAST_ACK狀態，說明尚未發FIN給Client，那麼多是在關閉鏈接以前還有許多數據要發送或者其餘事要作，致使沒有發這個FIN packet。
一般來講，一個CLOSE_WAIT會維持至少2個小時的時間。若是有個流氓特意寫了個程序，給你形成一堆的CLOSE_WAIT，消耗
你的資源，那麼一般是等不到釋放那一刻，系統就已經解決崩潰了。
只能經過修改一下TCP/IP的參數，來縮短這個時間：修改tcp_keepalive_*系列參數有助於解決這個問題。
proc/sys/net/ipv4/下各項的意義
/proc/sys/net/ipv4/icmp_timeexceed_rate
這個在traceroute時致使著名的「Solaris middle star」。這個文件控制發送ICMP Time Exceeded消息的比率。
/proc/sys/net/ipv4/igmp_max_memberships
主機上最多有多少個igmp (多播)套接字進行監聽。
/proc/sys/net/ipv4/inet_peer_gc_maxtime
求助: Add a little explanation about the inet peer storage? Minimum interval between garbage collection passes. This interval is in effect under low (or absent) memory pressure on the pool. Measured in jiffies.
/proc/sys/net/ipv4/inet_peer_gc_mintime
每一遍碎片收集之間的最小時間間隔。當內存壓力比較大的時候，調整這個間隔頗有效。以jiffies計。
/proc/sys/net/ipv4/inet_peer_maxttl
entries的最大生存期。在pool沒有內存壓力的狀況下(好比，pool中entries的數量不多的時候)，未使用的entries通過一段時間就會過時。以jiffies計。
/proc/sys/net/ipv4/inet_peer_minttl
entries的最小生存期。應該不小於匯聚端分片的生存期。當pool的大小不大於inet_peer_threshold時，這個最小生存期必須予以保證。以jiffies計。
/proc/sys/net/ipv4/inet_peer_threshold
The approximate size of the INET peer storage. Starting from this threshold entries will be thrown aggressively. This threshold also determines entries’ time-to-live anｄ time intervals between garbage collection passes. More entries, less time-to-live, less GC interval.
/proc/sys/net/ipv4/ip_autoconfig
這個文件裏面寫着一個數字，表示主機是否經過RARP、BOOTP、DHCP或者其它機制取得其IP配置。不然就是0。
/proc/sys/net/ipv4/ip_default_ttl
數據包的生存期。設置爲64是安全的。若是你的網絡規模巨大就提升這個值。不要由於好玩而這麼作??那樣會產生有害的路由環路。實際上，在不少狀況下你要考慮可否減少這個值。
/proc/sys/net/ipv4/ip_dynaddr/proc/sys/net/ipv4/icmp_destunreach_rate
若是你有一個動態地址的自動撥號接口，就得設置它。當你的自動撥號接口激活的時候，本地全部沒有收到答覆的TCP套接字會從新綁定到正確的地址上。這能夠解決引起撥號的套接字自己沒法工做，重試一次卻能夠的問題。
/proc/sys/net/ipv4/ip_forward
內核是否轉發數據包。缺省禁止。
/proc/sys/net/ipv4/ip_local_port_range
用於向外鏈接的端口範圍。缺省狀況下其實很小：1024到4999。
/proc/sys/net/ipv4/ip_no_pmtu_disc
若是你想禁止「沿途MTU發現」就設置它。「沿途MTU發現」是一種技術，能夠在傳輸路徑上檢測出最大可能的MTU值。參見Cookbook一章中關於「沿途MTU發現」的內容。
/proc/sys/net/ipv4/ipfrag_high_thresh
用於IP分片匯聚的最大內存用量。分配了這麼多字節的內存後，一旦用盡，分片處理程序就會丟棄分片。When ipfrag_high_thresh bytes of memory is allocated for this purpose, the fragment handler will toss packets until ipfrag_low_thresh is reached.
/proc/sys/net/ipv4/ip_nonlocal_bind
若是你但願你的應用程序可以綁定到不屬於本地網卡的地址上時，設置這個選項。若是你的機器沒有專線鏈接(甚至是動態鏈接)時很是有用，即便你的鏈接斷開，你的服務也能夠啓動並綁定在一個指定的地址上。
/proc/sys/net/ipv4/ipfrag_low_thresh
用於IP分片匯聚的最小內存用量。
/proc/sys/net/ipv4/ipfrag_time
IP分片在內存中的保留時間(秒數)。
/proc/sys/net/ipv4/tcp_abort_on_overflow
一個布爾類型的標誌，控制着當有不少的鏈接請求時內核的行爲。啓用的話，若是服務超載，內核將主動地發送RST包。
/proc/sys/net/ipv4/tcp_fin_timeout
如果套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間。對端能夠出錯並永遠不關閉鏈接，甚至意外當機。缺省值是60秒。2.2 內核的一般值是180秒，你能夠按這個設置，但要記住的是，即便你的機器是一個輕載的WEB服務器，也有由於大量的死套接字而內存溢出的風險，FIN- WAIT-2的危險性比FIN-WAIT-1要小，由於它最多隻能吃掉1.5K內存，可是它們的生存期長些。參見tcp_max_orphans。
/proc/sys/net/ipv4/tcp_keepalive_time
當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時。
/proc/sys/net/ipv4/tcp_keepalive_intvl
當探測沒有確認時，從新發送探測的頻度。缺省是75秒。
/proc/sys/net/ipv4/tcp_keepalive_probes
在認定鏈接失效以前，發送多少個TCP的keepalive探測包。缺省值是9。這個值乘以tcp_keepalive_intvl以後決定了，一個鏈接發送了keepalive以後能夠有多少時間沒有迴應。
/proc/sys/net/ipv4/tcp_max_orphans
系統中最多有多少個TCP套接字不被關聯到任何一個用戶文件句柄上。若是超過這個數字，孤兒鏈接將即刻被複位並打印出警告信息。這個限制僅僅是爲了防止簡單的DoS攻擊，你絕對不能過度依靠它或者人爲地減少這個值，更應該增長這個值(若是增長了內存以後)。This limit exists only to prevent simple DoS attacks, you _must_ not rely on this oｒ lower the limit artificially, but rather increase it (probably, after increasing installed memory), if network conditions require more than default value, anｄ tune network services to linger anｄ kill such states more aggressively. 讓我再次提醒你：每一個孤兒套接字最多可以吃掉你64K不可交換的內存。
/proc/sys/net/ipv4/tcp_orphan_retries
本端試圖關閉TCP鏈接以前重試多少次。缺省值是7，至關於50秒~16分鐘(取決於RTO)。若是你的機器是一個重載的WEB服務器，你應該考慮減低這個值，由於這樣的套接字會消耗不少重要的資源。參見tcp_max_orphans。
/proc/sys/net/ipv4/tcp_max_syn_backlog
記錄的那些還沒有收到客戶端確認信息的鏈接請求的最大值。對於有128M內存的系統而言，缺省值是1024，小內存的系統則是128。若是服務器不堪重負，試試提升這個值。注意！若是你設置這個值大於1024，最好同時調整include/net/tcp.h中的TCP_SYNQ_HSIZE，以保證 TCP_SYNQ_HSIZE*16 ≤tcp_max_syn_backlo，而後從新編譯內核。
/proc/sys/net/ipv4/tcp_max_tw_buckets
系統同時保持timewait套接字的最大數量。若是超過這個數字，time-wait套接字將馬上被清除並打印警告信息。這個限制僅僅是爲了防止簡單的 DoS攻擊，你絕對不能過度依靠它或者人爲地減少這個值，若是網絡實際須要大於缺省值，更應該增長這個值(若是增長了內存以後)。
/proc/sys/net/ipv4/tcp_retrans_collapse
爲兼容某些糟糕的打印機設置的「將錯就錯」選項。再次發送時，把數據包增大一些，來避免某些TCP協議棧的BUG。
/proc/sys/net/ipv4/tcp_retries1
在認定出錯並向網絡層提交錯誤報告以前，重試多少次。缺省設置爲RFC規定的最小值：3，至關於3秒~8分鐘（取決於RIO）。
/proc/sys/net/ipv4/tcp_retries2
在殺死一個活動的TCP鏈接以前重試多少次。RFC 1122規定這個限制應該長於100秒。這個值過小了。缺省值是15，至關於13~30分鐘（取決於RIO）。
/proc/sys/net/ipv4/tcp_rfc1337
這個開關能夠啓動對於在RFC1337中描述的「tcp的time-wait暗殺危機」問題的修復。啓用後，內核將丟棄那些發往time-wait狀態TCP套接字的RST包。卻省爲0。
/proc/sys/net/ipv4/tcp_sack
特別針對丟失的數據包使用選擇性ACK，這樣有助於快速恢復。
/proc/sys/net/ipv4/tcp_stdurg
使用TCP緊急指針的主機需求解釋。由於絕大多數主機採用BSD解釋，因此若是你在Linux上打開它，可能會影響它與其它機器的正常通信。缺省是FALSE。
/proc/sys/net/ipv4/tcp_syn_retries
在內核放棄創建鏈接以前發送SYN包的數量。
/proc/sys/net/ipv4/tcp_synack_retries
爲了打開對端的鏈接，內核須要發送一個SYN並附帶一個迴應前面一個SYN的ACK。也就是所謂三次握手中的第二次握手。這個設置決定了內核放棄鏈接以前發送SYN ACK包的數量。
/proc/sys/net/ipv4/tcp_timestamps
時間戳能夠避免序列號的卷繞。一個1Gbps的鏈路確定會遇到之前用過的序列號。時間戳可以讓內核接受這種「異常」的數據包。
/proc/sys/net/ipv4/tcp_tw_recycle
可以更快地回收TIME-WAIT套接字。缺省值是1。除非有技術專家的建議和要求，不然不該修改。
/proc/sys/net/ipv4/tcp_window_scaling
通常來講TCP/IP容許窗口尺寸達到65535字節。對於速度確實很高的網絡而言這個值可能仍是過小。這個選項容許設置上G字節的窗口大小，有利於在帶寬*延遲很大的環境中使用。
一旦內核認爲它沒法發包，就會丟棄這個包，並向發包的主機發送ICMP通知。
/proc/sys/net/ipv4/icmp_echo_ignore_all
根本不要響應echo包。請不要設置爲缺省，它可能在你正被利用成爲DoS攻擊的跳板時可能有用。
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts [Useful]
若是你ping子網的子網地址，全部的機器都應該予以迴應。這可能成爲很是好用的拒絕服務攻擊工具。設置爲1來忽略這些子網廣播消息。
/proc/sys/net/ipv4/icmp_echoreply_rate
設置了向任意主機迴應echo請求的比率。
/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
設置它以後，能夠忽略由網絡中的那些聲稱迴應地址是廣播地址的主機生成的ICMP錯誤。
/proc/sys/net/ipv4/icmp_paramprob_rate
一個相對不很明確的ICMP消息，用來回應IP頭或TCP頭損壞的異常數據包。你能夠經過這個文件控制消息的發送比率。
================================================================

http://skylove.study-area.org/blog/2006/07/linuxip_29.html

tcp_syn_retries ：INTEGER默認值是5對於一個新建鏈接，內核要發送多少個 SYN 鏈接請求才決定放棄。不該該大於255，默認值是5，對應於180秒左右時間。(對於大負載而物理通訊良好的網絡而言,這個值偏高,可修改成2.這個值僅僅是針對對外的鏈接,對進來的鏈接,是由tcp_retries1 決定的)tcp_synack_retries ：INTEGER默認值是5對於遠端的鏈接請求SYN，內核會發送SYN ＋ ACK數據報，以確認收到上一個 SYN鏈接請求包。這是所謂的三次握手( threeway handshake)機制的第二個步驟。這裏決定內核在放棄鏈接以前所送出的 SYN ACK 數目。不該該大於255，默認值是5，對應於180秒左右時間。(能夠根據上面的 tcp_syn_retries 來決定這個值)tcp_keepalive_time ：INTEGER默認值是7200(2小時)當keepalive打開的狀況下，TCP發送keepalive消息的頻率。(因爲目前網絡攻擊等因素,形成了利用這個進行的攻擊很頻繁,曾經也有cu 的朋友提到過,說若是2邊創建了鏈接,而後不發送任何數據或者rst/fin消息,那麼持續的時間是否是就是2小時,空鏈接攻擊? tcp_keepalive_time就是預防此情形的.我我的在作nat服務的時候的修改值爲1800秒)tcp_keepalive_probes：INTEGER默認值是9TCP發送keepalive探測以肯定該鏈接已經斷開的次數。(注意:保持鏈接僅在SO_KEEPALIVE套接字選項被打開是才發送.次數默認不須要修改,固然根據情形也能夠適當地縮短此值.設置爲5比較合適)tcp_keepalive_intvl：INTEGER默認值爲75探測消息發送的頻率，乘以tcp_keepalive_probes就獲得對於從開始探測以來沒有響應的鏈接殺除的時間。默認值爲75秒，也就是沒有活動的鏈接將在大約11分鐘之後將被丟棄。(對於普通應用來講,這個值有一些偏大,能夠根據須要改小.特別是web類服務器須要改小該值,15是個比較合適的值)tcp_retries1 ：INTEGER默認值是3放棄迴應一個TCP鏈接請求前?須要進行多少次重試。RFC 規定最低的數值是3?這也是默認值?根據RTO的值大約在3秒 – 8分鐘之間。(注意:這個值同時還決定進入的syn鏈接)tcp_retries2 ：INTEGER默認值爲15在丟棄激活(已創建通信情況)的TCP鏈接以前?須要進行多少次重試。默認值爲15，根據RTO的值來決定，至關於13-30分鐘(RFC1122規定，必須大於100秒).(這個值根據目前的網絡設置,能夠適當地改小,個人網絡內修改成了5)tcp_orphan_retries ：INTEGER默認值是7在近端丟棄TCP鏈接以前?要進行多少次重試。默認值是7個?至關於 50秒 – 16分鐘?視 RTO 而定。若是您的系統是負載很大的web服務器?那麼也許須要下降該值?這類 sockets 可能會耗費大量的資源。另外參的考 tcp_max_orphans 。(事實上作NAT的時候,下降該值也是好處顯著的,我本人的網絡環境中下降該值爲3)tcp_fin_timeout ：INTEGER默認值是 60對於本端斷開的socket鏈接，TCP保持在FIN-WAIT-2狀態的時間。對方可能會斷開鏈接或一直不結束鏈接或不可預料的進程死亡。默認值爲 60 秒。過去在2.2版本的內核中是 180 秒。您能夠設置該值?但須要注意?若是您的機器爲負載很重的web服務器?您可能要冒內存被大量無效數據報填滿的風險?FIN-WAIT-2 sockets 的危險性低於 FIN-WAIT-1 ?由於它們最多隻吃 1.5K 的內存?可是它們存在時間更長。另外參考 tcp_max_orphans。(事實上作NAT的時候,下降該值也是好處顯著的,我本人的網絡環境中下降該值爲30)tcp_max_tw_buckets ：INTEGER默認值是180000系統在同時所處理的最大 timewait sockets 數目。若是超過此數的話?time-wait socket 會被當即砍除而且顯示警告信息。之因此要設定這個限制?純粹爲了抵禦那些簡單的 DoS 攻擊?千萬不要人爲的下降這個限制?不過?若是網絡條件須要比默認值更多?則能夠提升它(或許還要增長內存)。(事實上作NAT的時候最好能夠適當地增長該值)tcp_tw_recycle ：BOOLEAN默認值是0打開快速 TIME-WAIT sockets 回收。除非獲得技術專家的建議或要求?請不要隨意修改這個值。(作NAT的時候，建議打開它)tcp_tw_reuse：BOOLEAN默認值是0該文件表示是否容許從新應用處於TIME-WAIT狀態的socket用於新的TCP鏈接(這個對快速重啓動某些服務,而啓動後提示端口已經被使用的情形很是有幫助)tcp_max_orphans ：INTEGER缺省值是8192系統所能處理不屬於任何進程的TCP sockets最大數量。假如超過這個數量?那麼不屬於任何進程的鏈接會被當即reset，並同時顯示警告信息。之因此要設定這個限制?純粹爲了抵禦那些簡單的 DoS 攻擊?千萬不要依賴這個或是人爲的下降這個限制(這個值Redhat AS版本中設置爲32768,可是不少防火牆修改的時候,建議該值修改成2000)tcp_abort_on_overflow ：BOOLEAN缺省值是0當守護進程太忙而不能接受新的鏈接，就象對方發送reset消息，默認值是false。這意味着當溢出的緣由是由於一個偶然的猝發，那麼鏈接將恢復狀態。只有在你確信守護進程真的不能完成鏈接請求時纔打開該選項，該選項會影響客戶的使用。(對待已經滿載的sendmail,apache這類服務的時候,這個能夠很快讓客戶端終止鏈接,能夠給予服務程序處理已有鏈接的緩衝機會,因此不少防火牆上推薦打開它)tcp_syncookies ：BOOLEAN默認值是0只有在內核編譯時選擇了CONFIG_SYNCOOKIES時纔會發生做用。當出現syn等候隊列出現溢出時象對方發送syncookies。目的是爲了防止syn flood攻擊。注意：該選項千萬不能用於那些沒有收到攻擊的高負載服務器，若是在日誌中出現synflood消息，可是調查發現沒有收到synflood攻擊，而是合法用戶的鏈接負載太高的緣由，你應該調整其它參數來提升服務器性能。參考:tcp_max_syn_backlogtcp_synack_retriestcp_abort_on_overflowsyncookie嚴重的違背TCP協議，不容許使用TCP擴展，可能對某些服務致使嚴重的性能影響(如SMTP轉發)。(注意,該實現與BSD上面使用的tcp proxy同樣,是違反了RFC中關於tcp鏈接的三次握手實現的,可是對於防護syn-flood的確頗有用.)tcp_stdurg ：BOOLEAN默認值爲0使用 TCP urg pointer 字段中的主機請求解釋功能。大部份的主機都使用老舊的 BSD解釋，所以若是您在 Linux 打開它?或會致使不能和它們正確溝通。tcp_max_syn_backlog ：INTEGER對於那些依然還未得到客戶端確認的鏈接請求?須要保存在隊列中最大數目。對於超過 128Mb 內存的系統?默認值是 1024 ?低於 128Mb 的則爲 128。若是服務器常常出現過載?能夠嘗試增長這個數字。警告?假如您將此值設爲大於 1024?最好修改 include/net/tcp.h 裏面的 TCP_SYNQ_HSIZE ?以保持 TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog ?而且編進核心以內。(SYN Flood攻擊利用TCP協議散佈握手的缺陷，僞造虛假源IP地址發送大量TCP-SYN半打開鏈接到目標系統，最終致使目標系統Socket隊列資源耗盡而沒法接受新的鏈接。爲了應付這種攻擊，現代Unix系統中廣泛採用多鏈接隊列處理的方式來緩衝(而不是解決)這種攻擊，是用一個基本隊列處理正常的完全鏈接應用(Connect()和Accept() )，是用另外一個隊列單獨存放半打開鏈接。這種雙隊列處理方式和其餘一些系統內核措施(例如Syn-Cookies/Caches)聯合應用時，可以比較有效的緩解小規模的SYN Flood攻擊(事實證實<1000p/s)加大SYN隊列長度能夠容納更多等待鏈接的網絡鏈接數，因此對Server來講能夠考慮增大該值.)tcp_window_scaling ：INTEGER缺省值爲1該文件表示設置tcp/ip會話的滑動窗口大小是否可變。參數值爲布爾值，爲1時表示可變，爲0時表示不可變。tcp/ip一般使用的窗口最大可達到 65535 字節，對於高速網絡，該值可能過小，這時候若是啓用了該功能，可使tcp/ip滑動窗口大小增大數個數量級，從而提升數據傳輸的能力(RFC 1323)。（對普通地百M網絡而言，關閉會下降開銷，因此若是不是高速網絡，能夠考慮設置爲0）tcp_timestamps ：BOOLEAN缺省值爲1Timestamps 用在其它一些東西中?能夠防範那些僞造的 sequence 號碼。一條1G的寬帶線路或許會重遇到帶 out-of-line數值的舊sequence 號碼(假如它是因爲上次產生的)。Timestamp 會讓它知道這是個 ‘舊封包’。(該文件表示是否啓用以一種比超時重發更精確的方法（RFC 1323）來啓用對 RTT 的計算；爲了實現更好的性能應該啓用這個選項。)tcp_sack ：BOOLEAN缺省值爲1使用 Selective ACK?它能夠用來查找特定的遺失的數據報— 所以有助於快速恢復狀態。該文件表示是否啓用有選擇的應答（Selective Acknowledgment），這能夠經過有選擇地應答亂序接收到的報文來提升性能（這樣可讓發送者只發送丟失的報文段）。(對於廣域網通訊來講這個選項應該啓用，可是這會增長對 CPU 的佔用。)tcp_fack ：BOOLEAN缺省值爲1打開FACK擁塞避免和快速重傳功能。(注意，當tcp_sack設置爲0的時候，這個值即便設置爲1也無效)tcp_dsack ：BOOLEAN缺省值爲1容許TCP發送」兩個徹底相同」的SACK。tcp_ecn ：BOOLEAN缺省值爲0打開TCP的直接擁塞通告功能。tcp_reordering ：INTEGER默認值是3TCP流中重排序的數據報最大數量。 (通常有看到推薦把這個數值略微調整大一些,好比5)tcp_retrans_collapse ：BOOLEAN缺省值爲1對於某些有bug的打印機提供針對其bug的兼容性。(通常不須要這個支持,能夠關閉它)tcp_wmem(3個INTEGER變量)： min, default, maxmin：爲TCP socket預留用於發送緩衝的內存最小值。每一個tcp socket均可以在建議之後均可以使用它。默認值爲4096(4K)。default：爲TCP socket預留用於發送緩衝的內存數量，默認狀況下該值會影響其它協議使用的net.core.wmem_default 值，通常要低於net.core.wmem_default的值。默認值爲16384(16K)。max: 用於TCP socket發送緩衝的內存最大值。該值不會影響net.core.wmem_max，」靜態」選擇參數SO_SNDBUF則不受該值影響。默認值爲 131072(128K)。（對於服務器而言，增長這個參數的值對於發送數據頗有幫助,在個人網絡環境中,修改成了51200 131072 204800）tcp_rmem (3個INTEGER變量)： min, default, maxmin：爲TCP socket預留用於接收緩衝的內存數量，即便在內存出現緊張狀況下tcp socket都至少會有這麼多數量的內存用於接收緩衝，默認值爲8K。default：爲TCP socket預留用於接收緩衝的內存數量，默認狀況下該值影響其它協議使用的 net.core.wmem_default 值。該值決定了在tcp_adv_win_scale、tcp_app_win和tcp_app_win=0默認值狀況下，TCP窗口大小爲65535。默認值爲87380max：用於TCP socket接收緩衝的內存最大值。該值不會影響 net.core.wmem_max，」靜態」選擇參數 SO_SNDBUF則不受該值影響。默認值爲 128K。默認值爲87380*2 bytes。（能夠看出，.max的設置最好是default的兩倍,對於NAT來講主要該增長它,個人網絡裏爲 51200 131072 204800）tcp_mem(3個INTEGER變量)：low, pressure, highlow：當TCP使用了低於該值的內存頁面數時，TCP不會考慮釋放內存。(理想狀況下，這個值應與指定給 tcp_wmem 的第 2 個值相匹配 – 這第 2 個值代表，最大頁面大小乘以最大併發請求數除以頁大小 (131072 * 300 / 4096)。 )pressure：當TCP使用了超過該值的內存頁面數量時，TCP試圖穩定其內存使用，進入pressure模式，當內存消耗低於low值時則退出 pressure狀態。(理想狀況下這個值應該是 TCP 可使用的總緩衝區大小的最大值 (204800 * 300 / 4096)。 )high：容許全部tcp sockets用於排隊緩衝數據報的頁面量。(若是超過這個值，TCP 鏈接將被拒絕，這就是爲何不要令其過於保守 (512000 * 300 / 4096) 的緣由了。在這種狀況下，提供的價值很大，它能處理不少鏈接，是所預期的 2.5 倍；或者使現有鏈接可以傳輸 2.5 倍的數據。個人網絡裏爲192000 300000 732000)通常狀況下這些值是在系統啓動時根據系統內存數量計算獲得的。tcp_app_win : INTEGER默認值是31保留max(window/2^tcp_app_win, mss)數量的窗口因爲應用緩衝。當爲0時表示不須要緩衝。tcp_adv_win_scale : INTEGER默認值爲2計算緩衝開銷bytes/2^tcp_adv_win_scale(若是tcp_adv_win_scale > 0)或者bytes-bytes/2^(-tcp_adv_win_scale)(若是tcp_adv_win_scale <= 0）。tcp_rfc1337 :BOOLEAN缺省值爲0這個開關能夠啓動對於在RFC1337中描述的」tcp 的time-wait暗殺危機」問題的修復。啓用後，內核將丟棄那些發往time-wait狀態TCP套接字的RST 包.tcp_low_latency : BOOLEAN缺省值爲0容許 TCP/IP 棧適應在高吞吐量狀況下低延時的狀況；這個選項通常情形是的禁用。(但在構建Beowulf 集羣的時候,打開它頗有幫助)tcp_westwood :BOOLEAN缺省值爲0啓用發送者端的擁塞控制算法，它能夠維護對吞吐量的評估，並試圖對帶寬的總體利用狀況進行優化；對於 WAN 通訊來講應該啓用這個選項。tcp_bic :BOOLEAN缺省值爲0爲快速長距離網絡啓用 Binary Increase Congestion；這樣能夠更好地利用以 GB 速度進行操做的連接；對於 WAN 通訊應該啓用這個選項。# 如下一段爲抵抗syn flood攻擊，平時建議關閉sysctl -w net.ipv4.tcp_syncookies=1 # tcp syncookie，默認關閉sysctl -w net.ipv4.tcp_max_syn_backlog=1280 # syn隊列，默認1024，> 1280可能工做不穩定，須要修改內核源碼參數sysctl -w net.ipv4.tcp_synack_retries=2 # syn-ack握手狀態重試次數，默認5，遭受syn-flood攻擊時改成1或2sysctl -w net.ipv4.tcp_syn_retries=2 # 外向syn握手重試次數，默認4# 如下一段爲應對tcp connect鏈接耗盡攻擊，若是開啓iptables connlimit模塊可禁用# 有嚴重鏈接性能影響和不穩定因素，慎用sysctl -w tcp_tw_recycle=1 # 默認0，tw快速回收sysctl -w tcp_tw_reuse=1 # 默認0，tw重用sysctl -w tcp_keepalive_intvl=60 # 默認75，tcp keeplive探測輪詢時間sysctl -w tcp_keepalive_probes=3 # 默認9，tcp keeplive探測輪詢次數sysctl -w tcp_keepalive_time=1800 # 默認7200，tcp keeplive時間sysctl -w tcp_fin_timeout=30 # 默認60，tcp fin狀態超時時間#sysctl -w net.ipv4.tcp_retries1=2 # tcp鏈接重傳參數，慎用#sysctl -w net.ipv4.tcp_retries2=8sysctl -w net.ipv4.ip_conntrack_max=65535 # 增大iptables狀態跟蹤表

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。