運輸層

• 1. 概述和運輸服務

  • 運輸層協議為運行在不同主機上的應用進程之間提供了邏輯通信功能, 運輸層協議是在端系統中而不是路由器中實現的, 網絡應用程序可以調用多種運輸層協議, 如因特網的兩種協議: TCP 和 UDP ,每種協議都能為調用的應用程序提供一組不同的運輸層服務

  • 1.1 運輸層和網絡層的關系 : 分工協作

    • 它們之間是分工協作、各司其職的關系，可以用一個經典的比喻來理解：送信與送包裹。
    • 網絡層 (Network Layer - IP) - “郵政系統”
      • 職責:?提供主機到主機（Host-to-Host）的邏輯通信。它的核心任務是路由和轉發。

      • 工作方式：網絡層（以IP協議為代表）只關心如何將一個個獨立的IP數據報（Packet）從源主機（例如，你的電腦）通過網絡中的路由器，盡力而為地（Best-Effort）傳遞到目標主機（例如，一個遙遠的服務器）。

      • 局限性：IP協議不關心這個數據報是屬于哪個應用程序的。它就像郵政系統，只負責把信件送到一棟大樓（目標主機），但不管這封信是給大樓里的張三（瀏覽器進程）還是李四（微信進程）。同時，它不保證信件一定送達、不保證送達順序、也不保證信件完好無損。

    • 運輸層 (Transport Layer - TCP/UDP) - “大樓里的前臺/分發員”

      • 職責：提供進程到進程（Process-to-Process 或 Application-to-Application）的端到端邏輯通信。它的核心任務是擴展IP的交付服務。

      • 工作方式：運輸層位于應用程序和網絡層之間。它接收來自不同應用程序的數據，并添加上運輸層首部（包含關鍵信息：端口號），形成報文段（Segment）。然后，它將報文段交給網絡層去發送。

      • 如何解決網絡層的局限性：

        • 復用 (Multiplexing) 和 分用 (Demultiplexing)：通過端口號（Port Number）?這個標識，運輸層可以將來自多個應用程序的數據（復用）通過同一個網絡層接口發送出去，也能將接收到的數據準確地分發給正確的應用程序（分用）。這就是“前臺”根據信封上的房間號（端口號）把信分發給不同員工（進程）的過程。
        • 增強服務：運輸層協議（如TCP）可以在網絡層提供的不可靠服務之上，提供可靠性保證、流量控制、擁塞控制等高級功能。
    • 總結關系：
      • 網絡層是通信的“基礎設施”，負責全局的、主機級別的數據傳輸。
      • 運輸層是通信的“服務增強者”，負責局部的、應用級別的數據傳輸，并在此基礎上提供更高質量、更可控的數據傳輸服務。
      • 沒有網絡層，運輸層無法實現通信；沒有運輸層，應用程序無法直接、可靠地使用網絡層服務。???????

  • 1.2 因特網運輸層概述

    • 因特網的設計者們深刻地理解上述的分工思想，因此其運輸層提供了兩種風格迥異的核心協議，以滿足不同應用程序的多樣化需求。這就好比提供了“順豐快遞”（強調可靠、安全）和“普通信件”（強調快速、簡單）兩種服務。

    • 因特網的運輸層協議主要有兩個：

      • 傳輸控制協議 (TCP - Transmission Control Protocol)

      • 用戶數據報協議 (UDP - User Datagram Protocol)

    • 下面是一個快速的對比概述：

      • 特性	TCP (傳輸控制協議)	UDP (用戶數據報協議)
        連接性	面向連接的 (Connection-Oriented)	無連接的 (Connectionless)
        	在數據傳輸前需要經過“三次握手”建立連接，傳輸結束后有“四次揮手”釋放連接。	無需建立連接，可直接發送數據。
        可靠性	可靠的 (Reliable)	不可靠的 (Unreliable)
        	通過確認、重傳、序號等機制，確保數據無差錯、不丟失、不重復且按序到達。	“盡力而為”交付，不保證數據一定到達，也不保證順序。
        流量控制	有	無
        	通過滑動窗口機制，確保發送方不會因為發送太快而淹沒接收方。	發送方以恒定速率發送，不管接收方能否處理。
        擁塞控制	有	無
        	通過復雜的算法（如慢啟動、擁塞避免）感知網絡擁堵并調整發送速率，對Internet整體穩定性至關重要。	沒有擁塞控制，網絡擁堵時可能會加重負擔。
        傳輸單位	字節流 (Byte Stream)	報文 (Message)
        	應用程序交付的數據被視為無結構的字節流，TCP會將其拆分/組合成合適的報文段。	應用程序交付的每一個數據塊都封裝成一個獨立的UDP數據報。
        頭部開銷	大 (通常20字節)	小 (僅8字節)
        	首部包含大量用于實現可靠傳輸和控制機制的字段。	首部非常簡單，只有源端口、目的端口、長度和校驗和。
        典型應用	Web (HTTP/HTTPS), 電子郵件 (SMTP), 文件傳輸 (FTP), 遠程終端 (SSH)	域名解析 (DNS), 語音/視頻通話 (VoIP), 流媒體, 在線游戲

    • 為了簡化術語, 我們將運輸層分組稱為報文段, 然而 因特網文獻(RFC文檔) 也將TCP的運輸層分組成為報文段, 而常將UDP 的分組成為數據報, 我們在這個系列的文章將TCP 和 UDP 的分組統稱為報文段, 而將數據報的稱謂留給網絡層分組

