TCP/IP TIME_WAIT状态原理
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 選項。?
總結
以上是生活随笔為你收集整理的TCP/IP TIME_WAIT状态原理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： sscanf，sscanf_s及其相关用
- 下一篇： AI 趋势