計算機網絡必修課：運輸層瞭解一下！

運輸層

---

【1】運輸層基本概念

用戶應用層的下面就是運輸層了，運輸層是作爲通信部分的最高層，也是用戶功能中的最低層。只有網絡邊緣部分的主機協議棧有運輸層，網絡核心部分的主機一般只用到了下面的三層（物理層、數據鏈路層、網絡層）

在一臺主機中，經常有多個應用進程分別與另一個主機中的多個應用進程通信

運輸層的重要功能： 複用（multiplex）、分用（demultiplex）

（1）複用針對發送方
（2）分用針對接收方

---

【1.1】端口

從上圖中可以看到，進程和TCP、UDP的通信採用端口接軌

從網絡層角度： 通信的雙方是主機
從運輸層的角度： 通信的雙方是主機中進程

端到端的通信是應用進程之間的通信

運輸層作用： 處理進程之間的通信，端口對應着進程

端口：

• 端口號一般是16位
• 端口號具有本地意義，即代表了本地計算機應用層的進程

故兩個計算機之間的通信，不僅要知道對方的IP地址（用來確定主機位置）還要知道對方的端口號（確定進程）

---

【1.2】運輸層和網絡層協議區別

1. IP協議的作用範圍（網絡層）： 提供主機之間的邏輯通信
2. TCP和UDP協議的作用範圍（運輸層）： 提供進程之間端到端的邏輯通信

運輸層的另一個特點就是屏蔽特性：運輸層向高層用戶屏蔽了下面的網絡細節，使得看起來就是進程和進程之間一個簡單的邏輯通信

---

【2】運輸層協議UDP和TCP

• UDP（User Datagram Protocol 用戶數據報協議）
• TCP（Transmission Control Protocol 傳輸控制協議）

當運輸層採用UDP協議時，UDP協議是無連接的，是一條不可靠信道
當運輸層採用TCP協議時，TCP是面向連接的，是一條可靠的全雙工信道

運輸層的運輸單元： 運輸協議數據單元TPDU（Transport Protocol Data Unit）

【2.1】用戶數據報協議UDP

UDP協議只在IP數據報服務上增加很少的功能：

• 複用和分用功能
• 差錯檢測功能

UDP協議的特點：

• 提供無連接服務，在傳輸數據前不需要提前建立連接
• 傳送的數據單元是UDP報文/用戶數據報
• 接收方收到UDP報文後，不用任何確認
• UDP支持所有的廣播/多播方式，一對一、一對多、多對一、多對多
• UDP的首部8字節（TCP首部20字節），UDP開銷更小

UDP用戶數據報在運輸層之間的端到端邏輯信道中傳輸，UDP將應用層傳下來的數據原封不動的轉發（不合並不拆分），一次發送一個報文

用戶數據報UDP有2個字段：

• 數據字段
• 首部字段（8字節）

UDP的通信雖然要用到端口號（對應進程），但由於UDP是無連接的，因此不需要套接字

UDP是面向報文的

【2.2】傳輸控制協議TCP

TCP是面向字節流的

• “流”stream：流入流出進程的字節序列
• 面向字節流：進程和TCP之間的傳輸是數據塊，但TCP僅僅將數據看成一連串無結構的字節流
• 接收方收到的字節流要與發送方一致
  

TCP不關心應用進程一次向TCP緩存寫入了多長的報文，TCP都會將連續的字節流進行分段，形成TCP報文段

TCP特點：

• 提供面向連接的服務
• 傳送數據單元是TCP報文段
• TCP不提供廣播或多播服務
• 開銷較大，因爲要提供可靠傳輸，首部字段增大，佔據更多處理機資源

TCP報文段是在運輸層抽象的端到端邏輯信道中傳輸的，是可靠的全雙工通信。不過在數據傳輸過程中，並不知道到底經過了多少個路由器，而且這些路由器也不知道運輸層是都建立了TCP 連接

注意：

• TCP連接是一條虛連接，不是實際的物理連接
• TCP不關心進程向TCP緩存寫入了多長的報文
• TCP自主根據網絡狀況，決定將報文拆分成多大的報文段（UDP報文段是由進程直接給出的）

---

【2.2.1】TCP套接字的概念

運輸層是進程間的通信，進程通過端口號對應。在UDP協議中進程對應端口號，在TCP協議中進程對應的是套接字（socket）

套接字： 端口號拼接到IP地址就是套接字（兩者的結合）

socket = （IP地址： 端口號）

運輸層的TCP協議是面向連接的，這條鏈接是虛連接，連接的兩個端點就是套接字

TCP鏈接 = { socket1, socket2} = {(IP1, port1), (IP2, port2)}

---

【2.2.2】TCP報文段的首部

TCP是面向字節流的，但TCP傳送的數據單元是報文段

TCP報文段的首部的前20個字節是固定的，後面的4n個字節是可變的

（TCP報文段的首部大小 >= 20字節）

---

【3】TCP可靠傳輸的原理

理想的傳輸條件：

• 傳輸信道不產生差錯
• 不管發送方以多快的速度傳送數據，接收方總是來得及處理接收到的數據

現實中的網絡信道都是無法滿足這些條件，故爲了達到可靠傳輸，需要使用一些可靠傳輸協議，在不可靠的信道中實現可靠傳輸

TCP有兩種實現可靠傳輸的協議：

• 停止等待協議
• 連續ARQ協議

---

【3.1】停止等待協議

停止等待協議： 每發送完一個分組就停止發送，等待接收方的確認（ACK），在收到對方確認後再發送下一個分組

ACK：Acknowledgement character 確認字符

接收方收到的分組會出現兩種情況： 有差錯和無差錯

