摘要：年月日項(xiàng)目生產(chǎn)環(huán)境出現(xiàn)大量數(shù)千個(gè)需要一一排查先上總結(jié)未開啟導(dǎo)致大量主動(dòng)斷開的連接與的連接默認(rèn)是短連接此時(shí)必然出現(xiàn)狀態(tài)確認(rèn)統(tǒng)計(jì)連接的本地地址前面很少的略過分析端口是對(duì)外端口端口是的端口對(duì)外端口經(jīng)過確認(rèn)的配置文件中存在一行不啟用

Last-Modified: 2019年7月10日21:58:43

項(xiàng)目生產(chǎn)環(huán)境出現(xiàn)大量TIME_WAIT(數(shù)千個(gè)), 需要一一排查

先上總結(jié):

nginx 未開啟 keep-alive 導(dǎo)致大量主動(dòng)斷開的tcp連接

nginx 與 fastcgi(php-fpm) 的連接默認(rèn)是短連接, 此時(shí)必然出現(xiàn) TIME_WAIT

統(tǒng)計(jì)TIME_WAIT 連接的本地地址

netstat -an | grep TIME_WAIT | awk "{print $4}" | sort | uniq -c | sort -n -k1

#    ... 前面很少的略過
#    2 127.0.0.1:56420
#    442 192.168.1.213:8080
#    453 127.0.0.1:9000

分析:

8080端口是nginx對(duì)外端口

9000端口是php-fpm的端口

經(jīng)過確認(rèn), nginx 的配置文件中存在一行

# 不啟用 keep-alive
keepalive_timeout 0;

嘗試抓取 tcp 包

tcpdump tcp -i any -nn port 8080 | grep "我的ip"

# 其中某一次連接的輸出如下
# 20:52:54.647907 IP 客戶端.6470 > 服務(wù)端.8080: Flags [S], seq 2369523978, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
# 20:52:54.647912 IP 服務(wù)端.8080 > 客戶端.6470: Flags [S.], seq 1109598671, ack 2369523979, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
# 20:52:54.670302 IP 客戶端.6470 > 服務(wù)端.8080: Flags [.], ack 1, win 256, length 0
# 20:52:54.680784 IP 客戶端.6470 > 服務(wù)端.8080: Flags [P.], seq 1:301, ack 1, win 256, length 300
# 20:52:54.680789 IP 服務(wù)端.8080 > 客戶端.6470: Flags [.], ack 301, win 123, length 0
# 20:52:54.702935 IP 服務(wù)端.8080 > 客戶端.6470: Flags [P.], seq 1:544, ack 301, win 123, length 543
# 20:52:54.702941 IP 服務(wù)端.8080 > 客戶端.6470: Flags [F.], seq 544, ack 301, win 123, length 0
# 20:52:54.726494 IP 客戶端.6470 > 服務(wù)端.8080: Flags [.], ack 545, win 254, length 0
# 20:52:54.726499 IP 客戶端.6470 > 服務(wù)端.8080: Flags [F.], seq 301, ack 545, win 254, length 0
# 20:52:54.726501 IP 服務(wù)端.8080 > 客戶端.6470: Flags [.], ack 302, win 123, length 0

上述具體的ip已經(jīng)被我批量替換了, 不方便暴露服務(wù)器ip

分析:

可以看到4次揮手的開始是由服務(wù)端主動(dòng)發(fā)起的(記住TIME_WAIT只會(huì)出現(xiàn)在主動(dòng)斷開連接的一方)

個(gè)人理解是, nginx 在配置"不啟用keep-alive"時(shí), 會(huì)在http請(qǐng)求結(jié)束時(shí)主動(dòng)斷開連接.

嘗試開啟http的keep-alive

修改 nginx 配置

keepalive_timeout 65;

reload nginx

nginx -s reload

再次抓包

tcpdump tcp -i any -nn port 8080 | grep "我的ip"

# 21:09:10.044918 IP 客戶端.8217 > 服務(wù)端.8080: Flags [S], seq 1499308169, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
# 21:09:10.044927 IP 服務(wù)端.8080 > 客戶端.8217: Flags [S.], seq 2960381462, ack 1499308170, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
# 21:09:10.070694 IP 客戶端.8217 > 服務(wù)端.8080: Flags [.], ack 1, win 256, length 0
# 21:09:10.077437 IP 客戶端.8217 > 服務(wù)端.8080: Flags [P.], seq 1:302, ack 1, win 256, length 301
# 21:09:10.077443 IP 服務(wù)端.8080 > 客戶端.8217: Flags [.], ack 302, win 123, length 0
# 21:09:10.198117 IP 服務(wù)端.8080 > 客戶端.8217: Flags [P.], seq 1:671, ack 302, win 123, length 670
# 21:09:10.222957 IP 客戶端.8217 > 服務(wù)端.8080: Flags [F.], seq 302, ack 671, win 254, length 0
# 21:09:10.222980 IP 服務(wù)端.8080 > 客戶端.8217: Flags [F.], seq 671, ack 303, win 123, length 0
# 21:09:10.247678 IP 客戶端.8217 > 服務(wù)端.8080: Flags [.], ack 672, win 254, length 0

