以太网数据报文各协议字段深度解析（第一、二章）

以太网数据报文各协议字段深度解析（第一、二章）

第一章 以太网数据报文：从“是什么”到“怎么传”的基础认知

咱们先从最基础的“以太网是什么”聊起——你每天用电脑连WiFi、插网线上网，背后跑的基本都是以太网。它不是凭空出现的，而是经历了几十年的迭代，才成了现在局域网里的“绝对主角”。

1.1 以太网的“前世今生”：为什么它能淘汰其他技术？

早在上世纪70年代，计算机之间的“沟通”还很混乱：不同厂家的设备用不同的连接方式，就像说不同语言的人没法聊天。1973年，施乐公司PARC实验室的工程师罗伯特·梅特卡夫，画了一张关于“多台计算机共享传输线路”的草图，这就是以太网的雏形。

当时他给这个技术起名为“Ethernet”，灵感来自“以太（Ether）”——19世纪科学家认为光传播需要的介质，梅特卡夫觉得自己的技术就像“让数据在‘以太’里流动”。1983年，施乐、英特尔、DEC三家公司联合推出了第一个商用以太网标准（10Mbps），这一年也被称为“以太网元年”。

后来IEEE（国际电气与电子工程师协会）接手制定了更统一的标准，也就是我们常说的IEEE 802.3。接下来的几十年里，以太网一路“升级打怪”：1995年百兆以太网（100Mbps）普及，2002年千兆以太网（1Gbps）走进企业，2010年10G以太网开始用于数据中心，现在400G、800G以太网已经成了高端网络的“标配”。

为什么以太网能淘汰令牌环（Token Ring）、FDDI这些竞争对手？核心就三个：便宜、好扩展、兼容性强。比如令牌环需要专门的设备管理“令牌”（只有拿到令牌才能发数据），成本高；而以太网只要一根网线、一个交换机，随便加电脑都能连，小企业也用得起。

用一张时间轴图，咱们更直观地看它的发展：

1.2 以太网数据报文的“家族体系”：协议栈就像快递系统

咱们平时说的“以太网数据报文”，其实不是一个“单一文件”，而是像快递包裹一样——从“客户寄件”到“快递员送货”，要经过好几层“打包”，每一层都有自己的规则。这个“打包规则体系”就是TCP/IP协议栈。

我拿快递系统类比，你一下子就能懂：

• 应用层：比如你要寄的“手机”（对应HTTP请求、DNS查询这些应用数据），是最核心的“内容”；
• 传输层：给手机套上“快递袋”，写上“收件人电话”（对应TCP/UDP的端口号，比如Web服务器用80端口）；
• 网络层：把快递袋放进“纸箱”，写上“收件人地址”（对应IP地址，比如百度服务器IP 180.101.49.11）；
• 数据链路层：给纸箱贴“快递面单”，写上“收发件人快递点编号”（对应MAC地址，比如你家路由器的MAC）；
• 物理层：把纸箱变成“运输车能运的信号”（对应网线里的电信号、光纤里的光信号）。

每层的“打包产物”有不同的名字，咱们整理成表格更清楚：

TCP/IP协议层	对应OSI层	核心协议	数据单元名称	类比（快递系统）	关键作用
应用层	7层	HTTP、FTP、DNS	数据（Data）	客户要寄的物品（手机、文件）	定义“传什么”（比如网页内容）
传输层	4层	TCP、UDP	段（Segment）/ datagram	套快递袋（写收件人电话）	确保“传给对的应用”（端口号）
网络层	3层	IP、ICMP、ARP	数据包（Packet）	装纸箱（写收件人地址）	确保“传到对的电脑”（IP地址）
数据链路层	2层	以太网（802.3）	帧（Frame）	贴快递面单（写快递点编号）	确保“传到对的设备”（MAC地址）
物理层	1层	以太网物理层	比特流（Bit）	转成运输车能运的信号	确保“信号能传出去”（电/光信号）

那这些层是怎么“协作打包”的？咱们用一张图展示从应用层“数据”到物理层“比特流”的过程——每一层都给上层的“产物”加个“头部”（就像快递每层加包装），到了接收端再反向“拆包”：

1.3 一个完整的“旅程”：访问百度时报文的一生

光说理论太抽象，咱们拿“你用电脑访问www.baidu.com”这个场景，拆解报文从“出发”到“回家”的全流程——就像跟踪一个快递从你家寄到百度服务器，再寄回来的过程。

第一步：应用层“生成需求”

你在浏览器里输入“www.baidu.com”，点击回车——浏览器马上生成一个“HTTP请求”，内容大概是“请把百度首页的HTML代码发给我”，这就是应用层的“原始数据”。