例：“A發送分組group1給B，發送完暫停等待B的確認應答”

接收端B在確認數據的過程中會出現2中情況：

1. 分組出錯：B接收到的group1出錯，則會自動放棄group1，不會通知A
2. 分組丟失：group1傳輸過程中丟失了，此刻B什麼也不知道，什麼也不做

（不論哪種情況，出錯後，接收端什麼也不會做）

---

【3.2】連續ARQ協議

【3.2.1】自動重傳請求ARQ

停止等待協議的問題——分組出錯後接收端什麼也不會做，這樣會造成很多問題，故引入自動重傳請求ARQ 來解決這個問題

ARQ（Automatic Repeat Request 自動重傳請求）：在發送端會設置一個超時計時器

• 在設定時間內收到了ACK確認應答則繼續發送下一個分組
• 若時間內沒有收到則重發分組（超時重發）
  

注意：

• 發送端在停止等待時，要暫時保存已發送的分組副本，以備超時重發
• 分組和確認分組都要進行編號
• 超時計時器的設定時間要大於數據往返的平均時間

自動重傳請求ARQ是自動進行的，接收方不需要告訴發送方“你要重傳”

---

【3.2.2】流水線傳輸

停止等待協議的傳輸效率較低，信道利用率也較低

流水線傳輸就是發送方可連續發送多個分組，不用每發送完一個分組就停下來等待對方確認，這樣信道上就不斷的有數據傳輸，提高傳輸效率和信道利用率

---

【3.2.3】連續ARQ協議

自動重傳請求ARQ解決了停止等待協議的問題，但是傳輸的效率依然較低，依然要等待很長時間才能完成傳輸

連續ARQ： 發送方設置一個發送窗口，且位於發送窗口內的分組都可以連續發送，不需要等待確認應答，每確認一個分組則發送窗口下移一位發送。若中間分組出錯，則窗口內後面的分組會跟着重傳一次。

例：“本來連續發送了5個分組，結果第2個分組丟失，故窗口僅僅移動了兩位，2、3、4、5號分組還會重傳一次”

連續ARQ協議的關鍵點在於那個發送窗口，類似於排隊的隊列，確認一個則從後面再安排一個進入窗口，以此提高效率的同時完成可靠傳輸

---

【3.3】可靠傳輸總結

• 可靠傳輸的本質： 確認應答 + 分組出錯會重傳
• 停止等待協議： 會確認應答確保發送分組送到了，但是出錯沒有反饋
• 自動重傳請求ARQ： 設置超時計時器，解決了重傳問題，但效率較低
• 連續ARQ： 利用發送窗口，解決了效率問題

---

【4】常用的熟知端口

---

【5】TCP擁塞控制

網絡出現擁塞的原因：對資源的需求 > 可用資源（發送到網絡上的數據太多了）

當擁塞很嚴重的時候，就變成了進程死鎖。同時，不能通過增大資源解決擁塞問題，反而會影響網絡性能。
擁塞引起的重傳不會緩解網絡的擁塞，返回會加劇擁塞程度，會導致更多的分組流入網絡被路由器丟棄

解決擁塞的核心點： 減少數據流入網絡——控制數據流入

擁塞控制的作用：

• 提高資源利用率
• 避免發生死鎖（吞吐量=0）
  

---

【5.1】流量控制和擁塞控制

擁塞控制：

• 擁塞控制是一個全局性的過程，涉及到所有的主機、所有的路由器、以及與網絡傳輸性能有關的所有因素
• 擁塞控制就是防止過多的數據流入到網絡中，使網絡中的路由器/鏈路不過載

流量控制：

• 流量控制是一個端到端的問題， 接收端和發送端之間的問題
• 流量控制就是發送端控制發送的速率，以便接收端可以來得及接收

---

【5.2】TCP擁塞控制方式

開環控制方法：設計網絡之初就做好放擁塞設計
閉環控制方法（TCP採用）： 是基於反饋環路的概念

1. 監測網絡系統，以便檢測到擁塞在何時何地
2. 將擁塞信息發送到可以處理的地方
3. 調整網絡運行以解決發生的問題

TCP採用基於窗口的方式進行擁塞控制（閉環控制方法）

（1）只要網絡無擁塞，就將擁塞窗口增大一些，以便把更多的分組發送出去
（2）只要網絡出現擁塞，就將窗口減小，減少注入到網絡中的分組數量

基於窗口的擁塞控制方法與連續ARQ協議不謀而合

擁塞判斷：

1. 重傳定時器超時
2. 收到三個相同/重複的分組

TCP擁塞控制算法：

• 慢開始（slow start）
• 擁塞避免（congestion avoidance）
• 快重傳（fast retransmit）
• 快恢復（fast recovery）

---

【6】TCP三次握手

TCP利用套接字建立連接的過程叫做握手
TCP的握手需要在客戶端和服務器端交換三個TCP報文段——“三報文握手”

三次握手的目的： 防止已失效的連接請求報文段突然又傳送到了，進而產生錯誤（建立可靠連接）

TCP三次握手過程：

1. 客戶端A的TCP向服務器B的TCP發出連接請求報文段，其首部中的同步位SYN=1，並選擇序號seq=x（表明傳送數據的第一個數據字節序號）
2. 服務器B的TCP收到請求報文段，若同意，則響應確認報文段：SYN=1，ACK=1，確認號ack=x+1，自選序號seq=y
3. 客戶端A收到確認報文段後再向服務器B確認：ACK=1，確認號ack=y+1，同時客戶端A通知上層應用連接已建立。

三次握手，說白了，就是多了一次再確認過程，客戶端向服務器確認一下它的響應是不是這個

---

微信公衆號：<小楊的python之路>