終於搞懂了服務器爲啥產生大量的 TIME_WAIT!
原文鏈接:http://ningg.top/computer-basic-theory-tcp-time-wait
寫在開頭,大概 4 年前,聽到運維同學提到 TIME_WAIT 狀態的 TCP 連接過多的問題,但是當時沒有去細琢磨;最近又聽人說起,是一個新手進行壓測過程中,遇到的問題,因此,花點時間,細深究一下。
從這幾個方面着手:
-
問題描述:什麼現象?什麼影響?
-
問題分析
-
解決方案
-
底層原理
1、問題描述
模擬高併發的場景,會出現批量的 TIME_WAIT 的 TCP 連接:
短時間後,所有的 TIME_WAIT 全都消失,被回收,端口包括服務,均正常。即,在高併發的場景下,TIME_WAIT 連接存在,屬於正常現象。
線上場景中,持續的高併發場景:
-
一部分 TIME_WAIT 連接被回收,但新的 TIME_WAIT 連接產生;
-
一些極端情況下,會出現大量的 TIME_WAIT 連接。
Think:上述大量的 TIME_WAIT 狀態 TCP 連接,有什麼業務上的影響嗎?
Nginx 作爲反向代理時,大量的短鏈接,可能導致 Nginx 上的 TCP 連接處於 time_wait 狀態:
-
- 每一個 time_wait 狀態,都會佔用一個「本地端口」,上限爲 65535(16 bit,2 Byte);
-
- 當大量的連接處於 time_wait 時,新建立 TCP 連接會出錯,address already in use : connect 異常
統計 TCP 連接的狀態:
// 統計:各種連接的數量
$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
ESTABLISHED 1154
TIME_WAIT 1645
Tips:TCP 本地端口數量,上限爲 65535(6.5w),這是因爲 TCP 頭部使用 16 bit,存儲「端口號」,因此約束上限爲 65535。
2、問題分析
大量的 TIME_WAIT 狀態 TCP 連接存在,其本質原因是什麼?
-
- 大量的短連接存在
-
- 特別是 HTTP 請求中,如果 connection 頭部取值被設置爲 close 時,基本都由「服務端」發起主動關閉連接
-
- 而,TCP 四次揮手關閉連接機制中,爲了保證 ACK 重發和丟棄延遲數據,設置 time_wait 爲 2 倍的 MSL(報文最大存活時間)
TIME_WAIT 狀態:
-
1.TCP 連接中,主動關閉連接的一方出現的狀態;(收到 FIN 命令,進入 TIME_WAIT 狀態,並返回 ACK 命令)
-
- 保持 2 個 MSL 時間,即,4 分鐘;(MSL 爲 2 分鐘)
3、解決辦法
解決上述 time_wait 狀態大量存在,導致新連接創建失敗的問題,一般解決辦法:
1. 客戶端,HTTP 請求的頭部,connection 設置爲 keep-alive,保持存活一段時間:現在的瀏覽器,一般都這麼進行了
2. 服務器端
允許 time_wait 狀態的 socket 被重用
縮減 time_wait 時間,設置爲 1 MSL(即,2 mins)
**結論:**幾個核心要點
1.time_wait 狀態的影響:
-
TCP 連接中,「主動發起關閉連接」的一端,會進入 time_wait 狀態
-
time_wait 狀態,默認會持續 2 MSL(報文的最大生存時間),一般是 2x2 mins
-
time_wait 狀態下,TCP 連接佔用的端口,無法被再次使用
-
TCP 端口數量,上限是 6.5w(65535,16 bit)
-
大量 time_wait 狀態存在,會導致新建 TCP 連接會出錯,address already in use : connect 異常
2. 現實場景:
-
服務器端,一般設置:不允許「主動關閉連接」
-
但 HTTP 請求中,http 頭部 connection 參數,可能設置爲 close,則,服務端處理完請求會主動關閉 TCP 連接
-
現在瀏覽器中, HTTP 請求 connection 參數,一般都設置爲 keep-alive
-
Nginx 反向代理場景中,可能出現大量短鏈接,服務器端,可能存在
3. 解決辦法:
-
服務器端允許 time_wait 狀態的 socket 被重用
-
縮減 time_wait 時間,設置爲 1 MSL(即,2 mins)
4、附錄 - 底層原理
幾個方面:
1.TCP 連接狀態的查詢
2.MSL 時間
3.TCP 三次握手和四次握手
附錄 A:查詢 TCP 連接狀態
Mac 下,查詢 TCP 連接狀態的具體命令:
// Mac 下,查詢 TCP 連接狀態
$ netstat -nat |grep TIME_WAIT
// Mac 下,查詢 TCP 連接狀態,其中 -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
// 統計:各種連接的數量
$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
ESTABLISHED 1154
TIME_WAIT 1645
附錄 B:MSL 時間
MSL,Maximum Segment Lifetime,“報文最大生存時間”
- 任何報文在網絡上存在的最長時間,超過這個時間報文將被丟棄。(IP 報文)
2.TCP 報文 (segment)是 ip 數據報(datagram)的數據部分。
Tips:RFC 793 中規定 MSL 爲 2 分鐘,實際應用中常用的是 30 秒,1 分鐘和 2 分鐘等。
2MSL,TCP 的 TIME_WAIT 狀態,也稱爲 2MSL 等待狀態:
-
當 TCP 的一端發起主動關閉(收到 FIN 請求),在發出最後一個 ACK 響應後,即第 3 次握 手完成後,發送了第四次握手的 ACK 包後,就進入了 TIME_WAIT 狀態。
-
- 必須在此狀態上停留兩倍的 MSL 時間,等待 2MSL 時間主要目的是怕最後一個 ACK 包對方沒收到,那麼對方在超時後將重發第三次握手的 FIN 包,主動關閉端接到重發的 FIN 包後,可以再發一個 ACK 應答包。
-
- 在 TIME_WAIT 狀態時,兩端的端口不能使用,要等到 2MSL 時間結束,纔可繼續使用。(IP 層)
-
- 當連接處於 2MSL 等待階段時,任何遲到的報文段都將被丟棄。
不過在實際應用中,可以通過設置 「SO_REUSEADDR 選項」,達到不必等待 2MSL 時間結束,即可使用被佔用的端口。
附錄 C:TCP 三次握手和四次握手
具體示意圖:
-
三次握手,建立連接過程
-
四次揮手,釋放連接過程
幾個核心疑問:
1. time_wait 是「服務器端」的狀態?or 「客戶端」的狀態?
-
RE:time_wait 是「主動關閉 TCP 連接」一方的狀態,可能是「客服端」的,也可能是「服務器端」的;
-
一般情況下,都是「客戶端」所處的狀態;「服務器端」一般設置「不主動關閉連接」。
2. 服務器在對外服務時,是「客戶端」發起的斷開連接?還是「服務器」發起的斷開連接?
-
正常情況下,都是「客戶端」發起的斷開連接;
-
「服務器」一般設置爲「不主動關閉連接」,服務器通常執行「被動關閉」;
-
但 HTTP 請求中,http 頭部 connection 參數,可能設置爲 close,則,服務端處理完請求會主動關閉 TCP 連接,
關於 HTTP 請求中,設置的主動關閉 TCP 連接的機制:TIME_WAIT 的是主動斷開方纔會出現的,所以主動斷開方是服務端?
-
答案是是的。在 HTTP1.1 協議中,有個 Connection 頭,Connection 有兩個值,close 和 keep-alive,這個頭就相當於客戶端告訴服務端,服務端你執行完成請求之後,是關閉連接還是保持連接,保持連接就意味着在保持連接期間,只能由客戶端主動斷開連接。還有一個 keep-alive 的頭,設置的值就代表了服務端保持連接保持多久。
-
HTTP 默認的 Connection 值爲 close,那麼就意味着關閉請求的一方几乎都會是由服務端這邊發起的。那麼這個服務端產生 TIME_WAIT 過多的情況就很正常了。
-
雖然 HTTP 默認 Connection 值爲 close,但是,現在的瀏覽器發送請求的時候一般都會設置 Connection 爲 keep-alive 了。所以,也有人說,現在沒有必要通過調整參數來使 TIME_WAIT 降低了。
關於 time_wait:
-
TCP 連接建立後,「主動關閉連接」的一端,收到對方的 FIN 請求後,發送 ACK 響應,會處於 time_wait 狀態;
-
time_wait 狀態,存在的必要性:
a、可靠的實現 TCP 全雙工連接的終止:四次揮手關閉 TCP 連接過程中,最後的 ACK 是由「主動關閉連接」的一端發出的,如果這個 ACK 丟失,則,對方會重發 FIN 請求,因此,在「主動關閉連接」的一段,需要維護一個 time_wait 狀態,處理對方重發的 FIN 請求;
b、處理延遲到達的報文:由於路由器可能抖動,TCP 報文會延遲到達,爲了避免「延遲到達的 TCP 報文」被誤認爲是「新 TCP 連接」的數據,則,需要在允許新創建 TCP 連接之前,保持一個不可用的狀態,等待所有延遲報文的消失,一般設置爲 2 倍的 MSL(報文的最大生存時間),解決「延遲達到的 TCP 報文」問題。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/ohGay7HNAYc75qSqdBTR0w