車載以太網網絡測試-16【傳輸層-UDP】

1 摘要

車載以太網的第五層是傳輸層，它在車載網絡架構中扮演著至關重要的角色。主要分為TCP協議和UDP協議，這倆協議在汽車網絡通信應用十分廣泛。因此，熟練掌握這倆協議是車載網絡測試工程師的必備技能，本文主要先對DUP協議進行詳細介紹。

2 車載以太網傳輸層概述

背景：
隨著汽車智能化、網聯化和電動化的快速發展，傳統的車載網絡（如CAN、LIN、FlexRay等）在帶寬、延遲和擴展性方面逐漸無法滿足需求。車載以太網作為一種高帶寬、低延遲、高可靠性的通信技術，逐漸成為車載網絡的主流選擇。
車載以太網基于OSI（開放系統互聯）模型，其中傳輸層（第五層）負責在通信的源端和目標端之間提供可靠的數據傳輸服務。

作用：
傳輸層的主要作用是為車載網絡中的應用程序提供端到端的數據傳輸服務，具體包括以下幾個方面：

可靠數據傳輸
確保數據在源端和目標端之間可靠傳輸，避免數據丟失或損壞。
流量控制
根據接收端的處理能力，動態調整數據傳輸速率，防止網絡擁塞。
錯誤檢測與恢復
通過校驗和、重傳機制等技術，檢測并糾正數據傳輸中的錯誤。
多路復用與分用
支持多個應用程序同時使用網絡資源，并通過端口號區分不同的應用服務。
連接管理
在通信雙方之間建立、維護和終止連接。

協議：
在車載以太網中，傳輸層主要使用以下兩種協議：

TCP（傳輸控制協議）
- 特點：面向連接、可靠傳輸、支持流量控制和錯誤恢復。
- 適用場景：適用于對數據可靠性要求高的應用，如OTA（空中升級）、車載診斷、高精度地圖更新等。
- 優點：保證數據的完整性和順序性。
- 缺點：由于復雜的控制機制，延遲較高，不適合實時性要求極高的場景。
UDP（用戶數據報協議）
- 特點：無連接、不可靠傳輸、低延遲。
- 適用場景：適用于對實時性要求高但允許少量數據丟失的應用，如車載音視頻傳輸、傳感器數據采集等。
- 優點：傳輸效率高，延遲低。
- 缺點：不保證數據的可靠性和順序性。

以下是車載以太網傳輸層的TCP協議和UDP協議的比對表格：

特性	TCP協議	UDP協議
全稱	傳輸控制協議 (Transmission Control Protocol)	用戶數據報協議 (User Datagram Protocol)
連接方式	面向連接 (Connection-oriented)	無連接 (Connectionless)
可靠性	高可靠性，提供數據確認、重傳機制	不可靠，不保證數據到達或順序
數據順序	保證數據順序	不保證數據順序
速度	較慢，由于確認和重傳機制	較快，無確認和重傳機制
開銷	較高，包含頭部信息和確認機制	較低，頭部信息簡單
適用場景	需要高可靠性的應用，如文件傳輸、電子郵件	實時性要求高的應用，如視頻流、在線游戲
擁塞控制	有擁塞控制機制	無擁塞控制機制
錯誤檢測	提供錯誤檢測和糾正	僅提供錯誤檢測
數據流控制	提供數據流控制	不提供數據流控制
報文結構	復雜，包含序列號、確認號等	簡單，僅包含源端口、目的端口等
應用層協議示例	HTTP, FTP, SMTP	DNS, DHCP, SNMP

TCP協議 適用于需要高可靠性和數據完整性的場景，如車載系統中的關鍵數據傳輸。
UDP協議 適用于對實時性要求較高的場景，如車載娛樂系統中的音視頻流傳輸。

選擇使用哪種協議應根據具體的應用需求和網絡環境來決定。

3 車載以太網UDP協議

UDP（User Datagram Protocol，用戶數據報協議）是TCP/IP協議族中的一種無連接傳輸層協議。與TCP相比，UDP具有傳輸效率高、延遲低的特點，因此在實時性要求較高的場景中得到了廣泛應用。在車載以太網中，UDP協議被用于滿足某些特定應用的需求。

3.1 車載以太網UDP協議的作用

