TCP創建斷開鏈接過程

TCP/IP創建與斷開鏈接詳細過程

TCP協議鏈接創建時3次握手的過程。

簡述TCP協議鏈接創建時3次握手的過程。

根據TCP頭部，說明下列3個包在鏈接創建過程當中的次序.

002000 50 83 aa
46 49 3e dd 33 96 37 a3 a0 12...P..FI>.3.7...

003016 a0 c4 c0 00 00 02 04 05 b4
04 02 08 0a d7 9b................

004062 b7 00 56 4a 2a 01 03 03
02b..VJ*....（1）

002083 aa 00 50
33 96 37 a2 00 00 00 00 a0 02.....P3.7.......

003016 d0 84 1d 00 00 02 04 05 b4
04 02 08 0a 00 56...............V

00404a 2a 00 00 00 00 01 03 03
00J*........（2）

002083 aa 00 50
33 96 37 a3 46 49 3e de 80 10.....P3.7.FI>...

003016 d0 f3 4b 00 00 01 01 08 0a
00 56 4a 36 d7 9b...K.......VJ6..

004062
b7b.
（3）

解：

在TCP/IP協議中，TCP協議提供可靠的鏈接服務，採用三次握手創建一個鏈接。

1）是第二次握手，flags位上爲12，二進制是0001 0010，即表示有syn和ack.

2）是第一次握手，flags位上爲02，二進制是0000 0010，即表示有syn沒有ack。

3）是第三次握手，flags位上爲10，二進制是0001 0000，即表示有ack沒有syn。

該鏈接訪問的是80端口，是爲HTTP（HyperText Transport Protocol，超文本傳輸協議）開放的，

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

tcp-斷開鏈接:

 

主要部分，四次握手： 斷開鏈接其實從個人角度看不區分客戶端和服務器端，任何一方均可以調用close(or closesocket)之類 的函數開始主動終止一個鏈接。這裏先暫時說正常狀況。當調用close函數斷開一個鏈接時，主動斷開的 一方發送FIN(finish報文給對方。有了以前的經驗，我想你應該明白我說的FIN報文時什麼東西。也就是 一個設置了FIN標誌位的報文段。FIN報文也可能附加用戶數據，若是這一方還有數據要發送時，將數據附 加到這個FIN報文時徹底正常的。以後你會看到，這種附加報文還會有不少，例如ACK報文。咱們所要把握 的原則是，TCP確定會力所能及地達到最大效率，因此你可以想到的優化方法，我想TCP都會想到。 當被動關閉的一方收到FIN報文時，它會發送ACK確認報文(對於ACK這個東西你應該很熟悉了)。這裏有個 東西要注意，由於TCP是雙工的，也就是說，你能夠想象一對TCP鏈接上有兩條數據通路。當發送FIN報文 時，意思是說，發送FIN的一端就不能發送數據，也就是關閉了其中一條數據通路。被動關閉的一端發送 了ACK後，應用層一般就會檢測到這個鏈接即將斷開，而後被動斷開的應用層調用close關閉鏈接。 我能夠告訴你，一旦當你調用close(or closesocket)，這一端就會發送FIN報文。也就是說，如今被動 關閉的一端也發送FIN給主動關閉端。有時候，被動關閉端會將ACK和FIN兩個報文合在一塊兒發送。主動 關閉端收到FIN後也發送ACK，而後整個鏈接關閉(事實上還沒徹底關閉，只是關閉須要交換的報文發送 完畢)，四次握手完成。如你所見，由於被動關閉端可能會將ACK和FIN合到一塊兒發送，因此這也算不上 嚴格的四次握手---四個報文段。 在前面的文章中，我一直沒提TCP的狀態轉換。在這裏我仍是在猶豫是否是該將那張四處通用的圖拿出來， 不過，這裏我只給出斷開鏈接時的狀態轉換圖，摘自<The TCP/IP Guide>： 給出一個正常關閉時的windump信息： 14:00:38.819856 IP cd-zhangmin.1748 > 220.181.37.55.80: F 1:1(0) ack 1 win 65535 14:00:38.863989 IP 220.181.37.55.80 > cd-zhangmin.1748: F 1:1(0) ack 2 win 2920 14:00:38.864412 IP cd-zhangmin.1748 > 220.181.37.55.80: . ack 2 win 65535 補充細節： 關於以上的四次握手，我補充下細節： 1. 默認狀況下(不改變socket選項)，當你調用close( or closesocket，如下說close再也不重複)時，若是 發送緩衝中還有數據，TCP會繼續把數據發送完。 2. 發送了FIN只是表示這端不能繼續發送數據(應用層不能再調用send發送)，可是還能夠接收數據。 3. 應用層如何知道對端關閉？一般，在最簡單的阻塞模型中，當你調用recv時，若是返回0，則表示對端 關閉。在這個時候一般的作法就是也調用close，那麼TCP層就發送FIN，繼續完成四次握手。若是你不調用 close，那麼對端就會處於FIN_WAIT_2狀態，而本端則會處於CLOSE_WAIT狀態。這個能夠寫代碼試試。 4. 在不少時候，TCP鏈接的斷開都會由TCP層自動進行，例如你CTRL+C終止你的程序，TCP鏈接依然會正常關 閉，你能夠寫代碼試試。 特別的TIME_WAIT狀態： 從以上TCP鏈接關閉的狀態轉換圖能夠看出，主動關閉的一方在發送完對對方FIN報文的確認(ACK)報文後， 會進入TIME_WAIT狀態。TIME_WAIT狀態也稱爲2MSL狀態。 什麼是2MSL？MSL即Maximum Segment Lifetime，也就是報文最大生存時間，引用<TCP/IP詳解>中的話：「 它(MSL)是任何報文段被丟棄前在網絡內的最長時間。」那麼，2MSL也就是這個時間的2倍。其實我以爲沒 必要把這個MSL<span STYLE="FonT-siZe: 10pt; CoLor: black; FonT-FAMiLY: 宋體; mso-bidi-font-family: Arial; mso-font-kerning: 0pt; mso-asc