TCP三次握手和四次握手

TCP

TCP，提供面向鏈接的服務，在傳送數據以前必須先創建鏈接，數據傳送完成後要釋放鏈接。所以，TCP是一種可靠的運輸服務，可是正由於這樣，不可避免的增長了許多的開銷，好比確認，流量控制等。對應的應用層協議主要有SMTP，Telnet，HTTP，FTP等。

TCP報文首部

源端口和目的端口

  計算機上的進程要和其餘進程通訊是要經過計算機端口的，而一個計算機端口某個時刻只能被一個進程佔用，因此經過指定源端口和目標端口，就能夠知道是哪兩個進程須要通訊。源端口、目標端口是用16位表示的，可推算計算機的端口個數爲2^16個

序號

  佔4個字節，表示本報文段所發送數據的第一個字節的編號。在TCP鏈接中所傳送的字節流的每個字節都會按順序編號。因爲序列號由32位表示，因此每2^32個字節，就會出現序列號迴繞，再次從 0 開始
  例如，一段報文的序號字段值是 301 ，而攜帶的數據共有100字段，顯然下一個報文段（若是還有的話）的數據序號應該從401開始；

確認號

  佔4個字節，是指望收到對方下一個報文的第一個數據字節的序號
  例如，B收到了A發送過來的報文，其序列號字段是501，而數據長度是200字節，這代表B正確的收到了A發送的到序號700爲止的數據。所以，B指望收到A的下一個數據序號是701，因而B在發送給A的確認報文段中把確認號置爲701

數據偏移

  佔4位，它指出TCP報文的數據距離TCP報文段的起始處有多遠

保留

  佔6位，保留從此使用，但目前應都爲0

緊急指針URG

  當URG=1，代表緊急指針字段有效。告訴系統此報文段中有緊急數據

確認ACK

  僅當ACK=1時，確認號字段纔有效。TCP規定，在鏈接創建後全部報文的傳輸都必須把ACK置1

推送PSH

  當兩個應用進程進行交互式通訊時，有時在一端的應用進程但願在鍵入一個命令後當即就能收到對方的響應，這時候就將PSH=1

復位RST

  當RST=1，代表TCP鏈接中出現嚴重差錯，必須釋放鏈接，而後再從新創建鏈接

同步SYN

  在鏈接創建時用來同步序號。當SYN=1，ACK=0，代表是鏈接請求報文，若贊成鏈接，則響應報文中應該使SYN=1，ACK=1

終止FIN

  用來釋放鏈接。當FIN=1，代表此報文的發送方的數據已經發送完畢，而且要求釋放

窗口

  佔2字節，表示如今容許對方發送的數據量，也就是告訴對方，從本報文段的確認號開始容許對方發送的數據量，達到此值，須要ACK確認後才能再繼續傳送後面數據

檢驗和

  佔2字節，校驗首部和數據這兩部分，提供額外的可靠性

緊急指針

  佔2字節，指出本報文段中的緊急數據的字節數

選項

  其最大長度可根據TCP首部長度進行推算。 TCP首部長度用4位表示，選項部分最長爲：(2^4-1)*4-20=40字節

TCP三次握手

最開始的時候 客戶端A 和 服務器B 都是處於CLOSED狀態。主動打開鏈接的爲客戶端，被動打開鏈接的是服務端

1. TCP服務器B 進程先建立傳輸控制塊TCB，時刻準備接受客戶A 進程的鏈接請求，此時 服務器B 就進入了LISTEN（收聽）狀態;
2. TCP客戶A 進程也是先建立傳輸控制塊TCB，而後向服務器B 發出鏈接請求報文，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端A 進程進入了 SYN-SENT（同步已發送）狀態。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但須要消耗掉一個序號。
3. TCP服務器B 收到請求報文後，若是贊成鏈接，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要爲本身初始化一個序列號 seq=y，此時，TCP服務器B 進程進入了SYN-RCVD（同步收到）狀態。這個報文也不能攜帶數據，可是一樣要消耗一個序號。
4. TCP客戶A 進程收到確認後，還要向服務器B 給出確認。確認報文的ACK=1，ack=y+1，本身的序列號seq=x+1，此時，TCP鏈接創建，客戶端A 進入ESTABLISHED（已創建鏈接）狀態。
5. 當服務器B 收到客戶端A 的確認後也進入ESTABLISHED（已創建鏈接）狀態，此後雙方就能夠開始通訊了。

