Tomcat 調優之從 Linux 內核源碼層面看 Tcp backlog
前兩天看到一群里在討論 Tomcat 參數調優，看到不止一個人說通過 accept-count 來配置執行緒池大小，我笑了笑，看來其實很多人並不太了解我們用的最多的 WebServer Tomcat，這篇文章就來聊下 Tomcat 調優，重點介紹下執行緒池調優及 TCP 半連接、全連接隊列調優。
Tomcat 執行緒池
先來說下執行緒池調優，就拿 SpringBoot 內置的 Tomcat 來說，確實是支援執行緒池參數配置的，但不是 accept-count 參數，可以通過 threads.max 和 threads.minSpare 來配置執行緒池最大執行緒數和核心執行緒數。
如果沒有設置，則會使用默認值
threads.max: 200
threads.minSpare: 10
Tomcat 底層用到的 ThreadPoolExecutor 也不是 JUC 原生的執行緒池，而是自定義的，做了一些調整來支援 IO 密集型場景使用，具體介紹可以看之前寫的兩篇文章。
動態執行緒池（DynamicTp），動態調整 Tomcat、Jetty、Undertow 執行緒池參數篇
通過這兩篇文章能了解到 Tomcat 自定義執行緒池的執行流程及原理，然後可以接入動態執行緒池框架 DynamicTp，將 Tomcat 執行緒池交由 DynamicTp 管理，使之能享受到動態調參、監控告警的功能。
在配置中心配置 tomcat 執行緒池核心參數
spring:
dynamic:
tp:
tomcatTp:
corePoolSize: 100
maximumPoolSize: 400
keepAliveTime: 60
Tomcat 執行緒池調優主要思想就是動態化執行緒池參數，上線前通過壓測初步確定一套較優的參數值，上線後通過監控、告警實時感知執行緒池負載情況，動態調整參數適應流量的變化。
執行緒池調優就說這些吧，下面主要介紹下 Tcp backlog 及半連接、全連接隊列相關內容。
劃重點
-
threads.max 和 threads.minSpare 是用來配置 Tomcat 的工作執行緒池大小的，是執行緒池維度的參數
-
accept-count 和 max-connections 是 TCP 維度的配置參數
TCP 狀態機
Client 端和 Server 端基於 TCP 協議進行通訊時，首先需要經過三次握手建連的，通訊結束時需要通過四次揮手斷連的。注意所謂的連接其實是個邏輯上的概念，並不存在真實連接的，那 TCP 是怎麼面向連接傳輸的呢？
TCP 定義了個複雜的有限狀態機模型，通訊雙方通過維護一個連接狀態，來達到看起來像有一條連接的效果。如下是 TCP 狀態機狀態流轉圖，這個圖非常重要，建議大家一定要掌握。圖片來自 TCP 狀態機
圖上半部分描述了三次握手建立連接過程中狀態的變化
圖下半部分描述了四次揮手斷開連接過程中狀態的變化
圖 2 是通過三次握手建立連接的過程，老八股文了，建議結合圖 1 狀態機變化圖看，圖片來源三次握手
圖 3 是通過四次揮手斷開連接的過程，建議結合圖 1 狀態機變化圖看，圖片來源四次揮手
服務端程式調用 listen() 函數後，TCP 狀態機從 CLOSED 轉變為 LISTEN，並且 linux 內核會創建維護兩個隊列。一個是半連接隊列（Syn queue），另一個是全連接隊列（Accept queue）。
建連主要流程如下：
客戶端向服務端發送 SYN 包請求建立連接，發送後客戶端進入 SYN_SENT 狀態
服務端收到客戶端的 SYN 請求，將該連接存放到半連接隊列（Syn queue）中，並向客戶端回復 SYN + ACK，隨後服務端進入 SYN_RECV 狀態
客戶端收到服務端的 SYN + ACK 後，回復服務端 ACK 並進入 ESTABLISHED 狀態
服務端收到客戶端的 ACK 後，從半連接隊列中取出連接放到全連接隊列（Accept queue）中，服務端進入 ESTABLISHED 狀態
服務端程式調用 accept() 方法，從全連接隊列中取出連接進行處理請求
連接隊列大小
上述提到了半連接隊列、全連接隊列，這兩隊列都有大小限制的，超過的連接會被丟掉或者返回 RST 包。
半連接隊列大小主要受：listen backlog、somaxconn、tcp_max_syn_backlog 這三參數影響
全連接隊列大小主要受：listen backlog 和 somaxconn 這兩參數影響
tcp_max_syn_backlog 和 somaxconn 都是 linux 內核參數，在 /proc/sys/net/ipv4/ 和 /proc/sys/net/core/ 下，可以通過 /etc/sysctl.conf 文件來修改，默認值為 128。
listen backlog 參數其實就是我們調用 listen 函數時傳入的第二個參數。回到主題，Tomcat 的 accept-count 其實最後就會傳給 listen 函數做 backlog 用。
int listen(int sockfd, int backlog);
可以在配置文件中配置 tomcat accept-count 大小，默認為 100
以下程式碼注釋中也註明了 acceptCount 就是 backlog
以 Nio2Endpoint 為例看下程式碼，bind 方法首先會根據配置的核心執行緒數、最大執行緒數創建 worker 執行緒池。然後調用 jdk nio2 中的 AsynchronousServerSocketChannelImpl 的 bind 方法，該方法內會調用 Net.listen() 進行 socket 監聽。通過這幾段程式碼，我們可以清晰的看到 Tomcat accept-count = Tcp backlog，默認值為 100。
上面說到了半全兩個連接隊列，至於這兩個連接隊列大小怎麼確定，其實不同 linux 內核版本演算法也都不太一樣，我們就以 v3.10 來看。
以下是 linux 內核 socket.c 中的源碼，也就是我們調用 listen() 函數會執行的程式碼
/*
* Perform a listen. Basically, we allow the protocol to do anything
* necessary for a listen, and if that works, we mark the socket as
* ready for listening.
*/
SYSCALL_DEFINE2(listen, int, fd, int, backlog)
{
struct socket *sock;
int err, fput_needed;
int somaxconn;
sock = sockfd_lookup_light(fd, &err, &fput_needed);
if (sock) {
somaxconn = sock_net(sock->sk)->core.sysctl_somaxconn;
if ((unsigned int)backlog > somaxconn)
backlog = somaxconn;
err = security_socket_listen(sock, backlog);
if (!err)
err = sock->ops->listen(sock, backlog);
fput_light(sock->file, fput_needed);
}
return err;
}
可以看到，此處會拿內核參數 somaxconn 和 傳入的 backlog 做比較，取二者中的較小者作為全連接隊列大小。
全連接隊列大小 = min(backlog, somaxconn)。
接下來 backlog 會依次傳遞給如下函數，格式約定（源程式碼文件名#函數名）
af_inet.c#inet_listen() -> inet_connection_sock.c#inet_csk_listen_start() -> request_sock.c#reqsk_queue_alloc()
reqsk_queue_alloc() 函數程式碼如下，主要就是用來計算半連接隊列大小的。
計算邏輯可以簡化為下述公式，簡單描述 roundup_pow_of_two 演算法就是向上取最接近的最大 2 的指數次冪，注意此處 backlog 已經是 min(backlog, somaxconn)
半連接隊列大小 = roundup_pow_of_two(max(8, min(backlog, tcp_max_syn_backlog))+1)
程式碼里 max_qlen_log 在一個 for 循環里計算，比如算出的半連接隊列大小 nr_table_entries = 16 = 2^4，那麼 max_qlen_log = 4，該值在判斷半連接隊列是否溢出時會用到。
舉個例子，如果 listen backlog = 10、somaxconn = 128、tcp_max_syn_backlog = 128，那麼半連接隊列大小 = 16，全連接隊列大小 = 10。
所以要知道，在做連接隊列大小調優的時候，一定要綜合上述三個參數，只修改某一個起不到想要的效果。
連接隊列大小查看
全連接隊列大小
可以通過 linux 提供的 ss 命令來查看全連接隊列的大小
參數說明，參數很多，其他參數可以自己 help 查看說明
l：表示顯示 listening 狀態的 socket
n：不解析服務名稱
t：只顯示 tcp sockets
這個命令結果怎麼解讀呢？
主要看前三個欄位，Recv-Q 和 Send-Q 在 State 為 LISTEN 和非 LISTEN 狀態時代表不同的含義。
State: LISTEN
Recv-Q: 全連接隊列的當前長度，也就是已經完成三次握手等待服務端調用 accept() 方法獲取的連接數量
Send-Q: 全連接隊列的最大長度，也就是我們上述分析的 backlog 和somaxconn 的最小值
State: 非 LISTEN
Recv-Q: 已接受但未被應用進程讀取的位元組數
Send-Q: 已發送但未收到確認的位元組數
以上區別從如下內核程式碼也可以看出，ss 命令就是從 tcp_diag 模組獲取的數據
半連接隊列大小
半連接隊列沒有像 ss 這種命令直接查看，但服務端處於 SYN_RECV 狀態的連接都在半連接隊列里，所以可以通過如下命令間接統計
netstat -natp | grep SYN_RECV | wc -l
半連接隊列最大長度可以使用我們上述分析得到的公式計算得到
半全連接隊列溢出
全連接隊列溢出
當請求量很大，全連接隊列比較小時，就有可能發生全連接隊列溢出的情況。
此程式碼是 linux 內核用來判斷全連接隊列是否已滿的函數，可以看到判斷用的是大於號，這也就是我們用 ss 命令可能會看到 Recv-Q > Send-Q 的原因
sk_ack_backlog 是當前全連接隊列的大小
sk_max_ack_backlog 是全連接隊列的最大長度，也就是 min(listen_backlog, somaxconn)
當全連接隊列滿了發生溢出時，會根據 /proc/sys/net/ipv4/tcp_abort_on_overflow 內核參數來決定怎麼處理後續的 ack 請求，tcp_abort_on_overflow 默認值為 0。
-
當 tcp_abort_on_overflow = 0 時，如果全連接隊列已滿，服務端會直接扔掉客戶端發送的 ACK，此時服務端處於 SYN_RECV 狀態，客戶端處於 ESTABLISHED 狀態，服務端的超時重傳定時器會重傳 SYN + ACK 包給客戶端（重傳次數由/proc/sys/net/ipv4/tcp_synack_retries 指定，默認值為 5，重試間隔為 1s、2s、4s、8s、16s，共 31s，第 5 次發出後還要等 32s 才知道第 5 次也超時了，所以總共需要 63s）。超過 tcp_synack_retries 後，服務端不會在重傳，這時如果客戶端發送數據過來，服務端會返回 RST 包，客戶端會報 connection reset by peer 異常
-
當 tcp_abort_on_overflow = 1 時，如果全連接隊列已滿，服務端收到客戶端的 ACK 後，會發送一個 RST 包給客戶端，表示結束掉這個握手過程和這個連接，客戶端會報 connection reset by peer 異常
一般情況下 tcp_abort_on_overflow 保持默認值 0 就行，能提高建立連接的成功率
半連接隊列溢出
我們知道，服務端收到客戶端發送的 SYN 包後會將該連接放入半連接隊列中，然後回復 SYN+ACK，如果客戶端一直不回復 ACK 做第三次握手，這樣就會使得服務端有大量處於 SYN_RECV 狀態的 TCP 連接存在半連接隊列里，超過設置的隊列長度後就會發生溢出。
下述程式碼是 linux 內核判斷是否發生半連接隊列溢出的函數
// 程式碼在 include/net/inet_connection_sock.h 中
static inline int inet_csk_reqsk_queue_is_full(const struct sock *sk)
{
return reqsk_queue_is_full(&inet_csk(sk)->icsk_accept_queue);
}
// 程式碼在 include/net/request_sock.h 中
static inline int reqsk_queue_is_full(const struct request_sock_queue *queue)
{
/*
* qlen 是當前半連接隊列大小
* max_qlen_log 上述解釋過，如果半連接隊列大小 = 16 = 2^4，那麼該值就是4
* 非常巧妙的用了移位運行來判斷半連接隊列是否溢出，底層滿滿的都是細節
*/
return queue->listen_opt->qlen >> queue->listen_opt->max_qlen_log;
}
我們常說的 SYN Flood 洪水攻擊 是一種典型的 DDOS 攻擊，就是利用了這個點，給服務端發送一個 SYN 包後客戶端就下線了，服務端會超時重傳 SYN+ACK 包，上述也說了總共需要 63s 才停止重傳，也就是說服務端需要經過 63s 後才斷開該連接，這樣就會導致半連接隊列快速被耗盡，不能處理正常的請求。
那是怎麼防止攻擊的呢？
linux 提供個一個內核參數 /proc/sys/net/ipv4/tcp_syncookies 來應對該攻擊，當半連接隊列滿了且開啟 tcp_syncookies = 1 配置時，服務端在收到 SYN 並返回 SYN+ACK 後，不將該連接放入半連接隊列，而是根據這個 SYN 包 TCP 頭資訊計算出一個 cookie 值。將這個 cookie 作為第二次握手 SYN+ACK 包的初始序列號 seq 發過去，如果是攻擊者，就不會有響應，如果是正常連接，客戶端回復 ACK 包後，服務端根據頭資訊計算 cookie，與返回的確認序列號進行比對，如果相同，則是一個正常建立連接。
下述程式碼是計算 cookie 的函數，可以看到跟這些欄位有關（源 ip、源埠、目標 ip、目標埠、客戶端 syn 包序列號、時間戳、mssind）
下面看下第一次握手，收到 SYN 包後服務端的處理程式碼，程式碼太多，簡化提出跟半連接隊列溢出相關程式碼
int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
/*
* 如果半連接隊列已滿，且 tcp_syncookies 未開啟，則直接丟棄該連接
*/
if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
want_cookie = tcp_syn_flood_action(sk, skb, "TCP");
if (!want_cookie)
goto drop;
}
/*
* 如果全連接隊列已滿，並且沒有重傳 SYN+ACk 包的連接數量大於1，則直接丟棄該連接
* inet_csk_reqsk_queue_young 獲取沒有重傳 SYN+ACk 包的連接數量
*/
if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) {
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
goto drop;
}
// 分配 request sock 內核對象
req = inet_reqsk_alloc(&tcp_request_sock_ops);
if (!req)
goto drop;
if (want_cookie) {
// 如果開啟了 tcp_syncookies 且半連接隊列已滿，則計算 cookie
isn = cookie_v4_init_sequence(sk, skb, &req->mss);
req->cookie_ts = tmp_opt.tstamp_ok;
} else if (!isn) {
/* 如果沒有開啟 tcp_syncookies 並且 max_syn_backlog - 半連接隊列當前大小 < max_syn_backlog >> 2，則丟棄該連接 */
else if (!sysctl_tcp_syncookies &&
(sysctl_max_syn_backlog - inet_csk_reqsk_queue_len(sk) <
(sysctl_max_syn_backlog >> 2)) &&
!tcp_peer_is_proven(req, dst, false)) {
LIMIT_NETDEBUG(KERN_DEBUG pr_fmt("drop open request from %pI4/%u\n"),
&saddr, ntohs(tcp_hdr(skb)->source));
goto drop_and_release;
}
isn = tcp_v4_init_sequence(skb);
}
tcp_rsk(req)->snt_isn = isn;
// 構造 syn+ack 響應包
skb_synack = tcp_make_synack(sk, dst, req,
fastopen_cookie_present(&valid_foc) ? &valid_foc : NULL);
if (likely(!do_fastopen)) {
int err;
// 發送 syn+ack 響應包
err = ip_build_and_send_pkt(skb_synack, sk, ireq->loc_addr,
ireq->rmt_addr, ireq->opt);
err = net_xmit_eval(err);
if (err || want_cookie)
goto drop_and_free;
tcp_rsk(req)->snt_synack = tcp_time_stamp;
tcp_rsk(req)->listener = NULL;
// 添加到半連接隊列，並且開啟超時重傳定時器
inet_csk_reqsk_queue_hash_add(sk, req, TCP_TIMEOUT_INIT);
} else if (tcp_v4_conn_req_fastopen(sk, skb, skb_synack, req))
goto drop_and_free;
}
查看溢出命令
當連接隊列溢出時，可以通過 netstart -s 命令查詢
# 表示全連接隊列溢出的次數，累計值
119005 times the listen queue of a socket overflowed
# 表示半連接隊列溢出的次數，累計值
119085 SYNs to LISTEN sockets dropped
如果發現這兩個值一直在增加，就說明發生了隊列溢出，需要看情況調大隊列大小
常用組件 backlog 大小
-
Redis 默認 backlog = 511
-
Nginx 默認 backlog = 511
-
Mysql 默認 backlog = 50
-
Undertow 默認 backlog = 1000
-
Tomcat 默認 backlog = 100
總結
這篇文章以 Tomcat 性能調優為切入點，首先簡單講了下 Tomcat 執行緒池調優。然後借 Tomcat 配置參數 accept-count 引出了 Tcp backlog，從 linux 內核源碼層面詳細講解了下 TCP backlog 參數以及半連接、全連接隊列的相關知識，包括連接隊列大小設置，以及隊列溢出怎麼排查，這些東西也是我們服務端開發需要掌握的，在性能調優，問題排查時會有一定的幫助。
個人開源項目
DynamicTp 是一個基於配置中心實現的輕量級動態執行緒池管理工具，主要功能可以總結為動態調參、通知報警、運行監控、三方包執行緒池管理等幾大類。
目前累計 2k star，歡迎大家試用，感謝你的 star，歡迎 pr，業務之餘一起給開源貢獻一份力量
gitee 地址：//gitee.com/dromara/dynamic-tp
github 地址：//github.com/dromara/dynamic-tp
