文章目錄
- 傳輸層協議概述
- 為什么需要傳輸層?
- 傳輸層功能
- 網絡層與傳輸層在實現 “端到端” 傳輸的異同
- 兩類服務:面向連接/無連接服務
- 傳輸控制協議 TCP
- TCP 協議數據單元格式
- TCP 的重傳機制
- 快重傳和快恢復
- 快重傳舉例
- 快恢復算法
- 用戶數據報協議 UDP
- UDP 概述
- UDP 基本工作過程
- UDP 用戶數據報的首部(Head)格式
- TCP 與 UDP 的比較
傳輸層協議概述
為什么需要傳輸層?
- OSI網絡層是通過 “逐節點”(Hop-by-Hop)實現源主機到目的主機間網絡協議數據單元(Internet 中的 IP)的 “端到端” 傳輸的。即使網絡層在節點間提供服務確認,仍不能保障 “端到端” 可靠傳輸(如果中間節點對收到的數據確認后,在前傳前出現節點故障)。
- 網絡層地址僅能標識網絡設備或端系統的網絡端口,不能作為標識系統內部的多個應用進程(用戶平臺的應用進程或信控管理平臺的特殊應用進程)的標識符,因此需要應用進程傳輸層標識符(TSAP);在 Internet 中稱為 “端口號”。
傳輸層功能
- 連接管理
- 流量控制
- 差錯檢測
- 對用戶請求的響應
- 建立無連接或面向連接的通信
— 面向連接:會話建立、數據傳輸、會話拆除
— 無連接:不保證數據的有序到達
網絡層與傳輸層在實現 “端到端” 傳輸的異同
- 網絡層(主機間):通過通信子網中中繼系統逐級轉發實現的 “源”、“目的” 主機間物理上的 “端到端” 的用戶數據的傳輸。但網絡層協議通常只定義節點間的轉發過程,因此網絡層協議執行過程不是 “端到端” 直接通信,而是 “逐級”(Hop-by-Hop)轉發實現的物理上的端到端通信。
- 傳輸層(應用進程間):由于用戶數據在通信子網的用戶數據平臺上沒有傳輸層實體,因此,應用進程利用傳輸層實現進程間的傳輸只是概念上/邏輯上的 “端到端” 的 “直接傳輸”。物理上仍然利用網絡層逐級實現的端到端服務。
兩類服務:面向連接/無連接服務
- 提供面向連接服務的協議:TCP (Transmission Control Protocol) - RFC 973
- 提供無連接服務的協議:UDP (UserDatagram Protocol) - RFC 768
傳輸控制協議 TCP
客戶(主動請求) / 服務器(被動響應)工作模式:
建立連接:通過三次握手方式建立連接。
數據傳輸
- 基本數據傳輸:能連續、雙向傳輸字節流。
- 提供敦促接收方迅速將收到的數據提交應用進程的功能(PUSH)。
- 可靠性:數據損壞、丟失、重復和錯序必須能恢復(機制:以字節為基礎的序號、正確接收確認(ACK)、重傳時鐘、檢錯)。
- 流量控制:窗口可變的 “滑動窗口” 流控方式,窗口大小以 “字節” 為基礎。
連接拆除
請求拆除、兩次拆除確認等待、請求方在確認的方式。
TCP 協議數據單元格式
源端口和目的端口字段
各占 2 字節。端口是傳輸層與應用層的服務接口。傳輸層的復用和分用功能都要通過端口才能實現。
序號字段
占 4 字節。TCP 連接中傳輸的數據流中的每一個字節都編上一個序號。序號字段的值則指的是本報文段所發送的數據的第一個字節的序號。
確認號字段
占 4 字節,是期望收到對方的下一個報文段的數據的第一個字節的序號。
數據偏移
占 4 bit,它指出 TCP 報文段的數據起始處距離 TCP 報文段的起始處有多遠。“數據偏移” 的單位不是字節而是 32 bit 字(4 字節為計算單位)。
保留字段
占 6 bit,保留為今后使用,但目前應置為 0。
緊急比特 URG
當 URG = 1 時,表明緊急指針字段有效。它告訴系統此報文段中有緊急數據,應盡快傳輸(相當于高優先級的數據)。
確認比特 ACK
只有當 ACK = 1 時確認號字段才有效。當 ACK = 0 時,確認號無效。
推送比特 PSH(PuSH)
接收 TCP 收到推送比特置 1 的報文段,就盡快地交付給接收應用進程,而不再等到整個緩存都填滿了后再向上交付。
復位比特 RST(ReSeT)
當 RST = 1 時,表明 TCP 連接中出現嚴重差錯(如由于主機崩潰或其他原因),必須釋放連接,然后再重新建立傳輸連接。
同步比特 SYN
同步比特 SYN 置為 1,就表示這是一個連接請求或連接接受報文。
終止比特 FIN(FINal)
用來釋放一個連接。當 FIN = 1 時,表明此報文段的發送端的數據已發送完畢,并要求釋放傳輸連接。
窗口字段
占 2 字節。窗口字段用來控制對方發送的數據量,單位為字節。TCP 連接的一端根據設置的緩存空間大小確定自己的接收窗口大小,然后通知對方以確定對方的發送窗口的上限。
檢驗和
占 2 字節。檢驗和字段檢驗的范圍包括首部和數據這兩部分。在計算檢驗和時,要在 TCP 報文段的前面加上 12 字節的偽首部。
緊急指針字段
占 16 bit。緊急指針指出:在本報文段中緊急數據共有多少個字節(緊急數據放在本報文段數據的最前面)。
選項字段
長度可變。TCP 只規定了一種選項,即最大報文段長度 MSS(Maximum Segment Size)。MSS 告訴對方 TCP:“我的緩存所能接收的報文段的數據字段的最大長度是 MSS 個字節”。MSS 是 TCP 報文段中的數據字段的最大長度。數據字段加上 TCP 首部才等于整個的 TCP 報文段。
填充字段
這是為了使整個首部長度是 4 字節的整數倍。
TCP 的重傳機制
重傳機制是 TCP 中最重要和最復雜的問題之一。
TCP 每發送一個報文段,就對這個報文段設置一次計時器。只要計時器設置的重傳時間到但還沒有收到確認,就要重傳這一報文段。
快重傳和快恢復
快重傳算法規定,發送端只要一連收到三個重復的 ACK 即可斷定有分組丟失了,就應立即重傳丟失的報文段而不必繼續等待為該報文段設置的重傳計時器的超時。
不難看出,快重傳并非取消重傳計時器,而是在某些情況下可更早地重傳丟失的報文段。
快重傳舉例
快恢復算法
- 當發送端收到連續三個重復的 ACK 時,就重新設置慢開始門限 ssthresh。
- 與慢開始不同之處是擁塞窗口 cwnd 不是設置為 1,而是設置為 ssthresh + 3 x MSS。
- 若收到的重復的 ACK 為 n 個(n>3),則將 cwnd 設置為 ssthresh + n x MSS。
- 若發送窗口值還容許發送報文段,就按擁塞避免算法繼續發送報文段。
- 若收到了確認新的報文段的 ACK,就將 cwnd 縮小到 ssthresh。
用戶數據報協議 UDP
UDP 概述
UDP 只在 IP 的數據報服務之上增加了很少一點的功能,即端口的功能和差錯檢測的功能。
雖然 UDP 用戶數據報只能提供不可靠的交付,但 UDP 在某些方面有其特殊的優點。
- 發送數據之前不需要建立連接。
- UDP 的主機不需要維持復雜的連接狀態表。
- UDP 用戶數據報只有 8 個字節的首部開銷。
- 網絡出現的擁塞不會使源主機的發送速率降低。這對某些實時應用是很重要的。
UDP 基本工作過程
UDP 數據報的發送和接收通過 UDP 端口實現
端口是一個可讀寫的結構,具有內部的報文緩沖區;
數據報發送
UDP 軟件將用戶數據封裝在 UDP 數據報中;
轉交給 IP 軟件,進行 IP 封裝和轉發;
數據報的接收
IP 層接收到 UDP 數據報, 提交給 UDP 軟件的各端口;
端口判斷該報文的目的端口號是否與當前端口匹配;
若匹配成功,將該數據報保存到相應端口的接收隊列中;(若隊列已滿,則丟棄該數據報)
若未匹配,則丟棄該數據報,同時向源端發送 “端口不可達” 的 ICMP 包。
UDP 用戶數據報的首部(Head)格式
TCP 與 UDP 的比較
- TCP 提供可靠的,面向連接的傳輸服務
- UDP 提供不可靠的,無連接的傳輸服務
- TCP 是面向流的協議;UDP 是基于數據報的協議
- TCP 適用于一次傳送大批量的數據
- UDP 適用于多次少量數據的傳輸,實時性要求高的業務
- 使用 TCP 傳輸的應用程序和協議包括:
FTP
Telnet
ΗΤΤΡ - 使用 UDP 傳輸的應用程序和協議包括:
RIP
TFTP
SNMP