第二步：传输层“加快递袋”（TCP封装）

因为网页访问需要“可靠传输”（不能丢包，不然首页会缺一块），所以用TCP协议。TCP会给HTTP数据加一个“头部”，里面包含：

• 源端口：你电脑上浏览器的随机端口，比如12345（相当于你家的电话，方便百度回电）；
• 目的端口：百度Web服务器的80端口（相当于百度的“客服电话”，专门接网页请求）；
• 序号：比如12345（相当于给数据编上号，方便百度按顺序拼接）。

这样一来，HTTP数据就变成了“TCP段”。

第三步：网络层“装纸箱”（IP封装）

接下来IP协议上场，给TCP段加“IP头部”，里面关键信息是：

• 源IP地址：你电脑的IP，比如192.168.1.100（相当于你家的地址）；
• 目的IP地址：百度服务器的IP，比如180.101.49.11（相当于百度公司的地址）；
• TTL：128（相当于“快递有效期”，每经过一个路由器减1，防止快递在网上“迷路”）。

现在，TCP段变成了“IP数据包”。

第四步：数据链路层“贴面单”（以太网帧封装）

你的电脑在局域网里，要先把数据包发给路由器（网关），所以需要MAC地址（相当于路由器的“快递点编号”）。以太网会给IP数据包加“头部”和“尾部”：

• 源MAC地址：你电脑网卡的MAC，比如00-AA-BB-CC-DD-EE（相当于你家楼下快递点的编号）；
• 目的MAC地址：路由器的MAC，比如00-11-22-33-44-55（相当于区域快递中心的编号）；
• FCS：4字节的校验码（相当于快递单上的“防伪码”，防止数据损坏）。

此时，IP数据包变成了“以太网帧”——这是能在网线里传输的“最终形态”。

第五步：物理层“发出去”（比特流传输）

你的电脑网卡把以太网帧转换成“电信号”，通过网线传到路由器。路由器收到后，会拆到IP层，看目的IP是180.101.49.11，然后查路由表，把数据包转发给下一个路由器，一路传到百度服务器。

第六步：接收端“拆包”+“回复”

百度服务器收到比特流后，反向解封装：先转成以太网帧（验FCS）→拆出IP数据包（查目的IP）→拆出TCP段（查目的端口80）→拆出HTTP请求（交给Web服务器处理）。

Web服务器处理后，生成“HTTP响应”（包含百度首页的HTML代码），然后按同样的流程封装成TCP段→IP数据包→以太网帧，再通过路由器传回到你的电脑，最后浏览器解析HTML，显示出百度首页。

整个过程用时序图展示更清晰：

第二章 数据链路层：以太网帧的“贴身包装”解析

咱们上一章说过，以太网帧是数据链路层的“产物”，相当于给IP数据包套的“贴身包装”——它的核心作用是“在局域网里找到对的设备”（靠MAC地址），同时“确保数据没损坏”（靠FCS）。

但以太网帧不是只有一种“款式”，主要分两种：Ethernet II帧和802.3帧。就像衣服有“休闲款”和“正装款”，各有各的用途。

2.1 以太网帧的两种“主流款式”：Ethernet II vs 802.3

为什么会有两种格式？这要追溯到以太网早期的“路线分歧”：

• 1983年施乐、英特尔、DEC推出的“DIX以太网”（DIX是三家公司首字母），用的是Ethernet II帧，特点是有个“类型字段”，直接告诉接收端“里面装的是什么上层协议”（比如IP、ARP）；
• 后来IEEE制定802.3标准时，觉得应该更“灵活”，把“类型字段”改成了“长度字段”，用来标识“数据部分的长度”，但这样就没法直接识别上层协议了——所以又加了个“LLC层”（逻辑链路控制层）来补这个功能，这就是802.3帧。

现在咱们用一张对比图，看两者的核心差异：

简单说，两种帧的“适用场景”完全不同：

• Ethernet II帧：现在99%的场景都用它！比如我们平时上网、看视频、传文件，TCP/IP协议栈里的IP数据包，都是用Ethernet II帧封装的——因为“类型字段”直接高效，不用多一层LLC处理；
• 802.3帧：主要用在工业控制、专用网络（比如工厂里的PLC设备通信）——因为LLC层的“DSAP/SSAP”字段能支持更多种上层协议，兼容性更强，但效率稍低。

举个例子：你用电脑连WiFi上网，网卡发的是Ethernet II帧；而工厂里的机器人和控制器通信，可能发的是802.3帧。

2.2 Ethernet II帧字段“逐个拆”：每个零件都有大作用