注意看上面很有意思的地方:

tcp 的揮手只有3次, 而非正常的4次. 個(gè)人理解是, 服務(wù)端在收到 FIN 時(shí), 已經(jīng)確認(rèn)自己不會(huì)再發(fā)送數(shù)據(jù), 因此就將 FIN 與 ACK 一同合并發(fā)送

此時(shí)是客戶端主動(dòng)斷開tcp連接, 因此服務(wù)端不會(huì)出現(xiàn) TIME_WAIT

再次查看連接狀態(tài)

netstat -an | grep TIME_WAIT | awk "{print $4}" | sort | uniq -c | sort -n -k1
#      ...忽略上面
#      1 127.0.0.1:60602
#      1 127.0.0.1:60604
#    344 127.0.0.1:9000

此時(shí)發(fā)現(xiàn)已經(jīng)沒有處于 TIME_WAIT 的連接了.

經(jīng)過網(wǎng)上查找資料, 整理:

nginx 與 fast-cgi 的默認(rèn)連接是短連接, 每次連接都需要經(jīng)過一次完整的tcp連接與斷開

當(dāng)前 nginx 配置

upstream phpserver{
    server 127.0.0.1:9000 weight=1;
}

修改nginx配置使其與fastcgi的連接使用長(zhǎng)連接

upstream phpserver{
    server 127.0.0.1:9000 weight=1;
    keepalive 100
}

fastcgi_keep_conn on;

說明:

upstream 中的 keepalive 指定nginx每個(gè)worker與fastcgi的最大長(zhǎng)連接數(shù), 當(dāng)長(zhǎng)連接不夠用時(shí), 此時(shí)新建立的連接會(huì)在請(qǐng)求結(jié)束后斷開(由于此時(shí)指定了 HTTP1.1, fastcgi不會(huì)主動(dòng)斷開連接, 因此nginx這邊會(huì)出現(xiàn)大量 TIME_WAIT, 需謹(jǐn)慎(未驗(yàn)證)

由于php-fpm設(shè)置了最大進(jìn)程數(shù)為100, 因此此處的 keepalive 數(shù)量指定 100 (未測(cè)試)

此處題外話, 如果 nginx 是作為反向代理, 則需增加如下配置:

# 將http版本由1.0修改為1.1
proxy_http_version 1.1;
# 清除"Connection"頭部
proxy_set_header Connection "";    

配置 proxy_pass 將請(qǐng)求轉(zhuǎn)發(fā)給后端

這里, 理解一下 proxy_pass 與 fastcgi_pass 區(qū)別

客戶端 --http-->  前端負(fù)載均衡Nginx --proxy_pass--> 業(yè)務(wù)服務(wù)器Nginx --fastcgi_pass--> 業(yè)務(wù)服務(wù)器 php-fpm

再次確認(rèn) tcp 連接情況

netstat -antp  | grep :9000 | awk "{print $(NF-1)}" | sort | uniq -c
#      6 ESTABLISHED
#      1 LISTEN

ok, 問題解決.

另一種解決方法:

若 nginx 與 fast-cgi 在同一臺(tái)服務(wù)器上, 則使用 unix域 會(huì)更為高效, 同時(shí)避免了 TIME_WAIT 的問題.

經(jīng)過上面優(yōu)化后, TIME_WAIT數(shù)量從上千個(gè)大幅下降到幾十個(gè), 此時(shí)發(fā)現(xiàn)TIME_WAIT中的存在大量的 127.0.0.1:6379, 6379是redis服務(wù)的默認(rèn)端口....

趕緊改業(yè)務(wù)代碼去, 將 $redis->connect(...) 改成 $redis->pconnect(...)

說明:

pconnect 表示 php-fpm 與 redis 建立 tcp 連接后, 在本次http請(qǐng)求結(jié)束后仍維持該連接, 下次新的請(qǐng)求進(jìn)來時(shí)可以復(fù)用該連接, 從而復(fù)用了tcp連接.