簡介：Linux系統TCP內核參數優化總結

日常運維工作中，會遇到很多TCP相關的問題，網上有很多文章介紹需要優化哪些TCP內核參數，但是并沒有很詳細說明優化的依據、適用的場景是什么，如果我們不了解各個參數實際的作用，照搬網上的配置到生產環境，很有可能會適得其反，本文從建立連接、數據傳輸、斷開連接三個階段對涉及到的相關TCP內核參數做出說明并給出優化建議。

圖1：TCP連接狀態變遷圖

1. 建立連接階段

• net.ipv4.tcp_syn_retries
  控制三次握手第一步客戶端發送syn得不到服務端響應時重傳syn的次數，如果是內網環境，中間鏈路少，網絡穩定，服務端無響應很可能是服務端應用出了問題，重傳多次的意義不大，還會加大服務端壓力，可以調低重傳次數，讓客戶端盡快去嘗試連接其他服務端。
  
• net.ipv4.tcp_syncookies
  開啟SYN Cookies，默認開啟，建議保持默認值，可以提升SYN Flood攻擊的防護能力。
  
• net.ipv4.tcp_synack_retries
  控制三次握手第二步服務端發送syn+ack得不到客戶端響應時重傳syn+ack的次數，如果是內網環境，中間鏈路少，網絡穩定，客戶端無響應很可能是客戶端出了問題，重傳多次的意義不大，可以調低重傳次數。
  
• net.ipv4.tcp_max_syn_backlog
  控制半連接隊列大小，所謂半連接是指還沒有完成TCP三次握手的連接。服務端收到了客戶端的SYN包后，就會把這個連接放到半連接隊列中，然后再向客戶端發送SYN+ACK，為了應對新建連接數暴增的場景，建議調大，半連接隊列溢出觀察方法：netstat -s | grep "SYNs to LISTEN"
  
• net.core.somaxconn
  全連接隊列=min（somaxconn，backlog），所謂全連接，是指服務端已經收到客戶端三次握手第三步的ACK，然后就會把這個連接放到全連接隊列中，全連接隊列中的連接還需要被 accept()系統調用取走，服務端應用才可以開始處理客戶端的請求，建議適當調大，全連接隊列溢出觀察方法：netstat -s | grep "listen queue"
  
• net.ipv4.tcp_abort_on_overflow
  當全連接隊列滿了之后，新的連接就會被丟棄掉。服務端在丟棄新連接時，默認行為是直接丟棄不去通知客戶端，有的時候需要發送reset來通知客戶端，這樣客戶端就不會再次重試，至于是否需要給客戶端發送reset，是由tcp_abort_on_overflow參數控制，默認為0，即不發送reset給客戶端，如非特殊需求，建議保持默認值。

2. 數據傳輸階段

• net.ipv4.tcp_wmem
  tcp發送緩沖區大小，包含min、default、max三個值，內核會控制發送緩沖區在min-max之間動態調整，可根據實際業務場景和服務器配置適當調大，如果設置了socket的SO_SNDBUF，動態調整功能失效，一般不建議設置。
  
• net.core.wmem_max
  socket發送緩沖區的最大值，需要設置net.core.wmem_max的值大于等于 net.ipv4.tcp_wmem的max值。
  
• net.ipv4.tcp_mem
  系統中所有tcp連接最多可消耗的內存，有三個值，當TCP總內存小于第1個值時，不需要內核進行自動調節，在第1和第2個值之間時，內核開始調節緩沖區的大小，大于第3個值時，內核不再為TCP分配新內存，此時無法新建連接，需要注意的是，三個值的單位都是內存頁，也就是4KB。
  
• net.ipv4.tcp_rmem
  tcp接收緩沖區大小，包含min、default、max三個值，內核會控制接收緩沖區在min-max之間動態調整，可根據實際業務場景和服務器配置適當調大，如果設置了socket的 SO_RECVBUF或者關閉了net.ipv4.tcp_moderate_rcvbuf，動態調整功能失效。
  
• net.core.rmem_max
  socket接收緩沖區的最大值，需要設置net.core.rmem_max的值大于等于net.ipv4.tcp_rmem 的max值。
  
• net.ipv4.tcp_moderate_rcvbuf
  接收緩沖區動態調整功能，默認打開，建議保持默認配置。
  
• net.ipv4.tcp_window_scaling
  擴充滑動窗口，tcp頭部中，窗口字段只有2個字節，最多只能達到2的16次方，即65535字節大小的窗口，打開此開關可以擴充窗口大小，默認打開，建議保持默認配置。
  
• net.ipv4.tcp_keepalive_probes
  keepalive探測失敗后通知應用前的重試次數，建議適當調低。
  
• net.ipv4.tcp_keepalive_intvl
  keepalive探測包的發送間隔時間，建議適當調低。
  
• net.ipv4.tcp_keepalive_time
  最后一次數據包到keepalive探測包的間隔時間，建議適當調低。
  
• net.ipv4.tcp_available_congestion_control
  查看內核支持的擁塞控制算法。
  
• net.ipv4.tcp_congestion_control
  配置擁塞控制算法，默認cubic，內核4.9版本后支持BBR，弱網絡條件下建議配置成BBR。

3. 斷開連接階段

• net.ipv4.tcp_fin_timeout
  是從Fin_WAIT_2到TIME_WAIT的超時時間，長時間收不到對端FIN包，大概率是對端機器有問題，不能及時調用close()關閉連接，建議調低，避免等待時間太長，資源開銷過大。
  
• net.ipv4.tcp_max_tw_buckets
  系統TIME_WAIT連接的最大數量，根據實際業務需要調整，超過最大值后dmesg會有報錯TCP: time wait bucket table overflow。
  
• net.ipv4.tcp_tw_reuse
  允許TIME_WAIT狀態的連接占用的端口用到新建連接中，客戶端可開啟。
  
• net.ipv4.tcp_tw_recycle
  開啟后，TIME_WAIT狀態的連接無需等待2MSL時間就可用于新建連接，在NAT環境下，開啟tcp_tw_recycle參數會觸發PAWS機制導致丟包，建議不開啟，事實上，內核在4.1版本后就把這個參數刪除了。

我們是阿里云智能全球技術服務-SRE團隊，我們致力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用云、基于云構建更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上云、用好云，讓客戶云上業務運行更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿里云SRE技術學院釘釘圈子，和更多云上人交流關于云平臺的那些事。

原文鏈接：https://developer.aliyun.com/article/796145?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的Linux系统TCP内核参数优化总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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