【測開基礎之計算機網絡】五: 傳輸層

1、傳輸層

1.1 傳輸層的作用

在這裏插入圖片描述

1.2 傳輸層協議應用場景

  • TCP/IP 的運輸層有兩個不同的協議:
    (1) 用戶數據報協議 UDP (User Datagram Protocol)
    (2) 傳輸控制協議 TCP (Transmission Control Protocol)

  • 兩個對等運輸實體在通信時傳送的數據單位叫作運輸協議數據單元 TPDU (Transport Protocol Data Unit)。
    TCP 傳送的數據單位協議是 TCP 報文段(segment)
    UDP 傳送的數據單位協議是 UDP 報文或用戶數據報

  • TCP
    分段、編號、流量控制、建立會話

    • 比如看電影,一臺服務器同時提供多人觀看電影,要建立連接,保證電影資源傳輸完成的情況下還要知道每個用戶看的是哪部電影
    • 服務端向客戶端發送數據,當客戶端處理不過來的時候,可以通知服務端,進行流量限制
  • UDP
    一個數據報就能完成數據通信,不建立會話、多廣播

    • 好比聊QQ,消息發送出去就可以,也不知道用戶下次什麼時候會再發消息,所以不會建立會話;如果發送失敗了就嘗試幾次,再失敗就直接告訴用戶發送失敗
    • 瀏覽器訪問網站的時候,我們輸入網址,然後通過域名解析獲取網站地址,我們只把網站域名送出去,等服務器給我們返回網站的地址即可,拿到地址後再去訪問網站就可以了,中間並不建立會話,一個包就可以搞定

1.3 傳輸層和應用層的關係

  • HTTP = TCP + 80端口
  • HTTPS = TCP + 443端口
  • FTP = TCP + 21端口
  • SMTP = TCP + 25端口
  • POP3 = TCP + 110端口
  • RDP = TCP + 3389端口
  • 共享文件夾 = TCP + 445端口
  • SQL(微軟的SqlServer) = TCP + 1433端口
  • DNS = UDP + 53端口 or TCP + 53端口(較少)

1.4 應用層協議和服務之間的關係

服務運行後在TCP或UDP的某個端口偵聽客戶端請求

1.5 UDP簡析

  • UDP是面向報文的
    在這裏插入圖片描述
    在這裏插入圖片描述
  • UDP基於端口的分用
    在這裏插入圖片描述

1.6 TCP詳解

1.6.1 TCP概述

  • TCP面向連接的運輸層協議。
  • 每一條 TCP 連接只能有兩個端點(endpoint),每一條 TCP 連接只能是點對點的(一對一)。
  • TCP 提供可靠交付的服務。
  • TCP 提供全雙工通信。
  • 面向字節流
    TCP面向字節流圖解:
    在這裏插入圖片描述

1.6.2 TCP的連接

  • TCP 把連接作爲最基本的抽象。
  • 每一條 TCP 連接有兩個端點。
  • TCP 連接的端點不是主機,不是主機的IP 地址,不是應用進程,也不是運輸層的協議端口。TCP 連接的端點叫做套接字(socket)或插口。
  • 端口號拼接到(contatenated with) IP 地址即構成了套接字
    在這裏插入圖片描述

1.6.3 可靠傳輸原理

網絡層只負責把數據包從一個網段轉到另一個網段,傳輸中若丟了,網絡層是不管的。可靠傳輸則是又傳輸層來實現的

  • 停止等待協議
    在這裏插入圖片描述
  • 確認丟失和確認遲到
    在這裏插入圖片描述
  • 可靠通信的實現
    • 使用上述的確認和重傳機制,我們就可以在不可靠的傳輸網絡上實現可靠的通信
    • 這種可靠傳輸協議常稱爲自動重傳請求ARQ (Automatic Repeat reQuest)。
    • ARQ 表明重傳的請求是自動進行的。接收方不需要請求發送方重傳某個出錯的分組 。
  • 信道利用率
    停止等待協議的優點是簡單,但缺點是信道利用率太低。
    在這裏插入圖片描述
    信道利用率計算公式如下
    在這裏插入圖片描述
    RTT和TA是固定的,因此若想要提高信道利用率,就可以增加TD來實現,也就是增加發包,稱之爲流水線傳輸
  • 發送方可連續發送多個分組,不必每發完一個分組就停頓下來等待對方的確認。
  • 由於信道上一直有數據不間斷地傳送,這種傳輸方式可獲得很高的信道利用率。
    在這裏插入圖片描述

