[tcp] WEB服務,Linux下的內核參數調優

前言:
web類應用通常會部署像nginx、tomcat、php等應用程序，使用默認的內核參數設置知足大部分場景，若是優化內核參數，也能夠釋放很多服務器性能，尤爲是在高併發下

一.SYN狀態的內核參數調優

大量SYN_SENT
這種是主動鏈接服務端，而未獲得響應，也就是SYN超時，通常是服務端根本不存在或者沒法訪問
如，我隨便telnet一個位置的IP和端口

telnet 172.18.11.110:90
[root@test bbs]# ss -an|grep SYN
SYN-SENT   0      1            172.16.196.145:55052        172.18.11.110:90

除了以上，還有種就是你的服務出現異常，好比mysql服務器宕機了，web服務去訪問mysql數據庫的時候就連不上，也會出現SYN_SENT狀態，但不管哪一種，都是主動發起鏈接致使的，所以業務上解決更好

net.ipv4.tcp_syn_retries = 2
新建鏈接若是無響應，內核要發送多少次SYN鏈接才放棄，默認值爲5

在Linux下，默認重試次數爲5次，該值不能大於255，重試的間隔時間從1s開始每次都翻倍(由於隔一秒重試後還會等待響應，所以其實是從3秒開始)，5次的重試時間間隔爲3s, 7s, 15s, 31s, 63s，總共63s，TCP纔會把斷開這個鏈接。統計成公式2^(n+1) - 1，所以設置越大，翻倍越多，對應內網環境，這個值修改成2比較合適

大量SYN_RECV
大量的SYN出現有兩種狀況，多是攻擊，也多是正常的業務請求，不管哪一種，都大量的佔用了服務器資源

net.ipv4.tcp_synack_retries = 2
跟參數net.ipv4.tcp_syn_retries同樣，只是這個內核參數是控制迴應SYN失敗的重試次數，默認值也是5，和上面同樣修改成2

其餘內核參數調整
net.ipv4.tcp_syncookies = 1
開啓SYN cookies，當出現SYN等待隊列溢出時，啓動cookies來處理

什麼是SYN cookies?咱們知道SYN攻擊是一系列僞造IP源地址的SYN包，IP地址是隨意選擇且不提供攻擊者任何的線索，SYN攻擊持續直到服務的SYN隊列被用滿。若是啓用該參數，此時SYN cookies會將TCP請求的SYN緩存起來，當服務器正常的時候，再處理，可是若是攻擊併發很高很大，其實用處不大，所以只能少許防範

SYN cookies可參考:https://blog.csdn.net/chenmo1...

net.ipv4.tcp_max_syn_backlog = 65535
指定所能接受SYN同步包的最大客戶端數量，即半鏈接上限，默認值爲128，對於web服務，頻繁大量的SYN同步包，應該放大這個值

注:這個值應該>=net.core.somaxconn，net.core.somaxconn後面會提到

二.FIN_WAIT_2狀態的內核參數調優

FIN_WAIT_2是主動關閉端等待對端關閉鏈接的狀態，若是被動關閉不發送FIN關閉鏈接，那麼這個狀態就會一直存在，固然Linux有針對該狀態的超時時間，默認爲60秒

net.ipv4.tcp_fin_timeout = 10

三.TIME_WAIT狀態的內核參數調優

TIME_WAIT是主動關閉端的狀態，也稱爲2MSL等待狀態，也就是2倍的MSL時間。在RFC 793[Postel 1981c]指出MSL爲2分鐘，然而現實中的經常使用值是30秒，1分鐘或者2分鐘(Linux設置爲30秒)，Linux也沒有提供可以修改TIME_WAIT狀態時間的接口，除非從新編譯系統內核

MSL的理解
MSL是英文Maximum Segment Lifetime的縮寫，翻譯爲"最長報文段壽命"，每一個具體TCP實現必須選擇一個報文段最大生存時間(Maximum Segment Lifetime)，而這個最大生存時間是任何報文段被丟棄前在網絡內的最長時間

