計算機網絡:網絡傳輸可靠性技術

一、傳輸層功能

在IP分組網絡中,主機在傳輸數據前無須與目的主機預先建立特定的“通路”,這屬於一種“不可靠的”數據報傳輸機制,它不能保證數據報準確到達,並可能造成數據報的損壞、亂序和丟失。爲了保證數據報傳輸的可靠性,將在網際層的上一層傳輸層引入傳輸控制協議(TCP,Transmission Control Protocol)和用戶數據報協議(UDP,User Datagram Protocol)。

在TCP/IP模型中,傳輸層位於網際層與應用層之間。數據通信應由應用層中的用戶進程發起,並通過網際層設備,如路由器和交換機等,將數據報從發送端主機傳輸到接收端主機。傳輸層協議工作在主機上,負責主機與用戶進程間的數據傳輸。

如圖3-31所示,網際層實現主機到主機之間的通信,傳輸層則進一步實現進程與進程之間的通信。

圖3-31網際層和傳輸層的工作範圍

傳輸層的功能:

在傳輸層嚮應用層提供服務時,屏蔽了網際層及以下層的細節內容,用戶進程只需與傳輸層進行交互,而不必關心數據報所經網絡的拓撲結構和採用的路由拓撲協議等。應用層中進程的QoS完全取決於傳輸層所使用的協議。例如,在採用TCP協議時,儘管網際層提供的服務是不可靠的,但傳輸層仍能嚮應用層提供可靠的數據傳輸服務;在採用UDP協議時,傳輸層只能嚮應用層提供不可靠的數據傳輸服務。

傳輸層還提供了複用和分用功能。

複用功能指傳輸層可以同時傳輸多個進程發送的數據,分用功能指傳輸層能對接收到的數據進行分類,並將數據準確交付給所屬進程。一臺主機上可以存在多個用戶進程,每個進程都可能會產生通信需求。網際層僅負責通過IP地址將數據報從源主機傳輸到目標主機,不提供數據報的區分功能。傳輸層協議中引入了協議端口號的概念,用於標記屬於不同用戶進程的數據,簡稱爲端口號。

網絡中數據傳輸的複用功能可通過端口號和IP地址的組合來實現,TCP和UDP協議均在數據報的首部附加了兩個端口字段:源端口和目的端口。源端口用於表示數據報發送端的用戶進程,目的端口則用於表示接收端的用戶進程。端口字段的長度爲16位,可用的端口號範圍爲0~65535。如表3-9所示,端口號可分爲3類。

表3-9 端口的劃分

端口類別

端口號範圍

應用

熟知

0 ~ 1023 由IANA分配給因特網上常用的應用層協議,例如HTTP、DNS和SMTP

註冊

1024 ~ 49151 由IANA分配給專有應用程序,例如Microsoft SQL Server和Oracle

隨機

49152 ~ 65535 由操作系統動態分配給用戶進程

用戶進程在進行通信時,應事先確定其所採用的端口號。源端口號一般均屬於隨機端口,而目的端口通常是熟知或註冊端口。表3-10給出了常用的應用層協議所使用的端口號。

表3-10 常用協議的端口號

傳輸層協議

應用層協議

端口號

TCP

HTTP

80

FTP

21

POP3

110

SMTP

25

SSH

22

telnet

23

UDP

DNS

53

SNMP

161

TFTP

69

如圖3-32所示,在網絡上有一臺WWW服務器和兩臺主機。Web服務器的IP地址爲192.168.1.2,主機PC1的IP地址爲192.168.1.3,主機PC2的IP地址爲192.168.1.4。假設PC1中有三個用戶進程通過HTTP協議與Web服務器進行通信,PC2中有兩個用戶進程通過HTTP協議與Web服務器進行通信。根據傳輸層端口分配原則可知,在用戶進程發送的數據報中,源端口號均在0~65535的範圍中隨機分配,且同一主機上不同進程所分配的源端口號不同。已知數據通信中使用的應用層協議只有HTTP協議,則由表3-10可知,所有數據報的目的端口號均爲80。

在如圖3-33所示的實例中,主機PC-A中有兩個用戶進程與服務器PC-B進行復用通信,服務器PC-B根據源端口號區分這兩個進程。若主機PC-A在向服務器PC-B發送的數據報中,源端口號爲50001,且目的端口號爲23,則表明這個數據報用於遠程登錄,由telnet用戶進程產生。若數據報的源端口號爲50003,且目的端口號爲80,則表明這個數據報屬於HTTP應用,由瀏覽器進程產生。PC-B在包含遠程登錄應答信息的數據報中,將源端口號設爲23,目的端口號設爲50001;在迴應HTTP請求的數據報中,將源端口號設爲80,目的端口號設爲50003。

二、UDP數據報服務

UDP是一種無連接的數據報協議,它提供“盡最大努力交付”的數據報傳輸服務。

當客戶寄送郵件時,郵政系統並不能保證郵件順利到達,若丟失,則發信方也不會從收信方得到任何反饋信息,也不會得到任何賠償。UDP協議同樣不關注數據報在傳輸過程中能否到達接收端,若上層的應用程序採用UDP協議,但又需要其可靠傳輸,則應用程序本身應該設置相應的機制來保證數據傳輸的可靠性。在應用對可靠性要求較低,實時性卻要求較高時,適合採用UDP協議,如視頻和音頻傳輸等。

UDP協議是一種面向報文的協議。

UDP用戶數據報可分爲兩部分:首部和數據部分。

UDP用戶數據報首部可分爲以下4個字段:

如圖3-34所示,對應用層向下移交的數據,UDP協議不進行合併或拆分操作,僅在添加UDP首部後交給網際層進行處理。在IP數據報首部中,當協議字段爲17時,代表數據部分爲UDP用戶數據報。

