1、建立連接協議（三次握手）
（1）客戶端發送一個帶SYN標志的TCP報文到服務器。這是三次握手過程中的報文1。
（2） 服務器端回應客戶端的，這是三次握手中的第2個報文，這個報文同時帶ACK標志和SYN標志。因此它表示對剛才客戶端SYN報文的回應；同時又標志SYN給客戶端，詢問客戶端是否准備好進行數據通訊。
（3） 客戶必須再次回應服務段一個ACK報文，這是報文段3。
2、連接終止協議（四次握手）
由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
（1） TCP客戶端發送一個FIN，用來關閉客戶到服務器的數據傳送（報文段4）。
（2） 服務器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將占用一個序號。
（3） 服務器關閉客戶端的連接，發送一個FIN給客戶端（報文段6）。
（4） 客戶段發回ACK報文確認，並將確認序號設置為收到序號加1（報文段7）。
CLOSED: 這個沒什么好說的了，表示初始狀態。
LISTEN: 這個也是非常容易理解的一個狀態，表示服務器端的某個SOCKET處於監聽狀態，可以接受連接了。
SYN_RCVD: 這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是服務器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態，很短暫，基本 上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程序，故意將三次TCP握手過程中最后一個ACK報文不予發送。因此這種狀態 時，當收到客戶端的ACK報文后，它會進入到ESTABLISHED狀態。
SYN_SENT: 這個狀態與SYN_RCVD遙想呼應，當客戶端SOCKET執行CONNECT連接時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀 態，並等待服務端的發送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已發送SYN報文。
ESTABLISHED：這個容易理解了，表示連接已經建立了。
FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別 是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連接，向對方發送了FIN報文，此時該SOCKET即 進入到FIN_WAIT_1狀態。而當對方回應ACK報文后，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬 上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。
FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數據需要傳送給你，稍后再關閉連接。
TIME_WAIT: 表示收到了對方的FIN報文，並發送出了ACK報文，就等2MSL后即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶 FIN標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。
CLOSING: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你發送FIN報文后，按理來說是應該先收到（或同時收到）對方的 ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文后，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什 么情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方幾乎在同時close一個SOCKET的話，那么就出現了雙方同時發送FIN報 文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連接。
CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎么理解呢？當對方close一個SOCKET后發送FIN報文給自己，你系統毫無疑問地會回應一個ACK報文給對 方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數據發送給對方，如果沒有的話，那么你也就可以 close這個SOCKET，發送FIN報文給對方，也即關閉連接。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連接。
LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在發送FIN報文后，最后等待對方的ACK報文。當收到ACK報文后，也即可以進入到CLOSED可用狀態了。
最后有2個問題的回答，我自己分析后的結論（不一定保證100%正確）
1、 為什么建立連接協議是三次握手，而關閉連接卻是四次握手呢？
這 是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一 個報文里來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可以未 必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的ACK報文 和FIN報文多數情況下都是分開發送的。
2、 為什么TIME_WAIT狀態還需要等2MSL后才能返回到CLOSED狀態？
這是因為： 雖然雙方都同意關閉連接了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到 ESTABLISH狀態那樣）；但是因為我們必須要假想網絡是不可靠的，你無法保證你最后發送的ACK報文會一定被對方收到，因此對方處於 LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的 ACK報文。
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 選項。