TIME_WAIT狀態原理

來源:本站原創 網絡技術 超過188 views圍觀 0條評論

TIME_WAIT狀態原理

—————————-

通信雙方建立TCP連接后,主動關閉連接的一方就會進入TIME_WAIT狀態。

客戶端主動關閉連接時,會發送最后一個ack后,然后會進入TIME_WAIT狀態,再停留2個MSL時間(后有MSL的解釋),進入CLOSED狀態。

下圖是以客戶端主動關閉連接為例,說明這一過程的。

TIME_WAIT狀態存在的理由

—————————-

TCP/IP協議就是這樣設計的,是不可避免的。主要有兩個原因:

1)可靠地實現TCP全雙工連接的終止

TCP協議在關閉連接的四次握手過程中,最終的ACK是由主動關閉連接的一端(后面統稱A端)發出的,如果這個ACK丟失,對方(后面統稱B端)將重發出最終的FIN,因此A端必須維護狀態信息(TIME_WAIT)允許它重發最終的ACK。如果A端不維持TIME_WAIT狀態,而是處于CLOSED 狀態,那么A端將響應RST分節,B端收到后將此分節解釋成一個錯誤(在java中會拋出connection reset的SocketException)。

因而,要實現TCP全雙工連接的正常終止,必須處理終止過程中四個分節任何一個分節的丟失情況,主動關閉連接的A端必須維持TIME_WAIT狀態 。

2)允許老的重復分節在網絡中消逝

TCP分節可能由于路由器異常而“迷途”,在迷途期間,TCP發送端可能因確認超時而重發這個分節,迷途的分節在路由器修復后也會被送到最終目的地,這個遲到的迷途分節到達時可能會引起問題。在關閉“前一個連接”之后,馬上又重新建立起一個相同的IP和端口之間的“新連接”,“前一個連接”的迷途重復分組在“前一個連接”終止后到達,而被“新連接”收到了。為了避免這個情況,TCP協議不允許處于TIME_WAIT狀態的連接啟動一個新的可用連接,因為TIME_WAIT狀態持續2MSL,就可以保證當成功建立一個新TCP連接的時候,來自舊連接重復分組已經在網絡中消逝。

MSL時間

—————————-

MSL就是maximum segment lifetime(最大分節生命期),這是一個IP數據包能在互聯網上生存的最長時間,超過這個時間IP數據包將在網絡中消失 。MSL在RFC 1122上建議是2分鐘,而源自berkeley的TCP實現傳統上使用30秒。

TIME_WAIT狀態維持時間

—————————-

TIME_WAIT狀態維持時間是兩個MSL時間長度,也就是在1-4分鐘。Windows操作系統就是4分鐘。

用于統計當前各種狀態的連接的數量的命令

—————————

#netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

返回結果如下:

LAST_ACK 14

SYN_RECV 348

ESTABLISHED 70

FIN_WAIT1 229

FIN_WAIT2 30

CLOSING 33

TIME_WAIT 18122

對上述結果的解釋:

CLOSED:無連接是活動的或正在進行

LISTEN:服務器在等待進入呼叫

SYN_RECV:一個連接請求已經到達,等待確認

SYN_SENT:應用已經開始,打開一個連接

ESTABLISHED:正常數據傳輸狀態

FIN_WAIT1:應用說它已經完成

FIN_WAIT2:另一邊已同意釋放

ITMED_WAIT:等待所有分組死掉

CLOSING:兩邊同時嘗試關閉

TIME_WAIT:另一邊已初始化一個釋放

LAST_ACK:等待所有分組死掉

進一步論述這個問題:

===============================

————–客戶端主動關閉連接———————–

注意一個問題,進入TIME_WAIT狀態的一般情況下是客戶端。

大多數服務器端一般執行被動關閉,服務器不會進入TIME_WAIT狀態。

當在服務器端關閉某個服務再重新啟動時,服務器是會進入TIME_WAIT狀態的。

舉例:

1.客戶端連接服務器的80服務,這時客戶端會啟用一個本地的端口訪問服務器的80,訪問完成后關閉此連接,立刻再次訪問服務器的