爲何TCP客戶端A最後還要發送一次確認呢？

  主要是防止已經失效的連接請求報文忽然又傳送到了服務器B，從而產生錯誤。

爲何要三次握手，而不是兩次握手呢？

  若是使用兩次握手創建鏈接，客戶端A 發送了第一個請求鏈接而且沒有丟失，只是由於在網絡結點中滯留時間過長，因爲TCP的客戶端A 這次沒有收到確認的報文，覺得服務器B 沒有收到，此時從新向服務器B 發送這條報文，此後客戶端A 和服務器B 通過兩次握手完成了鏈接欸，傳輸數據，而後關閉鏈接。此時此前滯留的那一次請求鏈接，網絡通暢了到達了服務器B ，這個報文本該是失效的，可是，兩次握手的機制將會讓客戶端A 和服務器B 再次創建鏈接，這將致使沒必要要的錯誤和資源的浪費。
  若是採用的是三次握手，就算是那一次失效的報文傳送過來了，服務端B 接受到了那條失效報文而且回覆了確認報文，可是客戶端A 不會再次發出確認。因爲服務器B 收不到確認，就知道客戶端A 並無請求鏈接。

TCP四次握手

數據傳輸完畢後，雙方均可釋放鏈接。最開始的時候，客戶端A 和服務器B 都是處於ESTABLISHED（創建）狀態，而後客戶端A 主動關閉，服務器B 被動關閉

1. 客戶端A 進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端A 進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即便不攜帶數據，也要消耗一個序號。
2. 服務器B 收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1，而且帶上本身的序列號seq=v，此時，服務端B 就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器B 通知高層的應用進程，客戶端A 向服務器B 的方向就釋放了，這時候處於半關閉狀態，即客戶端A 已經沒有數據要發送了，可是服務器B 若發送數據，客戶端A 依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3. 客戶端A 收到服務器B 的確認請求後，此時，客戶端A 就進入FIN-WAIT-2（終止等待2）狀態，等待服務器B 發送鏈接釋放報文（在這以前還須要接受服務器B 發送的最後的數據）。
4. 服務器B 將最後的數據發送完畢後，就向客戶端A 發送鏈接釋放報文，FIN=1，ack=u+1，因爲在半關閉狀態，服務器B 極可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器B 就進入了LAST-ACK（最後確認）狀態，等待客戶端A 的確認。
5. 客戶端A 收到服務器B 的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是seq=u+1，此時，客戶端A 就進入了TIME-WAIT（時間等待）狀態。注意此時TCP鏈接尚未釋放，必須通過2∗ *∗MSL（最長報文段壽命）的時間後，當客戶端A 撤銷相應的TCB後，才進入CLOSED狀態。
6. 服務器B 只要收到了客戶端A 發出的確認，當即進入CLOSED狀態。一樣，撤銷TCB後，就結束了此次的TCP鏈接。能夠看到，服務器B 結束TCP鏈接的時間要比客戶端A 早一些。

爲何客戶端A最後還要等待2MSL呢？

1. 保證客戶端A 發送的最後一個ACK報文可以到達服務器B，由於這個ACK報文可能丟失，站在服務器B 的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端A 尚未給我回應，應該是我發送的請求斷開報文它沒有收到，因而服務器B 又會從新發送一次，而客戶端A 就能在這個2MSL時間段內收到這個重傳的報文，接着給出迴應報文，而且會重啓2MSL計時器。
2. 防止相似與「三次握手」中提到了的「已經失效的鏈接請求報文段」出如今本鏈接中。客戶端A 發送完最後一個確認報文後，在這個2MSL時間中，就可使本鏈接持續的時間內所產生的全部報文段都從網絡中消失。這樣新的鏈接中不會出現舊鏈接的請求報文。

爲何創建鏈接是三次握手，關閉鏈接確是四次揮手呢？

  創建鏈接的時候， 服務器B 在LISTEN狀態下，收到創建鏈接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端A。  而關閉鏈接時，服務器B 收到對方的FIN報文時，僅僅表示對方再也不發送數據了可是還能接收數據，而本身也未必所有數據都發送給對方了，因此己方能夠當即關閉，也能夠發送一些數據給對方後，再發送FIN報文給對方來表示贊成如今關閉鏈接，所以，己方ACK和FIN通常都會分開發送，從而致使多了一次。