如何從TCP/IP協議討論Linux內核參數優化

這篇文章給大家介紹如何從TCP/IP協議討論Linux內核參數優化，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

在硬件資源有限的情況下，最大的壓榨服務器性能，提高服務器的并發處理能力，是很多技術人員思考的問題，除了優化Nginx/PHP-FPM/Mysql/Redis這類服務軟件配置外，還可以通過修改Linux的內核相關TCP參數，來最大的提高服務器性能。

在Linux內核參數優化之前，我們需要先搞懂TCP/IP協議，這是我們實施優化的理論依據。

TCP/IP協議

TCP/IP協議是十分復雜的協議，完全掌握不是一件容易的事情，但作為基本知識，我們必須知道TCP/IP協的三次握手和四次揮手的邏輯過程。

三次握手

所謂三次握手是指建立一個 TCP  連接時需要客戶端和服務器端總共發送三個包以確認連接的建立。在socket編程中，這一過程由客戶端執行connect來觸發。

三次握手流程圖：

三次握手流程

第一次握手：客戶端將標志位SYN置為1，隨機產生一個值seq=J，并將該數據包發送給服務器端，客戶端進入SYN_SENT狀態，等待服務器端確認。

第二次握手：服務器端收到數據包后由標志位SYN=1知道客戶端請求建立連接，服務器端將標志位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，并將該數據包發送給客戶端以確認連接請求，服務器端進入SYN_RCVD狀態。

第三次握手：客戶端收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數據包發送給服務器端，服務器端檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端和服務器端進入ESTABLISHED狀態，完成三次握手，隨后客戶端與服務器端之間可以開始傳輸數據了。

四次揮手

四次揮手即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發送4個包以確認連接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發。

由于TCP連接是全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成數據發送任務后，發送一個FIN來終止這一方向的連接，收到一個FIN只是意味著這一方向上沒有數據流動了，即不會再收到數據了，但是在這個TCP連接上仍然能夠發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉。

四次揮手的流程圖：

四次揮手流程

• 中斷連接端可以是客戶端，也可以是服務器端。

• 第一次揮手：客戶端發送一個FIN=M，用來關閉客戶端到服務器端的數據傳送，客戶端進入FIN_WAIT_1狀態。意思是說”我客戶端沒有數據要發給你了”，但是如果你服務器端還有數據沒有發送完成，則不必急著關閉連接，可以繼續發送數據。

• 第二次揮手：服務器端收到FIN后，先發送ack=M+1，告訴客戶端，你的請求我收到了，但是我還沒準備好，請繼續你等我的消息。這個時候客戶端就進入FIN_WAIT_2狀態，繼續等待服務器端的FIN報文。

• 第三次揮手：當服務器端確定數據已發送完成，則向客戶端發送FIN=N報文，告訴客戶端，好了，我這邊數據發完了，準備好關閉連接了。服務器端進入LAST_ACK狀態。

• 第四次揮手：客戶端收到FIN=N報文后，就知道可以關閉連接了，但是他還是不相信網絡，怕服務器端不知道要關閉，所以發送ack=N+1后進入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳。服務器端收到ACK后，就知道可以斷開連接了。客戶端等待了2MSL后依然沒有收到回復，則證明服務器端已正常關閉，那好，我客戶端也可以關閉連接了。最終完成了四次握手。

序列號與確認應答

大家都知道TCP/IP協議是以一種高可靠的通信協議，通過序列號與確認應答來保障通信高可靠，有如下幾個關鍵點：

• 當發送端的數據到達接收主機時，接收端主機會返回一個已收到消息的通知。這個消息叫做確認應答(ACK)。當發送端將數據發出之后會等待對端的確認應答。如果有確認應答，說明數據已經成功到達對端。反之，則數據丟失的可能性很大。

• 在一定時間內沒有等待到確認應答，發送端就可以認為數據已經丟失，并進行重發。由此，即使產生了丟包，仍然能夠保證數據能夠到達對端，實現可靠傳輸。

• 未收到確認應答并不意味著數據一定丟失。也有可能是數據對方已經收到，只是返回的確認應答在途中丟失。這種情況也會導致發送端誤以為數據沒有到達目的地而重發數據。

• 此外，也有可能因為一些其他原因導致確認應答延遲到達，在源主機重發數據以后才到達的情況也屢見不鮮。此時，源主機只要按照機制重發數據即可。

• 對于目標主機來說，反復收到相同的數據是不可取的。為了對上層應用提供可靠的傳輸，目標主機必須放棄重復的數據包。為此我們引入了序列號。

