來源：http://ningg.top/computer-basic-theory-tcp-time-wait/
幾個方面：
- 問題描述：什么現象？什么影響？
- 問題分析
- 解決方案
- 底層原理
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 狀態：
- 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）
更多細節，參考：
https://www.cnblogs.com/yjf512/p/5327886.html
結論：幾個核心要點
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.附錄
幾個方面：
- TCP 連接狀態的查詢
- MSL 時間
- 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 報文）
- 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 三次握手和四次握手
詳細細節，參考：
- TCP的三次握手與四次揮手（詳解+動圖）
具體示意圖：
- 三次握手，
建立連接程序 - 四次揮手，
釋放連接程序
幾個核心疑問：
1、 time_wait 是「服務器端」的狀態？or 「客戶端」的狀態？
- RE：time_wait 是「主動關閉 TCP 連接」一方的狀態，可能是「客服端」的，也可能是「服務器端」的
- 一般情況下，都是「客戶端」所處的狀態；「服務器端」一般設定「不主動關閉連接」
2、 服務器在對外服務時，是「客戶端」發起的斷開連接？還是「服務器」發起的斷開連接？
- 正常情況下，都是「客戶端」發起的斷開連接
- 「服務器」一般設定為「不主動關閉連接」，服務器通常執行「被動關閉」
- 但 HTTP 請求中，http 頭部 connection 引數，可能設定為 close，則，服務端處理完請求會主動關閉 TCP 連接
關于 Apache httpd 服務器的關聯配置，參考：
https://elf8848.iteye.com/blog/1739571
關于 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：
1、TCP 連接建立后，「主動關閉連接」的一端，收到對方的 FIN 請求后，發送 ACK 回應，會處于 time_wait 狀態；
2、 time_wait 狀態，存在的必要性：
- 可靠的實作 TCP 全雙工連接的終止：四次揮手關閉 TCP 連接程序中，最后的 ACK 是由「主動關閉連接」的一端發出的，如果這個 ACK 丟失，則，對方會重發 FIN 請求，因此，在「主動關閉連接」的一段，需要維護一個 time_wait 狀態，處理對方重發的 FIN 請求；
- 處理延遲到達的報文：由于路由器可能抖動，TCP 報文會延遲到達，為了避免「延遲到達的 TCP 報文」被誤認為是「新 TCP 連接」的資料，則，需要在允許新創建 TCP 連接之前，保持一個不可用的狀態，等待所有延遲報文的消失，一般設定為 2 倍的 MSL（報文的最大生存時間），解決「延遲達到的 TCP 報文」問題；
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.別在再滿屏的 if/ else 了，試試策略模式，真香！！
3.臥槽！Java 中的 xx ≠ null 是什么新語法？
4.Spring Boot 2.5 重磅發布，黑暗模式太炸了！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/356013.html
標籤：Java
上一篇：fastjson使用， mysql left join 合并多條資料， ArrayUtils.addAll注意事項， list set轉化， stream流式處理