1、計算機網絡計算機網絡自頂向下方法自頂向下方法第3章 運輸層3.1概述和運輸層服務3.3多路復合與多路分解3.3無連接運輸：UDP運輸服務和協議w 為運行在不同主機上應用進程之間提供邏輯通信功能w 運輸協議運行在端系統中的方法：發送方：將應用報文劃分為報文段，傳向網絡層接收方：將段重新裝配為報文，傳向應用層w 網絡應用程序可供使用的運輸協議不止一個因特網：TCP和UDP應用層運輸層網絡層數據鏈路層物理層網絡層數據鏈路層物理層應用層運輸層網絡層數據鏈路層物理層網絡層數據鏈路層物理層網絡層數據鏈路層物理層網絡層數據鏈路層物理層網絡層數據鏈路層物理層邏輯端到端傳輸3.1.1運輸層和網絡層的關系w網絡層

2、: 主機間的邏輯通信w運輸層: 進程間的邏輯通信依賴、強化網絡層服務家庭類比:12個孩子向12個孩子發信w 進程 = 孩子w 應用報文= 信封中的信w 主機 = 家庭w 運輸層協議 = Ann和Billw 網絡層協議= 郵政服務1.運輸層協議只工作在端系統。事實上，中間路由器既不處理也不識別運輸層加在應用層報文的任何信息。2.計算機網絡中可以安排多種運輸層協議，每種協議為應用層提供不同的服務模型。3.運輸協議所能提供的服務常常受制于底層網絡層協議的服務模型。例如，時延和寬帶保證。4即使底層網絡層網絡協議不能在網絡層提供相應的服務，運輸層協議也能提供某些服務。例如（1）即使底層網絡協議是不可靠的

3、，運輸協議也能為應用程序提供可靠的數據傳輸服務。（2）即使網絡層不能保證運輸層報文段的機密性，運輸層協議也能使用加密來確保應用程序報文不被入侵者讀取。3.1.2因特網運輸層概述IP(因特網網絡層協議)服務模型：盡力而為交付服務 不確保報文段的交 不保證報文段的按序交付 不可靠服務不可靠服務不保證報文段中數據的完整性 每臺主機至少有一個每臺主機至少有一個IP地址地址TCP（可靠地，面向連接的服務） -可靠數據傳輸：確保正確地、按序地將數據從發送地將數據從發送進程交付給運輸進程。 -擁塞控制：防止任何一條TCP連接用過多流量來淹沒通信主機之間的鏈路和交換設備。UDP（不可靠，無連接的服務） TCP

4、 和UDP基本責任：將兩個端系統間IP的交付服務擴展為運行在端系統上的兩個進程之間的交付服務。3.2 多路復用和多路分解 運輸層的的多路復用和多路分解，是將網絡層提供的主機到主機交付服務延伸到為運行在主機上的應用程序提供進程到進程的交付服務。 一個進程（作為網絡應用的一部分）有一個或多個套接字，它相當于從網絡向進程傳遞數據和從進程向網絡傳遞數據的門戶。 將運輸層報文段中的數據交付 給正確的套接字的工作多路分解：從多個套接字收集數據，用首部封裝數據(以后用于分解 )多路復合：應用層運輸層網絡層鏈路層物理層P1應用層運輸層網絡層鏈路層物理層應用層運輸層網絡層鏈路層物理層P2P3P4P1主機1主機2

5、主機3套接字 進程如圖所示，在接受主機中運輸層實際上并沒有直接將數據交付給進程，而是將數據交給了一個中間的套接字。由于在任一時刻，在接受主機上可能有不止一個套接字，所以每個套接字都有唯一標識符。值得注意的是圖中間那臺主機的運輸層必須將從其下的網絡層收到的報文段分解后交給其上的P1或P2進程。中間主機中的運輸層也必須收集從這些套接字輸出的數據，形成運輸層報文段然后將其向下傳遞給網絡層。 工作過程w 運輸層多路復合要求套接字有唯一標識符每個報文段有特殊字段 （源端口號字段和目的端口字段） 來指示該報文段所要交 付的套接字w 運輸層分解服務w 主機使用IP地址和端口號將報文段定向到相應的套接字。然后

