tcp三次握手和四次揮手的全過程
tcp是主機對主機層的傳輸控制協議，提供可靠的連線服務，採用三次握手確認建立乙個連線:syn(synchronous建立連線)
ack(acknowledgement 表示響應、確認)
psh(push表示有data資料傳輸)
fin(finish關閉連線)
rst(reset表示連線重置)
urg(urgent緊急指標字段值有效)
三次握手：
第一次握手：客戶端傳送syn包(syn=x)到伺服器，並進入syn_send狀態，等待伺服器確認；
第二次握手：伺服器收到syn包，必須確認客戶的syn（ack=x+1），同時自己也傳送乙個syn包（syn=y），即syn+ack包，此時伺服器進入syn_recv狀態；
第三次握手：客戶端收到伺服器的syn＋ack包，向伺服器傳送確認包ack(ack=y+1)，此包傳送完畢，客戶端和伺服器進入established狀態，完成三次握手。
握手過程中傳送的包裡不包含資料，三次握手完畢後，客戶端與伺服器才正式開始傳送資料。理想狀態下，tcp連線一旦建立，在通訊雙方中的任何一方主動關閉連線之前，tcp 連線都將被一直保持下去。與建立連線的「三次握手」類似，斷開乙個tcp連線則需要「四次揮手」。
第一次揮手：主動關閉方傳送乙個fin，用來關閉主動方到被動關閉方的資料傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發資料了(當然，在fin包之前傳送出去的資料，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些資料)，但是，此時主動關閉方還可以接受資料。
第二次揮手：被動關閉方收到fin包後，傳送乙個ack給對方，確認序號為收到序號+1（與syn相同，乙個fin占用乙個序號）。
第三次揮手：被動關閉方傳送乙個fin，用來關閉被動關閉方到主動關閉方的資料傳送，也就是告訴主動關閉方，我的資料也傳送完了，不會再給你發資料了。
第四次揮手：主動關閉方收到fin後，傳送乙個ack給被動關閉方，確認序號為收到序號+1，至此，完成四次揮手。
tcp的四次揮手過程（簡言之）：主動關閉方向被動關閉方傳送不會再給你發資料了的資訊；被動關閉方對收到的主動關閉方的報文段進行確認；被動關閉方向主動關閉方傳送我也不會再給你發資料了的資訊；主動關閉方再次對被動關閉方的確認進行確認。
tcp三次握手和四次揮手的全過程如下圖：
tcp的三次握手過程？為什麼會採用三次握手，若採用二次握手可以嗎？
答：建立連線的過程是利用客戶伺服器模式，假設主機a為客戶端，主機b為伺服器端。
（1）tcp的三次握手過程：主機a向b傳送連線請求；主機b對收到的主機a的報文段進行確認；主機a再次對主機b的確認進行確認。
（2）採用三次握手是為了防止失效的連線請求報文段突然又傳送到主機b，因而產生錯誤。失效的連線請求報文段是指：主機a發出的連線請求沒有收到主機b的確認，於是經過一段時間後，主機a又重新向主機b傳送連線請求，且建立成功，順序完成資料傳輸。考慮這樣一種特殊情況，主機a第一次傳送的連線請求並沒有丟失，而是因為網路節點導致延遲達到主機b，主機b以為是主機a又發起的新連線，於是主機b同意連線，並向主機a發回確認，但是此時主機a根本不會理會，主機b就一直在等待主機a傳送資料，導致主機b的資源浪費。
（3）採用兩次握手不行，原因就是上面說的失效的連線請求的特殊情況，因此採用三次握手剛剛好，兩次可能出現失效，四次甚至更多次則沒必要，反而複雜了。
三次握手和四次揮手
三次握手和四次揮手如圖所示 為什麼是三次握手而不是兩次 因為當客戶端第傳送syn到服務端的時候，如果有幾次請求是因為網路等原因延時等情況的時候，如果沒有第三次握手的確定。服務端就會認為客戶端重寫傳送請求了，就會去開啟連線相應。為什麼關閉連線的時候是四次握手而不是三次？當客戶端傳送請求關閉連線的時候，...
三次握手和四次揮手
1.在學習tcp協議的時候，總是在強調三次握手，那麼為什麼是三次？而不是兩次或者四次？強迫症表示黑人問號？今天我們就來分析一下為什麼是三次，下圖是一次tcp通訊的時序 在這個例子中,首先客戶端主動發起連線 傳送請求,然後伺服器端響應請求,然後客戶端主動關閉連線。兩條豎線表示通訊的兩端,從上到下表 示...
三次握手和四次揮手
1.三次握手 1 目的 連線伺服器指定埠，建立tcp連線，並同步連線雙方的序列號和確認號，並交換tcp視窗大小資訊 2 過程 在socket程式設計中，客戶端執行connect 時進行三次握手 如上圖所示，第一握手進行後，客戶端處於syn sent狀態，客戶端的syn報文伺服器收到後，伺服器處於li...