一、傳輸層功能
在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。
圖3-32瀏覽器訪問實例
圖3-33 傳輸層復用通信實例
二、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-35TCP報文
1．TCP三次握手
如圖3-36所示，為了保證會話的可靠性，兩台主機在進行TCP數據傳輸前，必須通過三次握手建立TCP連接。
圖3-36TCP建立連接過程
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）所示。
| （a） | （b） |
| （a） | （b） |
圖3-39滑動窗口機制
通過滑動窗口機制可以動態地調整數據報的發送和接收數量，當接收端數據處理能力達到飽和時，可采用較小的窗口來降低發送端發送數據報的速度。此外，當網絡擁塞時，也可以通過滑動窗口機制來避免數據報丟失。在網絡擁塞解除后，可擴大窗口來提高鏈路的利用率。