80,這時客戶端會啟用另一個本地的端口,而不是剛才使用的那個本地端口。原因就是剛才的那個連接還處于TIME_WAIT狀態。

2.客戶端連接服務器的80服務,這時服務器關閉80端口,立即再次重啟80端口的服務,這時可能不會成功啟動,原因也是服務器的連

接還處于TIME_WAIT狀態。

服務端提供服務時,一般監聽一個端口就夠了。例如Apach監聽80端口。

客戶端則是使用一個本地的空閑端口(大于1024),與服務端的Apache的80端口建立連接。

當通信時使用短連接,并由客戶端主動關閉連接時,主動關閉連接的客戶端會產生TIME_WAIT狀態的連接,一個TIME_WAIT狀態的連接就占用了一個本地端口。這樣在TIME_WAIT狀態結束之前,本地最多就能承受6萬個TIME_WAIT狀態的連接,就無端口可用了。

客戶端與服務端進行短連接的TCP通信,如果在同一臺機器上進行壓力測試模擬上萬的客戶請求,并且循環與服務端進行短連接通信,那么這臺機器將產生4000個左右的TIME_WAIT socket,后續的短連接就會產生address already in use : connect的異常。

關閉的時候使用RST的方式,不進入 TIME_WAIT狀態,是否可行?

————–服務端主動關閉連接——————————

服務端提供在服務時,一般監聽一個端口就夠了。例如Apach監聽80端口。

客戶端則是使用一個本地的空閑端口(大于1024),與服務端的Apache的80端口建立連接。

當通信時使用短連接,并由服務端主動關閉連接時,主動關閉連接的服務端會產生TIME_WAIT狀態的連接。

由于都連接到服務端80端口,服務端的TIME_WAIT狀態的連接會有很多個。

假如server一秒鐘處理1000個請求,那么就會積壓240秒*1000=24萬個TIME_WAIT的記錄,服務有能力維護這24萬個記錄。

大多數服務器端一般執行被動關閉,服務器不會進入TIME_WAIT狀態。

服務端為了解決這個TIME_WAIT問題,可選擇的方式有三種:

    ?  保證由客戶端主動發起關閉(即做為B端)

    ?  關閉的時候使用RST的方式

    ?  對處于TIME_WAIT狀態的TCP允許重用

一般Apache的配置是:

Timeout 30 

KeepAlive On   #表示服務器端不會主動關閉鏈接 

MaxKeepAliveRequests 100 

KeepAliveTimeout 180 

表示:Apache不會主動關閉鏈接,

兩種情況下Apache會主動關閉連接:

1、Apache收到了http協議頭中有客戶端要求Apache關閉連接信息,如setRequestHeader("Connection", "close"); 

2、連接保持時間達到了180秒的超時時間,將關閉。

如果配置如下:

KeepAlive Off   #表示服務器端會響應完數據后主動關閉鏈接 

————–有代理時——————————

nginx代理使用了短鏈接的方式和后端交互,如果使用了nginx代理,那么系統TIME_WAIT的數量會變得比較多,這是由于nginx代理使用了短鏈接的方式和后端交互的原因,使得nginx和后端的ESTABLISHED變得很少而TIME_WAIT很多。這不但發生在安裝nginx的代理服務器上,而且也會使后端的app服務器上有大量的TIME_WAIT。查閱TIME_WAIT資料,發現這個狀態很多也沒什么大問題,但可能因為它占用了系統過多的端口,導致后續的請求無法獲取端口而造成障礙。

對于大型的服務,一臺server搞不定,需要一個LB(Load Balancer)把流量分配到若干后端服務器上,如果這個LB是以NAT方式工作的話,可能會帶來問題。假如所有從LB到后端Server的IP包的source address都是一樣的(LB的對內地址),那么LB到后端Server的TCP連接會受限制,因為頻繁的TCP連接建立和關閉,會在server上留下TIME_WAIT狀態,而且這些狀態對應的remote address都是LB的,LB的source port撐死也就60000多個(2^16=65536,1~1023是保留端口,還有一些其他端口缺省也不會用),每個LB上的端口一旦進入Server的TIME_WAIT黑名單,就有240秒不能再用來建立和Server的連接,這樣LB和Server最多也就能支持300個左右的連接。如果沒有LB,不會有這個問題,因為這樣server看到的remote address是internet上廣闊無垠的集合,對每個address,60000多個port實在是夠用了。

