一、前言

在Linux系統中，網絡參數優化對于提升網絡性能和確保穩定通信至關重要。

適當的網絡配置可以減少延遲、提高吞吐量，并優化資源利用率。例如，調整TCP窗口大小、隊列長度和超時設置等參數，能夠更好地適應不同網絡環境和應用需求，從而改善用戶體驗，特別是在高并發和大數據傳輸場景下。

此外，優化網絡參數也有助于預防擁塞，增強網絡故障恢復能力，確保服務的可靠性和效率。

Linux網絡優化最多的是傳輸層TCP相關的網絡優化。以下為工作中的經常遇到可能會調整Linux網絡協議棧參數。

二、傳輸層優化

2.1 優化TCP SYN重傳次數

當我們的服務器作為Client， Client 會給 Server 發送一個 SYN 包，但是該 SYN 包可能會在傳輸過程中丟失，或者因為其他原因導致 Server 無法處理，此時 Client 這一側就會觸發超時重傳機制。

tcp_syn_retries 的默認值是 6，也就是說如果 SYN 一直發送失敗，會在（1 + 2 + 4 + 8 + 16+ 32 + 64）秒，即 127 秒后產生 ETIMEOUT 的錯誤。

#我們可以通過調小重傳次數來減少阻塞時間：

net.ipv4.tcp_syn_retries = 2

2.2 優化半連接隊列（syn queue）

半連接，即收到了 SYN 后還沒有回復 SYNACK 的連接，Server 每收到一個新的 SYN 包，都會創建一個半連接，然后把該半連接加入到半連接隊列（syn queue）中。

當系統中積壓的半連接個數超過了該值后，新的 SYN 包就會被丟棄。對于服務器而言，可能瞬間會有非常多的新建連接，所以我們可以適當地調大該值，以免 SYN 包被丟棄而導致 Client 收不到 SYNACK。系統默認值為128。

net.ipv4.tcp_max_syn_backlog = 16384

2.3 開啟SYN Cookies

在 Server 收到 SYN 包時，不去分配資源來保存 Client 的信息，而是根據這個 SYN 包計算出一個 Cookie 值，然后將 Cookie 記錄到 SYNACK 包中發送出去。對于正常的連接，該 Cookies 值會隨著 Client 的 ACK 報文被帶回來。然后 Server 再根據這個 Cookie 檢查這個 ACK 包的合法性，如果合法，才去創建新的 TCP 連接。

SYN Cookies 可以防止部分 SYN Flood 攻擊。所以對于 Linux 服務器而言，推薦開啟 SYN Cookies。

net.ipv4.tcp_syncookies = 1

2.4 優化TCP SYNACK的重傳次數

當Client向Server端發送SYN報文后，Server會返回給Client SYNACK報文，當Client沒有響應Server ACK報文，則Server會進行重傳，我們可以減少重傳次數。系統默認值為5。

net.ipv4.tcp_synack_retries = 2

2.5 優化全連連隊列（accept queue）

三次握手就完成了，即產生了一個 TCP 全連接（complete），它會被添加到全連接隊列（accept queue）中。然后 Server 就會調用 accept() 來完成 TCP 連接的建立。

當服務器中積壓的全連接個數超過隊列長度后，新的全連接就會被丟棄掉。

全連接隊列（accept queue）的長度是由 listen(sockfd, backlog) 這個函數里的 backlog 控制的，而該 backlog 的最大值則是 somaxconn。系統默認值為1024。

net.core.somaxconn = 16384

2.6 全連接溢出是否通知客戶端

當服務器中積壓的全連接個數超過該值后，新的全連接就會被丟棄掉。Server 在將新連接丟棄時，有的時候需要發送 reset 來通知 Client，這樣 Client 就不會再次重試了。

不過，默認行為是直接丟棄不去通知 Client。至于是否需要給 Client 發送 reset，是由 tcp_abort_on_overflow 這個配置項來控制的，該值默認為 0，即不發送 reset 給 Client。推薦也是將該值配置為 0。

因為Server 如果來不及 accept() 而導致全連接隊列滿，這往往是由瞬間有大量新建連接請求導致的，正常情況下 Server 很快就能恢復，然后 Client 再次重試后就可以建連成功了。也就是說，將 tcp_abort_on_overflow 配置為 0，給了 Client 一個重試的機會。

net.ipv4.tcp_abort_on_overflow = 0

2.7 優化FIN超時時間

• 當Client向Server端發送FIN報文后，就會進入FIN_WAIT_1狀態。
• 當Server回復客戶端ACK報文后，Client就會進入FIN_WAIT_2狀態。

TCP 進入到這個狀態后，如果本端遲遲收不到對端的 FIN 包，那就會一直處于這個狀態，于是就會一直消耗系統資源。Linux 為了防止這種資源的開銷，設置了這個狀態的超時時間 tcp_fin_timeout，默認為 60s，超過這個時間后就會自動銷毀該連接。

對于數據中心內部的機器而言，將它調整為 2s 足以。

net.ipv4.tcp_fin_timeout = 2

2.8 優化TIME_WAIT

• 當Client向Server端發送FIN報文后，就會進入FIN_WAIT_1狀態；
• 當Server回復Client ACK報文后，Client就會進入FIN_WAIT_2狀態；
• 當Client收到Server的FIN報文后，會回復Server ACK報文，此時Client進入TIME_WAIT狀態。

TIME_WAIT 狀態存在的意義是：

• 最后發送的這個 ACK 包可能會被丟棄掉或者有延遲，這樣對端就會再次發送 FIN 包。如果不維持 TIME_WAIT 這個狀態，那么再次收到對端的 FIN 包后，本端就會回一個 Reset 包，這可能會產生一些異常。

