2、以太网基础：TCP/IP协议栈简介、UDP与TCP的区别、MAC地址与IP地址、以太网帧结构

做CAN转以太网网关，说白了就是让两个世界对话。CAN那边是现场总线，讲究实时和可靠；以太网这边是IP网络，讲究分层和路由。你得先搞懂以太网这边怎么玩，才能把CAN报文塞进去、再安全送出来。

我个人习惯，不管项目多急，都会先花半天把TCP/IP协议栈理一遍。为什么？因为后面你配置路由、抓包排错，全得靠这点底子。今天咱们就把这四块硬骨头啃下来。

2.1 TCP/IP协议栈简介

TCP/IP不是单个协议，是一整套协议族。它分四层，每层干每层的活。我当年刚入行时，总觉得记这些层没用，直到有一次调试网关，发现CAN数据到了以太网侧就是发不出去。查了两天，最后发现是IP层配置错了。嗯，从那以后我再也不敢跳过协议栈了。

你想想看，CAN转以太网网关，其实就是把CAN的数据帧，从应用层或传输层“塞进”IP包，再从以太网口发出去。反过来也一样。每一层都要做封装和解封装。

下面这张图，是我在项目里经常给团队画的，能帮你快速理解数据在协议栈里怎么“穿衣服”。

2.2 UDP与TCP的区别

这是网关选型最纠结的地方。TCP可靠但慢，UDP快但不可靠。怎么选？我直接说结论：工业实时控制，优先UDP；文件传输或配置下发，用TCP。

我曾经在一个项目里，用TCP传CAN的实时转速数据，结果因为TCP的重传机制，导致数据到了终端已经滞后了200ms。现场电机直接抖起来了。后来换成UDP，配合应用层自己做超时判断，问题就解决了。

对比项	TCP	UDP
连接方式	面向连接（三次握手）	无连接
可靠性	可靠（确认重传）	不可靠（尽力而为）
传输顺序	保证顺序	不保证顺序
传输速度	较慢（有开销）	较快（无开销）
数据边界	流式（无边界）	报文式（有边界）
典型应用	HTTP、FTP、Modbus TCP	DNS、SNMP、NTP、实时CAN转发

2.3 MAC地址与IP地址

这两个地址，很多人搞混。我简单说：MAC是身份证，IP是门牌号。

MAC地址出厂就烧死在网卡里，48位，全球唯一。IP地址是网络管理员分配的，32位（IPv4），可以变。你在公司用192.168.1.x，回家可能就变成192.168.0.x了，但MAC地址还是那个。

在CAN转以太网网关里，这两个地址怎么用？

• MAC地址：用于同一网段内的设备通信。网关收到以太网帧，先看目标MAC是不是自己，不是就丢弃。
• IP地址：用于跨网段路由。网关的核心功能之一，就是根据目标IP地址，决定把数据转发到哪个端口。

我记得有一次在现场，网关死活ping不通。我抓包一看，ARP请求能收到，但网关回的ARP包里MAC地址写错了。原来是代码里把MAC数组的顺序搞反了。这种低级错误，排查起来最费时间。

2.4 以太网帧结构

数据在以太网上跑，不是裸奔的。它得穿一件“以太网帧”的外衣。你抓包时看到的每一行，都是这个结构。

字段	长度（字节）	说明
前导码	7	同步时钟用，抓包时通常不显示
帧起始定界符	1	标识帧开始
目标MAC地址	6	接收方MAC
源MAC地址	6	发送方MAC
类型/长度	2	0x0800=IP，0x0806=ARP
数据	46-1500	IP包（包含TCP/UDP头和应用数据）
帧校验序列（FCS）	4	CRC32校验，检查帧是否损坏

你想想看，CAN的一帧数据最多8字节。以太网一帧最少46字节数据。所以CAN转以太网时，你得把多个CAN帧拼成一个以太网帧，或者用UDP报文一次带多个CAN帧。这就是网关里“CAN报文聚合”功能的由来。