1.6.4 連續 ARQ 協議

上面說到了連續發送來增加信道利用率,那麼在連續發送的過程中如何保證傳輸的可靠性呢,這個時候就需要滑動窗口的技術
在這裏插入圖片描述
雖然使用了滑動窗口可以連續發送,但是每個數據包都需要ack,這樣效率還是會受影響,因此可以使用累積確認

  • 接收方一般採用累積確認的方式。即不必對收到的分組逐個發送確認,而是對按序到達的最後一個分組發送確認,這樣就表示:到這個分組爲止的所有分組都已正確收到了。
  • 累積確認有的優點是:容易實現,即使確認丟失也不必重傳。缺點是:不能向發送方反映出接收方已經正確收到的所有分組的信息。

1.6.5 TCP報文段的首部格式

在這裏插入圖片描述

  • 源端口目的端口字段——各佔 2 字節。端口是運輸層與應用層的服務接口。運輸層的複用和分用功能都要通過端口才能實現。
  • 序號字段——佔 4 字節。TCP 連接中傳送的數據流中的每一個字節都編上一個序號。序號字段的值則指的是本報文段所發送的數據的第一個字節的序號。
  • 確認號字段——佔 4 字節,是期望收到對方的下一個報文段的數據的第一個字節的序號。
  • 數據偏移(即首部長度)——佔 4 位,它指出 TCP 報文段數據起始處距離 TCP 報文段的起始處有多遠。“數據偏移”的單位是 32 位字(以 4 字節爲計算單位)。
  • 保留字段——佔 6 位,保留爲今後使用,但目前應置爲 0。
  • 緊急 URG —— 當 URG = 1 時,表明緊急指針字段有效。它告訴系統此報文段中有緊急數據,應儘快傳送(相當於高優先級的數據)。
  • 確認 ACK —— 只有當 ACK = 1 時確認號字段纔有效。當 ACK = 0 時,確認號無效。
  • 同步 SYN —— 同步 SYN = 1 表示這是一個連接請求或連接接受報文。
  • 終止 FIN (FINis) —— 用來釋放一個連接。FIN  1 表明此報文段的發送端的數據已發送完畢,並要求釋放運輸連接
  • 窗口字段 —— 佔 2 字節,用來讓對方設置發送窗口的依據,單位爲字節
  • 檢驗和 —— 佔 2 字節。檢驗和字段檢驗的範圍包括首部和數據這兩部分。在計算檢驗和時,要在 TCP 報文段的前面加上 12 字節的僞首部。
  • 緊急指針字段 —— 佔 16 位,指出在本報文段中緊急數據共有多少個字節(緊急數據放在本報文段數據的最前面)。
  • 選項字段 —— 長度可變。TCP 最初只規定了一種選項,即最大報文段長度 MSS。MSS 告訴對方 TCP:“我的緩存所能接收的報文段的數據字段的最大長度是 MSS 個字節。”

    MSS (Maximum Segment Size)是 TCP 報文段中的數據字段的最大長度。數據字段加上 TCP 首部纔等於整個的 TCP 報文段

  • 填充字段 —— 這是爲了使整個首部長度是 4 字節的整數倍。

1.6.6 TCP可靠傳輸實現

1)以字節爲單位的滑動窗口技術

在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述

  • 發送緩存
    在這裏插入圖片描述
  • 接收緩存
    在這裏插入圖片描述

1.6.7 超時重傳