• 序列號是按照順序給發送數據的每一個字節(8位字節)都標上號碼的編號。接收端查詢接收數據 TCP  首部中的序列號和數據的長度，將自己下一步應該接收的序列號作為確認應答返送回去。通過序列號和確認應答號，TCP  能夠識別是否已經接收數據，又能夠判斷是否需要接收，從而實現可靠傳輸。

• 重發超時是指在重發數據之前，等待確認應答到來的那個特定時間間隔。如果超過這個時間仍未收到確認應答，發送端將進行數據重發。最理想的是，找到一個最小時間，它能保證“確認應答一定能在這個時間內返回”。

• TCP  要求不論處在何種網絡環境下都要提供高性能通信，并且無論網絡擁堵情況發生何種變化，都必須保持這一特性。為此，它在每次發包時都會計算往返時間及其偏差。將這個往返時間和偏差時間相加，重發超時的時間就是比這個總和要稍大一點的值。

• 數據被重發之后若還是收不到確認應答，則進行再次發送。此時，等待確認應答的時間將會以2倍、4倍的指數函數延長。

• 此外，數據也不會被無限、反復地重發。達到一定重發次數之后，如果仍沒有任何確認應答返回，就會判斷為網絡或對端主機發生了異常，強制關閉連接。并且通知應用通信異常強行終止。

TCP/IP協議缺陷

了解了TCP/IP協議之后，我們就會發現幾個問題：

• 在三次握手中，如果客戶端發起第一次握手后就中斷或者不響應服務器發回的ACK=1數據包，那服務器就會不斷的重試發送數據包，直到超時。 沒錯，這就是SYN  FLOOD攻擊原理。

• 在四次揮手中，主動關閉連接的客戶端處在TIME_WAIT狀態后，會一直持續2MSL時間長度，MSL就是maximum segment  lifetime(最大分節生命期)，這是一個IP數據包能在互聯網上生存的最長時間，超過這個時間將在網絡中消失(TIME_WAIT狀態一般維持在1-4分鐘)。通過2MSL時間長度來確保舊的連接狀態不會對新連接產生影響。處于TIME_WAIT狀態的連接占用的資源不會被內核釋放，所以作為服務器，在可能的情  況下，盡量不要主動斷開連接，以減少TIME_WAIT狀態造成的資源浪費。如果我們的服務器是負載均衡服務器，上游服務器長時間沒有影響，負載均衡服務器將主動關閉鏈接，高并發場景下將導致TIME_WAIT狀態的累積。

• 在四次揮手中，如果客戶端在收到FIN 報文后，應用沒有返回  ACK，服務端同樣會不斷嘗試發送FIN報文，這樣服務端就會出現CLOSE_WAIT狀態的累積。

SYN Flood攻擊

Syn  Flood攻擊是當前網絡上最為常見的DDoS攻擊，也是最為經典的拒絕服務攻擊，它利用了TCP協議實現上的一個缺陷，通過向網絡服務所在端口發送大量的偽造源地址的攻擊報文，就可能造成目標服務器中的半開連接隊列被占滿，從而阻止其他合法用戶進行訪問。

Syn Flood攻擊原理

攻擊者首先偽造地址對服務器發起SYN請求(我可以建立連接嗎?)，服務器就會回應一個ACK+SYN(可以+請確認)。而真實的IP會認為，我沒有發送請求，不作回應。服務器沒有收到回應，會重試3-5次并且等待一個SYN  Time(一般30秒-2分鐘)后，丟棄這個連接。

如果攻擊者大量發送這種偽造源地址的SYN請求，服務器端將會消耗非常多的資源來處理這種半連接，保存遍歷會消耗非常多的CPU時間和內存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。TCP是可靠協議，這時就會重傳報文，默認重試次數為5次，重試的間隔時間從1s開始每次都番倍，分別為1s  + 2s + 4s + 8s +16s = 31s,第5次發出后還要等32s才知道第5次也超時了，所以一共是31 + 32 = 63s。

一段假的syn報文，會占用TCP準備隊列63s之久，而半連接隊列默認為1024，在沒有任何防護的情況下，每秒發送20個偽造syn包，就足夠撐爆半連接隊列，從而使真正的連接無法建立，無法響應正常請求。  最后的結果是服務器無暇理睬正常的連接請求—拒絕服務。

內核TCP參數優化

編輯文件/etc/sysctl.conf，加入以下內容：