高實時性傳輸
- UDP協議不需要建立連接，也沒有復雜的確認和重傳機制，因此數據傳輸的延遲較低。在車載環境中，某些應用（如傳感器數據傳輸、視頻流傳輸等）對實時性要求較高，UDP協議能夠滿足這些需求。
低開銷
- UDP協議的頭部開銷較小（僅8字節），適合傳輸小數據包或需要高效傳輸的場景。在車載網絡中，資源有限，UDP的低開銷特性有助于提高網絡效率。
支持廣播和多播
- UDP支持廣播和多播傳輸，適用于車載環境中需要將數據同時發送給多個節點的場景，例如車載娛樂系統的音頻/視頻流分發。
適用于非關鍵性數據傳輸
- 對于不需要高可靠性的應用（如某些傳感器數據或診斷信息），UDP協議可以提供高效的傳輸方式，而不需要像TCP那樣保證數據的完整性和順序。
與車載以太網協議棧的兼容性
- 車載以太網通常采用基于IP的通信架構，UDP作為IP協議棧的一部分，能夠與其他協議（如SOME/IP、DoIP等）無縫集成，滿足車載系統的多樣化需求。
支持新興應用
- 在智能駕駛和車聯網中，UDP協議可以用于傳輸高帶寬數據（如攝像頭、雷達、激光雷達等傳感器的原始數據），同時滿足低延遲的要求。

3.2 UDP報文幀結構

車載以太網UDP報文幀通常由以下幾個部分組成：

以太網幀頭（Ethernet Header）：
- 目的MAC地址（Destination MAC Address）：6字節，表示數據幀的目的地。
- 源MAC地址（Source MAC Address）：6字節，表示數據幀的發送方。
- 以太網類型（EtherType）：2字節，表示上層協議類型，例如IPv4（0x0800）。
IP頭（IP Header）：
- 版本（Version）：4位，表示IP版本，IPv4為4。
- 頭長度（IHL）：4位，表示IP頭的長度（以32位字為單位）。
- 服務類型（Type of Service, ToS）：1字節，表示服務質量（QoS）。
- 總長度（Total Length）：2字節，表示整個IP數據報的長度。
- 標識（Identification）：2字節，用于分片和重組。
- 標志（Flags）：3位，用于分片控制。
- 片偏移（Fragment Offset）：13位，表示分片的位置。
- 生存時間（Time to Live, TTL）：1字節，表示數據報的最大生存時間。
- 協議（Protocol）：1字節，表示上層協議類型，UDP為17。
- 頭校驗和（Header Checksum）：2字節，用于校驗IP頭的完整性。
- 源IP地址（Source IP Address）：4字節，表示發送方的IP地址。
- 目的IP地址（Destination IP Address）：4字節，表示接收方的IP地址。
UDP頭（UDP Header）：
- 源端口（Source Port）：2字節，表示發送方的端口號。
- 目的端口（Destination Port）：2字節，表示接收方的端口號。
- 長度（Length）：2字節，表示UDP數據報的總長度（包括UDP頭和UDP數據）。
- 校驗和（Checksum）：2字節，用于校驗UDP數據的完整性。
UDP數據（UDP Data）：
- 數據（Data）：可變長度，表示UDP數據報的有效載荷。
以太網幀尾（Ethernet Trailer）：
- 幀校驗序列（Frame Check Sequence, FCS）：4字節，用于校驗整個以太網幀的完整性。

UDP頭（UDP Header）：
車載以太網中的UDP（用戶數據報協議）頭部與標準以太網中的UDP頭部結構相同，通常由4個字段組成，每個字段占2個字節（16位）。以下是UDP頭部的字段及其作用的表格展示：

字段名稱	大小（字節）	描述
源端口號	2	發送方的端口號，用于標識發送數據的應用程序。
目的端口號	2	接收方的端口號，用于標識接收數據的應用程序。
長度	2	UDP數據報的總長度（包括頭部和數據部分），以字節為單位。
校驗和	2	用于檢測UDP數據報在傳輸過程中是否發生錯誤。如果為0，則表示不校驗。

詳細說明：

源端口號（Source Port）：
- 標識發送UDP數據報的應用程序的端口號。
- 在接收方回復時，可以用來確定回復的目的地。
目的端口號（Destination Port）：
- 標識接收UDP數據報的應用程序的端口號。
- 接收方根據此字段將數據傳遞給相應的應用程序。
長度（Length）：
- 表示整個UDP數據報的長度，包括頭部和數據部分。
- 最小值為8字節（僅頭部），最大值為65535字節。
校驗和（Checksum）：
- 用于驗證UDP數據報在傳輸過程中是否發生了錯誤。
- 校驗和的計算包括UDP頭部、數據部分以及偽頭部（偽頭部包含IP地址等信息）。
- 如果校驗和為0，表示發送方未計算校驗和（在某些情況下允許）。

實例示例：

假設我們有一個車載以太網UDP報文，其內容如下：

目的MAC地址：00:1A:2B:3C:4D:5E
源MAC地址：00:1A:2B:3C:4D:5F
以太網類型：IPv4（0x0800）
源IP地址：192.168.1.100
目的IP地址：192.168.1.200
源端口：5000
目的端口：6000
UDP數據：Hello, Car Ethernet!