既然Ethernet II帧是咱们最常用的，那咱们就“庖丁解牛”，把它的每个字段都讲透——从7字节的“前导码”到4字节的“FCS”，每个字段都不是随便加的，背后都有设计逻辑。

咱们先看一张“Ethernet II帧详细结构示意图”，标清楚每个字段的长度、作用和示例值：

现在咱们逐个字段“深扒”：

1. 前导码（Preamble）：7字节的“唤醒信号”

你可以把前导码理解成“快递员敲门”——接收设备（比如路由器）平时可能在“摸鱼”（处于低功耗状态），前导码就是“咚咚咚”的敲门声，告诉它“快醒醒，有数据要来了！”。

它的值是连续的7个0x55（也就是二进制的01010101），为什么用这个值？因为0和1交替的信号，最容易让接收端的时钟和发送端同步——就像两个人跳舞，先跟着节奏踩点，后面才能跳整齐。

2. SFD（帧起始定界符）：1字节的“开始口令”

前导码是“敲门”，SFD就是“说暗号”——它的值是0xD5（二进制11010101），最后一位从0变成1，相当于告诉接收端：“别等了，真正的数据从下一个字节开始！”。

如果没有SFD，接收端会误以为前导码后面还有前导码，没法区分“准备阶段”和“数据阶段”。比如你跟朋友说“准备——开始！”，“开始！”就是SFD的作用。

3. 目的MAC地址（DA）：6字节的“收件人编号”

MAC地址是设备的“物理地址”，每个网卡出厂时就自带一个全球唯一的MAC地址，就像身份证号一样，不会重复。

它有三种类型，对应不同的“收件范围”：

• 单播MAC：最常用，比如00-11-22-33-44-55，只能发给“指定的那一个设备”（就像快递寄给具体某个人）；
• 广播MAC：FF-FF-FF-FF-FF-FF，发给“同一局域网里的所有设备”（就像小区里贴通知，所有人都能看到）；
• 组播MAC：首字节的最低位是1，比如01-00-5E-00-00-01，发给“加入了某个组的设备”（就像公司里发部门邮件，只有该部门的人能收到）。

举个例子：你的电脑要发ARP请求（查询网关的MAC），目的MAC就是广播MAC——因为你不知道网关是谁，只能“喊一嗓子”，让所有设备都听到，网关听到后再回复你。

4. 源MAC地址（SA）：6字节的“寄件人编号”

这个字段是“谁发的数据”，值是发送设备的MAC地址，比如你电脑的00-AA-BB-CC-DD-EE。

为什么必须有SA？因为接收端收到数据后，可能需要回复——就像快递上要写寄件人地址，对方收到后想退货，才能寄回来。比如网关收到你的ARP请求，要回复ARP应答，就得知道把应答发给谁（看SA字段）。

5. 类型字段（Type）：2字节的“内容标签”

这个字段是Ethernet II帧的“灵魂”，它直接告诉接收端：“我里面装的是什么上层协议，你该交给哪个‘部门’处理”。

最常见的类型值有：

• 0x0800：里面是IP数据包，交给网络层的IP协议处理；
• 0x0806：里面是ARP报文，交给网络层的ARP协议处理；
• 0x86DD：里面是IPv6数据包，交给IPv6协议处理。

比如你的电脑收到一个Ethernet II帧，Type字段是0x0800，就知道要把里面的数据拆出来，交给IP协议处理；如果是0x0806，就交给ARP协议处理。

6. 数据字段（Data）：46~1500字节的“核心内容”

这个字段是以太网帧的“肚子”，装的是上层协议的数据，比如IP数据包、ARP报文。

它有两个长度限制，背后都是“权衡”的结果：

• 最小46字节：这是为了兼容以太网早期的CSMA/CD机制（载波监听多点接入/碰撞检测）。简单说，数据要足够长，才能让发送端在发完数据前，检测到是否有其他设备同时发数据（避免冲突）。如果数据太短（比如10字节），发送端一秒就发完了，没来得及检测冲突，数据就丢了。
• 最大1500字节：这是“最大传输单元（MTU）”的限制。如果数据太长（比如10000字节），一旦传输中出错，整个长帧都要重传，效率太低；1500字节是“效率”和“可靠性”的平衡点——既不会太频繁重传，也不会让帧太多导致网络拥堵。

如果上层数据不够46字节怎么办？以太网会自动在数据后面加“填充字节”（比如填0x00），凑够46字节；如果超过1500字节，IP层会把数据“分片”，分成多个小于1500字节的IP数据包，每个包单独封装成以太网帧传输。

7. FCS（帧校验序列）：4字节的“安检码”

