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）。
[b][color=red]closed：[/color][/b] 這個沒什麼好說的了，表示初始狀態。
[b][color=red]listen：[/color][/b] 這個也是非常容易理解的乙個狀態，表示伺服器端的某個socket處於監聽狀態，可以接受連線了。
[b][color=red]syn_rcvd：[/color][/b]這個狀態表示接受到了syn報文，在正常情況下，這個狀態是伺服器端的socket在建立tcp連線時的三次握手會話過程中的乙個中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了乙個客戶端測試程式，故意將三次tcp握手過程中最後乙個ack報文不予傳送。因此這種狀態時，當收到客戶端的ack報文後，它會進入到established狀態。
[b][color=red]syn_sent：[/color][/b]這個狀態與syn_rcvd遙相呼應，當客戶端socket執行connect連線時，它首先傳送syn報文，因此也隨即它會進入到了syn_sent狀態，並等待服務端的傳送三次握手中的第2個報文。syn_sent狀態表示客戶端已傳送syn報文。
[b][color=red]established：[/color][/b]這個容易理解了，表示連線已經建立了。
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看到。
[b][color=red]fin_wait_2[/color][/b]：上面已經詳細解釋了這種狀態，實際上fin_wait_2狀態下的socket，表示半連線，也即有一方要求close連線，但另外還告訴對方，我暫時還有點資料需要傳送給你，稍後再關閉連線。
[b][color=red]time_wait[/color][/b]：表示收到了對方的fin報文，並傳送出了ack報文，就等2msl後即可回到closed可用狀態了。如果fin_wait_1狀態下，收到了對方同時帶 fin標誌和ack標誌的報文時，可以直接進入到time_wait狀態，而無須經過fin_wait_2狀態。
[b][color=red]closing[/color][/b]：這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你傳送fin報文後，按理來說是應該先收到（或同時收到）對方的 ack報文，再收到對方的fin報文。但是closing狀態表示你傳送fin報文後，並沒有收到對方的ack報文，反而卻也收到了對方的fin報文。什麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方幾乎在同時close乙個socket的話，那麼就出現了雙方同時傳送fin報文的情況，也即會出現closing狀態，表示雙方都正在關閉socket連線。
[b][color=red]close_wait[/color][/b]：這種狀態的含義其實是表示在等待關閉。怎麼理解呢？當對方close乙個socket後傳送fin報文給自己，你系統毫無疑問地會回應乙個ack報文給對方，此時則進入到close_wait狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有資料傳送給對方，如果沒有的話，那麼你也就可以 close這個socket，傳送fin報文給對方，也即關閉連線。所以你在close_wait狀態下，需要完成的事情是等待你去關閉連線。
[b][color=red]last_ack[/color][/b]： 這個狀態還是比較容易好理解的，它是被動關閉一方在傳送fin報文後，最後等待對方的ack報文。當收到ack報文後，也即可以進入到closed可用狀態了。
附乙個狀態轉換圖：
[img]
1.closed：起始點，在超時或者連線關閉時候進入此狀態。
2.listen：svr端在等待連線過來時候的狀態，svr端為此要呼叫socket， bind,listen函式，就能進入此狀態。此稱為應用程式被動開啟（等待客戶端來連線）。
3.syn_sent:客戶端發起連線，傳送syn給伺服器端。如果伺服器端不能連線，則直接進入closed狀態。
4.syn_rcvd：跟3對應，伺服器端接受客戶端的syn請求，伺服器端由listen狀態進入syn_rcvd狀態。同時伺服器端要回應乙個ack，同時傳送乙個syn給客戶端；另外一種情況，客戶端在發起syn的同時接收到伺服器端得syn請求，客戶端就會由syn_sent到syn_rcvd狀態。
5.established：伺服器端和客戶端在完成3次握手進入狀態，說明已經可以開始傳輸資料了。
以上是建立連線時伺服器端和客戶端產生的狀態轉移說明。相對來說比較簡單明瞭，如果你對三次握手比較熟悉，建立連線時的狀態轉移還是很容易理解。
接下來伺服器端和客戶端就進行資料傳輸。。。。，當然，裡面也大有學問，就此打住，稍後再表。
下面，我們來看看連線關閉時候的狀態轉移說明，關閉需要進行4次雙方的互動，還包括要處理一些善後工作（time_wait狀態），注意，這裡主動關閉的一方或被動關閉的一方不是指特指伺服器端或者客戶端，是相對於誰先發起關閉請求來說的：
6.fin_wait_1:主動關閉的一方，由狀態5進入此狀態。具體的動作時傳送fin給對方。
7.fin_wait_2:主動關閉的一方，接收到對方的fin ack，進入此狀態。由此不能再接收對方的資料。但是能夠向對方傳送資料。
8.close_wait：接收到fin以後，被動關閉的一方進入此狀態。具體動作時接收到fin，同時傳送ack。
9.last_ack：被動關閉的一方，發起關閉請求，由狀態8進入此狀態。具體動作時傳送fin給對方，同時在接收到ack時進入closed狀態。
10.closing：兩邊同時發起關閉請求時，會由fin_wait_1進入此狀態。具體動作是，接收到fin請求，同時響應乙個ack。
11.time_wait：最糾結的狀態來了。從狀態圖上可以看出，有3個狀態可以轉化成它，我們一一來分析：
a.由fin_wait_2進入此狀態：在雙方不同時發起fin的情況下，主動關閉的一方在完成自身發起的關閉請求後，接收到被動關閉一方的fin後進入的狀態。
b.由closing狀態進入:雙方同時發起關閉，都做了發起fin的請求，同時接收到了fin並做了ack的情況下，由closing狀態進入。
c.由fin_wait_1狀態進入：同時接受到fin（對方發起），ack（本身發起的fin回應），與b的區別在於本身發起的fin回應的ack先於對方的fin請求到達，而b是fin先到達。這種情況概率最小。
關閉的4次連線最難理解的狀態是time_wait，存在time_wait的2個理由：
1.可靠地實現tcp全雙工連線的終止。
2.允許老的重複分節在網路中消逝。
TCP協議連線過程詳解
1 建立連線協議 三次握手 1 客戶端傳送乙個帶syn標誌的tcp報文到伺服器。這是三次握手過程中的報文1.2 伺服器端回應客戶端的，這是三次握手中的第2個報文，這個報文同時帶ack標誌和syn標誌。因此它表示對剛才客戶端syn報文的回應 同時又標誌syn給客戶端，詢問客戶端是否準備好進行資料通訊。...
TCP連線解釋及連線過程描述
1.tcp連線的建立 設主機b執行乙個伺服器程序，它先發出乙個被動開啟命令，告訴它的tcp要準備接收客戶程序的連續請求，然後服務程序就處於聽的狀態。不斷檢測是否有客戶程序發起連續請求，如有，作出響應。設客戶程序執行在主機a中，他先向自己的tcp發出主動開啟的命令，表明要向某個ip位址的某個埠建立運輸...
zabbix主動 被動TCP連線過程
zabbix agent檢測分為主動 agent active 和被動 agent 兩種形式，主動與被動的說法均是相對於agent來討論的。簡單說明一下主動與被動的區別如下 主動 agent請求server獲取主動的監控項列表，並主動將監控項內需要檢測的資料提交給server proxy 被動 se...