tcp/ip三次握手四次分手，撒手。。。。

‍

TCP/IP協議三次握手與四次撒手流程解析

•  

  1、TCP報文格式
    TCP/IP協議的詳細信息參看《TCP/IP協議詳解》三卷本。下面是TCP報文格式圖：
  
  圖1 TCP報文格式
    上圖中有幾個字段須要重點介紹下：
    （1）序號：Seq序號，佔32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。
    （2）確認序號：Ack序號，佔32位，只有ACK標誌位爲1時，確認序號字段纔有效，Ack=Seq+1。
    （3）標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義以下：
    （A）URG：緊急指針（urgent pointer）有效。
    （B）ACK：確認序號有效。
    （C）PSH：接收方應該儘快將這個報文交給應用層。
    （D）RST：重置鏈接。
    （E）SYN：發起一個新鏈接。
    （F）FIN：釋放一個鏈接。
  
   須要注意的是：
    （A）不要將確認序號Ack與標誌位中的ACK搞混了。
    （B）確認方Ack=發起方Req+1，兩端配對。 
  
  2、三次握手
    所謂三次握手（Three-Way Handshake）即創建TCP鏈接，就是指創建一個TCP鏈接時，須要客戶端和服務端總共發送3個包以確認鏈接的創建。在socket編程中，這一過程由客戶端執行connect來觸發，整個流程以下圖所示：
  
  圖2 TCP三次握手
    （1）第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
    （2）第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求創建鏈接，Server將標誌位SYN和ACK都置爲 1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認鏈接請求，Server進入SYN_RCVD狀態。
    （3）第三次握手：Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發 送給Server，Server檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入 ESTABLISHED狀態，完成三次握手，隨後Client與Server之間能夠開始傳輸數據了。
   
    SYN攻擊：
    在三次握手過程當中，Server發送SYN-ACK以後，收到Client的ACK以前的TCP鏈接稱爲半鏈接（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是 Client在短期內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server回覆確認包，並等待Client的確認，因爲源地址 是不存在的，所以，Server須要不斷重發直至超時，這些僞造的SYN包將產時間佔用未鏈接隊列，致使正常的SYN請求由於隊列滿而被丟棄，從而引發網 絡堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式很是簡單，即當Server上有大量半鏈接狀態且源IP地址是隨機的，則能夠判定遭到SYN攻擊了，使用以下命令可讓之現行：
    #netstat -nap | grep SYN_RECV
  
  3、四次揮手
   三次握手耳熟能詳，四次揮手估計就，所謂四次揮手（Four-Way Wavehand）即終止TCP鏈接，就是指斷開一個TCP鏈接時，須要客戶端和服務端總共發送4個包以確認鏈接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發，整個流程以下圖所示：
  
  圖3 TCP四次揮手
    因爲TCP鏈接時全雙工的，所以，每一個方向都必需要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的鏈接，收到一個 FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，可是在這個TCP鏈接上仍然可以發送數據，直到這一方向也發送了FIN。首先進行關閉的 一方將執行主動關閉，而另外一方則執行被動關閉，上圖描述的便是如此。
   （1）第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。
    （2）第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
   （3）第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。
    （4）第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。
    上面是一方主動關閉，另外一方被動關閉的狀況，實際中還會出現同時發起主動關閉的狀況，具體流程以下圖：

  
  圖4 同時揮手
    流程和狀態在上圖中已經很明瞭了，在此再也不贅述，能夠參考前面的四次揮手解析步驟。
  
  4、附註
    關於三次握手與四次揮手一般都會有典型的面試題，在此提出供有需求的XDJM們參考：
    （1）三次握手是什麼或者流程？四次握手呢？答案前面分析就是。
    （2）爲何創建鏈接是三次握手，而關閉鏈接倒是四次揮手呢？
    這是由於服務端在LISTEN狀態下，收到創建鏈接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。而關閉鏈接時，當收到對方的FIN 報文時，僅僅表示對方再也不發送數據了可是還能接收數據，己方也未必所有數據都發送給對方了，因此己方能夠當即close，也能夠發送一些數據給對方後，再 發送FIN報文給對方來表示贊成如今關閉鏈接，所以，己方ACK和FIN通常都會分開發送。