net.ipv4.tcp_fin_timeout = 2 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_keepalive_time = 600 net.ipv4.ip_local_port_range = 4000 65000 net.ipv4.tcp_max_syn_backlog = 16384 net.ipv4.tcp_max_tw_buckets = 36000 net.ipv4.route.gc_timeout = 100 net.ipv4.tcp_syn_retries = 1 net.ipv4.tcp_synack_retries = 1 net.core.somaxconn = 16384 net.core.netdev_max_backlog = 16384 net.ipv4.tcp_max_orphans = 16384

然后執行 sysctl -p 讓參數生效。

作用說明：

• net.ipv4.tcp_fin_timeout 表示套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間，默認值是60秒。  該參數對應系統路徑為：/proc/sys/net/ipv4/tcp_fin_timeout 60

• net.ipv4.tcp_tw_reuse 表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認值為0，表示關閉。  該參數對應系統路徑為：/proc/sys/net/ipv4/tcp_tw_reuse 0

• net.ipv4.tcp_tw_recycle 表示開啟TCP連接中TIME-WAIT sockets的快速回收。  該參數對應系統路徑為：/proc/sys/net/ipv4/tcp_tw_recycle，默認為0，表示關閉。  提示：reuse和recycle這兩個參數是為防止生產環境下Web、Squid等業務服務器time_wait網絡狀態數量過多設置的。

• net.ipv4.tcp_syncookies 表示開啟SYN  Cookies功能。當出現SYN等待隊列溢出時，啟用Cookies來處理，可防范少量SYN攻擊，這個參數也可以不添加。  該參數對應系統路徑為：/proc/sys/net/ipv4/tcp_syncookies,默認值為1

• net.ipv4.tcp_keepalive_time  表示當keepalive啟用時，TCP發送keepalive消息的頻度。默認是2小時，建議改為10分鐘。  該參數對應系統路徑為：/proc/sys/net/ipv4/tcp_keepalive_time,默認為7200秒。

• net.ipv4.ip_local_port_range 該選項用來設定允許系統打開的端口范圍，即用于向外連接的端口范圍。  該參數對應系統路徑為：/proc/sys/net/ipv4/ip_local_port_range 32768 61000

• net.ipv4.tcp_max_syn_backlog  表示SYN隊列的長度，默認為1024，建議加大隊列的長度為8192或更多，這樣可以容納更多等待連接的網絡連接數。  該參數為服務器端用于記錄那些尚未收到客戶端確認信息的連接請求最大值。  該參數對象系統路徑為：/proc/sys/net/ipv4/tcp_max_syn_backlog

• net.ipv4.tcp_max_tw_buckets  表示系統同時保持TIME_WAIT套接字的最大數量，如果超過這個數值，TIME_WAIT套接字將立刻被清除并打印警告信息。  默認為180000，對于Apache、Nginx等服務器來說可以將其調低一點，如改為5000~30000，不通業務的服務器也可以給大一點，比如LVS、Squid。  此項參數可以控制TIME_WAIT套接字的最大數量，避免Squid服務器被大量的TIME_WAIT套接字拖死。  該參數對應系統路徑為：/proc/sys/net/ipv4/tcp_max_tw_buckets

• net.ipv4.tcp_synack_retries 參數的值決定了內核放棄連接之前發送SYN+ACK包的數量。  該參數對應系統路徑為：/proc/sys/net/ipv4/tcp_synack_retries,默認值為5

• net.ipv4.tcp_syn_retries 表示在內核放棄建立連接之前發送SYN包的數量。  該參數對應系統路徑為：/proc/sys/net/ipv4/tcp_syn_retries 5

• net.ipv4.tcp_max_orphans 用于設定系統中最多有多少個TCP套接字不被關聯到任何一個用戶文件句柄上。  如果超過這個數值，孤立連接將被立即被復位并打印出警告信息。  這個限制只有為了防止簡單的DoS攻擊。不能過分依靠這個限制甚至認為減少這個值，更多的情況是增加這個值。  該參數對應系統路徑為：/proc/sys/net/ipv4/tcp_max_orphans 65536

• net.core.somaxconn  該選項默認值是128，這個參數用于調節系統同時發起的TCP連接數，在高并發的請求中，默認的值可能會導致鏈接超時或重傳，因此，需要結合并發請求數來調節此值。  該參數對應系統路徑為：/proc/sys/net/core/somaxconn 128

• net.core.netdev_max_backlog 表示當每個網絡接口接收數據包的速率比內核處理這些包的速率快時，允許發送到隊列的數據包最大數。  該參數對應系統路徑為：/proc/sys/net/core/netdev_max_backlog，默認值為1000 

關于如何從TCP/IP協議討論Linux內核參數優化就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。