計算機網絡 運輸層(一)UDP和TCP

計算機網絡(十二)

學習計算機網絡過程中的心得體會以及知識點的整理,方便我自己查找,也希望可以和大家一起交流。

—— 運輸層 ——

1 運輸層協議概述

1.1 進程之間的通信

  • 從通信和信息處理的角度看,運輸層向它上面的應用層提供通信服務,它屬於面向通信部分的最高層,同時也是用戶功能中的最低層。
  • 當網絡的邊緣部分中的兩個主機使用網絡的核心部分的功能進行端到端的通信時,只有位於網絡邊緣部分的主機的協議棧纔有運輸層,而網絡核心部分中的路由器在轉發分組時都只用到下三層的功能。
    運輸層
    作用:
  • “邏輯通信”的意思是“好像是這樣通信,但事實上並非真的這樣通信”。
  • 從IP層來說,通信的兩端是兩臺主機。但“兩臺主機之間的通信”這種說法還不夠清楚。
  • 嚴格地講,兩臺主機進行通信就是兩臺主機中的應用進程互相通信。
  • 從運輸層的角度看,通信的真正端點並不是主機而是主機中的進程。 也就是說,端到端的通信是應用進程之間的通信。
  • 在一臺主機中經常有多個應用進程同時分別和另一臺主機中的多個應用進程通信。
  • 這表明運輸層有一個很重要的功能——複用 (multiplexing)和分用 (demultiplexing)
  • 根據應用程序的不同需求,運輸層需要有兩種不同的運輸協議,即面向連接的 TCP 和無連接的 UDP

網絡層和運輸層有明顯的區別
運輸層
運輸層

  • 運輸層向高層用戶屏蔽了下面網絡核心的細節(如網絡拓撲、所採用的路由選擇協議等),它使應用進程看見的就是好像在兩個運輸層實體之間有一條端到端的邏輯通信信道。
    運輸層

  • 但這條邏輯通信信道對上層的表現卻因運輸層使用的不同協議而有很大的差別。

  • 當運輸層採用面向連接的 TCP 協議時,儘管下面的網絡是不可靠的(只提供盡最大努力服務),但這種邏輯通信信道就相當於一條全雙工的可靠信道

  • 當運輸層採用無連接的 UDP 協議時,這種邏輯通信信道是一條不可靠信道

運輸層

1.2 運輸層的兩個主要協議

TCP/IP 的運輸層有兩個主要協議:

  • (1) 用戶數據報協議 UDP (User Datagram Protocol)
  • (2) 傳輸控制協議 TCP (Transmission Control Protocol)

運輸層

  • 兩個對等運輸實體在通信時傳送的數據單位叫作運輸協議數據單元 TPDU (Transport Protocol Data Unit)

  • TCP 傳送的數據單位協議是 TCP 報文段(segment)

  • UDP 傳送的數據單位協議是 UDP 報文或用戶數據報

  • UDP:一種無連接協議

    • 提供無連接服務。
    • 在傳送數據之前不需要先建立連接。
    • 傳送的數據單位協議是 UDP 報文或用戶數據報
    • 對方的運輸層在收到 UDP 報文後,不需要給出任何確認。
    • 雖然 UDP 不提供可靠交付,但在某些情況下 UDP 是一種最有效的工作方式。
  • TCP:一種面向連接的協議

    • 提供面向連接的服務。
    • 傳送的數據單位協議是 TCP 報文段 (segment)
    • TCP 不提供廣播或多播服務
    • 由於 TCP 要提供可靠的、面向連接的運輸服務,因此不可避免地增加了許多的開銷。這不僅使協議數據單元的首部增大很多,還要佔用許多的處理機資源。
  • 運輸層的 UDP 用戶數據報與網際層的IP數據報有很大區別。

    • IP 數據報要經過互連網中許多路由器的存儲轉發。
    • UDP 用戶數據報是在運輸層的端到端抽象的邏輯信道中傳送的。
  • TCP 報文段是在運輸層抽象的端到端邏輯信道中傳送,這種信道是可靠的全雙工信道。但這樣的信道卻不知道究竟經過了哪些路由器,而這些路由器也根本不知道上面的運輸層是否建立了 TCP 連接。