• 2. 多路復用與多路分解

  • 在一臺主機上，通常同時運行著多個網絡應用程序（如瀏覽器、微信、音樂播放器）。它們可能同時在使用網絡收發數據。

    • 那么問題來了：當主機從網絡層收到一個數據報時，它應該如何知道這個數據報是屬于瀏覽器進程的，還是屬于微信進程的？

    • 答案就是：通過運輸層的多路分解。

    • 反過來：當主機上的多個應用程序都要發送數據時，它們的數據是如何通過同一個網絡接口卡（NIC）發送出去的？

    • 答案就是：通過運輸層的多路復用。

  • 簡單定義：

    • 多路復用 (Multiplexing)：在發送方，運輸層從多個不同套接字（Socket）接收應用程序數據，并為每塊數據封裝上運輸層首部信息（主要是端口號），然后將這些報文段傳遞到網絡層的過程。

    • 多路分解 (Demultiplexing)：在接收方，運輸層檢查報文段中的字段（主要是目的端口號），標識出接收套接字，從而將運輸層報文段中的數據定向到正確的套接字的過程。

  • 2.1 無連接的多路復用和多路分解 (UDP)

    • UDP的多路復用與分解非常簡單直接，其socket用一個二元組來標識：(目的IP地址, 目的端口號)。

    • 發送方 (多路復用)：

      • 1. 應用程序創建一個UDP套接字。操作系統會為該套接字分配一個源端口號（可以是自動分配的，也可以是應用程序綁定的）。
      • 2. 應用程序通過該套接字發送數據時，UDP會為數據封裝一個首部，其中包含源端口號和目的端口號。
      • 3. 所有應用程序的UDP報文段都通過同一個“通道”（主機網絡層接口）發送出去。
    • ???????接收方 (多路分解)：
      • 1. UDP維護著一個套接字表，可以理解為一張簡單的清單，記錄了本機所有正在監聽的UDP套接字及其綁定的端口號。
      • 2. 當主機收到一個UDP報文段時，UDP檢查報文段首部中的目的端口號。
      • 3. UDP將該報文段的數據部分導向到正在監聽該目的端口號的那個套接字。
      • 4. 注意：UDP不關心源地址和源端口號，它只認目的端口號。這意味著，只要目的端口號相同，來自任何源IP和源端口的報文都會被送到同一個套接字。

    • 一個生動的比喻：
      UDP就像一個大學宿舍樓的公用快遞架。

      • 多路復用：所有學生（應用程序）都把要寄出的快遞（數據報）放在架子上（交給網絡層），快遞單上寫著收件人的地址和宿舍號（目的IP和端口）。

      • 多路分解：快遞小哥把送來的快遞放到架子上。學生只根據快遞單上的宿舍號（目的端口）?來認領自己的快遞。他不在乎這個快遞是來自北京的媽媽還是上海的朋友（不區分源）。

  • 2.2 面向連接的多路復用和多路分解 (TCP)

    • TCP的多路分解機制比UDP要精細和復雜得多，這是由其面向連接的特性決定的。一個TCP套接字不是由一個二元組，而是由一個四元組來唯一標識的：
      (源IP地址, 源端口號, 目的IP地址, 目的端口號)

    • 為什么需要四元組？
      因為TCP是面向連接的。一臺服務器（如Web服務器）通常只在一個端口上監聽（如80），但卻要同時處理成千上萬個來自不同客戶端的連接。如果只使用目的端口號進行分解，所有客戶端的請求都會被導向同一個監聽套接字，服務器將無法區分彼此獨立的連接。

    • 接收方 (多路分解)：

      • 1. 服務器有一個歡迎套接字（Welcome Socket），它被綁定在某個特定端口（如80）上，專門用于監聽新的連接請求。
      • 2. 當一個客戶端發起連接（SYN報文段到達）時，歡迎套接字會接受它，服務器內核會為這個特定的連接創建一個新的連接套接字（Connection Socket）。
      • 3. 此后，所有來自這個客戶端（具有特定源IP和源端口）的報文段，在通過IP層交付后，TCP會根據其四元組信息，精確地將數據定向到為其創建的那個唯一的連接套接字中。
      • 4. 因此，服務器上最終會有一個歡迎套接字和成百上千個活躍的連接套接字，每個連接套接字都通過四元組與一個客戶端連接唯一對應。
    • ???????發送方 (多路復用)：

    • 在客戶端，一個TCP應用也可能同時建立多個連接（例如，瀏覽器同時打開多個標簽頁連接到同一個服務器）。TCP會為每個連接創建不同的套接字。在發送時，數據從不同套接字流出，TCP會為每個報文段封裝上對應的源和目的端口號，然后復用到網絡層。

    • 一個生動的比喻：TCP就像一個公司的前臺接待。

      • 歡迎套接字：前臺總機號碼（如公司總機：12345678）。任何人打這個號碼都會連接到前臺。

      • 連接請求：一個客戶（源IP:端口 = 客戶A的手機號）打電話到總機，說要聯系銷售部。

      • 創建新套接字：前臺將電話轉接（Forward）?給銷售部的某位專員張三（創建一個新的連接套接字）。此后，客戶A與張三直接通話。

      • 多路分解：此時，另一個客戶B（另一個源IP:端口）也打電話到總機，也要找銷售部。前臺會把他的電話轉接給另一位專員李四（創建另一個新的連接套接字）。

      • 四元組的作用：這樣，雖然所有外部電話都打向同一個總機號（目的IP:80），但公司內部卻建立了多條獨立的、并發的通話線路。前臺/電話系統通過來電號碼（源IP:端口）?來區分該把電話轉給誰。

  • 2.3 Web 服務器與TCP

    • Web服務器是闡述TCP多路復用與多路分解原理的完美例子。
    • 場景：一個Web服務器（IP地址：192.168.1.1）運行著HTTP服務，監聽端口80。

      • 1.?初始化：

        • 服務器啟動，創建一個歡迎套接字，并將其綁定到192.168.1.1:80。這個套接字開始監聽來自任何源地址的連接請求。

      • 2.?客戶端連接：

        • 客戶端A（IP:?10.0.0.2）打開瀏覽器訪問網站。操作系統為瀏覽器分配一個臨時（ephemeral）端口，例如?49152。瀏覽器發起TCP連接到?192.168.1.1:80。

        • 這個連接請求的報文段包含：

          • 源地址：10.0.0.2:49152

          • 目的地址：192.168.1.1:80

        • 服務器端的TCP接收到這個SYN報文段。它檢查目的端口是80，于是知道這個請求是給HTTP服務的。它接受連接，并創建一個新的連接套接字，專門用于和客戶端A?(10.0.0.2:49152)?通信。

      • ???????3.?另一個客戶端同時連接：

        • 幾乎同時，客戶端B（IP:?10.0.0.3）也訪問同一網站。其操作系統分配了另一個臨時端口?49153。它發起連接到?192.168.1.1:80。

        • 這個連接請求的報文段包含：

          • 源地址：10.0.0.3:49153

          • 目的地址：192.168.1.1:80

        • 服務器端TCP再次看到目的端口是80，但它發現源地址?(10.0.0.3:49153)?與之前為客戶端A創建的套接字不同。因此，它會再創建一個新的連接套接字，專門用于和客戶端B通信。

      • ???????4.?多路分解的實現：

        • 現在，服務器上有三個套接字：

          • 套接字 #1：歡迎套接字，監聽?:80。

          • 套接字 #2：連接套接字，關聯四元組?(10.0.0.2:49152, 192.168.1.1:80)。

          • 套接字 #3：連接套接字，關聯四元組?(10.0.0.3:49153, 192.168.1.1:80)。

        • 當后續的數據報文段從網絡到達時，服務器TCP棧會檢查報文段的四元組。

          • 如果是?(10.0.0.2:49152, 192.168.1.1:80)，數據被導向套接字 #2。

          • 如果是?(10.0.0.3:49153, 192.168.1.1:80)，數據被導向套接字 #3。

        • 這樣，兩個客戶端雖然連接到服務器的同一個IP和端口，但它們的數據流被完全隔離，互不干擾。Web服務器可以為每個連接套接字單獨分配資源（如一個線程或進程），從而實現并發處理多個客戶端請求。???????

    • 核心要點：

      • ???????Web服務器通過一個固定的端口號（如80）對外提供服務。

      • 它利用TCP的四元組多路分解機制，為每個客戶端連接創建獨立的通信通道。

      • 客戶端使用的臨時端口號是實現這種并發連接的關鍵，它確保了每個連接的“源IP:源端口”二元組在主機上是唯一的，從而使得四元組在全球范圍內唯一標識一個連接。

      • 這種機制是所有高性能服務器（Web、數據庫、游戲等）能夠同時服務海量客戶端的基石。

• 3. UDP -- 無連接運輸

  • 3.1 UDP 報文段結構

  • 3.2 UDP 檢驗和

• 4. 可靠數據傳輸原理

  • 4.1 構造可靠數據傳輸協議

  • 4.2 流水線可靠數據傳輸協議

  • 4.3 回退N步

  • 4.4 選擇重傳

• 5. TCP -- 面向連接的運輸

  • 5.1 TCP 連接

  • 5.2 TCP 報文段結構

  • 5.3 往返時間的估計與超時

  • 5.4 可靠數據傳輸

  • 5.5 流量控制

  • 5.6 TCP 連接管理

• 6. 擁塞控制原理

  • 6.1 擁塞原因與代價

  • 6.2 擁塞控制方法

• 7. TCP擁塞控制

  • 7.1 公平性

  • 7.2 網絡輔助擁塞控制

• s
• s
• s
• s
• s