TCP 每發送一個報文段,就對這個報文段設置一次計時器。只要計時器設置的重傳時間到但還沒有收到確認,就要重傳這一報文段。

  • 加權平均往返時間
    在這裏插入圖片描述
    在這裏插入圖片描述
    超時重傳時間應略大於上面得出的加權平均往返時間

1.6.8 TCP流量控制

  • 一般說來,我們總是希望數據傳輸得更快一些。但如果發送方把數據發送得過快,接收方就可能來不及接收,這就會造成數據的丟失。
  • 流量控制(flow control)就是讓發送方的發送速率不要太快,既要讓接收方來得及接收,也不要使網絡發生擁塞。
  • 利用滑動窗口機制可以很方便地在 TCP 連接上實現流量控制。
    在這裏插入圖片描述
    總結起來就是利用滑動窗口,接收端告訴發送端,接收窗口的大小來實現的

1.6.9 TCP擁塞控制

擁塞控制的一般原理

  • 出現資源擁塞的條件:
    對資源需求的綜合 > 可用資源
  • 擁塞控制是一個全局性的過程,涉及到所有主機、所有的路由器,以及與降低網絡傳輸性能有關的所有因素
  • 流量控制往往指在給定的發送端和接收端之間的點對點通信量的控制,它所要做的就是抑制發送端發送數據的速率,以便使接收端來得及接收。

擁塞控制所起的作用

在這裏插入圖片描述

控制擁塞方法-慢開始和擁塞避免

  • 慢開始:
    • 在主機剛剛開始發送報文段時可先設置擁塞窗口 cwnd = 1,即設置爲一個最大報文段 MSS 的數值。
    • 在每收到一個對新的報文段的確認後,將擁塞窗口加 1,即增加一個 MSS 的數值。
    • 用這樣的方法逐步增大發送端的擁塞窗口 cwnd,可以使分組注入到網絡的速率更加合理
      在這裏插入圖片描述
  • 慢開始和擁塞避免算法的實現舉例
    在這裏插入圖片描述
    • 發送端的發送窗口不能超過擁塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我們假定接收端窗口足夠大,因此現在發送窗口的數值等於擁塞窗口的數值。
    • 在執行慢開始算法時,擁塞窗口 cwnd 的初始值爲 1,發送第一個報文段 M0。
    • 發送端每收到一個確認 ,就把 cwnd 加 1。於是發送端可以接着發送 M1 和 M2 兩個報文段
    • 接收端共發回兩個確認。發送端每收到一個對新報文段的確認,就把發送端的 cwnd 加 1。現在 cwnd 從 2 增大到 4,並可接着發送後面的 4 個報文段
    • 發送端每收到一個對新報文段的確認,就把發送端的擁塞窗口加 1,因此擁塞窗口 cwnd 隨着傳輸輪次按指數規律增長。
    • 當擁塞窗口 cwnd 增長到慢開始門限值 ssthresh 時(即當 cwnd = 16 時),就改爲執行擁塞避免算法,擁塞窗口按線性規律增長。
    • 假定擁塞窗口的數值增長到 24 時,網絡出現超時,表明網絡擁塞了。
    • 更新後的 ssthresh 值變爲 12(即發送窗口數值 24 的一半),擁塞窗口再重新設置爲 1,並執行慢開始算法
    • 當 cwnd = 12 時改爲執行擁塞避免算法,擁塞窗口按按線性規律增長,每經過一個往返時延就增加一個 MSS 的大小。

注意:
“擁塞避免”並非指完全能夠避免了擁塞。利用以上的措施要完全避免網絡擁塞還是不可能的。
“擁塞避免”是說在擁塞避免階段把擁塞窗口控制爲按線性規律增長,使網絡比較不容易出現擁塞。

快重傳舉例

在這裏插入圖片描述

  • 快重傳算法首先要求接收方每收到一個失序的報文段後就立即發出重複確認。這樣做可以讓發送方及早知道有報文段沒有到達接收方。
  • 發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段。
  • 不難看出,快重傳並非取消重傳計時器,而是在某些情況下可更早地重傳丟失的報文段。

