syn：同步序列編號
; ack=1:
確認序號
; fin
附加標記的報文段（
fin表示英文
finish
）乙個tcp連線必須要經過三次「對話
」才能建立起來，其中的過程非常複雜，只簡單的 描述下這三次對話的簡單過程：
主機a向主機b發出連線請求資料報：「我想給你發資料，可以嗎？」，這是第一次對話；三次「主機b向主機a傳送同意連線和要求同步 （同步就是兩台主機乙個在傳送，乙個在接收，協調工作）的資料報：「可以，你什麼時候發？」，這是第二次對話；
主機a再發出乙個資料報確認主機b的要求同 步：「我現在就發，你接著吧！」，這是第三次對話。
對話」的目的是使資料報的傳送和接收同步，經過三次「對話
」之後，主機
a才向主機
b正式傳送資料。
為什麼需要「三次握手
」?在謝希仁著《計算機網路》第四版中講「三次握手
」的目的是
「為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤」。在另一部經典的《計算機網路》一書中講
「三次握手
」的目的是為了解決
「網路中存在延遲的重複分組
」的問題。這兩種不一樣的表述其實闡明的是同乙個問題。
謝希仁版《計算機網路》中的例子是這樣的，
「已失效的連線請求報文段
」的產生在這樣一種情況下：
client
發出的第乙個連線請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連線釋放以後的某個時間才到達
server
。本來這是乙個早已失效的報文段。但server收到此失效的連線請求報文段後，就誤認為是
client
再次發出的乙個新的連線請求。於是就向
client
發出確認報文段，同意建立連線。假設不採用
「三次握手
」，那麼只要
server
發出確認，新的連線就建立了。由於現在
client
並沒有發出建立連線的請求，因此不會理睬
server
的確認，也不會向
server
傳送資料。但
server
卻以為新的運輸連線已經建立，並一直等待
client
發來資料。這樣，
server
的很多資源就白白浪費掉了。採用「三次握手
」的辦法可以防止上述現象發生。例如剛才那種情況，
client
不會向server
的確認發出確認。
server
由於收不到確認，就知道
client
並沒有要求建立連線。
」。主要目的防止server端一直等待，浪費資源。
為什麼需要「四次揮手
」？可能有人會有疑問，在tcp連線握手時為何
ack是和
syn一起傳送，這裡
ack卻沒有和
fin一起傳送呢。原因是因為tcp是全雙工模式，接收到
fin時意味將沒有資料再發來，但是還是可以繼續傳送資料。
握手，揮手過程中各狀態介紹:
3次握手過程狀態：
listen: 這個也是非常容易理解的乙個狀態，表示伺服器端的某個
socket
處於監聽狀態，可以接受連線了。
syn_sent: 當客戶端
socket
執行connect
連線時，它首先傳送
syn報文，因此也隨即它會進入到了
syn_sent
狀態，並等待服務端的傳送三次握手中的第
2個報文。
syn_sent
狀態表示客戶端已傳送
syn報文。（傳送端）
syn_rcvd: 這個狀態與
syn_sent
遙想呼應這個狀態表示接受到了
syn報文，在正常情況下，這個狀態是伺服器端的
socket
在建立tcp
連線時的三次握手會話過程中的乙個中間狀態，很短暫，基本上用
netstat
你是很難看到這種狀態的，除非你特意寫了乙個客戶端測試程式，故意將三次
tcp握手過程中最後乙個
ack報文不予傳送。因此這種狀態時，當收到客戶端的
ack報文後，它會進入到
established
狀態。（伺服器端）
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連線，但另外還告訴對方，我暫時還有點資料需要傳送給你
(ack資訊)
，稍後再關閉連線。（主動方）
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
可用狀態了。（被動方）
closed:表示連線中斷。
TCP三次握手 四次揮手
tcp 三次握手 tcp 連線是通過三次握手進行初始化的。三次握手的目的是同步連線雙方的序列號和確認號並交換 tcp 視窗大小資訊。以下步驟概述了通常情況下客戶端計算機聯絡伺服器計算機的過程 1.客戶端向伺服器傳送乙個syn置位的tcp報文，其中包含連線的初始序列號x和乙個視窗大小 表示客戶端上用來...
TCP三次握手 四次揮手
服務端的tcp程序先建立傳輸控制塊tcb，準備接受客戶端程序的連線請求，然後服務端程序處於listen狀態，等待客戶端的連線請求，如有，則作出響應。1 客戶端的tcp程序也首先建立傳輸控制模組tcb，然後向服務端發出連線請求報文段，該報文段首部中的syn 1，ack 0，同時選擇乙個初始序號seq ...
TCP三次握手四次揮手
tcp transmission control protocol 傳輸控制協議 tcp是主機對主機層的傳輸控制協議，提供可靠的連線服務，採用三次握手確認建立乙個連線。位碼即tcp標誌位,有6種標誌 urg urgent緊急 ack acknowledgement 確認 psh push傳送 rst...