1.3 運輸層的端口

  • 運行在計算機中的進程是用進程標識符來標誌的。
  • 但運行在應用層的各種應用進程卻不應當讓計算機操作系統指派它的進程標識符。這是因爲在互聯網上使用的計算機的操作系統種類很多,而不同的操作系統又使用不同格式的進程標識符。
  • 爲了使運行不同操作系統的計算機的應用進程能夠互相通信,就必須用統一的方法對 TCP/IP 體系的應用進程進行標誌。

需要解決的問題:

  • 由於進程的創建和撤銷都是動態的,發送方几乎無法識別其他機器上的進程。
  • 有時我們會改換接收報文的進程,但並不需要通知所有發送方。
  • 我們往往需要利用目的主機提供的功能來識別終點,而不需要知道實現這個功能的進程。

端口號 (protocol port number)

  • 解決這個問題的方法就是在運輸層使用協議端口號 (protocol port number),或通常簡稱爲端口 (port)
  • 雖然通信的終點是應用進程,但我們可以把端口想象是通信的終點,因爲我們只要把要傳送的報文交到目的主機的某一個合適的目的端口,剩下的工作(即最後交付目的進程)就由 TCP 來完成。
1.3.1 軟件端口與硬件端口
  • 兩個不同的概念。
  • 在協議棧層間的抽象的協議端口是軟件端口。
  • 路由器或交換機上的端口是硬件端口。
  • 硬件端口是不同硬件設備進行交互的接口,而軟件端口是應用層的各種協議進程與運輸實體進行層間交互的一種地址。
1.3.2 TCP/IP 運輸層端口
  • 端口用一個 16 位端口號進行標誌。
  • 端口號只具有本地意義,即端口號只是爲了標誌本計算機應用層中的各進程。
  • 在互聯網中,不同計算機的相同端口號是沒有聯繫的。
1.3.3 兩大類端口

(1) 服務器端使用的端口號

  • 熟知端口,數值一般爲 0~1023。
  • 登記端口號,數值爲 1024~49151,爲沒有熟知端口號的應用程序使用的。使用這個範圍的端口號必須在 IANA 登記,以防止重複。
    (2) 客戶端使用的端口號
  • 又稱爲短暫端口號,數值爲 49152~65535,留給客戶進程選擇暫時使用。
  • 當服務器進程收到客戶進程的報文時,就知道了客戶進程所使用的動態端口號。通信結束後,這個端口號可供其他客戶進程以後使用。
1.3.4 常用的熟知端口

運輸層

2 用戶數據報協議 UDP

2.1 UDP 概述

  • UDP 只在 IP 的數據報服務之上增加了很少一點的功能:
    • 複用和分用的功能
    • 差錯檢測的功能
  • 雖然 UDP 用戶數據報只能提供不可靠的交付,但 UDP 在某些方面有其特殊的優點。
2.1.1 UDP 的主要特點
  • (1) UDP 是無連接的,發送數據之前不需要建立連接,,因此減少了開銷和發送數據之前的時延。
  • (2) UDP 使用盡最大努力交付,即不保證可靠交付,因此主機不需要維持複雜的連接狀態表。
  • (3) UDP 是面向報文的。UDP 對應用層交下來的報文,既不合並,也不拆分,而是保留這些報文的邊界。UDP 一次交付一個完整的報文。
  • (4) UDP 沒有擁塞控制,因此網絡出現的擁塞不會使源主機的發送速率降低。這對某些實時應用是很重要的。很適合多媒體通信的要求。
  • (5) UDP 支持一對一、一對多、多對一和多對多的交互通信
  • (6) UDP 的首部開銷小,只有 8 個字節,比 TCP 的 20 個字節的首部要短。
2.1.2 面向報文的 UDP
  • 發送方 UDP 對應用程序交下來的報文,在添加首部後就向下交付 IP 層。UDP 對應用層交下來的報文,既不合並,也不拆分,而是保留這些報文的邊界。
  • 應用層交給 UDP 多長的報文,UDP 就照樣發送,即一次發送一個報文。
  • 接收方 UDP 對 IP 層交上來的 UDP 用戶數據報,在去除首部後就原封不動地交付上層的應用進程,一次交付一個完整的報文。
  • 應用程序必須選擇合適大小的報文。
    • 若報文太長,UDP 把它交給 IP 層後,IP 層在傳送時可能要進行分片,這會降低 IP 層的效率。
    • 若報文太短,UDP 把它交給 IP 層後,會使 IP 數據報的首部的相對長度太大,這也降低了 IP 層的效率。
      運輸層

2.2 UDP 的首部格式

運輸層

