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