快恢復舉例

  • 當發送端收到連續三個重複的確認時,就執行“乘法減小”算法,把慢開始門限 ssthresh 減半。但接下去不執行慢開始算法。
  • 由於發送方現在認爲網絡很可能沒有發生擁塞,因此現在不執行慢開始算法,即擁塞窗口 cwnd 現在不設置爲 1,而是設置爲慢開始門限 ssthresh 減半後的數值,然後開始執行擁塞避免算法(“加法增大”),使擁塞窗口緩慢地線性增大。
    在這裏插入圖片描述

發送窗口的上限值

發送窗口的上限值 = Min [rwnd, cwnd]

  • 當 rwnd < cwnd 時,是接收方的接收能力限制發送窗口的最大值。
  • 當 cwnd < rwnd 時,則是網絡的擁塞限制發送窗口的最大值

1.6.10 TCP的傳輸連接管理

  • 傳輸連接有三哥階段,即:
    連接建立數據傳輸連接釋放

  • TCP連接的建立都是採用客戶服務器方式

  • 主動發起連接建立的應用進程叫做客戶(client)

  • 被動等待連接建立的應用進程叫做服務器(server)

TCP建立連接的三次握手

在這裏插入圖片描述
分析:

  • 由上圖可以看到,其實在前兩次的握手過程中,已經可以確認信息,建立連接了,哪怕是需要確認接收窗口rwnd的大小也可以實現,那麼爲何還需要第三次握手呢?

    • 1、現假如沒有第三次握手,客戶端A向服務端B發送了一個請求,而這個請求選擇了一條較遠的路徑傳輸,因此發送的時間較長;
    • 2、這時客戶端A發現一直沒有響應就重新發了一遍連接請求,而這次的路徑較短,請求很快就到達了服務端B;
    • 3、服務端B的確認也很快,直接到達了A,這時就建立了連接,開始進行數據的傳輸;
    • 4、而這時最開始較遠的那條連接請求也到了服務端B;
    • 5、服務器B這時收到了請求後就又會給客戶端發送連接確認,等待數據傳輸;
    • 6、因爲A、B已經建立了連接,所以對於這條信息A就會不理會,而B就會一直等,這樣就消耗了B的資源,若這樣的情況太多就會造成服務器B的“崩潰”
  • 所以,就要進行第三次握手,當B返回確認後,由A再次返回確認,這時建立連接,開始傳輸數據,B不再進行等待;若長時間沒有收到第三次握手,B就釋放此次連接。

TCP的連接釋放

在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
最後需要等2MSL時間(默認爲4分鐘)纔可以釋放,是因爲防止最後A向B的ACK沒有發送成功,這時在這4分鐘內便可以使B重新發送釋放連接請求,A也就可以再次ACK到B進行連接釋放。

2、相關面試題

2.1 UDP相關

  • UDP 和 TCP 的簡單介紹

    • TCP
      分段、編號、流量控制、建立會話,一個面向連接的,面向字節流的傳輸層協議
    • UDP
      UDP 是一個簡單的面向數據報的運輸層協議:進程的每個輸出操作都正好產生一個 UDP 數據報,並組裝成一份待發送的 IP 數據報。
      其餘可詳見上文
  • 爲什麼要加有僞首部?
    目的是讓 UDP 兩次檢查數據是否已經正確到達目的地。
    IP 接受正確的目的地址,傳送到正確的上層程序。 所有僞首部包括:源 IP 地址,目的 IP 地址,0,協議號,UDP 長度。

