三次握手
tcp是面向連線的，無論哪一方向另一方傳送資料之前，都必須先在雙方之間建立一條連線。在tcp/ip協議中，tcp 協議提供可靠的連線服務，連線是通過三次握手進行初始化的。三次握手的目的是同步連線雙方的序列號和確認號 並交換 tcp視窗大小資訊。
1.第一次握手：建立連線。客戶端傳送連線請求報文段，將syn位置為1，sequence number為x;然後，客戶端進入syn_send狀態，等待伺服器的確認;
2.第二次握手：伺服器收到syn報文段。伺服器收到客戶端的syn報文段，需要對這個syn報文段進行確認，設定acknowledgment number為x+1(sequence number+1);同時，自己自己還要傳送syn請求資訊，將syn位置為1，sequence number為y;伺服器端將上述所有資訊放到乙個報文段(即syn+ack報文段)中，一併傳送給客戶端，此時伺服器進入syn_recv狀態;
3.第三次握手：客戶端收到伺服器的syn+ack報文段。然後將acknowledgment number設定為y+1，向伺服器傳送ack報文段，這個報文段傳送完畢以後，客戶端和伺服器端都進入established狀態，完成tcp三次握手。
完成了三次握手，客戶端和伺服器端就可以開始傳送資料。以上就是tcp三次握手的總體介紹。
那四次揮手呢?
當客戶端和伺服器通過三次握手建立了tcp連線以後，當資料傳送完畢，肯定是要斷開tcp連線的啊。那對於tcp的斷開連線，這裡就有了神秘的「四次揮手」。
1.第一次揮手：主機1(可以使客戶端，也可以是伺服器端)，設定sequence number和acknowledgment number，向主機2傳送乙個fin報文段;此時，主機1進入fin_wait_1狀態;這表示主機1沒有資料要傳送給主機2了;
2.第二次揮手：主機2收到了主機1傳送的fin報文段，向主機1回乙個ack報文段，acknowledgment number為sequence number加1;主機1進入fin_wait_2狀態;主機2告訴主機1，我也沒有資料要傳送了，可以進行關閉連線了;
3.第三次揮手：主機2向主機1傳送fin報文段，請求關閉連線，同時主機2進入close_wait狀態;
4.第四次揮手：主機1收到主機2傳送的fin報文段，向主機2傳送ack報文段，然後主機1進入time_wait狀態;主機2收到主機1的ack報文段以後，就關閉連線;此時，主機1等待2msl後依然沒有收到回覆，則證明server端已正常關閉，那好，主機1也可以關閉連線了。
至此，tcp的四次揮手就這麼愉快的完成了。當你看到這裡，你的腦子裡會有很多的疑問，很多的不懂，感覺很凌亂;沒事，我們繼續總結。
為什麼要三次握手?
既然總結了tcp的三次握手，那為什麼非要三次呢?怎麼覺得兩次就可以完成了。那tcp為什麼非要進行三次連線呢?在謝希仁的《計算機網路》中是這樣說的：
為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤。
在書中同時舉了乙個例子，如下：
"已失效的連線請求報文段」的產生在這樣一種情況下：client發出的第乙個連線請求報文段並沒有丟失，
而是在某個網路結點長時間的滯留了，以致延誤到連線釋放以後的某個時間才到達server。本來這是一
個早已失效的報文段。但server收到此失效的連線請求報文段後，就誤認為是client再次發出的乙個新
的連線請求。於是就向client發出確認報文段，同意建立連線。假設不採用「三次握手」，那麼只要server
發出確認，新的連線就建立了。由於現在client並沒有發出建立連線的請求，因此不會理睬server的確認，
也不會向server傳送資料。但server卻以為新的運輸連線已經建立，並一直等待client發來資料。這樣，
server的很多資源就白白浪費掉了。採用「三次握手」的辦法可以防止上述現象發生。例如剛才那種情況，
client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連線。"
這就很明白了，防止了伺服器端的一直等待而浪費資源。
為什麼要四次揮手?
那四次揮手又是為何呢?tcp協議是一種面向連線的、可靠的、基於位元組流的運輸層通訊協議。tcp是全雙工 模式，這就意味著，當主機1發出fin報文段時，只是表示主機1已經沒有資料要傳送了，主機1告訴主機2， 它的資料已經全部傳送完畢了;但是，這個時候主機1還是可以接受來自主機2的資料;當主機2返回ack報文 段時，表示它已經知道主機1沒有資料傳送了，但是主機2還是可以傳送資料到主機1的;當主機2也傳送了fin 報文段時，這個時候就表示主機2也沒有資料要傳送了，就會告訴主機1，我也沒有資料要傳送了，之後彼此 就會愉快的中斷這次tcp連線。如果要正確的理解四次揮手的原理，就需要了解四次揮手過程中的狀態變化。
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資訊)，稍後再關閉連線。 (主動方)
close_wait：這種狀態的含義其實是表示在等待關閉。怎麼理解呢?當對方close乙個socket後傳送fin 報文給自己，你系統毫無疑問地會回應乙個ack報文給對方，此時則進入到close_wait狀態。接下來呢，實 際上你真正需要考慮的事情是察看你是否還有資料傳送給對方，如果沒有的話，那麼你也就可以 close這個 socket，傳送fin報文給對方，也即關閉連線。所以你在close_wait狀態下，需要完成的事情是等待你去關 閉連線。(被動方)
last_ack: 這個狀態還是比較容易好理解的，它是被動關閉一方在傳送fin報文後，最後等待對方的ack報 文。當收到ack報文後，也即可以進入到closed可用狀態了。(被動方)
time_wait: 表示收到了對方的fin報文，並傳送出了ack報文，就等2msl後即可回到closed可用狀態了。 如果finwait1狀態下，收到了對方同時帶fin標誌和ack標誌的報文時，可以直接進入到time_wait狀態，而無 須經過fin_wait_2狀態。(主動方)
closed: 表示連線中斷。
三次握手四次揮手的原理
tcp是面向連線的，無論哪一方向另一方傳送資料之前，都必須先在雙方之間建立一條連線。在tcp ip協議中，tcp 協議提供可靠的連線服務，連線是通過三次握手進行初始化的。三次握手的目的是同步連線雙方的序列號和確認號 並交換 tcp視窗大小資訊。1.第一次握手 建立連線。客戶端傳送連線請求報文段，將s...
三次握手 四次揮手
1.tcp連線的建立 1 首先是伺服器初始化的過程，從 closed 關閉 狀態開始通過順序呼叫 socket bind listen 和accept 原語建立 socket 套接字，進入 listen 監聽 狀態，等待客戶端的 tcp傳輸連線請求。2 客戶端最開始也是從 closed 狀態開始呼叫...
三次握手，四次揮手
三次握手 three times handshake three way handshake 所謂的 三次握手 即對每次傳送的 資料量是怎樣跟蹤進行協商使 資料段的傳送和接收同步，根據所接收到的資料量而確定的資料確認數及資料傳送 接收完畢後何時撤消聯絡，並建立虛連線。為了提供可靠的傳送，tcp在傳送...