FCS是以太网帧的“最后一道防线”，用CRC（循环冗余校验）算法计算出来——发送端在发帧前，会根据前导码之外的所有字段（SFD+DA+SA+Type+Data）计算一个4字节的CRC值，填到FCS字段；接收端收到后，用同样的算法再算一遍，如果结果和FCS一致，说明数据没损坏；如果不一致，就直接丢弃这个帧。

比如你寄快递，快递员会在面单上盖个“完好章”（FCS），收件人收到后检查章是否完整（校验FCS），如果章模糊了（FCS不一致），就说明快递可能被拆开过（数据损坏），直接拒收。

2.3 802.3帧与LLC/SNAP：“特殊包装”的补充规则

咱们前面说过，802.3帧把Ethernet II的“类型字段”改成了“长度字段”，但这样就有个问题：接收端不知道里面装的是什么上层协议，没法交给对应的协议处理——比如接收端拿到一个802.3帧，看到长度字段是100字节，只知道数据部分有100字节，但不知道这100字节是IP数据还是其他协议数据。

为了解决这个问题，802.3帧加了LLC层（逻辑链路控制层），相当于给数据加了个“中间翻译官”；如果LLC还不够用，再加SNAP层（子网访问协议层），相当于“高级翻译官”。

咱们先看802.3帧+LLC+SNAP的完整结构：

graph LRsubgraph 802.3帧（含LLC+SNAP）direction TBP8[前导码：7字节] --> S8[SFD：1字节]S8 --> DA8[目的MAC：6字节]DA8 --> SA8[源MAC：6字节]SA8 --> L8[长度字段：2字节<br>示例：0x0064（100字节）]L8 --> LLC[LLC层（3字节）1. DSAP：1字节（目的服务访问点）2. SSAP：1字节（源服务访问点）3. Control：1字节（控制字段）]LLC --> SNAP[SNAP层（5字节）1. OUI：3字节（组织唯一标识符）2. Type：2字节（协议类型，同Ethernet II）]SNAP --> D8[数据：46~1500字节]D8 --> F8[FCS：4字节]style LLC fill:#e6f7ff,stroke:#333style SNAP fill:#fff2e6,stroke:#333end

1. LLC层：3字节的“基础翻译官”

LLC层有三个字段，核心是DSAP和SSAP（服务访问点），相当于“协议的门牌号”：

• DSAP（目的服务访问点）：告诉接收端，数据要交给哪个上层协议，比如0x06对应IP协议，0xE0对应IPX协议（一种旧的局域网协议）；
• SSAP（源服务访问点）：告诉接收端，发送端用的是哪个上层协议，通常和DSAP一样；
• Control（控制字段）：用于LLC层自身的通信控制，比如0x03表示“无编号帧”（简单通信，不用确认），0x01表示“编号帧”（需要确认，更可靠）。

比如一个802.3帧的DSAP=0x06，接收端就知道要把数据交给IP协议处理——这和Ethernet II帧的Type=0x0800效果一样，但多了一层LLC处理。

2. SNAP层：5字节的“高级翻译官”

LLC层的DSAP/SSAP只有1字节，能表示的协议有限（最多256种），而且很多协议没有对应的DSAP值——比如IPv6、AppleTalk（苹果的旧协议），这时候就需要SNAP层来“补位”。

SNAP层有两个关键字段：

• OUI（组织唯一标识符）：3字节，标识一个组织，比如0x000000代表“IEEE标准组织”；
• Type（协议类型）：2字节，和Ethernet II帧的Type字段完全一样！比如0x0800=IP，0x86DD=IPv6。

简单说，SNAP层的作用就是“复用Ethernet II的Type字段”——当LLC的DSAP=0xAA（表示需要SNAP）时，接收端就会去看SNAP的Type字段，按Ethernet II的规则解析上层协议。

举个例子：一个802.3帧要传IPv6数据，LLC的DSAP=0xAA，SNAP的OUI=0x000000，Type=0x86DD——接收端看到DSAP=0xAA，就去读SNAP的Type=0x86DD，知道里面是IPv6数据，交给IPv6协议处理。

3. 802.3帧的实际应用：工业场景的“偏爱”

为什么工业控制网络喜欢用802.3帧？因为工业设备的协议太多了——除了TCP/IP，还有Modbus、Profinet、EtherNet/IP这些专用协议，LLC+SNAP能兼容所有这些协议，而Ethernet II帧只能处理有Type字段的协议。

比如工厂里的PLC（可编程逻辑控制器）和传感器通信，用的是Modbus协议，这个协议没有对应的Ethernet II Type值，所以只能用802.3帧+LLC层，DSAP设为Modbus对应的值，确保数据能正确交给Modbus协议处理。