【Study】 TCP/IP協議 -- 計算機網絡之傳輸層篇（03）

1.傳輸層

傳輸層概述：

傳輸層是管理端到端的通訊鏈接。

 

 

傳輸層之間的通訊實際上是進程與進程之間的通訊，使用端口來標記不一樣的網絡進程。

 

 

2.傳輸層協議

傳輸層主要有兩種協議：TCP和UDP協議。

 

 

TCP與UDP涵蓋的重點內容：

 

 

3.UDP協議詳解

UDP（User Datagram Protocol）：用戶數據報協議

UDP對於應用層給到的數據（數據報Datagram）不合並、不拆分，數據長度是多長就接收處理多長的數據——至關於對數據報不作任何地處理。

UDP在IP數據報中的位置以下：

 

 

UDP協議的特色：

①UDP是無鏈接的協議；

②UDP在進行通信的時候並不須要提早地創建鏈接；

③UDP不能保證可靠的交付數據（想發就發，沒法保證數據在網絡中是否丟失）；

④UDP是面向報文傳輸的（不作任何處理）；

⑤UDP沒有擁塞控制——不會感知網絡是否擁塞，都會盡可能把數據交付出去；

⑥UDP的首部開銷很小——首部相對於TCP來講

4.TCP協議詳解

TCP（Transmission Control Protocol：傳輸控制協議），TCP協議是計算機網絡中很是複雜的一個協議。

TCP在IP數據報中的位置以下：

 

 

TCP協議的特色：

①TCP是面向鏈接的協議；

②TCP的一個鏈接有兩端（點對點的通訊）；

③TCP提供可靠的傳輸服務；

④TCP協議提供全雙工的通訊；（打電話時能夠同時在電話裏面對話）；

⑤TCP是面向字節流的協議；（能夠取出數據裏面的某一段來進行傳輸，可對用戶的數據塊進行合併和分拆）

 

 

TCP協議的首部：

 

 

4.1.TCP的標記

 

 

4.2.中止等待協議

①發送的消息在路上丟失了；

②確認的消息在路上丟失了；

③確認的消息好久纔到；

這三種狀況基於TCP/IP可靠傳輸都要進行超時重傳的機制。

 

優缺點：

中止等待協議是最簡單的可靠傳輸協議；

中止等待協議對信道的利用效率不高。

4.3.連續ARQ協議

ARQ(Automatic Repeat reQuest：自動重傳請求)

這個協議能夠大幅度提供對信道的利用率。

 

 

 

 

4.4.TCP協議的可靠傳輸

TCP的可靠傳輸基於連續ARQ協議；

TCP的滑動窗口以字節爲單位

4.5.TCP協議的擁塞控制

 

 

流量控制考慮點對點的通訊量的控制；

擁塞控制考慮整個網絡，是全局性的考慮

過程當中主要運用到的算法：慢啓動算法、擁塞避免算法。

5.TCP鏈接的三次握手

首先咱們來看下TCP中的六種TCP標記：

 

 

重點關注ACK、SYN、FIN三種標記：

 

 

①發送方須要主動地和接收方創建起第一次鏈接，所以發送方會發出第一次報文，這時SYN是爲1的，它表示的是這是一個鏈接請求的報文，而且在這個報文裏面還會同步本身的序列號（假設seq=x），這是三次握手的第一次握手；

 

 

②接收方在接收到這個報文的時候，它也會被動地去打開這個TCP鏈接，同時也會發出一個報文，這個報文是第二次握手，對於第二個報文它有這些關鍵信息，首先是SYN標記，SYN=1表示是鏈接請求的意思，ACK=1表示對序列號的確認，ack=x+1表示指望收到x+1序列號的值，同時這個報文也會攜帶當前本身的序列號seq=y，總的這是第二次握手所攜帶的信息；

 

 

③那麼在發送方接受到接受方發送的消息以後呢，它也會進行一個迴應，這個迴應咱們稱之爲三次握手裏面的第三次握手，這個報文也會有一些關鍵信息，首先他有一個ACK=1表示說這個確認報文是有用的，ack=y+1表示我指望收到你的序號爲y+1的這個數據，而且也會同步本身的一個序列號爲x+1，表示說當前我發送的數據的序列號是x+1，這個就是第三次握手數據報的一些關鍵的內容，經過這三次握手，雙方的TCP鏈接就創建起來了：

 

 

④三次握手時間軸中不一樣的時間點也會有不一樣的狀態：

首先對於在接收方在沒有接受到數據以前，是一直處於監聽的狀態（Listen狀態）；

對於發送方在第一個報文發送以及收到第一個報文的時間之間是屬於同步已發送狀態（SYNC-SENT），即發送方已經把這個SYN發送出去了而且等待對方的SYN信息，這時狀態是屬於這個同步已發送的狀態；

從接收方發出第一個報文到接收到第二個報文呢，是屬於同步已接收的狀態，表示說發送方所發送給個人這個SYN信息我已經收到了；