上面這都是書上的死話看的人真噁心。。。

來通俗點的

在TCP/IP協議中，TCP協議提供可靠的鏈接服務，採用三次握手創建一個鏈接。 
第一次握手：創建鏈接時，客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認； 
第 二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進 入SYN_RECV狀態； 第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入 ESTABLISHED狀態，完成三次握手。 完成三次握手，客戶端與服務器開始傳送數據.

四次分手：

 

（1）客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送（報文段4）。

（2）服務器B收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1（報文段5）。和SYN同樣，一個FIN將佔用一個序號。

（3）服務器B關閉與客戶端A的鏈接，發送一個FIN給客戶端A（報文段6）。

（4）客戶端A發回ACK報文確認，並將確認序號設置爲收到序號加1（報文段7）。

我的的簡單理解

3次握手：1.客戶端發個請求「我要和你鏈接」到服務端

2.服務端發個「確認容許你鏈接+我要和你鏈接」到客戶端

3.客戶端蛋疼的再發個「我收到了你的容許了」到服務端

ok創建鏈接

四次撒手

1：客戶端說：我要關了，給服務器，而後本身在那等消息。client-close-wait

2.服務器聽到了，而後說，「我知道了」給客戶端，也在等--server-close-wait

3.服務器關了鏈接，發個，我關了，給客戶端，等客戶端「說我知道了」 --server-close-wait-ack

4.客戶端發個我知道了，以後本身就關了

後期學習過程會遇到不少深刻的問題，好比咱們發現本機有不少Time wait狀態，那個就是四次分手最後一步的狀態，在這個狀態下的端口是不可新建鏈接的

咱們須要明白爲何須要timewait這個狀態：

緣由以下：

1.可靠實現TCP全雙工鏈接終止，這個狀態下才會發送咱們的確認關閉信息，要不server端還會繼續發送Fin

2.TCP分節可能會由於路由器異常而後「迷途：， 這個時候有可能tcp發送端確認超時而重發分節，可是迷途的分節在修復後也會發送到最終目的地，此時前一個tcp鏈接完成後，他已經正確完成了，而迷途的纔到達，他會繼續新建一個ip端口相同的tcp鏈接把迷途的分節傳過去。。這是然並卵。。。 因此爲了不這種狀況timewait組織在短期內再次新建鏈接。

就這樣了我是這樣理解的，其實很簡單的東西就被專業術語複雜化了，若是少了那麼多晦澀難懂的專業術語我相信人類至少進步500年 。--by   迫不得已  固然官方術語有他的好處須要檢查調整的時候那些seq ack是很重要的因此仍是要多看看。

TCP滑動窗口機制

(2013-10-23 12:01:36)

轉載▼

標籤： tcp 三次握手 滑動窗口

分類：TCP/IP.OS

咱們能夠大概看一下上圖的模型：

1. 首先是AB之間三次握手創建TCP鏈接。在報文的交互過程當中，A將本身的緩衝區大小（窗口大小）3發送給B，B同理，這樣雙方就知道了對端的窗口大小。

2. A開始發送數據，A連續發送3個單位的數據，由於他知道B的緩衝區大小。在這一波數據發送完後，A就不能再發了，需等待B的確認。

3. A發送過來的數據逐漸將緩衝區填滿。

4. 這時候緩衝區中的一個報文被進程讀取，緩衝區有了一個空位，因而B向A發送一個ACK，這個報文中指示窗口大小爲1。
   A收到B發過來的ACK消息，而且知道B將窗口大小調整爲1，所以他只發送了一個單位的數據而且等待B的下一個確認報文。

5. 如此反覆。