作者：NingG+
幾個方面：
- 問題描述：什么現(xiàn)象昌妹？什么影響？
- 問題分析
- 解決方案
- 底層原理
1飞崖、問題描述
模擬高并發(fā)的場景，會出現(xiàn)批量的 TIME_WAIT 的 TCP 連接：
短時間后固歪，所有的 TIME_WAIT 全都消失胯努，被回收，端口包括服務叶沛，均正常。
即忘朝，在高并發(fā)的場景下灰署，TIME_WAIT 連接存在，屬于正尘粥遥現(xiàn)象溉箕。
線上場景中，持續(xù)的高并發(fā)場景
- 一部分
TIME_WAIT連接被回收悦昵，但新的TIME_WAIT連接產(chǎn)生肴茄； - 一些極端情況下，會出現(xiàn)大量的
TIME_WAIT連接旱捧。
Think：
上述大量的
TIME_WAIT狀態(tài) TCP 連接独郎，有什么業(yè)務上的影響嗎？
Nginx 作為反向代理時枚赡，大量的短鏈接氓癌，可能導致 Nginx 上的 TCP 連接處于 time_wait 狀態(tài)：
- 每一個 time_wait 狀態(tài)，都會占用一個「本地端口」贫橙，上限為
65535(16 bit贪婉，2 Byte)； - 當大量的連接處于
time_wait時卢肃，新建立 TCP 連接會出錯疲迂，address already in use : connect 異常
統(tǒng)計 TCP 連接的狀態(tài)：
1. `// 統(tǒng)計：各種連接的數(shù)量`
2. `$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'`
3. `ESTABLISHED 1154`
4. `TIME_WAIT 1645`
Tips：
TCP 本地端口數(shù)量，上限為
65535（6.5w）莫湘，這是因為 TCP 頭部使用16 bit尤蒿，存儲「端口號」，因此約束上限為65535幅垮。
2腰池、問題分析
大量的 TIME_WAIT 狀態(tài) TCP 連接存在，其本質原因是什么忙芒？
- 大量的短連接存在
- 特別是 HTTP 請求中示弓，如果
connection頭部取值被設置為close時，基本都由「服務端」發(fā)起主動關閉連接 - 而呵萨，
TCP 四次揮手關閉連接機制中奏属，為了保證ACK 重發(fā)和丟棄延遲數(shù)據(jù)，設置time_wait為 2 倍的MSL（報文最大存活時間）
TIME_WAIT 狀態(tài)：
- TCP 連接中潮峦，主動關閉連接的一方出現(xiàn)的狀態(tài)囱皿；（收到 FIN 命令勇婴，進入 TIME_WAIT 狀態(tài)，并返回 ACK 命令）
- 保持 2 個
MSL時間铆帽，即咆耿，4 分鐘；（MSL 為 2 分鐘）
3爹橱、解決辦法
解決上述 time_wait 狀態(tài)大量存在，導致新連接創(chuàng)建失敗的問題窄做，一般解決辦法：
1、客戶端椭盏，HTTP 請求的頭部掏颊，connection 設置為 keep-alive，保持存活一段時間：現(xiàn)在的瀏覽器盆偿，一般都這么進行了2事扭、服務器端乐横，
- 允許
time_wait狀態(tài)的 socket 被重用 - 縮減
time_wait時間葡公，設置為1 MSL（即，2 mins）
更多細節(jié)涵亏，參考：
結論：幾個核心要點
1溯乒、 time_wait 狀態(tài)的影響：
- TCP 連接中豹爹，「主動發(fā)起關閉連接」的一端，會進入 time_wait 狀態(tài)
- time_wait 狀態(tài)光稼，默認會持續(xù)
2 MSL（報文的最大生存時間），一般是 2x2 mins - time_wait 狀態(tài)下采够，TCP 連接占用的端口冰垄，無法被再次使用
- TCP 端口數(shù)量，上限是 6.5w（
65535逝薪，16 bit） - 大量 time_wait 狀態(tài)存在董济，會導致新建 TCP 連接會出錯要门，address already in use : connect 異常
2、 現(xiàn)實場景：
- 服務器端封豪，一般設置：不允許「主動關閉連接」
- 但 HTTP 請求中撑毛，http 頭部 connection 參數(shù)，可能設置為 close藻雌，則胯杭，服務端處理完請求會主動關閉 TCP 連接
- 現(xiàn)在瀏覽器中受啥， HTTP 請求
connection參數(shù)滚局，一般都設置為keep-alive - Nginx 反向代理場景中，可能出現(xiàn)大量短鏈接太闺，服務器端嘁圈，可能存在
3、 解決辦法：服務器端钞澳，
- 允許
time_wait狀態(tài)的 socket 被重用 - 縮減
time_wait時間，設置為1 MSL（即策治，2 mins）
4逃延、附錄
幾個方面：
- TCP 連接狀態(tài)的查詢
- MSL 時間
- TCP 三次握手和四次握手
附錄 A：查詢 TCP 連接狀態(tài)
Mac 下揽祥，查詢 TCP 連接狀態(tài)的具體命令：
1. `// Mac 下檩电，查詢 TCP 連接狀態(tài)`
2. `$ netstat -nat |grep TIME_WAIT`
3. ``
4. `// Mac 下俐末，查詢 TCP 連接狀態(tài)卓箫，其中 -E 表示 grep 或的匹配邏輯`
5. `$ netstat -nat | grep -E "TIME_WAIT|Local Address"`
6. `Proto Recv-Q Send-Q Local Address Foreign Address (state)`
7. `tcp4 0 0 127.0.0.1.1080 127.0.0.1.59061 TIME_WAIT`
8. ``
9. `// 統(tǒng)計：各種連接的數(shù)量`
10. `$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'`
11. `ESTABLISHED 1154`
12. `TIME_WAIT 1645`
附錄 B：MSL 時間
MSL，Maximum Segment Lifetime闷盔，“報文最大生存時間”逢勾，
- 任何報文在網(wǎng)絡上存在的最長時間藐吮，超過這個時間報文將被丟棄谣辞。（IP 報文）
- TCP報文 （segment）是ip數(shù)據(jù)報（datagram）的數(shù)據(jù)部分。
Tips：
RFC 793中規(guī)定MSL為2分鐘句占，實際應用中常用的是30秒歉闰，1分鐘和2分鐘等。
2MSL凹炸，TCP 的 TIME_WAIT 狀態(tài)，也稱為2MSL等待狀態(tài)：
- 當TCP的一端發(fā)起主動關閉（收到 FIN 請求）奕筐，在發(fā)出最后一個ACK 響應后离赫，即第3次握 手完成后，發(fā)送了第四次握手的ACK包后渊胸，就進入了TIME_WAIT狀態(tài)台妆。
- 必須在此狀態(tài)上停留兩倍的MSL時間接剩，等待2MSL時間主要目的是怕最后一個 ACK包對方?jīng)]收到，那么對方在超時后將重發(fā)第三次握手的FIN包疫稿，主動關閉端接到重發(fā)的FIN包后鹃两，可以再發(fā)一個ACK應答包怔毛。
- 在 TIME_WAIT 狀態(tài)時，兩端的端口不能使用碎绎，要等到2MSL時間結束筋帖，才可繼續(xù)使用冤馏。（IP 層）
- 當連接處于2MSL等待階段時，任何遲到的報文段都將被丟棄墩划。
不過在實際應用中乙帮，可以通過設置 「SO_REUSEADDR選項」极景，達到不必等待2MSL時間結束，即可使用被占用的端口氢卡。
附錄 C：TCP 三次握手和四次握手
詳細細節(jié)译秦，參考：
- TCP的三次握手與四次揮手（詳解+動圖）
具體示意圖：
-
三次握手诀浪，
建立連接過程 -
四次揮手延都，
釋放連接過程
幾個核心疑問：
1晰房、 time_wait 是「服務器端」的狀態(tài)殊者？or 「客戶端」的狀態(tài)猖吴？
- RE：time_wait 是「主動關閉 TCP 連接」一方的狀態(tài)，可能是「客服端」的海蔽，也可能是「服務器端」的
- 一般情況下党窜，都是「客戶端」所處的狀態(tài)；「服務器端」一般設置「不主動關閉連接」
2幌衣、 服務器在對外服務時豁护，是「客戶端」發(fā)起的斷開連接？還是「服務器」發(fā)起的斷開連接断部？
- 正常情況下家坎，都是「客戶端」發(fā)起的斷開連接
- 「服務器」一般設置為「不主動關閉連接」虱疏，服務器通常執(zhí)行「被動關閉」
- 但 HTTP 請求中做瞪，http 頭部 connection 參數(shù)装蓬，可能設置為 close牍帚，則暗赶，服務端處理完請求會主動關閉 TCP 連接
關于 Apache httpd 服務器的關聯(lián)配置，參考：https://elf8848.iteye.com/blog/1739571
關于 HTTP 請求中肃叶，設置的主動關閉 TCP 連接的機制：TIME_WAIT的是主動斷開方才會出現(xiàn)的蹂随，所以主動斷開方是服務端？
- 答案是是的因惭。在HTTP1.1協(xié)議中岳锁，有個 Connection 頭，Connection有兩個值蹦魔，close和keep-alive激率，這個頭就相當于客戶端告訴服務端，服務端你執(zhí)行完成請求之后版姑，是關閉連接還是保持連接柱搜，保持連接就意味著在保持連接期間，只能由客戶端主動斷開連接剥险。還有一個keep-alive的頭聪蘸，設置的值就代表了服務端保持連接保持多久健爬。
- HTTP默認的Connection值為close蜕衡，那么就意味著關閉請求的一方幾乎都會是由服務端這邊發(fā)起的纳胧。那么這個服務端產(chǎn)生TIME_WAIT過多的情況就很正常了。
- 雖然HTTP默認Connection值為close牢硅，但是惩系，現(xiàn)在的瀏覽器發(fā)送請求的時候一般都會設置Connection為keep-alive了妙黍。所以，也有人說浇借，現(xiàn)在沒有必要通過調整參數(shù)來使TIME_WAIT降低了。
關于 time_wait：
1、TCP 連接建立后，「主動關閉連接」的一端，收到對方的 FIN 請求后创橄，發(fā)送 ACK 響應船老，會處于 time_wait 狀態(tài)；
2确沸、 time_wait 狀態(tài)，存在的必要性：
- 可靠的實現(xiàn) TCP 全雙工連接的終止：四次揮手關閉 TCP 連接過程中捉偏，最后的 ACK 是由「主動關閉連接」的一端發(fā)出的，如果這個 ACK 丟失缠劝，則矿卑，對方會重發(fā) FIN 請求，因此，在「主動關閉連接」的一段，需要維護一個 time_wait 狀態(tài)，處理對方重發(fā)的 FIN 請求；
- 處理延遲到達的報文：由于路由器可能抖動，TCP 報文會延遲到達，為了避免「延遲到達的 TCP 報文」被誤認為是「新 TCP 連接」的數(shù)據(jù)舒帮，則，需要在允許新創(chuàng)建 TCP 連接之前侦厚，保持一個不可用的狀態(tài)想诅，等待所有延遲報文的消失忘古，一般設置為 2 倍的 MSL（報文的最大生存時間），解決「延遲達到的 TCP 報文」問題祭阀；