2.2.1 UDP 基於端口的分用

運輸層
運輸層
運輸層

2.2.2 計算 UDP 檢驗和的例子

運輸層

3 傳輸控制協議 TCP 概述

3.1 TCP 最主要的特點

  • TCP 是面向連接的運輸層協議。
  • 每一條 TCP 連接只能有兩個端點 (endpoint),每一條 TCP 連接只能是點對點的(一對一)。
  • TCP 提供可靠交付的服務。
  • TCP 提供全雙工通信
  • 面向字節流
    • TCP 中的“流”(stream)指的是流入或流出進程的字節序列。
    • “面向字節流”的含義是:雖然應用程序和 TCP 的交互是一次一個數據塊,但 TCP 把應用程序交下來的數據看成僅僅是一連串無結構的字節流。
3.1.1 TCP 面向流的概念
  • TCP 不保證接收方應用程序所收到的數據塊和發送方應用程序所發出的數據塊具有對應大小的關係。
    - 但接收方應用程序收到的字節流必須和發送方應用程序發出的字節流完全一樣
    運輸層
    運輸層

注 意

  • TCP 連接是一條虛連接而不是一條真正的物理連接。
  • TCP 對應用進程一次把多長的報文發送到TCP 的緩存中是不關心的。
  • TCP 根據對方給出的窗口值當前網絡擁塞的程度來決定一個報文段應包含多少個字節(UDP 發送的報文長度是應用進程給出的)。
  • TCP 可把太長的數據塊劃分短一些再傳送。
  • TCP 也可等待積累有足夠多的字節後再構成報文段發送出去。

3.2 TCP 的連接

  • TCP 把連接作爲最基本的抽象
  • 每一條 TCP 連接有兩個端點。
  • TCP 連接的端點不是主機,不是主機的IP 地址,不是應用進程,也不是運輸層的協議端口。TCP 連接的端點叫做套接字 (socket) 或插口。
  • 端口號拼接到 (contatenated with) IP 地址即構成了套接字。
    運輸層
3.2.1 TCP 連接,IP 地址,套接字
  • TCP 連接就是由協議軟件所提供的一種抽象。
  • TCP 連接的端點是個很抽象的套接字,即(IP 地址:端口號)。
  • 同一個 IP 地址可以有多個不同的 TCP 連接。
  • 同一個端口號也可以出現在多個不同的 TCP 連接中。
3.2.2 Socket 有多種不同的意思
  • 應用編程接口 API 稱爲 socket API, 簡稱爲 socket。
  • socket API 中使用的一個函數名也叫作 socket。
  • 調用 socket 函數的端點稱爲 socket。
  • 調用 socket 函數時其返回值稱爲 socket 描述符,可簡稱爲 socket。
  • 在操作系統內核中連網協議的 Berkeley 實現,稱爲 socket 實現。

4 可靠傳輸的工作原理

  • 理想的傳輸條件有以下兩個特點:
    • (1) 傳輸信道不產生差錯。
    • (2) 不管發送方以多快的速度發送數據,接收方總是來得及處理收到的數據。
  • 在這樣的理想傳輸條件下,不需要採取任何措施就能夠實現可靠傳輸。
  • 然而實際的網絡都不具備以上兩個理想條件。必須使用一些可靠傳輸協議,在不可靠的傳輸信道實現可靠傳輸。

4.1 停止等待協議

  • “停止等待”就是每發送完一個分組就停止發送,等待對方的確認。在收到確認後再發送下一個分組。
  • 全雙工通信的雙方既是發送方也是接收方。
  • 爲了討論問題的方便,我們僅考慮 A 發送數據而 B 接收數據併發送確認。因此 A 叫做發送方,而 B 叫做接收方
4.1.1 無差錯情況

運輸層

4.1.2 出現差錯
  • 在接收方 B 會出現兩種情況:
    • B 接收 M1 時檢測出了差錯,就丟棄 M1,其他什麼也不做(不通知 A 收到有差錯的分組)。
    • M1 在傳輸過程中丟失了,這時 B 當然什麼都不知道,也什麼都不做。
  • 在這兩種情況下,B 都不會發送任何信息。
  • 如何保證 B 正確收到了 M1 呢?
  • 解決方法:超時重傳
    • A 爲每一個已發送的分組都設置了一個超時計時器。
    • A 只要在超時計時器到期之前收到了相應的確認,就撤銷該超時計時器,繼續發送下一個分組 M2 。
      運輸層