一開始我覺得用上LB會很大程度上限制TCP的連接數,但是實驗表明沒這回事,LB后面的一臺Windows Server 2003每秒處理請求數照樣達到了600個,難道TIME_WAIT狀態沒起作用?用Net Monitor和netstat觀察后發現,Server和LB的XXXX端口之間的連接進入TIME_WAIT狀態后,再來一個LB的XXXX端口的SYN包,Server照樣接收處理了,而是想像的那樣被drop掉了。翻書,從書堆里面找出覆滿塵土的大學時代買的《UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI》,中間提到一句,對于BSD-derived實現,只要SYN的sequence number比上一次關閉時的最大sequence number還要大,那么TIME_WAIT狀態一樣接受這個SYN,難不成Windows也算BSD-derived?有了這點線索和關鍵字(BSD),找到這個post,在NT4.0的時候,還是和BSD-derived不一樣的,不過Windows Server 2003已經是NT5.2了,也許有點差別了。

做個試驗,用Socket API編一個Client端,每次都Bind到本地一個端口比如2345,重復的建立TCP連接往一個Server發送Keep-Alive=false的HTTP請求,Windows的實現讓sequence number不斷的增長,所以雖然Server對于Client的2345端口連接保持TIME_WAIT狀態,但是總是能夠接受新的請求,不會拒絕。那如果SYN的Sequence Number變小會怎么樣呢?同樣用Socket API,不過這次用Raw IP,發送一個小sequence number的SYN包過去,Net Monitor里面看到,這個SYN被Server接收后如泥牛如海,一點反應沒有,被drop掉了。

按照書上的說法,BSD-derived和Windows Server 2003的做法有安全隱患,不過至少這樣至少不會出現TIME_WAIT阻止TCP請求的問題,當然,客戶端要配合,保證不同TCP連接的sequence number要上漲不要下降。

——————————————-

Q: 我正在寫一個unix server程序,不是daemon,經常需要在命令行上重啟它,絕大

多數時候工作正常,但是某些時候會報告"bind: address in use",于是重啟失

敗。

A: Andrew Gierth

server程序總是應該在調用bind()之前設置SO_REUSEADDR套接字選項。至于

TIME_WAIT狀態,你無法避免,那是TCP協議的一部分。

Q: 編寫 TCP/SOCK_STREAM 服務程序時,SO_REUSEADDR到底什么意思?

A: 這個套接字選項通知內核,如果端口忙,但TCP狀態位于 TIME_WAIT ,可以重用

端口。如果端口忙,而TCP狀態位于其他狀態,重用端口時依舊得到一個錯誤信息,

指明"地址已經使用中"。如果你的服務程序停止后想立即重啟,而新套接字依舊

使用同一端口,此時 SO_REUSEADDR 選項非常有用。必須意識到,此時任何非期

望數據到達,都可能導致服務程序反應混亂,不過這只是一種可能,事實上很不

可能。

一個套接字由相關五元組構成,協議、本地地址、本地端口、遠程地址、遠程端

口。SO_REUSEADDR 僅僅表示可以重用本地本地地址、本地端口,整個相關五元組

還是唯一確定的。所以,重啟后的服務程序有可能收到非期望數據。必須慎重使

用 SO_REUSEADDR 選項。

文章出自:CCIE那點事 http://www.qdxgqk.live/ 版權所有。本站文章除注明出處外,皆為作者原創文章,可自由引用,但請注明來源。 禁止全文轉載。
本文標題:TIME_WAIT狀態原理
本文鏈接:http://www.qdxgqk.live/?p=3999轉載請注明轉自CCIE那點事
如果喜歡:點此訂閱本站
  • 相關文章
  • 為您推薦
  • 各種觀點
?
暫時還木有人評論,坐等沙發!
發表評論

您必須 [ 登錄 ] 才能發表留言!

?
?
萌宠夺宝游戏