大量的 TCP 連接是 TIME_WAIT 狀態(tài)，有什么影響？怎么處理？

0.概要

1.問(wèn)題描述

// 統(tǒng)計(jì)：各種連接的數(shù)量$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'ESTABLISHED 1154TIME_WAIT 1645

2.問(wèn)題分析

3.解決辦法

1. 
   
1. TCP 連接中，「主動(dòng)發(fā)起關(guān)閉連接」的一端，會(huì)進(jìn)入 time_wait 狀態(tài)

   
   

2. time_wait 狀態(tài)，默認(rèn)會(huì)持續(xù)?2 MSL（報(bào)文的最大生存時(shí)間），一般是 2x2 mins

   
   

3. time_wait 狀態(tài)下，TCP 連接占用的端口，無(wú)法被再次使用

   
   

4. TCP 端口數(shù)量，上限是 6.5w（65535，16 bit）

   
   

5. 大量 time_wait 狀態(tài)存在，會(huì)導(dǎo)致新建 TCP 連接會(huì)出錯(cuò)，address already in use : connect?異常

1. 
   
1. 服務(wù)器端，一般設(shè)置：不允許「主動(dòng)關(guān)閉連接」

   
   

2. 但 HTTP 請(qǐng)求中，http 頭部 connection 參數(shù)，可能設(shè)置為 close，則，服務(wù)端處理完請(qǐng)求會(huì)主動(dòng)關(guān)閉 TCP 連接

   
   

3. 現(xiàn)在瀏覽器中， HTTP 請(qǐng)求?connection?參數(shù)，一般都設(shè)置為?keep-alive

   
   

4. Nginx 反向代理場(chǎng)景中，可能出現(xiàn)大量短鏈接，服務(wù)器端，可能存在

3.解決辦法：

1. 
   
1. 服務(wù)器端允許?time_wait?狀態(tài)的 socket 被重用

   
   

2. 縮減?time_wait?時(shí)間，設(shè)置為?1 MSL（即，2 mins）

   
   

   
   

4.附錄

附錄 A：查詢(xún) TCP 連接狀態(tài)

// Mac 下，查詢(xún) TCP 連接狀態(tài)$ netstat -nat |grep TIME_WAIT
// Mac 下，查詢(xún) TCP 連接狀態(tài)，其中 -E 表示 grep 或的匹配邏輯$ netstat -nat | grep -E "TIME_WAIT|Local Address"Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)tcp4       0      0  127.0.0.1.1080         127.0.0.1.59061        TIME_WAIT
// 統(tǒng)計(jì)：各種連接的數(shù)量$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'ESTABLISHED 1154TIME_WAIT 1645

附錄 B：MSL 時(shí)間

附錄 C：TCP 三次握手和四次握手

1. RE：time_wait 是「主動(dòng)關(guān)閉 TCP 連接」一方的狀態(tài)，可能是「客服端」的，也可能是「服務(wù)器端」的
   
   

   
   

2. 一般情況下，都是「客戶(hù)端」所處的狀態(tài)；「服務(wù)器端」一般設(shè)置「不主動(dòng)關(guān)閉連接」
   

2.服務(wù)器在對(duì)外服務(wù)時(shí)，是「客戶(hù)端」發(fā)起的斷開(kāi)連接？還是「服務(wù)器」發(fā)起的斷開(kāi)連接？

1. 正常情況下，都是「客戶(hù)端」發(fā)起的斷開(kāi)連接
   
   
2. 「服務(wù)器」一般設(shè)置為「不主動(dòng)關(guān)閉連接」，服務(wù)器通常執(zhí)行「被動(dòng)關(guān)閉」
   
   
3. 但 HTTP 請(qǐng)求中，http 頭部 connection 參數(shù)，可能設(shè)置為 close，則，服務(wù)端處理完請(qǐng)求會(huì)主動(dòng)關(guān)閉 TCP 連接
   
   

1. 可靠的實(shí)現(xiàn) TCP 全雙工連接的終止：四次揮手關(guān)閉 TCP 連接過(guò)程中，最后的 ACK 是由「主動(dòng)關(guān)閉連接」的一端發(fā)出的，如果這個(gè) ACK 丟失，則，對(duì)方會(huì)重發(fā) FIN 請(qǐng)求，因此，在「主動(dòng)關(guān)閉連接」的一段，需要維護(hù)一個(gè) time_wait 狀態(tài)，處理對(duì)方重發(fā)的 FIN 請(qǐng)求；

   
   

2. 處理延遲到達(dá)的報(bào)文：由于路由器可能抖動(dòng)，TCP 報(bào)文會(huì)延遲到達(dá)，為了避免「延遲到達(dá)的 TCP 報(bào)文」被誤認(rèn)為是「新 TCP 連接」的數(shù)據(jù)，則，需要在允許新創(chuàng)建 TCP 連接之前，保持一個(gè)不可用的狀態(tài)，等待所有延遲報(bào)文的消失，一般設(shè)置為 2 倍的 MSL（報(bào)文的最大生存時(shí)間），解決「延遲達(dá)到的 TCP 報(bào)文」問(wèn)題；
3. 

   Kafka 為什么能那么快的 6 個(gè)原因，我猜你不知道！

4. 

   Redis 6.0 除了多線程，這個(gè)功能也賊牛逼！

點(diǎn)個(gè)在看,贊?支持我吧