MSL的時間是有限的，由於TCP報文段以IP數據報在網絡內傳輸，而IP數據報則有限制其生存時間的TTL(time to live)字段，TTL可譯爲生存時間，IP數據報每通過一個路由器，它的值就減1，當這個值爲0時，數據報則被丟棄

爲何等待2MSL
1.確保有足夠的時間讓服務端收到ACK，如沒有收到，則會響應對方新的FIN+ACK封包。好比主動關閉端(客戶端)發送了最後一個ACK報文段給被動關閉端(服務端)，但這個ACK報文段有可能丟失，若是服務端沒有收到這個ACK，那麼處於LAST_ACK的服務端在超時後回重發FIN+ACK報文段，這樣客戶端就能在2MSL時間內收到這個重發的FIN+ACK報文段。若是客戶端發送了最後的ACK報文不進入TIME_WAIT而是當即釋放鏈接，那麼就沒法收到客戶端重發的FIN+ACK報文段。所以等待2MSL是爲了更安全的斷開鏈接

2.有足夠的時間讓處於TIME_WAIT狀態的鏈接不會跟後面的鏈接混在一塊兒。好比一些延遲的包發過來，可是若是沒有TIME_WAIT，那麼就發到了新鏈接上，這樣就混爲一團，而若是是TIME_WAIT，則會丟棄這些延遲的包

等待2MSL的缺點
TCP鏈接在2MSL等待期間，這個處於TIME_WAIT狀態的鏈接(客戶端的IP地址和端口編號，服務器的IP地址和端口號)不能再被使用，它只能在2MSL結束後才能再被使用，而這些TIME_WAIT狀態佔用大量服務資源，對於web服務來講是不合理的

修改內核參數防止由於2MSL致使TIME_WAIT過多
對於web服務器，因爲咱們須要常常去鏈接mysql、redis或者一些RPC調用等，會有大量的主動關閉狀態(TIME_WAIT)，所以能夠修改內核參數限制TIME_WAIT的數量

net.ipv4.tcp_max_tw_buckets = 20000
限制timewait 的數量，防止大量timewait致使系統負載升高，一旦達到限定值，則強制清理TIME_WAIT狀態的鏈接並在打印系統日誌(time wait bucket table overflow)，該參數官方文檔說明主要用來對抗DDos攻擊

net.ipv4.tcp_tw_recycle= 1
啓用timewait快速回收

net.ipv4.tcp_timestamps = 0
時間戳，0關閉，1開啓。不能和net.ipv4.tcp_tw_recycle參數同時開啓，由於一旦開啓net.ipv4.tcp_tw_recycle，服務器就會檢查包的時間戳，若是對方發來的包的時間戳是亂跳或者說時間戳是滯後的，這樣服務器就不會回覆，服務器會把帶了"倒退"的時間戳包看成是"recycle"的tw鏈接的重傳數據，不是新的請求，因而丟掉不回包，就容易出現syn不響應

net.ipv4.tcp_tw_reuse = 1
開啓重用，容許將TIME-WAIT sockets 從新用於新的TCP 鏈接

TIME_WAIT總結
其實TIME_WAIT是主動斷開鏈接，因此若是讓對方主動斷開鏈接的話，那麼這個TIME_WAIT問題就對方的了。因此若是這個問題出現過多，多從業務着手，好比HTTP服務，NGINX設置keepalive參數(瀏覽器會重用一個TCP鏈接來處理多個HTTP請求)，而後讓客戶端斷開鏈接，固然這個要設置好keepalive_timeout的超時時間，由於有些瀏覽器可能不會主動斷開鏈接

而若是是主動鏈接mysql、redis等後端調用，能夠考慮使用長鏈接來避免TIME_WAIT過多的問題

四.長鏈接(keepalive)的內核參數調整

Linux下，keepalive不是默認開啓，也無內核參數控制，它須要在TCP的socket中單獨開啓，Linux內核影響keepalive的參數目的僅僅是探測TCP鏈接是否存活，而後處理異常鏈接

