CLOSE_WAIT，TCP的癌癥，TCP的朋友。
CLOSE_WAIT狀態(tài)的生成原因
首先我們知道，如果我們的服務(wù)器程序APACHE處于
CLOSE_WAIT狀態(tài)的話，說明套接字是被動關(guān)閉的！
因為如果是CLIENT端主動斷掉當前連接的話，那么雙方關(guān)閉這個TCP連接共需要四個packet：
??????Client?--->??FIN??--->??Server?
??????Client?<---??ACK??<---??Server?
?這時候Client端處于FIN_WAIT_2狀態(tài)；而Server?程序處于
CLOSE_WAIT狀態(tài)。
??????Client?<---??FIN??<---??Server?
這時Server?發(fā)送FIN給Client，Server?就置為LAST_ACK狀態(tài)。
???????Client?--->??ACK??--->??Server?
Client回應(yīng)了ACK，那么Server?的套接字才會真正置為CLOSED狀態(tài)。
Server?程序處于
CLOSE_WAIT狀態(tài)，而不是LAST_ACK狀態(tài)，說明還沒有發(fā)FIN給Client，那么可能是在關(guān)閉連接之前還有許多數(shù)據(jù)要發(fā)送或者其他事要做，導(dǎo)致沒有發(fā)這個FIN?packet。
通常來說，一個
CLOSE_WAIT會維持至少2個小時的時間。如果有個流氓特地寫了個程序，給你造成一堆的
CLOSE_WAIT，消耗
你的資源，那么通常是等不到釋放那一刻，系統(tǒng)就已經(jīng)解決崩潰了。
只能通過修改一下TCP/IP的參數(shù)，來縮短這個時間：修改tcp_keepalive_*系列參數(shù)有助于解決這個問題。
?
proc/sys/net/ipv4/下各項的意義
/proc/sys/net/ipv4/icmp_timeexceed_rate
這個在traceroute時導(dǎo)致著名的“Solaris?middle?star”。這個文件控制發(fā)送ICMP?Time?Exceeded消息的比率。
/proc/sys/net/ipv4/igmp_max_memberships
主機上最多有多少個igmp?(多播)套接字進行監(jiān)聽。
/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
每一遍碎片收集之間的最小時間間隔。當內(nèi)存壓力比較大的時候，調(diào)整這個間隔很有效。以jiffies計。
/proc/sys/net/ipv4/inet_peer_maxttl
entries的最大生存期。在pool沒有內(nèi)存壓力的情況下(比如，pool中entries的數(shù)量很少的時候)，未使用的entries經(jīng)過一段時間就會過期。以jiffies計。
/proc/sys/net/ipv4/inet_peer_minttl
entries的最小生存期。應(yīng)該不小于匯聚端分片的生存期。當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?and?time?intervals?between?garbage?collection?passes.?More?entries,?less?time-to-live,?less?GC?interval.
/proc/sys/net/ipv4/ip_autoconfig
這個文件里面寫著一個數(shù)字，表示主機是否通過RARP、BOOTP、DHCP或者其它機制取得其IP配置。否則就是0。
/proc/sys/net/ipv4/ip_default_ttl
數(shù)據(jù)包的生存期。設(shè)置為64是安全的。如果你的網(wǎng)絡(luò)規(guī)模巨大就提高這個值。不要因為好玩而這么做——那樣會產(chǎn)生有害的路由環(huán)路。實際上，在很多情況下你要考慮能否減小這個值。
/proc/sys/net/ipv4/ip_dynaddr/proc/sys/net/ipv4/icmp_destunreach_rate
如果你有一個動態(tài)地址的自動撥號接口，就得設(shè)置它。當你的自動撥號接口激活的時候，本地所有沒有收到答復(fù)的TCP套接字會重新綁定到正確的地址上。這可以解決引發(fā)撥號的套接字本身無法工作，重試一次卻可以的問題。
/proc/sys/net/ipv4/ip_forward
內(nèi)核是否轉(zhuǎn)發(fā)數(shù)據(jù)包。缺省禁止。
/proc/sys/net/ipv4/ip_local_port_range
用于向外連接的端口范圍。缺省情況下其實很小：1024到4999。
/proc/sys/net/ipv4/ip_no_pmtu_disc
如果你想禁止“沿途MTU發(fā)現(xiàn)”就設(shè)置它。“沿途MTU發(fā)現(xiàn)”是一種技術(shù)，可以在傳輸路徑上檢測出最大可能的MTU值。參見Cookbook一章中關(guān)于“沿途MTU發(fā)現(xiàn)”的內(nèi)容。
/proc/sys/net/ipv4/ipfrag_high_thresh
用?于
IP分片匯聚的最大內(nèi)存用量。分配了這么多字節(jié)的內(nèi)存后，一旦用盡，分片處理程序就會丟棄分片。
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
如果你希望你的應(yīng)用程序能夠綁定到不屬于本地網(wǎng)卡的地址上時，設(shè)置這個選項。如果你的機器沒有專線連接(甚至是動態(tài)連接)時非常有用，即使你的連接斷開，你的服務(wù)也可以啟動并綁定在一個指定的地址上。
/proc/sys/net/ipv4/ipfrag_low_thresh
用于IP分片匯聚的最小內(nèi)存用量。
/proc/sys/net/ipv4/ipfrag_time
IP分片在內(nèi)存中的保留時間(秒數(shù))。
/proc/sys/net/ipv4/tcp_abort_on_overflow
一個布爾類型的標志，控制著當有很多的連接請求時內(nèi)核的行為。啟用的話，如果服務(wù)超載，內(nèi)核將主動地發(fā)送RST包。
/proc/sys/net/ipv4/tcp_fin_timeout
如?果
套接字由本端要求關(guān)閉，這個參數(shù)決定了它保持在FIN-WAIT-2狀態(tài)的時間。對端可以出錯并永遠不關(guān)閉連接，甚至意外當機。缺省值是60秒。
2.2?內(nèi)核的通常值是180秒，你可以按這個設(shè)置，但要記住的是，即使你的機器是一個輕載的WEB服務(wù)器，也有因為大量的死套接字而內(nèi)存溢出的風
險，F(xiàn)IN-?WAIT-2的危險性比FIN-WAIT-1要小，因為它最多只能吃掉1.5K內(nèi)存，但是它們的生存期長些。參見
tcp_max_orphans。
/proc/sys/net/ipv4/tcp_keepalive_time
當keepalive起用的時候，TCP發(fā)送keepalive消息的頻度。缺省是2小時。
/proc/sys/net/ipv4/tcp_keepalive_intvl
當探測沒有確認時，重新發(fā)送探測的頻度。缺省是75秒。
/proc/sys/net/ipv4/tcp_keepalive_probes
在認定連接失效之前，發(fā)送多少個TCP的keepalive探測包。缺省值是9。這個值乘以tcp_keepalive_intvl之后決定了，一個連接發(fā)送了keepalive之后可以有多少時間沒有回應(yīng)。
/proc/sys/net/ipv4/tcp_max_orphans
系?統(tǒng)
中最多有多少個TCP套接字不被關(guān)聯(lián)到任何一個用戶文件句柄上。如果超過這個數(shù)字，孤兒連接將即刻被復(fù)位并打印出警告信息。這個限制僅僅是為了防止簡單的
DoS攻擊，你絕對不能過分依靠它或者人為地減小這個值，更應(yīng)該增加這個值(如果增加了內(nèi)存之后)。
This?limit?exists?only?to?prevent?simple?DoS?attacks,?you?_must_?not?rely?on?this?or?lower?the?limit?artificially,?but?rather?increase?it?(probably,?after?increasing?installed?memory),?if?network?conditions?require?more?than?default?value,?and?tune?network?services?to?linger?and?kill?such?states?more?aggressively.?讓
我再次提醒你：每個孤兒套接字最多能夠吃掉你64K不可交換的內(nèi)存。
/proc/sys/net/ipv4/tcp_orphan_retries
本端試圖關(guān)閉TCP連接之前重試多少次。缺省值是7，相當于50秒~16分鐘(取決于RTO)。如果你的機器是一個重載的WEB服務(wù)器，你應(yīng)該考慮減低這個值，因為這樣的套接字會消耗很多重要的資源。參見tcp_max_orphans。
/proc/sys/net/ipv4/tcp_max_syn_backlog
記?錄
的那些尚未收到客戶端確認信息的連接請求的最大值。對于有128M內(nèi)存的系統(tǒng)而言，缺省值是1024，小內(nèi)存的系統(tǒng)則是128。如果服務(wù)器不堪重負，
試?試提高這個值。注意！如果你設(shè)置這個值大于1024，最好同時調(diào)整include/net/tcp.h中的TCP_SYNQ_HSIZE，以保
證?TCP_SYNQ_HSIZE*16?≤tcp_max_syn_backlo，然后重新編譯內(nèi)核。
/proc/sys/net/ipv4/tcp_max_tw_buckets
系?統(tǒng)
同時保持timewait套接字的最大數(shù)量。如果超過這個數(shù)字，time-wait套接字將立刻被清除并打印警告信息。這個限制僅僅是為了防止簡單
的?DoS攻擊，你絕對不能過分依靠它或者人為地減小這個值，如果網(wǎng)絡(luò)實際需要大于缺省值，更應(yīng)該增加這個值(如果增加了內(nèi)存之后)。
/proc/sys/net/ipv4/tcp_retrans_collapse
為兼容某些糟糕的打印機設(shè)置的“將錯就錯”選項。再次發(fā)送時，把數(shù)據(jù)包增大一些，來避免某些TCP協(xié)議棧的BUG。
/proc/sys/net/ipv4/tcp_retries1
在認定出錯并向網(wǎng)絡(luò)層提交錯誤報告之前，重試多少次。缺省設(shè)置為RFC規(guī)定的最小值：3，相當于3秒~8分鐘（取決于RIO）。
/proc/sys/net/ipv4/tcp_retries2
在殺死一個活動的TCP連接之前重試多少次。RFC?1122規(guī)定這個限制應(yīng)該長于100秒。這個值太小了。缺省值是15，相當于13~30分鐘（取決于RIO）。
/proc/sys/net/ipv4/tcp_rfc1337
這個開關(guān)可以啟動對于在RFC1337中描述的“tcp的time-wait暗殺危機”問題的修復(fù)。啟用后，內(nèi)核將丟棄那些發(fā)往time-wait狀態(tài)TCP套接字的RST包。卻省為0。
/proc/sys/net/ipv4/tcp_sack
特別針對丟失的數(shù)據(jù)包使用選擇性ACK，這樣有助于快速恢復(fù)。
/proc/sys/net/ipv4/tcp_stdurg
使用TCP緊急指針的主機需求解釋。因為絕大多數(shù)主機采用BSD解釋，所以如果你在Linux上打開它，可能會影響它與其它機器的正常通訊。缺省是FALSE。
/proc/sys/net/ipv4/tcp_syn_retries
在內(nèi)核放棄建立連接之前發(fā)送SYN包的數(shù)量。
/proc/sys/net/ipv4/tcp_synack_retries
為了打開對端的連接，內(nèi)核需要發(fā)送一個SYN并附帶一個回應(yīng)前面一個SYN的ACK。也就是所謂三次握手中的第二次握手。這個設(shè)置決定了內(nèi)核放棄連接之前發(fā)送SYN+ACK包的數(shù)量。
/proc/sys/net/ipv4/tcp_timestamps
時間戳可以避免序列號的卷繞。一個1Gbps的鏈路肯定會遇到以前用過的序列號。時間戳能夠讓內(nèi)核接受這種“異常”的數(shù)據(jù)包。
/proc/sys/net/ipv4/tcp_tw_recycle
能夠更快地回收TIME-WAIT套接字。缺省值是1。除非有技術(shù)專家的建議和要求，否則不應(yīng)修改。
/proc/sys/net/ipv4/tcp_window_scaling
一般來說TCP/IP允許窗口尺寸達到65535字節(jié)。對于速度確實很高的網(wǎng)絡(luò)而言這個值可能還是太小。這個選項允許設(shè)置上G字節(jié)的窗口大小，有利于在帶寬*延遲很大的環(huán)境中使用。
一旦內(nèi)核認為它無法發(fā)包，就會丟棄這個包，并向發(fā)包的主機發(fā)送ICMP通知。
/proc/sys/net/ipv4/icmp_echo_ignore_all
根本不要響應(yīng)echo包。請不要設(shè)置為缺省，它可能在你正被利用成為DoS攻擊的跳板時可能有用。
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts?[Useful]
如果你ping子網(wǎng)的子網(wǎng)地址，所有的機器都應(yīng)該予以回應(yīng)。這可能成為非常好用的拒絕服務(wù)攻擊工具。設(shè)置為1來忽略這些子網(wǎng)廣播消息。
/proc/sys/net/ipv4/icmp_echoreply_rate
設(shè)置了向任意主機回應(yīng)echo請求的比率。
/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
設(shè)置它之后，可以忽略由網(wǎng)絡(luò)中的那些聲稱回應(yīng)地址是廣播地址的主機生成的ICMP錯誤。
/proc/sys/net/ipv4/icmp_paramprob_rate
一個相對不很明確的ICMP消息，用來回應(yīng)IP頭或TCP頭損壞的異常數(shù)據(jù)包。你可以通過這個文件控制消息的發(fā)送比率。
================================================================
?
http://skylove.study-area.org/blog/2006/07/linuxip_29.htmltcp_syn_retries?：INTEGER
默認值是5
對
于一個新建連接，內(nèi)核要發(fā)送多少個?SYN?連接請求才決定放棄。不應(yīng)該大于255，默認值是5，對應(yīng)于180秒左右時間。(對于大負載而物理通信良好的
網(wǎng)絡(luò)而言,這個值偏高,可修改為2.這個值僅僅是針對對外的連接,對進來的連接,是由tcp_retries1?決定的)
tcp_synack_retries?：INTEGER
默認值是5
對
于遠端的連接請求SYN，內(nèi)核會發(fā)送SYN?＋?ACK數(shù)據(jù)報，以確認收到上一個?SYN連接請求包。這是所謂的三次握手
(?threeway?handshake)機制的第二個步驟。這里決定內(nèi)核在放棄連接之前所送出的?SYN+ACK?數(shù)目。不應(yīng)該大于255，默認值是
5，對應(yīng)于180秒左右時間。(可以根據(jù)上面的?tcp_syn_retries?來決定這個值)
tcp_keepalive_time?：INTEGER
默認值是7200(2小時)
當
keepalive打開的情況下，TCP發(fā)送keepalive消息的頻率。(由于目前網(wǎng)絡(luò)攻擊等因素,造成了利用這個進行的攻擊很頻繁,曾經(jīng)也有cu的
朋友提到過,說如果2邊建立了連接,然后不發(fā)送任何數(shù)據(jù)或者rst/fin消息,那么持續(xù)的時間是不是就是2小時,空連接攻
擊??tcp_keepalive_time就是預(yù)防此情形的.我個人在做nat服務(wù)的時候的修改值為1800秒)
tcp_keepalive_probes：INTEGER
默認值是9
TCP發(fā)送keepalive探測以確定該連接已經(jīng)斷開的次數(shù)。(注意:保持連接僅在SO_KEEPALIVE套接字選項被打開是才發(fā)送.次數(shù)默認不需要修改,當然根據(jù)情形也可以適當?shù)乜s短此值.設(shè)置為5比較合適)
tcp_keepalive_intvl：INTEGER
默認值為75
探
測消息發(fā)送的頻率，乘以tcp_keepalive_probes就得到對于從開始探測以來沒有響應(yīng)的連接殺除的時間。默認值為75秒，也就是沒有活動的
連接將在大約11分鐘以后將被丟棄。(對于普通應(yīng)用來說,這個值有一些偏大,可以根據(jù)需要改小.特別是web類服務(wù)器需要改小該值,15是個比較合適的
值)
tcp_retries1?：INTEGER
默認值是3
放棄回應(yīng)一個TCP連接請求前﹐需要進行多少次重試。RFC?規(guī)定最低的數(shù)值是3﹐這也是默認值﹐根據(jù)RTO的值大約在3秒?-?8分鐘之間。(注意:這個值同時還決定進入的syn連接)
tcp_retries2?：INTEGER
默認值為15
在丟棄激活(已建立通訊狀況)的TCP連接之前﹐需要進行多少次重試。默認值為15，根據(jù)RTO的值來決定，相當于13-30分鐘(RFC1122規(guī)定，必須大于100秒).(這個值根據(jù)目前的網(wǎng)絡(luò)設(shè)置,可以適當?shù)馗男?我的網(wǎng)絡(luò)內(nèi)修改為了5)
tcp_orphan_retries?：INTEGER
默認值是7
在近端丟棄TCP連接之前﹐要進行多少次重試。默認值是7個﹐相當于?50秒?-?16分鐘﹐視?RTO?而定。如果您的系統(tǒng)是負載很大的web服務(wù)器﹐那么也許需要降低該值﹐這類?
sockets?可能會耗費大量的資源。另外參的考?tcp_max_orphans?。(事實上做NAT的時候,降低該值也是好處顯著的,我本人的網(wǎng)絡(luò)環(huán)境中降低該值為3)
tcp_fin_timeout?：INTEGER
默認值是?60
對于本端斷開的
socket連
接，TCP保持在FIN-WAIT-2狀態(tài)的時間。對方可能會斷開連接或一直不結(jié)束連接或不可預(yù)料的進程死亡。默認值為?60?秒。過去在2.2版本的內(nèi)
核中是?180?秒。您可以設(shè)置該值﹐但需要注意﹐如果您的機器為負載很重的web服務(wù)器﹐您可能要冒內(nèi)存被大量無效數(shù)據(jù)報填滿的風險﹐FIN-
WAIT-2?
sockets?的危險性低于?FIN-WAIT-1?﹐因為它們最多只吃?1.5K?的內(nèi)存﹐但是它們存在時間更長。另外參考?tcp_max_orphans。(事實上做NAT的時候,降低該值也是好處顯著的,我本人的網(wǎng)絡(luò)環(huán)境中降低該值為30)
tcp_max_tw_buckets?：INTEGER
默認值是180000
系?統(tǒng)在同時所處理的最大?timewait?
sockets?數(shù)目。如果超過此數(shù)的話﹐time-wait?
socket?會被立即砍除并且顯示警告信息。之所以要設(shè)定這個限制﹐純粹為了抵御那些簡單的?DoS?攻擊﹐千萬不要人為的降低這個限制﹐不過﹐如果網(wǎng)絡(luò)條件需要比默認值更多﹐則可以提高它(或許還要增加內(nèi)存)。(事實上做NAT的時候最好可以適當?shù)卦黾釉撝?
tcp_tw_recycle?：BOOLEAN
默認值是0
打開快速?TIME-WAIT?
sockets?回收。除非得到技術(shù)專家的建議或要求﹐請不要隨意修改這個值。(做NAT的時候，建議打開它)
?
tcp_tw_reuse：BOOLEAN
默認值是0
該文件表示是否允許重新應(yīng)用處于TIME-WAIT狀態(tài)的
socket用于新的TCP連接(這個對快速重啟動某些服務(wù),而啟動后提示端口已經(jīng)被使用的情形非常有幫助)
tcp_max_orphans?：INTEGER
缺省值是8192
系統(tǒng)所能處理不屬于任何進程的TCP?
sockets
最大數(shù)量。假如超過這個數(shù)量﹐那么不屬于任何進程的連接會被立即reset，并同時顯示警告信息。之所以要設(shè)定這個限制﹐純粹為了抵御那些簡單
的?DoS?攻擊﹐千萬不要依賴這個或是人為的降低這個限制(這個值Redhat?AS版本中設(shè)置為32768,但是很多防火墻修改的時候,建議該值修改
為2000)
tcp_abort_on_overflow?：BOOLEAN
缺省值是0
當守護進程太忙而不能接受新的連
接，就象對方發(fā)送reset消息，默認值是false。這意味著當溢出的原因是因為一個偶然的猝發(fā)，那么連接將恢復(fù)狀態(tài)。只有在你確信守護進程真的不能完
成連接請求時才打開該選項，該選項會影響客戶的使用。(對待已經(jīng)滿載的sendmail,apache這類服務(wù)的時候,這個可以很快讓客戶端終止連接,可
以給予服務(wù)程序處理已有連接的緩沖機會,所以很多防火墻上推薦打開它)
tcp_syncookies?：BOOLEAN
默認值是0
只有在內(nèi)核編譯時選擇了CONFIG_SYNCOOKIES時才會發(fā)生作用。當出現(xiàn)syn等候隊列出現(xiàn)溢出時象對方發(fā)送syncookies。目的是為了防止syn?flood攻擊。
注意：該選項千萬不能用于那些沒有收到攻擊的高負載服務(wù)器，如果在日志中出現(xiàn)synflood消息，但是調(diào)查發(fā)現(xiàn)沒有收到synflood攻擊，而是合法用戶的連接負載過高的原因，你應(yīng)該調(diào)整其它參數(shù)來提高服務(wù)器性能。參考:
tcp_max_syn_backlog
tcp_synack_retries
tcp_abort_on_overflow
syncookie
嚴重的違背TCP協(xié)議，不允許使用TCP擴展，可能對某些服務(wù)導(dǎo)致嚴重的性能影響(如SMTP轉(zhuǎn)發(fā))。(注意,該實現(xiàn)與BSD上面使用的
tcp?proxy一樣,是違反了RFC中關(guān)于tcp連接的三次握手實現(xiàn)的,但是對于防御syn-flood的確很有用.)
tcp_stdurg?：BOOLEAN
默認值為0
使用?TCP?urg?pointer?字段中的主機請求解釋功能。大部份的主機都使用老舊的?BSD解釋，因此如果您在?Linux?打開它﹐或會導(dǎo)致不能和它們正確溝通。
?
tcp_max_syn_backlog?：INTEGER
對
于那些依然還未獲得客戶端確認的連接請求﹐需要保存在隊列中最大數(shù)目。對于超過?128Mb?內(nèi)存的系統(tǒng)﹐默認值是?1024?﹐低于?128Mb?的則
為?128。如果服務(wù)器經(jīng)常出現(xiàn)過載﹐可以嘗試增加這個數(shù)字。警告﹗假如您將此值設(shè)為大于?1024﹐最好修改?include/net/tcp.h?里
面的?TCP_SYNQ_HSIZE?﹐以保持?TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog?﹐并且編進核心
之內(nèi)。(SYN?Flood攻擊利用TCP協(xié)議散布握手的缺陷，偽造虛假源IP地址發(fā)送大量TCP-SYN半打開連接到目標系統(tǒng)，最終導(dǎo)致目標系統(tǒng)
Socket隊
列資源耗?盡而無法接受新的連接。為了應(yīng)付這種攻擊，現(xiàn)代Unix系統(tǒng)中普遍采用多連接隊列處理的方式來緩沖(而不是解決)這種攻擊，是用一個基本隊列處
理正常的完?全連接應(yīng)用(Connect()和Accept()?)，是用另一個隊列單獨存放半打開連接。這種雙隊列處理方式和其他一些系統(tǒng)內(nèi)核措施(例
如Syn-Cookies/Caches)聯(lián)合應(yīng)用時，能夠比較有效的緩解小規(guī)模的SYN?Flood攻擊(事實證明<1000p/s)加大SYN
隊列長度可以容納更多等待連接的網(wǎng)絡(luò)連接數(shù)，所以對Server來說可以考慮增大該值.)
tcp_window_scaling?：INTEGER
缺省值為1
該?文
件表示設(shè)置tcp/ip會話的滑動窗口大小是否可變。參數(shù)值為布爾值，為1時表示可變，為0時表示不可變。tcp/ip通常使用的窗口最大可達
到?65535?字節(jié)，對于高速網(wǎng)絡(luò)，該值可能太小，這時候如果啟用了該功能，可以使tcp/ip滑動窗口大小增大數(shù)個數(shù)量級，從而提高數(shù)據(jù)傳輸?shù)哪芰?
(RFC?1323)。（對普通地百M網(wǎng)絡(luò)而言，關(guān)閉會降低開銷，所以如果不是高速網(wǎng)絡(luò)，可以考慮設(shè)置為0）
tcp_timestamps?：BOOLEAN
缺省值為1
Timestamps?用
在其它一些東西中﹐可以防范那些偽造的?sequence?號碼。一條1G的寬帶線路或許會重遇到帶?out-of-line數(shù)值的舊
sequence?號碼(假如它是由于上次產(chǎn)生的)。Timestamp?會讓它知道這是個?'舊封包'。(該文件表示是否啟用以一種比超時重發(fā)更精確的
方法（RFC?1323）來啟用對?RTT?的計算；為了實現(xiàn)更好的性能應(yīng)該啟用這個選項。)
tcp_sack?：BOOLEAN
缺省值為1
使?用?Selective?ACK﹐
它可以用來查找特定的遺失的數(shù)據(jù)報---?因此有助于快速恢復(fù)狀態(tài)。該文件表示是否啟用有選擇的應(yīng)答
（Selective?Acknowledgment），這可以通過有選擇地應(yīng)答亂序接收到的報文來提高性能（這樣可以讓發(fā)送者只發(fā)送丟失的報文
段）。(對于廣域網(wǎng)通信來說這個選項應(yīng)該啟用，但是這會增加對?CPU?的占用。)
tcp_fack?：BOOLEAN
缺省值為1
打開FACK擁塞避免和快速重傳功能。(注意，當tcp_sack設(shè)置為0的時候，這個值即使設(shè)置為1也無效)
tcp_dsack?：BOOLEAN
缺省值為1
允許TCP發(fā)送"兩個完全相同"的SACK。
tcp_ecn?：BOOLEAN
缺省值為0
打開TCP的直接擁塞通告功能。
tcp_reordering?：INTEGER
默認值是3
TCP流中重排序的數(shù)據(jù)報最大數(shù)量?。?(一般有看到推薦把這個數(shù)值略微調(diào)整大一些,比如5)
tcp_retrans_collapse?：BOOLEAN
缺省值為1
對于某些有bug的打印機提供針對其bug的兼容性。(一般不需要這個支持,可以關(guān)閉它)
tcp_wmem(3個INTEGER變量)：?min,?default,?max
min：為TCP?
socket預(yù)留用于發(fā)送緩沖的內(nèi)存最小值。每個tcp?
socket都可以在建議以后都可以使用它。默認值為4096(4K)。
default：為TCP?
socket預(yù)留用于發(fā)送緩沖的內(nèi)存數(shù)量，默認情況下該值會影響其它協(xié)議使用的net.core.wmem_default?值，一般要低于net.core.wmem_default的值。默認值為16384(16K)。
max:?用于TCP?
socket發(fā)
送緩沖的內(nèi)存最大值。該值不會影響net.core.wmem_max，"靜態(tài)"選擇參數(shù)SO_SNDBUF則不受該值影響。默認值為
131072(128K)。（對于服務(wù)器而言，增加這個參數(shù)的值對于發(fā)送數(shù)據(jù)很有幫助,在我的網(wǎng)絡(luò)環(huán)境中,修改為了
51200?131072?204800）
tcp_rmem?(3個INTEGER變量)：?min,?default,?max
min：為TCP?
socket預(yù)留用于接收緩沖的內(nèi)存數(shù)量，即使在內(nèi)存出現(xiàn)緊張情況下tcp?
socket都至少會有這么多數(shù)量的內(nèi)存用于接收緩沖，默認值為8K。
default：為TCP?
socket預(yù)
留用于接收緩沖的內(nèi)存數(shù)量，默認情況下該值影響其它協(xié)議使用的?net.core.wmem_default?值。該值決定了在
tcp_adv_win_scale、tcp_app_win和tcp_app_win=0默認值情況下，TCP窗口大小為65535。默認值為
87380
max：用于TCP?
socket接收緩沖的內(nèi)存最大值。該值不
會影響?net.core.wmem_max，"靜態(tài)"選擇參數(shù)?SO_SNDBUF則不受該值影響。默認值為?128K。默認值為
87380*2?bytes。（可以看出，.max的設(shè)置最好是default的兩倍,對于NAT來說主要該增加它,我的網(wǎng)絡(luò)里
為?51200?131072?204800）
tcp_mem(3個INTEGER變量)：low,?pressure,?high
low：當TCP使用了低于該值的內(nèi)存頁面數(shù)時，TCP不會考慮釋放內(nèi)存。(理想情況下，這個值應(yīng)與指定給?tcp_wmem?的第?2?個值相匹配?-?這第?2?個值表明，最大頁面大小乘以最大并發(fā)請求數(shù)除以頁大小?(131072?*?300?/?4096)。?)
pressure：
當TCP使用了超過該值的內(nèi)存頁面數(shù)量時，TCP試圖穩(wěn)定其內(nèi)存使用，進入pressure模式，當內(nèi)存消耗低于low值時則退出pressure狀
態(tài)。(理想情況下這個值應(yīng)該是?TCP?可以使用的總緩沖區(qū)大小的最大值?(204800?*?300?/?4096)。?)
high：允許所有tcp?
sockets
用于排隊緩沖數(shù)據(jù)報的頁面量。(如果超過這個值，TCP?連接將被拒絕，這就是為什么不要令其過于保守?(512000?*?300?/?4096)?的
原因了。?在這種情況下，提供的價值很大，它能處理很多連接，是所預(yù)期的?2.5?倍；或者使現(xiàn)有連接能夠傳輸?2.5?倍的數(shù)據(jù)。?我的網(wǎng)絡(luò)里為
192000?300000?732000)
一般情況下這些值是在系統(tǒng)啟動時根據(jù)系統(tǒng)內(nèi)存數(shù)量計算得到的。
tcp_app_win?:?INTEGER
默認值是31
保留max(window/2^tcp_app_win,?mss)數(shù)量的窗口由于應(yīng)用緩沖。當為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
這個開關(guān)可以啟動對于在RFC1337中描述的"tcp?的time-wait暗殺危機"問題的修復(fù)。啟用后，內(nèi)核將丟棄那些發(fā)往time-wait狀態(tài)TCP套接字的RST?包.
?
tcp_low_latency?:?BOOLEAN
缺省值為0
允許?TCP/IP?棧適應(yīng)在高吞吐量情況下低延時的情況；這個選項一般情形是的禁用。(但在構(gòu)建Beowulf?集群的時候,打開它很有幫助)
?
tcp_westwood?:BOOLEAN
缺省值為0
啟用發(fā)送者端的擁塞控制算法，它可以維護對吞吐量的評估，并試圖對帶寬的整體利用情況進行優(yōu)化；對于?WAN?通信來說應(yīng)該啟用這個選項。
?
tcp_bic?:BOOLEAN
缺省值為0
為快速長距離網(wǎng)絡(luò)啟用?Binary?Increase?Congestion；這樣可以更好地利用以?GB?速度進行操作的鏈接；對于?WAN?通信應(yīng)該啟用這個選項。
?
?
?
#?以下一段為抵抗syn?flood攻擊，平時建議關(guān)閉
sysctl?-w?net.ipv4.tcp_syncookies=1??????????????#?tcp?syncookie，默認關(guān)閉
sysctl?-w?net.ipv4.tcp_max_syn_backlog=1280???#?syn隊列，默認1024，>?1280可能工作不穩(wěn)定，需要修改內(nèi)核源碼參數(shù)
sysctl?-w?net.ipv4.tcp_synack_retries=2?????????????#?syn-ack握手狀態(tài)重試次數(shù)，默認5，遭受syn-flood攻擊時改為1或2
sysctl?-w?net.ipv4.tcp_syn_retries=2??????????????????#?外向syn握手重試次數(shù)，默認4
?
?
#?以下一段為應(yīng)對tcp?connect連接耗盡攻擊，如果開啟iptables?connlimit模塊可禁用
#?有嚴重連接性能影響和不穩(wěn)定因素，慎用
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探測輪詢次數(shù)
sysctl?-w?tcp_keepalive_time=1800????????????????#?默認7200，tcp?keeplive時間
sysctl?-w?tcp_fin_timeout=30????????????????????????#?默認60，tcp?fin狀態(tài)超時時間
#sysctl?-w?net.ipv4.tcp_retries1=2?????????????????????#?tcp連接重傳參數(shù)，慎用
#sysctl?-w?net.ipv4.tcp_retries2=8
?
sysctl?-w?net.ipv4.ip_conntrack_max=65535??????????#?增大iptables狀態(tài)跟蹤表
待驗證：
?1.（客戶端問題） ?
? ? ? 包阻塞的情況多發(fā)生于緩沖區(qū)域充滿了數(shù)據(jù)，客戶端不再進行讀取操作時。 ?
? ? ? 這種情況下，可能是由于客戶端的處理節(jié)奏慢于接受包的速度，可以考慮 ?
? ? ? 將包處理過程放入線程處理，而對包的接受采用阻塞的方式。 ?
? 2.（服務(wù)器端問題） ?
? ? ? 由于數(shù)據(jù)包頭中部分變量的類型定義不合理而引起包的流水號越界或溢出， ?
? ? ? 都可能導(dǎo)致服務(wù)器端出現(xiàn)core文件或異常停止。建議如果有在包頭中定義 ?
? ? ? 流水號等，用long型變量。 ?
? 3.（協(xié)議包問題） ?
? ? ? 在大數(shù)據(jù)量傳輸中，盡量減少網(wǎng)絡(luò)資源的重復(fù)使用次數(shù)，所以在網(wǎng)絡(luò)狀況 ?
? ? ? 佳的情況下，建議將原有的包體長度適當?shù)臄U大。如2k擴大到30k左右， ?
? ? ? 同時可以減少客戶端的處理次數(shù)。