視頻地址：湖南科技大學計算機網絡微課堂https://www.bilibili.com/video/BV1c4411d7jb
5.1 運輸層概述
為什么需要運輸層
- 之前介紹的計算機網絡體系結構中的物理層、數據鏈路層以及網絡層它們共同解決了將主機通過異構網絡互聯起來所面臨的問題，實現了
主機到主機的通信。 - 但實際上在計算機網絡中進行通信的真正實體是位於通信兩端
主機中的進程。 - 如何為運行在不同主機上的應用進程提供直接的通信服務是運輸層的任務，運輸層協議又稱為
端到端協議。
運輸層直接為應用進程間的邏輯通信提供服務
- 運輸層向高層用戶屏蔽了下面網絡核心的細節（如網絡拓撲、所采用的路由選擇協議等)，它使應用進程看見的就好像是在兩個運輸層實體之間有一條端到端的邏輯通信信道。
- 根據應用需求的不同，因特網的運輸層為應用層提供了兩種不同的運輸協議，即
面向連接的TCP和無連接的UDP。
5.2 端口號、復用、分用的概念
5.2.1 端口號
為什么需要端口號？
- 運行在計算機上的進程使用進程標識符
PID來標志。 - 因特網上的計算機並不是使用統一的操作系統，不同的操作系統(windows，Linux，Mac os)又使用不同格式的進程標識符。
- 為了使運行不同操作系統的計算機的應用進程之間能夠進行網絡通信，就必須使用統一的方法對TCP/IP體系的應用進程進行標識。
- TCP/IP體系的運輸層使用端口號來區分應用層的不同應用進程。
端口號分類
端口號使用16比特表示，取值范圍0~65535;
- 熟知端口號:0~1023，這些端口號指派給了TCP/IP體系中最重要的一些應用協議，例如:FTP使用21/20，HTTP使用80，DNS使用53。
- 登記端口號:1024~49151，為沒有熟知端口號的應用程序使用。使用這類端口號必須登記，以防止重復。例如: MySql使用的端口號3306。
- 短暫端口號:49152~65535，留給客戶進程選擇暫時使用。當服務器進程收到客戶進程的報文時，就知道了客戶進程所使用的動態端口號。通信結束后，這個端口號可供其他客戶進程以后使用。
端口號只具有本地意義，即端口號只是為了標識本計算機應用層中的各進程，在因特網中不同計算機中的相同端口號是沒有聯系的。
5.2.2 發送方的復用和接收方的分用
發送方
- 發送方的某些應用進程所發送的不同應用報文，在運輸層使用UDP協議進行封裝，稱為
UDP復用。使用TCP協議進行封裝，稱為TCP復用。運輸層使用端口號來區分不同的應用進程。 - 不管是使用運輸層的UDP協議封裝成的UDP數據報，還是TCP數據報，在網絡層都需要使用IP協議封裝成IP數據報，稱為
IP復用。 - IP數據報首部中協議字段的值，用來表示IP數據報的數據載荷部分封裝的是何種協議數據單元。
- 協議字段為6，表示封裝的是TCP報文段。協議字段為17，表示封裝的是UDP報文段。
接收方
- 接收方的網絡層收到IP數據報后進行IP分用。
- 根據IP數據報中協議字段的值是6還是17分別交付給運輸層的UDP或者TCP。
- 運輸層根據協議不同分別進行UDP分用和TCP分用。也就是根據端口號將其上交給上層的應用進程。
TCP/IP體系的應用層常用協議所使用的運輸層熟知端口號
【舉例】運輸層端口號的作用
如圖所示：
- 用戶PC通過交換機和DNS服務器以及Web服務器互聯，他們處在同一個以太網中。
- DNS服務器中記錄有Web服務器域名所對應的IP地址
用戶PC發送DNS查詢請求報文
- 用戶在瀏覽器中輸入URL來訪問Web服務器的內容，在瀏覽器輸入Web服務器的域名。
- 用戶PC中的DNS客戶端進程會發送一個
DNS查詢請求報文（查詢域名對應的IP地址） - DNS查詢請求報文需要使用UDP協議封裝成
UDP數據報。 - UDP數據報首部的源端口從短暫端口號:49152~65535中挑選一個未占用的，用來表示
DNS客戶端進程如：49152。目的端口為53。這是DNS服務器端進程使用的端口號。 - 將UDP數據報封裝到
IP數據報中，通過以太網發送到DNS服務器。
DNS服務器收到用戶PC發送的IP數據報
- 收到
IP數據報，解封出UDP數據報。UDP首部的目的端口是53，表示應該將UDP數據報的數據載荷部分（DNS查詢請求報文）交給本服務器的DNS服務器端進程處理。 - DNS服務器端解析DNS查詢請求報文內容，然后按其要求查詢對應域名的IP地址。
- 查到后，會給用戶PC發送
DNS響應報文（內容為域名對應的IP地址）。 - DNS響應報文使用UDP協議封裝為
UDP數據報，源端口為53，目的端口為49152。 - 將UDP數據報封裝為
IP數據報，通過以太網發送到用戶PC。
用戶PC收到DNS服務器響應報文
- 解析出
UDP數據報，目的端口是49152，需要將響應報文交給DNS客戶端進程處理。 - DNS客戶端進程解響應報文，得到域名對應的IP地址。
- 有了IP地址，用戶PC端的HTTP客戶端進程，就可以向Web服務器發送
HTTP請求報文了（首頁內容是什么） - HTTP請求報文使用TCP協議封裝成
TCP報文段。 - TCP數據報首部的源端口從短暫端口號:49152~65535中挑選一個未占用的，用來表示
HTTP客戶端進程如：49152。目的端口為80。這是HTTP服務器端進程使用的端口號。 - 將TCP報文段封裝在
IP數據報中，通過以太網發送到Web服務器。
Web服務器收到用戶PC發送的IP數據報
- 收到IP數據報，解封出
TCP報文段。TCP首部的目的端口是80，表示應該將TCP報文段的數據載荷部分（HTTP請求報文）交給本服務器的HTTP服務器端進程處理。 - HTTP服務器端解析
HTTP請求報文內容，然后按其要求查詢首頁內容。 - 查到后，會給用戶PC發送
HTTP響應報文（HTTP客戶端請求的首頁內容）。 - HTTP響應報文使用TCP協議封裝為TCP報文段，源端口為80，目的端口為
49152。 - 將TCP報文段封裝為
IP數據報，通過以太網發送到用戶PC。
用戶PC收到Web服務器響應報文
- 收到
IP數據報后，解析出TCP報文段，TCP首部的目的端口是49152，表示應該將TCP報文段的數據載荷部分（HTTP響應報文）交給用戶PC端的HTTP客戶端進程處理。 - HTTP客戶端解析
HTTP響應報文內容，並在網頁瀏覽器上顯示。 - 這樣就可以在瀏覽器上看到Web服務器提供的首頁內容了。
5.3 UDP和TCP的對比
- UDP什么時候都可以進行數據傳輸，TCP必須建立連接才能傳輸數據。
TCP和UDP廣播數據通信
- UDP支持單播，多播以及廣播（一對一，一對多，一對全的通信），TCP只支持單播（一對一）。
TCP和UDP對應用報文的處理
- UDP對發送方應用進程的報文既不合並也不拆分，直接將其交互給接收方應用進程。（面向應用報文）
- 發送方的TCP協議把應用進程的報文，看做一連串的為無結構的字節流。TCP將其編號存儲在自己的發送緩沖中。
- TCP根據發送策略，從發送緩存中提取一定數量的字節，構建TCP報文段並發送。
- 接收方的TCP協議，一方面從所接收到的TCP報文段中取出數據載荷並存儲在接收緩存中，一方面將緩存中的一些字節交給應用進程。
- TCP不保證接收方應用進程所收到的數據塊與發送方應用進程所發送的數據塊具有對應大小關系。例如：發送方應用進程交給發送方的TCP共10個數據塊。但接收方的TCP可能只用了4個數據塊就把收到的字節流交付給了上層的應用進程。
- 接收方應用進程收到的字節流必須和發送方應用進程發出的字節流完全一樣。
- 接極方的應用進程必須有能力識別收到的字節流，把它還原成有意義的應用層數據。（面向字節流）
TCP和UDP提供的傳輸服務
TCP/IP體系結構的網際層向上層提供不可靠傳輸服務
- 當運輸層使用UDP時，向上層提供的也是無連接不可靠傳輸服務
- 使用UDP時，若傳輸過程中用戶數據報受到平擾而產生誤碼，接收方UDP可以通過該數據報首部中的校驗和字段的值檢查出產生誤碼的情況。 但僅僅丟棄該數據報，其他什么也不做。
- 如果該數據報被因特網中的某個路由器丟棄了。發送方UDP不做任何處理。
- 盡管網際層中的IP協議,向上提供的是無連接不可靠的傳輸服務。但只要運輸層使用TCP協議，就可向其上層提供面向連接的可靠傳輸服務。
- 可以將其想象成：使用TCP協議的收發雙方，基於TCP連接的可靠信道進行數據傳輸。不會出現誤碼、丟失、亂序以及重復等傳輸差錯。
UDP用戶數據報和TCP報文段的首部
- UDP首部僅有4個字段，每個字段長2個字節。共8個字節。
- 由於UDP提供不可靠傳輸服務，僅僅在網際層的基礎上添加了用於區分應用進程的端口。
- TCP報文段首部最小20字節，最大60字節
- 這是因為要實現可靠傳輸、流量控制、擁塞控制等服務。首部比較復雜。
5.4 TCP的流量控制
為什么需要流量控制
- 一般來說，我們總是希望數據傳輸得更快一些。
- 但如果發送方把數據發送得過快，接收方就可能來不及接收，這就會造成數據的丟失。
- 所謂流量控制（flow control)就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
- 利用滑動窗口機制可以很方便地在TCP連接上實現對發送方的流量控制。
5.5 TCP的擁塞控制
- 在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡性能就要變壞。這種情況就叫做擁塞(congestion)。
- 在計算機網絡中的鏈路容量（即帶寬)、交換結點中的緩存和處理機等，都是網絡的資源
- 若出現擁塞而不進行控制，整個網絡的吞吐量將隨輸入負荷的增大而下降。
5.6 TCP可靠儲傳輸的實現
- TCP基於以字節為單位的滑動窗口來實現可靠傳輸
【假設】發送方收到了接收方的確認報文段。首部信息：rwnd=20，ack=31。
- 在報文段首部中的窗口字段的值是20，也就是接收方表明自己的接收窗口的尺寸為20字節。
- 確認號字段的字節為31，這表明接收方希望收到的下一個數據的序號是31。序號30及之前的數據已經全部正確接收了。
- 發送方根據這兩個字段的值構造自己的發送窗口。