net.ipv4.tcp_keepalive_time = 120 單位秒，表示TCP鏈接在多少秒沒有數據報文傳輸時啓動探測報文，探測鏈接是否正常
net.ipv4.tcp_keepalive_intvl = 5 單位秒，先後探測報文之間的時間間隔
net.ipv4.tcp_keepalive_probes = 3 探測次數，超過設置後丟棄

五.TCP/UDP內存參數調整

(1)TCP內存使用設置

針對TCP socket buffer
net.ipv4.tcp_mem = 94500000 915000000 927000000
指定TCP內存的總體使用情況，單位爲頁。這3個值爲TCP總體內存【低、壓力、高】，在web服務中，放大這個值便可
第一個值tcp_mem[0]：當TCP全局分配的頁數低於此數時，TCP不調整其內存分配
第二個值tcp_mem[1]：當TCP分配的內存量超過這個頁數，進入內存壓力模式，TCP調節內存消耗
第三個值tcp_mem[2]：TCP全局使用的最大頁數分配，這個會值覆蓋任何其餘限制，如超過，全部的新的TCP的buffer(緩衝區)內存分配都會失敗

其實咱們能夠設置這個值較大，只要不限制系統分配內存，而後以監控來應對內存問題，通常來講，根據業務所選配置，很難將內存耗盡，不然優化的就不只僅是這個參數了

net.ipv4.tcp_rmem = 4096 87380 6291456
net.ipv4.tcp_wmem = 4096 16384 4194304
上面兩組參數表示單個TCP鏈接上的讀寫buffer(緩衝)內存上限，單位字節，這三個值分別爲最小值、默認值(會覆蓋rmem_default、wmem_default配置)、最大值

最小值:TCP socket的發送緩衝區(tcp_rmem)/接收緩衝區(tcp_wmem)的內存，默認1頁(4K)

默認值:TCP socket使用的發送緩衝區(tcp_rmem)/接收緩衝區(tcp_wmem)初始大小，這個值會覆蓋(net.core.wmem_default/net.core.rmem_default)，通常設置要低於(net.core.wmem_default/net.core.rmem_default)這個值，默認值爲16K

最大值:TCP socket使用的發送緩衝區(tcp_rmem)/接收緩衝區(tcp_wmem)的最大大小，這個值不會覆蓋(net.core.wmem_max/net.core.rmem_max)，默認爲4M

這兩個內核參數的設置主要是針對每個TCP鏈接來講的，使用默認設置就差很少了，若是設置太大，單個TCP鏈接佔用過多內存也是有問題的

什麼是TCP讀寫buffer(緩衝)？
實際上，TCP鏈接所用內存的多少是由讀寫buffer大小決定，對讀buffer來說，當收到對端鏈接的TCP報文時，會致使讀buffer內存增長，若是這個報文加上當前讀buffer內存超過tcp_rmem[3]上限，那麼該報文將被丟棄。只有當調用read、recv這樣的方法讀取TCP流時，讀buffer內存就會減小，所以讀buffer內存是一個動態變化的，用多少就分配多少buffer，若是這個鏈接空閒時，而用戶進程已經把鏈接上收到的數據都消費了，那麼讀buffer使用的內存就爲0了

對於寫buffer也是同樣的，在socket編程中，當調用send或者write時，就會形成寫buffer增大，那麼何時減小？就是當接收到對端TCP鏈接發來的ACK確認了報文成功發送時，寫buffer就會減小，相似於我給你發一個文件，我先拷貝出來發給你，我確認你收到了，我就把這個源文件刪除，以避免佔用空間，若是確認沒收到，那麼我會重發

因此讀寫buffer是一直不停變化的，那麼怎樣的場景會致使讀寫buffer達到上限呢？就讀buffer而言，好比接收TCP對端報文，對端發了不少不少報文，我讀取後沒法及時讀取(read和recv)，致使讀buffer堆積愈來愈多，最終達到上限，最後丟棄報文，寫buffer也同樣，send或者write大量的報文時，若是TCP對端不能及時read和recv就會致使寫buffer堆積。