如圖3-34所示,首部長度爲8個字節,數據部分的長度則由應用層根據需要確定。

1.源端口字段,記錄分配給數據報發送端用戶程序的端口號,用於接收端返回應答信息。

2.目的端口字段,記錄數據報的目的端口號,運行在接收端主機上的UDP協議根據這一端口號將數據報交付給用戶進程。

3.長度字段,記錄UDP用戶數據報的長度,單位爲字節,最小值爲8。此時,數據報的數據部分爲空。

4.校驗和字段,用於檢測UDP用戶數據報在傳輸過程中是否發生差錯。

圖3-34 UDP數據報

三、TCP可靠傳輸服務

傳輸控制協議TCP是一種面向連接的,具有流量控制和可靠傳輸等功能的傳輸層協議。TCP協議規定,用戶進程在數據開始傳輸前,必須通過“三次握手”建立TCP連接,並在數據傳輸結束後釋放TCP連接。TCP通過使用自動重傳請求的滑動窗口機制,提供流量控制和可靠傳輸功能。

TCP協議也是一種面向字節流的傳輸層協議,它不同於UDP協議,TCP對應用層向下移交的數據進行合併或拆分,以適應網絡的傳輸要求。通過TCP協議傳輸的數據,在字節流層面保持不變,但數據分組可能會發生變化。合併或拆分後的數據在被添加到TCP首部後,交付給網際層進行處理。

TCP報文:

如圖3-35所示,TCP首部包含20個字節的固定參數和長度不定的可選參數,可選參數部分的長度總是4個字節的整數倍。固定首部可分爲以下字段:

1.源端口字段,記錄分配給數據報發送端用戶程序的端口號,用於接收端返回應答信息。

2.目的端口字段,記錄數據報的目的端口號,運行在接收端主機上的TCP協議根據這一端口號將數據報交付給用戶進程。

3.序號字段,記錄數據部分在用戶進程提交的字符流中的起始位置。

4.確認號字段,用於接收端給出期望接收的下一個分組的序號。

5.數據偏移字段,用於給出分組中TCP首部的長度。

6.保留字段,尚未定義功能。

7.URG-FIN字段,用於傳輸控制。

8.窗口字段,用於表示接收端接收窗口的大小。

9.校驗和字段,用於檢測UDP用戶數據報在傳輸過程中是否發生了差錯。

10.緊急指針字段,用於指出數據部分中緊急數據所佔的字節數。

圖3-35 TCP報文

1.TCP三次握手

如圖3-36所示,爲了保證會話的可靠性,兩臺主機在進行TCP數據傳輸前,必須通過三次握手建立TCP連接。

圖3-36 TCP建立連接過程

1)主機PC1將一個SYN數據報發送到主機PC2,希望建立一個TCP連接。

2)主機PC2發送ACK數據報,確認收到了PC1的SYN數據報,併發送SYN數據報,等待PC1確認。

3)主機PC1發送ACK數據報,確認接收到了PC2發送的SYN+ACK數據報,表示TCP連接已成功建立。

2.滑動窗口

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

圖3-37自動重傳請求ARQ機制

在自動重傳請求機制下,發送端在發送完分組後,保留的副本並停止數據發送,直到接收端確認已接收到了,發送端才清除的副本,並開始發送下一個報文段。若超過一定時間後,發送端仍沒有接收到接收端對的確認,則發送端再利用的副本對進行重傳。

如圖3-37所示,發送端在發送完第一個分組後暫停,接收端順利接收到並返回對的確認。發送端接收到確認後,開始發送第二個分組,在傳輸過程中出現了差錯,接收端檢測到這一差錯,將丟棄。一定時間後,發送端因爲等待超時,利用的副本對進行重傳,接收端順利接收到,並返回對的確認,傳輸繼續進行。

上述ARQ機制中,由於每個分組在發送時都要求對上一分組進行確認,數據傳輸效率較低,連續ARQ機制可以解決該問題。連續ARQ中,引入了發送窗口的概念。如圖3-38(a)和3-38(b)所示,深灰色部分爲當前的發送窗口,發送窗口中的分組可連續發送,而不必等待接收端一一確認。在圖3-42(a)中,發送窗口的左端位於1號分組,右端位於5號分組,發送端連續發送編號爲1~5的分組後,停止數據傳輸並等待接收端的確認。接收端只對按序到達的分組中的最後一個進行確認,例如,接收端接收到的分組編號爲1、2、3和5,則只對3號分組進行確認。如圖3-42(b)所示,發送端接收到確認後,將發送窗口的左端移動到4號分組,右端移動到8號分組,並開始下一輪的數據傳輸。

 

圖3-38連續ARQ機制

2)滑動窗口

在滑動窗口機制中,發送端發送窗口的大小不能超過接收端的接收窗口。因此,接收端可以通過接收窗口限制發送端的發送速率,進行流量控制。在圖3-39(a)中,發送端的發送窗口包含編號爲4~7的分組,接收端在接收到這些分組後,向發送端返回7號分組的確認信息,然後將接收窗口大小重新設置爲2個分組並通知發送端,發送端在開始下一輪發送時,根據接收窗口的大小將發送窗口左端移動到8號分組,右端移動到9號分組,如圖3-39(b)所示。

圖3-39滑動窗口機制

通過滑動窗口機制可以動態地調整數據報的發送和接收數量,當接收端數據處理能力達到飽和時,可採用較小的窗口來降低發送端發送數據報的速度。此外,當網絡擁塞時,也可以通過滑動窗口機制來避免數據報丟失。在網絡擁塞解除後,可擴大窗口來提高鏈路的利用率。

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