以太網幀頭：

目的MAC地址：00 1A 2B 3C 4D 5E
源MAC地址：00 1A 2B 3C 4D 5F
以太網類型：08 00

IP頭：

版本和頭長度：45
服務類型：00
總長度：00 29
標識：00 00
標志和片偏移：00 00
生存時間：40
協議：11（UDP）
頭校驗和：00 00
源IP地址：C0 A8 01 64
目的IP地址：C0 A8 01 C8

UDP頭：

源端口：13 88
目的端口：17 70
長度：00 15
校驗和：00 00

4.UDP數據：

數據：48 65 6C 6C 6F 2C 20 43 61 72 20 45 74 68 65 72 6E 65 74 21

以太網幀尾：

幀校驗序列：00 00 00 00（假設為0）

完整UDP報文幀示例：

00 1A 2B 3C 4D 5E 00 1A 2B 3C 4D 5F 08 00 45 00
00 29 00 00 00 00 40 11 00 00 C0 A8 01 64 C0 A8
01 C8 13 88 17 70 00 15 00 00 48 65 6C 6C 6F 2C
20 43 61 72 20 45 74 68 65 72 6E 65 74 21 00 00
00 00

3.3 UDP協議的通信過程

3.3.1 通信過程

數據封裝：

應用層數據生成：
- 應用層（如ADAS、信息娛樂系統等）生成需要傳輸的數據。
UDP封裝：
- 數據被傳遞到傳輸層，UDP協議將數據封裝為UDP數據報。
- UDP數據報包括以下字段：
  - 源端口號（2字節）：發送方的端口號。
  - 目的端口號（2字節）：接收方的端口號。
  - 長度（2字節）：UDP數據報的總長度（包括頭部和數據）。
  - 校驗和（2字節）：用于檢測數據傳輸中的錯誤（可選）。
IP封裝：
- UDP數據報被傳遞到網絡層，封裝為IP數據包。
- IP數據包包括源IP地址和目的IP地址。

數據傳輸：

發送方：
- 發送方將封裝好的IP數據包通過物理層（如以太網）發送到網絡中。
- 由于UDP是無連接的，發送方不需要與接收方建立連接。
網絡傳輸：
- 數據包通過車載以太網交換機或路由器進行轉發。
- 網絡設備根據IP地址和路由表將數據包傳遞到目標設備。
接收方：
- 接收方的網絡層接收IP數據包，解封裝后提取UDP數據報。
- 接收方的傳輸層根據目的端口號將數據傳遞到相應的應用程序。

數據接收：

應用層處理：
- 接收方的應用層處理接收到的數據。
- 由于UDP不保證可靠性，接收方可能需要檢測數據是否完整或有序。
錯誤處理：
- 如果數據包丟失或損壞，UDP不會自動重傳，需要由應用層處理。

3.3.2 實例示例

假設我們有一個車載系統，其中包含一個音頻播放器和一個音頻接收器。音頻播放器通過UDP協議將音頻數據發送到音頻接收器。

音頻播放器（發送端）

應用層：音頻播放器生成音頻數據。
傳輸層：音頻數據被封裝成UDP數據報，源端口號為5000，目的端口號為6000。
網絡層：UDP數據報被封裝成IP數據包，源IP地址為192.168.1.100，目的IP地址為192.168.1.200。
數據鏈路層：IP數據包被封裝成以太網幀，源MAC地址為00:11:22:33:44:55，目的MAC地址為00:11:22:33:44:66。
物理層：以太網幀通過車載以太網傳輸到音頻接收器。

音頻接收器（接收端）

物理層：音頻接收器接收到以太網幀。
數據鏈路層：以太網幀被解封裝，提取出IP數據包。
網絡層：IP數據包被解封裝，提取出UDP數據報。
傳輸層：UDP數據報被解封裝，提取出音頻數據。
應用層：音頻數據被傳遞給音頻接收器的應用層進行播放。

3.3.3 代碼示例

以下是一個簡單的Python代碼示例，模擬UDP協議的通信過程。

發送端（音頻播放器）

import socket# 創建UDP套接字
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)# 目標地址和端口
target_ip = '192.168.1.200'
target_port = 6000# 音頻數據
audio_data = b'This is a sample audio data'# 發送數據
sock.sendto(audio_data, (target_ip, target_port))# 關閉套接字
sock.close()

接收端（音頻接收器）

import socket# 創建UDP套接字
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)# 綁定地址和端口
sock.bind(('192.168.1.200', 6000))# 接收數據
data, addr = sock.recvfrom(1024)  # 1024是緩沖區大小
print(f"Received audio data: {data} from {addr}")# 關閉套接字
sock.close()