針對系統的讀寫buffer參數調整
net.core.rmem_default = 4194304 默認讀buffer大小，單位字節
net.core.wmem_default = 4194304 默認寫buffer大小，單位字節
net.core.rmem_max = 4194304 最大讀buffer大小，單位字節
net.core.wmem_max = 4194304 最大寫buffer大小，單位字節
看到其定義，是否是以爲跟net.ipv4.tcp_mem、net.ipv4.tcp_rmem、net.ipv4.tcp_wmem含義很重合呢？

其實(net.ipv4.tcp_mem、net.ipv4.tcp_rmem、net.ipv4.tcp_wmem)這幾個參數只控制TCP socket的內存大小，並且若是遇到TCP socket申請內存，(net.core.rmem_default、net.core.wmem_default)會被(net.ipv4.tcp_rmem、net.ipv4.tcp_wmem)覆蓋

因此(net.core.rmem_default、net.core.wmem_default、net.core.rmem_max、net.core.wmem_max)控制系統全部協議的讀寫buffer大小

(2)UDP協議內存使用設置

net.ipv4.udp_mem = 752832 1003776 1505664
net.ipv4.udp_rmem_min = 4096
net.ipv4.udp_wmem_min = 4096
這幾個參數針對UDP協議，則跟上面TCP的含義一致

六.其餘內核參數

net.ipv4.ip_local_port_range = 1024 65000
表示用於向外鏈接的臨時端口範圍。缺省狀況下很小：32768到61000，由於主動鏈接須要用到不少臨時端口(如鏈接mysql、redis)，而臨時端口最大值爲(2^16-1)65535，1000以前通常爲系統保留端口，因此建議設置爲1024到65000的較大範圍

net.core.somaxconn = 65535
net.core.somaxconn表示socket監聽(listen)的backlog上限，backlog是socket的監聽隊列，也就是服務端所能accept(socket編程中accpet()函數爲創建TCP鏈接接受鏈接狀態)即處理數據的最大客戶端數量隊列，默認值爲128，若是隊列滿了的時候新來一條創建鏈接，該鏈接會被拒絕

該值應當小於等於net.ipv4.tcp_max_syn_backlog，由於net.ipv4.tcp_max_syn_backlog參數控制的SYN隊列客戶端的數量，還在創建鏈接以前，所以設置爲65535同樣比較合適

fs.file-max = 6553600
設置系統全部進程一共能夠打開多少個文件句柄，這是一個系統級的設置，管控的是全部進程總共能夠同時打開多少文件句柄，若是多個進程打開了較多文件就會致使文件句柄不足，所以設置較大值，不過要注意程序打開的文件越多，就佔用更多的內存，所以要根據業務和服務器配置起來設置

若是想單獨對某個進程設置能夠打開多少文件句柄，那麼可使用ulimit -n命令設置，但該命令只對當前session生效，默認值爲1024
ulimit -n 655350

也能夠寫入文件永久生效，對每一個進程的打開文件數量限制
vim /etc/security/limits.conf
* soft nofile 655350
* hard nofile 655350

總結

如今多數線上業務，服務器不多暴露在外網了，前端通常有負載均衡、防火牆等代理。甚至服務器已經變成VPC(虛擬內網)環境，將這些服務器隔離在外網環境以外，這樣就減小了像DDOS等攻擊，這些攻擊通常都讓外部代理承受了。

對於服務器的一些內核性能參數範圍，若是網絡環境及架構設計好，一些範圍參數能夠設置的偏大，性能偏極限一些，這樣能最大釋放服務器的性能，其餘的就用系統默認的參數配置便可。對於WEB服務的優化，是多方面的，內核參數僅僅是釋放了服務器本該有的性能，而更高的承載能力，須要從服務器配置、網絡、架構、數據庫及緩存和實際業務應用等多方面着手，不一樣的調整知足不一樣的需求

RT:以上有些地方可能會解釋得不對，還望指正，一塊兒學習