2.2 TCP相關

  • TCP 通過哪些方式來保證可靠性?
  1. 應用數據被分割成 TCP 認爲最適合發送的數據塊。
  2. 確認機制,發送報文後,等待確認。
  3. 重發機制,沒有收到確認,將重發數據段。
  4. 保持它首部和數據的校驗和。確認數據的準確性。
  5. 排序,丟棄重複的,流量控制
  • TCP 與 UDP 的概念相互的區別及優劣
  1. TCP 面向連接,UDP 面向無鏈接
  2. TCP 面向字節流,UDP面向報文
  3. TCP 提供可靠傳輸服務(數據順序、正確性),UDP 傳輸不可靠
  4. TCP 協議傳輸速度慢,UDP協議傳輸速度快
  5. TCP 協議對系統資源要求多(頭部開銷大),UDP 協議要求少
  • 爲什麼要 3 次握手,4 次揮手
    • 3 次握手:防止已過期的連接請求報文突然又傳送到服務器,因而產生錯誤
    • 4 次揮手:確保數據能夠完成傳輸,但關閉連接時,當收到對方的 FIN 報文通知時,它
      僅僅表示對方沒有數據發送給你了;但未必你所有的數據都全部發送給對方了,所以你可以未必會馬上會關閉 SOCKET,也即你可能還需要發送一些數據給對方之後,再發送 FIN 報文 給對方來表示你同意現在可以關閉連接了,所以它這裏的 ACK 報文和 FIN 報文多數情況下都是分開發送的
  • TCP 的流量控制機制(詳見上文)
    • 慢啓動(慢開始):
    1. 慢開始不是指 cwnd 的增長速度慢(指數增長),而是指 TCP 開始發送設置 cwnd=1。 2. 思路:不要一開始就發送大量的數據,先探測一下網絡的擁塞程度,也就是說由小到大 逐漸增加擁塞窗口的大小。這裏用報文段的個數的擁塞窗口大小舉例說明慢開始算法,實時 擁塞窗口大小是以字節爲單位的。
    2. 爲了防止 cwnd 增長過大引起網絡擁塞,設置一個慢開始門限(ssthresh 狀態變量) 當 cnwd<ssthresh,使用慢開始算法
      當 cnwd=ssthresh,既可使用慢開始算法,也可以使用擁塞避免算法
      當 cnwd>ssthresh,使用擁塞避免算法
    • 擁塞避免:
    1. 擁塞避免並非完全能夠避免擁塞,是說在擁塞避免階段將擁塞窗口控制爲按線性規律增 長,使網絡比較不容易出現擁塞。
    2. 思路:讓擁塞窗口 cwnd 緩慢地增大,即每經過一個往返時間 RTT 就把發送方的擁塞控 制窗口加一。
      無論是在慢開始階段還是在擁塞避免階段,只要發送方判斷網絡出現擁塞(其根據就是沒有 收到確認,雖然沒有收到確認可能是其他原因的分組丟失,但是因爲無法判定,所以都當做 擁塞來處理),就把慢開始門限設置爲出現擁塞時的發送窗口大小的一半。然後把擁塞窗口 設置爲 1,執行慢開始算法。
    • 快速重傳:
    1. 快重傳要求接收方在收到一個失序的報文段後就立即發出重複確認(爲的是使發送方及 早知道有報文段沒有到達對方)而不要等到自己發送數據時捎帶確認。快重傳算法規定,發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段,而不必繼續等待設 置的重傳計時器時間到期。
    2. 由於不需要等待設置的重傳計時器到期,能儘早重傳未被確認的報文段,能提高整個網絡的吞吐量。
    • 快速恢復:
    1. 當發送方連續收到三個重複確認時,就執行“乘法減小”算法,把 ssthresh 門限減半。 但是接下去並不執行慢開始算法。
    2. 考慮到如果網絡出現擁塞的話就不會收到好幾個重複的確認,所以發送方現在認爲網絡 可能沒有出現擁塞。所以此時不執行慢開始算法,而是將 cwnd 設置爲 ssthresh 的大小, 然後執行擁塞避免算法。

3、參考

主體內容參考韓立剛老師主講的《計算機網絡》- 第5版 - 謝希仁

部分內容參考書本《計算機網絡》- 第7版 - 謝希仁

相關面試題由網絡蒐集

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章