所以維持 TIME_WAIT 狀態一段時間，可以保障 TCP 連接正常斷開。TIME_WAIT 的默認存活時間在 Linux 上是 60s（TCP_TIMEWAIT_LEN），這個時間對于數據中心而言可能還是有些長了，所以有的時候也會修改內核做些優化來減小該值，或者將該值設置為可通過 sysctl 來調節。

在Linux的內核中，TCP/IP協議的TIME-WAIT狀態持續60秒且無法修改。Alibaba Cloud Linux 2從內核版本4.19.43-13.al7開始，新增內核接口用于修改TCP TIME-WAIT超時時間。

#配置TIME_WAIT 狀態最大個數。

• 默認值為16384，對于數據中心而言，網絡是相對很穩定的，基本不會存在 FIN 包的異常，所以建議將該值調小一些。

net.ipv4.tcp_max_tw_buckets = 10000

#配置TIME_WAIT 狀態端口復用。

• Client 關閉跟 Server 的連接后，也有可能很快再次跟 Server 之間建立一個新的連接，而由于 TCP 端口最多只有 65536 個，如果不去復用處于 TIME_WAIT 狀態的連接，就可能在快速重啟應用程序時，出現端口被占用而無法創建新連接的情況。

net.ipv4.tcp_tw_reuse = 1

#選項 tcp_tw_recycle 來控制 TIME_WAIT 狀態。

• 但是該選項是很危險的，因為它可能會引起意料不到的問題，比如可能會引起 NAT 環境下的丟包問題。因為打開該選項后引起了太多的問題，所以新版本的內核就索性刪掉了這個配置選項。默認為關閉。

net.ipv4.tcp_tw_recycle = 0

2.9 優化TCP發送緩沖區

緩存了要發出去的數據。如果發送緩沖區已滿，應用程序的寫操作就會被阻塞。

tcp_wmem 中這三個數字的含義分別為 min、default、max。TCP 發送緩沖區的大小會在 min 和 max 之間動態調整，初始的大小是 default，這個動態調整的過程是由內核自動來做的，應用程序無法干預。自動調整的目的，是為了在盡可能少的浪費內存的情況下來滿足發包的需要。

#默認值為 4096  16384  4194304。

net.ipv4.tcp_wmem = 8192 65536 16777216

2.10 優化套接字發送緩沖區

tcp_wmem 中的 max 不能超過 net.core.wmem_max（套接字發送緩沖區） 這個配置項的值，如果超過了，TCP 發送緩沖區最大就是 net.core.wmem_max。

#默認值為212992。

net.core.wmem_max = 16777216

2.11 優化TCP接收緩沖區

#默認值為4096  87380  6291456。

net.ipv4.tcp_rmem = 8192 65536 16777216

2.12 優化套接字接收緩沖區

#默認值為212992。

net.core.wmem_max = 16777216

2.13 優化TCP內存消耗限制

tcp_wmem 以及 wmem_max 的大小設置都是針對單個 TCP 連接的，這兩個值的單位都是 Byte（字節）。系統中可能會存在非常多的 TCP 連接，如果 TCP 連接太多，就可能導致內存耗盡。因此，所有 TCP 連接消耗的總內存也有限制。

與前兩個選項不同的是，該選項中這些值的單位是 Page（頁數），也就是 4K。它也有 3 個值：min、pressure、max。當所有 TCP 連接消耗的內存總和達到 max 后，也會因達到限制而無法再往外發包。

#默認值為88053  117407  176106。

net.ipv4.tcp_mem = 8388608 12582912 16777216

2.14 優化CPU輪詢處理數據包數量

數據包到達網卡后，就會觸發中斷（IRQ）來告訴 CPU 讀取這個數據包。但是在高性能網絡場景下，數據包的數量會非常大，如果每來一個數據包都要產生一個中斷，那 CPU 的處理效率就會大打折扣，所以就產生了 NAPI（New API）這種機制讓 CPU 一次性地去輪詢（poll）多個數據包，以批量處理的方式來提升效率，降低網卡中斷帶來的性能開銷。

該控制選項的默認值是 300，在網絡吞吐量較大的場景中，我們可以適當地增大該值，比如增大到 600。增大該值可以一次性地處理更多的數據包。但是這種調整也是有缺陷的，因為這會導致 CPU 在這里 poll 的時間增加，如果系統中運行的任務很多的話，其他任務的調度延遲就會增加。

net.core.netdev_budget = 600

三、網絡層優化

3.1 優化本地端口范圍

IP 層這里容易觸發問題的地方是 net.ipv4.ip_local_port_range 這個配置選項，它是指和其他服務器建立 IP 連接時本地端口（local port）的范圍。我們在生產環境中就遇到過默認的端口范圍太小，以致于無法創建新連接的問題。所以通常情況下，我們都會擴大默認的端口范圍。

#默認值為 32768  60999：

net.ipv4.ip_local_port_range = 1024 65535

3.2 優化 txqueuelen隊列

為了能夠對 TCP/IP 數據流進行流控，Linux 內核在 IP 層實現了 qdisc（排隊規則）。

qdisc 的隊列長度是我們用 ifconfig 來看到的 txqueuelen，我們在生產環境中也遇到過因為 txqueuelen 太小導致數據包被丟棄的情況，這類問題可以通過下面這個命令來觀察。

ip -s -s link ls dev ens33

如果觀察到 dropped 這一項不為 0，那就有可能是 txqueuelen 太小導致的。當遇到這種情況時，你就需要增大該值了，比如增加 eth0 這個網絡接口的 txqueuelen：

ip link set eth0 txqueuelen 2000

#查看系統 txqueuelen大小。

ip a

圖片