TIME_WAIT狀態與解決方法

阿新 • • 發佈：2019-01-19

tcp_tw_recycle和tcp_timestamps】
參考官方文件（http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt），tcp_tw_recycle解釋如下：
tcp_tw_recycle選項作用為：Enable fast recycling TIME-WAIT sockets. Default value is 0.
tcp_timestamps選項作用為：Enable timestamps as defined in RFC1323. Default value is 1.

這兩個選項是linux核心提供的控制選項，和具體的應用程式沒有關係，而且網上也能夠查詢到大量的相關資料，但資訊都不夠完整，最主要的幾個問題如下；
1）快速回收到底有多快？
2）有的資料說只要開啟tcp_tw_recycle即可，有的又說要tcp_timestamps同時開啟，具體是哪個正確？
3）為什麼從虛擬機器NAT出去發起客戶端連線時選項無效，非虛擬機器連線就有效？

為了回答上面的疑問，只能看程式碼，看出一些相關的程式碼供大家參考：
=====linux-2.6.37 net/ipv4/tcp_minisocks.c 269======
void tcp_time_wait(struct sock *sk, int state, int timeo)
{
struct inet_timewait_sock *tw = NULL;
const struct inet_connection_sock *icsk = inet_csk(sk);
const struct tcp_sock *tp = tcp_sk(sk);
int recycle_ok = 0;

//判斷是否快速回收，這裡可以看出tcp_tw_recycle和tcp_timestamps兩個選項都開啟的時候才進行快速回收，
//且還有進一步的判斷條件，後面會分析，這個進一步的判斷條件和第三個問題有關
if (tcp_death_row.sysctl_tw_recycle && tp->rx_opt.ts_recent_stamp)
recycle_ok = icsk->icsk_af_ops->remember_stamp(sk);

if (tcp_death_row.tw_count < tcp_death_row.sysctl_max_tw_buckets)
tw = inet_twsk_alloc(sk, state);

if (tw != NULL) {
struct tcp_timewait_sock *tcptw = tcp_twsk((struct sock *)tw);
//計算快速回收的時間，等於 RTO * 3.5，回答第一個問題的關鍵是RTO（Retransmission Timeout）大概是多少
const int rto = (icsk->icsk_rto << 2) - (icsk->icsk_rto >> 1);

//。。。。。。此處省略很多程式碼。。。。。。

if (recycle_ok) {
//設定快速回收的時間
tw->tw_timeout = rto;
} else {
tw->tw_timeout = TCP_TIMEWAIT_LEN;
if (state == TCP_TIME_WAIT)
timeo = TCP_TIMEWAIT_LEN;
}

//。。。。。。此處省略很多程式碼。。。。。。
}

RFC中有關於RTO計算的詳細規定，一共有三個：RFC-793、RFC-2988、RFC-6298，Linux的實現是參考RFC-2988。
對於這些演算法的規定和Linuxde 實現，有興趣的同學可以自己深入研究，實際應用中我們只要記住Linux如下兩個邊界值：
=====linux-2.6.37 net/ipv4/tcp.c 126================
#define TCP_RTO_MAX ((unsigned)(120*HZ))
#define TCP_RTO_MIN ((unsigned)(HZ/5))
==========================================
這裡的HZ是1s，因此可以得出RTO最大是120s，最小是200ms，對於區域網的機器來說，正常情況下RTO基本上就是200ms，因此3.5 RTO就是700ms
也就是說，快速回收是TIME_WAIT的狀態持續700ms，而不是正常的2MSL（Linux是1分鐘，請參考：include/net/tcp.h 109行TCP_TIMEWAIT_LEN定義）。
實測結果也驗證了這個推論，不停的檢視TIME_WAIT狀態的連線，偶爾能看到1個。

最後一個問題是為什麼從虛擬機發起的連線即使設定了tcp_tw_recycle和tcp_timestamps，也不會快速回收，繼續看程式碼：
tcp_time_wait函式中的程式碼行：recycle_ok = icsk->icsk_af_ops->remember_stamp(sk);對應的實現如下：
=====linux-2.6.37 net/ipv4/tcp_ipv4.c 1772=====
int tcp_v4_remember_stamp(struct sock *sk)
{
//。。。。。。此處省略很多程式碼。。。。。。

//當獲取對端資訊時，進行快速回收，否則不進行快速回收
if (peer) {
if ((s32)(peer->tcp_ts - tp->rx_opt.ts_recent) <= 0 ||
((u32)get_seconds() - peer->tcp_ts_stamp > TCP_PAWS_MSL &&
peer->tcp_ts_stamp <= (u32)tp->rx_opt.ts_recent_stamp)) {
peer->tcp_ts_stamp = (u32)tp->rx_opt.ts_recent_stamp;
peer->tcp_ts = tp->rx_opt.ts_recent;
}
if (release_it)
inet_putpeer(peer);
return 1;
}

return 0;
}
上面這段程式碼應該就是測試的時候虛擬機器環境不會釋放的原因，當使用虛擬機器NAT出去的時候，伺服器無法獲取隱藏在NAT後的機器資訊。
生產環境也出現了設定了選項，但TIME_WAIT連線數達到4W多的現象，可能和虛擬機器有關，也可能和組網有關。

總結一下：
1）快速回收到底有多快？
區域網環境下，700ms就回收；
2）有的資料說只要開啟tcp_tw_recycle即可，有的又說要tcp_timestamps同時開啟，具體是哪個正確？
需要同時開啟，但預設情況下tcp_timestamps就是開啟的，所以會有人說只要開啟tcp_tw_recycle即可；
3）為什麼從虛擬機發起客戶端連線時選項無效，非虛擬機器連線就有效？
和網路組網有關係，無法獲取對端資訊時就不進行快速回收；

綜合上面的分析和總結，可以看出這種方法不是很保險，在實際應用中可能受到虛擬機器、網路組網、防火牆之類的影響從而導致不能進行快速回收。

附：
1）tcp_timestamps的說明詳見RF1323，和TCP的擁塞控制（Congestion control）有關。
2）開啟此選項，可能導致無法連線，請參考：http://www.pagefault.info/?p=416

TIME_WAIT狀態與解決方法

TIME_WAIT狀態與解決方法

loadrunner---壓力機出現TIME_WAIT狀態的解決方法

TCP連線狀態詳解及TIME_WAIT過多的解決方法

CLOSE_WAIT狀態的原因與解決方法

zabbix 監控平臺搭建過程中的報錯與解決方法總結

inline-block元素的空隙與解決方法

AppFuse 3常見問題與解決方法

spring定時任務執行兩次的原因與解決方法

CSS - 移動端常見小bug整理與解決方法總結【更新中】

希捷企業盤ST4000NM0035 V5更新TN04固件遇到的問題與解決方法

java.sql.SQLException: Field 'id' doesn't have a default value（用eclipse操作數據庫時報了這種奇怪的錯誤）的原因與解決方法

weblogic修改jdk版本遇到的問題與解決方法

淺談xss攻擊原理與解決方法

Eslint報錯整理與解決方法（持續整理）

NGINX反向代理對HTML頁面的POST請求返回405狀態碼解決方法

rsync 常見錯誤與解決方法整理

遠端連線區域網內的sql server 無法連線錯誤與解決方法

ShapeDTW程式碼執行問題記錄與解決方法

Oracle中發生表加鎖、死鎖的原因，檢視，與解決方法

onchange監聽input值變化及input隱藏後change事件不觸發的原因與解決方法(設定readonly後onchange不起作用的解決方案)

TIME_WAIT狀態與解決方法

相關推薦