Tcp三次握手協議

Tcp三次握手協議

A--àB

A發送信息到B

B肯定後，發送給A

這樣A不就能夠肯定這條鏈路是通的了，爲何A要再次發送才能肯定呢?

這是由於弄錯了要肯定的主體，真正要肯定的是B

B在listen端口等待客戶發送連接，B在收到客戶肯定是要發送數據，才真正的創建連接。只有在獲得A確實是要發送連接，B才準備和A創建連接，不然不創建。

第一步

A首先發送sychornize(SYN)想要同步的字節碼給B，說：「我想和你創建連接，不知道可不能夠啊?」，這個字節只包含A將要發送數據的初始序列號。不帶任何數據，只包含了IP頭部，和一個tcp頭部及可能有的tcp選項。(爲何這樣作?)

一、不能肯定你要鏈接的B是否空閒，是否能夠提供服務，若是B(服務器，也能夠是一臺普通的電腦)不存在，或者沒法提供服務，那A就沒必要要再去發送數據。

這樣作的緣由：

1)節省了網絡上帶寬。若是全部的連接都是無論三七二十一的把數據發送到另一臺電腦上，這樣在全部的鏈路上都充斥都大量可能沒有用的數據，

2)在網絡的設計之初，寬帶很小，傳輸的速度也很慢。

第二步

B電腦，若是能夠響應，那麼就發送一個SYN，表示能夠創建鏈接。這個SYN含有服務器同一鏈接中發送的數據的初始化序列號。服務器以單個字節向客戶發送syn和對客戶syn的ACK(表示確認)。

若是B電腦沒法提供服務，於A電腦在等待一段時間後自動放棄該鏈接，或者A能夠持續發送「我要鏈接到B」的請求，直到A確認。

第三步

客戶A要確認B電腦的SYN。發送一個ACK到B。服務器B肯定A要鏈接。服務器B等待同一鏈接上A發送具體的數據。

這裏面重點是B要肯定A，由於B是爲A(C,D,E)提供連接服務的。

這裏面有幾個問題：

• 1. 客戶數據的初始化序列號，是怎麼個生成原則?

• 2. 同理服務器的初始化序列號，生成原則是什麼?

• 3. 服務器對客戶端SYN的ACK是如何生成的?

• 4. 同理客戶端對服務器SYN是如何生成的?

• 5. 客戶端對服務器發送的ACK是若是辨別的?

• 6. 服務器對客戶端發送的ACK是若是辨別的?

解決這些問題首先要明白：

SYN和ACK都是單個字節。

爲何是一個字節，而不是一位比特算了?

由於他要在這8個比特中包含一個IP頭部，TCP頭部及可能有的TCP選項。

一個字節，8位0---255個十進制數，是很硬件，軟件的最小處理單位

硬盤是以最小單位一個字節來讀取數據

Mysql的tinyInt,bit也都是單個字節來存儲的，我想這和硬盤的最小處理單位有關，並且C語言上的基本數據類型，最小的char也是一個字節，java中的char是兩個字節。

SYN和ACK是怎麼個回事?

TCP發送數據是按分節發送的，這個分節應該是字節分段發送的意思，一段是一個分節。

每個分節內的每個字節都對應一個序列號，這個序列號從1開始遞增，到達對端後，從新按序列號進行排序。一個分節最大能夠放1024個字節。

可是打招呼時用到的SYN和ACK只用到了一個字節的序列號空間(1-256)，這也就意味着他們的內容數據大小在1-256個字節。而這256個字節只含有一個IP頭部，一個TCP頭部，和可能的TCP選項。

問題一：IP頭部包含什麼?

問題二：TCP頭部和TCP選項是什麼關係?

一個分節最大能夠放1024個字節。這一個容量並不固定不變的，受TCP選項中的MSS(Maximum segment size)的控制，可能經過TCP_MAXSEG套接字獲取與設置容量。

MSSà用於控制單個分節的容量大小。

TCP選項是對TCP對部的補充，好比說：窗口規模選項，這個功能會隨着高速網絡和衛星鏈路，發生改變，以補充TCP頭部中通知最大窗口大小爲65535.

引出一個問題：窗口規模選項中的窗口是什麼，和一個分節傳輸的大小有何關聯?

窗口規模的目的是：提供流量控制

機制是：該窗口在任意時刻都指出接收緩衝區中的可用空間。

應用程序從緩衝區讀取數據則窗口變大，緩衝區寫入數據則窗口變小。滿了，則等待進程讀取了數據以後，再接收數據。

進程從硬盤讀取數據會有一個層次的緩衝機制，網絡鏈接原來是有緩衝，說就說明，緩衝對於計算機應用程序是一個很好的機制。能夠解決性能的問題。

全雙工的意思就能夠接收數據的同時發送數據(full-duplex)

TCP重要的五點內容：

1.  面向鏈接

2. 提供可靠性

3.  每一個字節數據關聯一個序列號，以便排序

4.  提供流量控制

5.  鏈接是全雙工

轉載於究問社區 ：http://www.ijiuwen.com/blog/937871407235072