4.1.3 確認丟失
  • 若 B 所發送的對 M1 的確認丟失了,那麼 A 在設定的超時重傳時間內不能收到確認,但 A 並無法知道:是自己發送的分組出錯、丟失了,或者 是 B 發送的確認丟失了。因此 A 在超時計時器到期後就要重傳 M1
  • 假定 B 又收到了重傳的分組 M1。這時 B 應採取兩個行動:
    • 第一,丟棄這個重複的分組 M1,不向上層交付。
    • 第二,向 A 發送確認。不能認爲已經發送過確認就不再發送,因爲 A 之所以重傳 M1 就表示 A 沒有收到對 M1 的確認。
      運輸層
4.1.4 確認遲到
  • 傳輸過程中沒有出現差錯,但 B 對分組 M1 的確認遲到了。
  • A 會收到重複的確認。對重複的確認的處理很簡單:收下後就丟棄。
  • B 仍然會收到重複的 M1,並且同樣要丟棄重複的 M1,並重傳確認分組。
    運輸層
    請注意
  • 在發送完一個分組後,必須暫時保留已發送的分組的副本,以備重發。
  • 分組和確認分組都必須進行編號。
  • 超時計時器的重傳時間應當比數據在分組傳輸的平均往返時間更長一些。
4.1.5 自動重傳請求 ARQ
  • 通常 A 最終總是可以收到對所有發出的分組的確認。如果 A 不斷重傳分組但總是收不到確認,就說明通信線路太差,不能進行通信。
  • 使用上述的確認和重傳機制,我們就可以在不可靠的傳輸網絡上實現可靠的通信。
  • 像上述的這種可靠傳輸協議常稱爲自動重傳請求 ARQ (Automatic Repeat reQuest)。意思是重傳的請求是自動進行的,接收方不需要請求發送方重傳某個出錯的分組。
4.1.6 信道利用率

運輸層

  • 可以看出,當往返時間 RTT 遠大於分組發送時間 TD 時,信道的利用率就會非常低。
  • 若出現重傳,則對傳送有用的數據信息來說,信道的利用率就還要降低。
4.1.7 流水線傳輸
  • 爲了提高傳輸效率,發送方可以不使用低效率的停止等待協議,而是採用流水線傳輸
  • 流水線傳輸就是發送方可連續發送多個分組,不必每發完一個分組就停頓下來等待對方的確認。這樣可使信道上一直有數據不間斷地傳送。
  • 由於信道上一直有數據不間斷地傳送,這種傳輸方式可獲得很高的信道利用率。
    運輸層

4.2 連續 ARQ 協議

  • 滑動窗口協議比較複雜,是 TCP 協議的精髓所在。
  • 發送方維持的發送窗口,它的意義是:位於發送窗口內的分組都可連續發送出去,而不需要等待對方的確認。這樣,信道利用率就提高了。
  • 連續 ARQ 協議規定,發送方每收到一個確認,就把發送窗口向前滑動一個分組的位置

運輸層

  • 接收方一般採用累積確認的方式。即不必對收到的分組逐個發送確認,而是對按序到達的最後一個分組發送確認,這樣就表示:到這個分組爲止的所有分組都已正確收到了。
    • 優點:容易實現,即使確認丟失也不必重傳。
    • 缺點:不能向發送方反映出接收方已經正確收到的所有分組的信息。
4.2.1 Go-back-N(回退 N)
  • 如果發送方發送了前 5 個分組,而中間的第 3 個分組丟失了。這時接收方只能對前兩個分組發出確認。發送方無法知道後面三個分組的下落,而只好把後面的三個分組都再重傳一次。
  • 這就叫做 Go-back-N(回退 N)表示需要再退回來重傳已發送過的 N 個分組
  • 可見當通信線路質量不好時,連續 ARQ 協議會帶來負面的影響。
4.2.2 TCP 可靠通信的具體實現.
  • TCP 連接的每一端都必須設有兩個窗口——一個發送窗口和一個接收窗口
  • TCP 的可靠傳輸機制用字節的序號進行控制。TCP 所有的確認都是基於序號而不是基於報文段。
  • TCP 兩端的四個窗口經常處於動態變化之中。
  • TCP連接的往返時間 RTT 也不是固定不變的。需要使用特定的算法估算較爲合理的重傳時間。

後續內容查看《計算機網絡 運輸層(二)》

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