三次握手：
瀏覽器和遠端web伺服器通過tcp三次握手協商來建立乙個tcp/ip連線。該握手包括乙個同步報文，乙個同步-應答報文和乙個應答報文，這三個報文在瀏覽器和伺服器之間傳遞。首先由客戶端嘗試建立通訊，而後伺服器應答並接受客戶端的請求，最後由客戶端發出該請求已經被接受的報文。
第一次握手：建立連線
客戶端傳送連線請求報文段，將syn值設為1，seq為x。客戶端進入syn_send狀態，等待伺服器的確認。
第二次握手：伺服器收到syn報文段
伺服器收到客戶端syn報文段，需要對這個syn報文段進行確認，設定ack number為x+1（即seq number + 1）。同時，自己還要傳送syn請求資訊，將syn值設為1，seq number設為y。伺服器端將上述所有資訊放到乙個報文段（即syn+ack報文段）中，一併傳送給客戶端，伺服器進入syn_recv狀態。
第三次握手：客戶端收到syn+ack報文段
客戶端收到伺服器的syn+ack報文段後將ack number設為y+1，向伺服器傳送ack報文段，這個報文段傳送完畢後，客戶端和伺服器端都進入established狀態，完成tcp三次握手。
為什麼是三次握手？
假如是2次的話，可能會出現這樣乙個情況：
當客戶端傳送一次請求a後，但是a在網路延遲了很久，接著客戶端又傳送了一次b，但是此時a已經無效了。接著伺服器響應了b，並返回tcp連線頭，建立了連線（到此2次握手了）。然後呢，a歷經千山萬水終於到達了伺服器，伺服器一看請求來了，則接受，由於一開始a帶著的tcp格式都是正確的，那麼伺服器理所當然的也返回成功連線的flag，但是此時客戶端已經判斷a請求無效，廢棄了。然後伺服器就這麼一直掛著（浪費資源）。所以為保險起見，再補充一次連線就可以了，三次最合適，如果用4，5，6，7...次的話，不就更浪費嗎？
四次揮手：
第一次揮手：客戶端想分手
假設客戶端想要關閉連線，客戶端傳送乙個fin標誌位為1的包（fin=1，seq=x），表示自己已經沒有資料可以傳送了，但是仍然可以接受資料。傳送完畢，客戶端進入fin_wait_1狀態。
第二次揮手：服務端也想分手
伺服器端確認客戶端的fin包，傳送乙個確認包（ack=1， acknum=x+1）,表明自己接受到了客戶端關閉連線的請求，但還沒有準備好關閉連線。傳送完畢後，伺服器端進入close_wait狀態，客戶端接收到這個確認包之後，進入fin_wait_2狀態，等待伺服器端關閉連線。
第三次揮手：服務端準備好分手
伺服器端準備好關閉連線時，向客戶端傳送結束連線請求，fin置為1（fin=1，seq=y）。傳送完畢後，伺服器端進入last_ack狀態，等待來自客戶端的最後乙個ack。
第四次揮手：分手
客戶端接收到來自伺服器端的關閉請求，傳送乙個確認包（ack=1, acknum=y+1）,並進入time_wait狀態，等待可能出現的要求重傳的ack包。
伺服器端接收到這個確認包之後，關閉連線，進入close狀態。
客戶端等待2msl（2 maximum segment lifetime）之後，沒有收到回覆，確保伺服器端確實是關閉了，客戶端也關閉連線，進入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...