對於發送方來講，在同步已發送以後就是創建鏈接的狀態了，對於發送方來講只要第二次握手成功以後呢，發送方就創建起這個鏈接了，可是對於接收方來講，只有接收到第三次握手的數據報以後呢纔是創建鏈接的狀態，總的以下圖所示，能夠看出雙方對於創建鏈接的時間是不同的，發送方只要在第二次握手以後就變成創建鏈接的狀態了，可是對於接收方來講只能在第三次握手成功以後呢，它才變成創建鏈接的狀態，只有在雙方都創建起鏈接以後呢，

才能夠進行數據的傳輸。

 

 

5.1.爲何發送方要發出第三個確認報文？

TCP的鏈接須要進行三次握手，兩次握手爲何不行呢？

結論是：

 

對於發送方若是說要創建起這個鏈接的話，首先會發出一個請求報文，也就是第一次握手，假設第一次握手在網絡中傳輸了好久纔到達接收方，由於傳輸了好久，因此發送方好久都沒有接收到確認消息，那麼發送方就認爲這個報文已經超時了，因此發送方會發送第二次一樣的報文，假設第二次很快就到達了對方，接收方在接收到這個請求報文呢，就會進行迴應而且創建起雙方的鏈接，對於第一次請求的鏈接報文就是一個失效的請求報文，由於它的功能已經被第二次請求完成了；

 

 

對於兩次握手就創建起鏈接的話，對於第二次迴應的報文就創建起鏈接了，而對於第一次發送的請求，失效的請求也會創建起這個鏈接，這樣會致使一樣的請求發送了兩次，就會創建兩次TCP鏈接的狀況，這個狀況是錯誤的，兩次握手會引起這個錯誤：

 

 

而三次握手的話，確認會首先到達發送方，發送方會再發送一個報文表示確認第三次握手，而第三次握手才創建起這個鏈接的話，就創建好鏈接了，而比較慢到達接收方的報文，接收方也會回覆一條報文給發送方表示確認，可是發送方已經進行了第三次握手了，所以發送方對於第二次的確認消息呢，它會忽略掉，並不會進行任何操做，後面接收方到達的這個確認發送方就不會進行第三次握手了，這樣就避免了兩次握手會引起的這個錯誤（創建兩次鏈接）

 

 

6.TCP鏈接的四次揮手

TCP鏈接的釋放又叫作TCP鏈接的四次揮手。

在雙方鏈接正常的狀況下，能夠一直進行數據的傳輸的，假設數據傳輸已經完成了，那麼這個發送與接收方就可能進行鏈接的釋放，假設發送方須要主動地進行鏈接的釋放，那麼首先會發送一個特殊的報文，FIN=1表示我須要釋放這個鏈接，這個就稱之爲第一次揮手；發送方在發送了這條報文以後就進入了FIN-WAIT-1(鏈接結束的第一個等待的狀態)

 

 

接收方在接收到這個報文以後呢，就知道對方要結束這個鏈接了，所以它也會發送一條報文進行確認，這裏面確認的是你發送給個人這條報文我已經確認收到了，而且我已經對你的消息進行了一個確認，這個報文就是第二次揮手，這個是由接收方所發送出來的，而發送方在接收到這個報文以後就進入了斷開鏈接的第二個等待狀態，而對於接收方來講，只要第二次報文發出去以後呢，就進入了關閉等待的狀態，（這時接收方還能夠進行數據的發送）

 

 

等到接收方數據發送完成以後，還會發送一條新的報文，攜帶FIN=1的標記，表示說我也能夠進行鏈接的釋放了，而且還會攜帶一個ack，重複對第一個報文進行確認，這個是屬於第三次揮手，

 

 

那麼發送方在接收到第三次報文（三次揮手）以後呢，又會發送一個報文表示鏈接釋放的信號已經收到了，如今咱們能夠一塊兒把這個鏈接釋放掉吧，這個就是第四次揮手報文的意思，對於接收方來講，從第三次報文到第四次報文的狀態時最後確認的狀態，這是爲了確認發送方已經收到了這個鏈接釋放的報文的，這個狀態稱爲是最後確認的狀態(LAST-ACK)，而對於發送方來講會進入一個等待計時器（TIME-WAIT）的狀態，它會等待一段時間，確保這段時間內沒有出現任何問題，而後才進入關閉的狀態，這個就是四次揮手的這個過程；

 

 

 

6.1等待計時器

 

 

等待計時器的功能：

 

 

 

 

7.套接字與套接字編程

對於IP與端口的組合有一個好聽的名字去表明它們，這個就稱爲套接字，也叫做Socket。

 

 

 

 

TCP是由兩端進行鏈接的，經過兩端能夠惟一的肯定一個套接字，經過兩個IP:Port能夠肯定一個TCP的鏈接：

 

 

套接字編程針對於客戶端與服務端：

 

客戶端與服務器端鏈接的過程：

 

 

7.1.Socket編程示例