6、報文段中的數據通過套接字進入其所連接的進程。源端口號目的端口號32 bits應用數據(報文)其他首部字段運輸層報文段中的源與目的端口字段1.無連接的多路復合與多路分解創建一個UDP套接字：運輸層自動的為該套接字分配一個端口號。（通常，應用程序的客戶端讓運輸層自動地（并且是透明的）分配端口號，而服務器則分配一個特定的端口號。）所以具有不同源IP地址和/或源端口號，但具有相同目的IP地址和目的端口號的兩個UDP報文段，通過相同的目的套接字被定向到相同的目的進程。由二元組標識-當從網絡到達UDP報文段時，主機通過檢查該報文段中的目的端口號定向到相應的套接字。-完整的返回地址是A的IP地址和源端口號。

7、2.面向連接的多路復合與多路分解w TCP套接字由四元組標識: 源IP地址源端口號目的IP地址目的端口號w 接收主機使用這四個值來將段定向到適當的套接字w 與UDP不同的是，兩個具有不同源IP地址或源端口號的到達TCP報文段將被定向到兩個不同的套接字，除非TCP報文段攜帶了初始創建連接的請求。w 服務器主機可能支持許多并行的TCP套接字（每個套接字由其自己的四元組標識）面向連接 (續)圖中主機C向服務器B發起了兩個HTTP會話，主機A向服務器B發起了一個HTTP會話。主機A與主機C及服務器B都有自己唯一的IP地址。主機C為其兩個HTTP連接分配了兩個不同的源端口號（26145和7532）。因為

8、主機A選擇源端口號與主機C互不相干，服務器B仍然能夠正確分解這兩個具有相同源端口號的連接，因為這兩條連接具有不同的IP地址。3.Web服務器與TCPw 如圖，Web服務器為每條連接生成一個新進程連接套接字與進程之間并非總是有著一對一的關系如果客戶與服務器使用持續HTTP，客戶與服務器之間經由同一根服務器套接字交換HTTP報文。若為非持續HTTP，則對每一個請求/響應都創建一個新的TCP連接并隨后關閉，對每一個請求/響應創建一個新的套接字并隨后關閉。這種套接字的頻繁創建和關閉輝嚴重影響一個繁忙的Web服務器的性能。3.3 無連接運輸：UDPw 互聯網傳輸協議w “盡力而為”服務，UDP段可能：丟

9、包對應用程序交付失序w 無連接無連接:在UDP發送報文段之前，發送方和接收方之間無握手（例：DNS）為何要有 UDP協議?w 關于何時、發送什么數據的應用層控制更為精細w 無需連接創建w 無連接狀態w 分組首部開銷小w 常用于流式多媒體應用丟包容忍速率敏感w 但是，UDP中缺乏擁塞控制那個導致UDP發送方和接受方之間的高丟包率，并擠垮了TCP會話，這是一個潛在的嚴重問題。w UDP的可靠傳輸 : 在應用層增加可靠性應用進程可以進行看看通信，而無需受制于由TCP擁塞控制機制無需受制于傳輸速率限制3.3.1 UDP報文段結構w 由RFC768定義。應用層數據占用UDP報文段的數據字段。w UDP首

10、部只有4的字段，每個字段由兩個字節組成。w 通過端口號可以使目的主機將應用數據交給運行在目的端系統中的相應進程(執行分解功能)。w UDP報文段的長度需要明確，包括首部在內，以字節為單位。源端口號目的端口號32 bits應用數據(報文)UDP 報文段結構長度檢查和3.3.2UDP檢驗和發送方:w 將報文段內容處理為16比特整數序列w 檢驗和: UDP中所有16比特字的和進行反碼運算的結果w 發送方將檢查和放入UDP檢和字段接收方:w 計算接收的段的檢驗和w 核對計算的檢驗和是否等于檢驗和字段的值UDP檢驗和提供了差錯檢驗功能。目的: 當UDP報文段從源到目的地移動是，比特是否發生了改變假定有下面3個16比特的字：w 注意到最后一次加法有溢出，它要被回卷。w 反碼就是將所有的0換成1，所有的1換成0。w 該和的反碼運算結果是1011010100111101，這就變為了檢驗和。w 在接受方，全部的4個16比特字加在一起，如果分組中沒有引入差錯，則顯然在接受方處該和是1111111111111111。w UDP首先提供了檢驗和，是由于不能保證源和目的之間的所有鏈路都提供差錯檢驗。w 在既無法確保逐鏈路的可靠性，又無法確保內存中的差錯