1. 数据链路层在解决什么问题理解数据帧之前必须先懂这一层的定位1.1 物理层只能保证比特在流动但认不出消息很多人刚接触网络分层模型时最困惑的问题就是物理层已经把比特流发出去了为什么还要数据链路层多此一举地封装成帧这个问题的答案恰恰是理解数据链路层帧格式的钥匙。物理层的职责非常简单粗暴把0和1变成电信号、光信号或者无线电波送到对端。它不关心这些比特代表什么也不关心是从哪台机器发出来的、要送到哪台机器。就像一条传送带只管把零件运过去至于零件是哪个订单的、要装到哪台设备上传送带一概不管。如果物理层就这么直接传输网络里就会乱套——接收方收到一串比特既不知道这串比特从哪来、到哪去也不知道到哪里算一条完整的消息、哪里是下一条。数据链路层就是来解决这个问题的。它在物理层提供的原始比特流之上把比特流按照一定规则切分成一个个数据帧在每一帧里加上发送方地址、接收方地址、校验信息等包装再交给物理层发送。接收方的数据链路层收到后先检查这个帧是否完整、有没有出错然后根据目的地址决定是收下还是丢弃。这个过程本质上就是在不可靠的物理通道上建立一条看起来比较可靠的通信链路。1.2 帧的三大核心能力定界、寻址、纠错一个数据链路层的帧无论具体协议是哪一种核心职责都可以归结为三件事定界、寻址、纠错。定界解决的是哪几个比特算一个完整消息的问题。物理层是连续的比特流不知道从哪里断开。数据链路层通过在帧头帧尾加入特定标志比如HDLC的0x7E标志字段或者在帧头声明长度让接收方能准确切出每一个帧。这就好比邮寄包裹时快递单上会有一块区域专门写着包裹的边界——虽然包裹本身没有边界线但你一眼能看出一个包裹从哪里开始、到哪里结束。寻址解决的是这一帧到底送给谁的问题。局域网里挂着很多设备数据发出去以后每个设备的网卡都会收到这份电信号但只有目的MAC地址匹配的设备才会把帧交给上层处理其他设备直接丢弃。这也是为什么数据帧头里一定要有目的地址和源地址。纠错解决的是比特在传输过程中被干扰了怎么办的问题。电磁干扰、信号衰减都会导致比特翻转接收方需要一个机制来判断收到的帧是否和发送时一致。最常见的办法是CRC循环冗余校验发送方根据帧内容算出一个校验值附在帧尾接收方重新计算并比对不一致就认为帧已经损坏直接丢弃。1.3 数据帧、数据包、数据报名称背后的层级关系在学习过程中还会碰上一堆容易混淆的名字数据帧Frame、数据包Packet、数据报Datagram、报文Message。这些词看起来差不多其实对应的是不同层的封装结果。数据帧数据链路层的封装单位包含帧头、载荷、帧尾数据包网络层IP层的封装单位包含IP头和数据数据段传输层的封装单位包含端口号等信息报文更泛化的说法通常指某个协议层完整的一个消息单元这里的关键在于封装关系上层的数据包会被完整地塞进下层数据帧的载荷字段里。也就是说一个IP数据包加上帧头和帧尾就成了一个数据帧。理解这个套娃关系后面看抓包工具里的报文内容时会非常有用——你会看到Wireshark一层层展开从帧信息一路看到TCP端口号其实就是这个封装过程的还原。2. 以太网帧逐字段拆解一个经典帧从头发到尾长什么样2.1 从整体看结构前导码、SFD和帧本体在众多数据链路层协议里以太网Ethernet是应用最广泛、也最值得先弄懂的一个。经典的以太网帧格式从介质上实际传输的内容说起分为这么几块前导码Preamble7字节每个字节都是二进制10101010十六进制0xAA帧起始定界符SFD1字节二进制10101011十六进制0xAB目的MAC地址6字节源MAC地址6字节类型/长度字段EtherType/Length2字节载荷Payload46到1500字节帧校验序列FCS4字节前导码和SFD严格来说不属于帧本体它们是物理层和链路层之间配合用的。前导码的作用是让接收方的网卡时钟同步——一串0101交替的信号接收方拿它来对表找到正确的比特判决时机。SFD的最后两位是11标志着一个关键边界接下来就是真正的帧头了。我早年调试时犯过一个错误拿着抓包工具的十六进制数据从前导码开始一个一个字段对结果发现自己怎么也对不上MAC地址的位置。原因就是抓包工具默认已经把前导码和SFD过滤掉了它展示的数据从目的MAC开始。如果你拿着示波器或逻辑分析仪在物理线路上抓原始比特才能看到完整的前导码和SFD。2.2 源目的MAC交换机转发的判断依据MAC地址是数据链路层最核心的寻址信息一共6字节48位通常写成用冒号分隔的十六进制形式比如00:1a:2b:3c:4d:5e。前3字节是OUI组织唯一标识符由IEEE分配给厂商后3字节由厂商自行分配。在交换机内部有一个MAC地址表记录着哪个MAC地址从哪个端口学习到。当一个帧到达交换机时交换机看目的MAC查表决定从哪个端口转发出去查不到就往所有端口泛洪广播。这个过程完全工作在数据链路层交换机根本不关心帧里面装的是IPv4还是IPv6包里的源IP是多少。这个特点对理解网络有很大帮助——很多排查思路一旦到了交换机转发层面就要以MAC为主而不是以IP为主。2.3 EtherType还是Length老协议的两种解释方式紧跟在MAC地址后面的2字节字段初看很不起眼但它有一个历史演变过程。早期以太网规范用这个字段表示payload的长度单位是字节后来改用这个字段表示上层协议的类型比如0x0800载荷是IPv4数据包0x0806载荷是ARP报文0x86DD载荷是IPv6数据包0x8100帧带有802.1Q VLAN标签接收方是靠这个字段决定把载荷交给IP协议栈还是ARP协议栈处理的。如果收到一个帧这个字段的值小于1500按长度解释大于等于1536按类型解释。之所以用得这么别扭是为了兼容早期设备——当时的网卡和驱动都已经按长度实现了协议设计者不想直接废弃就采用了分段解释的办法。现在实际网络里基本都是按类型用了。2.4 FCS与CRC32怎么知道帧在传输中受了伤帧尾的4字节FCS是数据链路层为数据完整性上的一道保险。计算方法是发送方对整个帧从目的MAC到载荷末尾应用CRC32算法把得出的4字节校验值放在帧尾接收方收到帧后对同样的范围重新计算CRC如果结果和帧尾的FCS不一致就认为帧在传输过程中出错了。CRC32的数学细节不展开但有一点值得知道它比简单的校验和比如把所有字节相加取低字节健壮得多。CRC32能可靠检测出几乎所有常见的错误模式比如连续多位翻转、突发错误等。我实际排查网络问题时见过很多次网卡丢包率特别高的案例最终定位到光模块衰减或网线质量问题靠的就是交换机端口统计里不断增加的CRC错误帧计数。CRC出错率高基本可以断定物理链路有问题而不是协议配置有问题。2.5 为什么帧最短64字节、最长1518字节以太网帧的载荷是46到1500字节加上帧头帧尾帧本体不含前导码和SFD最短64字节662464最长1518字节66215004。最小64字节的由来跟经典的CSMA/CD冲突检测机制绑定。在半双工以太网里一台设备发送数据的同时要监听有没有冲突。以太网设计时规定的最大冲突检测时间换算成在10Mbps速率的比特数就是512比特即64字节。如果发送的帧太短发送方可能已经发完了还没听见冲突信号就无法重传了。因此如果上层数据不够46字节链路层会自动填充Padding到最小帧长。最大1518字节则和MTU最大传输单元挂钩。IP层的默认MTU是1500字节这个值定了以太网载荷上限就是1500加上14字节帧头和4字节FCS就是1518。现在网络里为了传输大文件效率更高很多人启用巨型帧Jumbo Frame把MTU调到9000字节那么以太网帧也能超过1518字节。但这里有个重要坑巨型帧要求链路两端以及中间所有交换机都支持且配置一致只要有一台设备不支持就会出现丢包或分片问题。3. 不止以太网PPP、HDLC与802.11帧格式横向对比3.1 PPP帧点对点链路上的轻量设计说以太网帧是局域网的主角那么在广域网的点对点链路上出场率最高的是PPPPoint-to-Point Protocol。这种场景下没有交换机、没有多个设备竞争介质帧设计就可以简化很多。PPP帧格式是这样的标志字段Flag1字节固定0x7E表示帧的起始和结束地址字段Address1字节固定0xFF控制字段Control1字节固定0x03协议字段Protocol1~2字节标识载荷类型比如0x0021表示IP数据包信息字段Information可变长度FCS2字节或4字节地址字段和控制字段在PPP里是固定的因为在点对点链路上不需要寻址这两个字段保留更多的是出于和HDLC格式对齐的考虑。PPP的核心价值在于它能承载多种协议IP、IPX等而且支持认证PAP/CHAP、压缩和链路质量检测。拨号上网时代PPP是绝对主角现在家庭宽带的PPPoE本质上是PPP over Ethernet把PPP帧封装进以太网帧里既能使用以太网的物理设施又能享受PPP的认证计费能力。3.2 HDLC帧标志字段与比特填充的来历HDLCHigh-Level Data Link Control比PPP更古老很多广域网设备上的serial接口默认封装就是HDLC。它的帧格式和PPP相似也是用0x7E作为标志字段。问题来了如果帧内部的数据里恰好出现了0x7E这个字节接收方就会误以为帧结束了。怎么解决答案是比特填充Bit Stuffing。规则很简单发送方在数据部分扫描如果连续出现5个1就在后面插入一个0接收方收数据时如果看到连续5个1后跟一个0就自动删掉这个0还原数据如果看到连续5个1后跟一个1那就是标志字段意味着帧结束或者帧异常中止。这个机制的巧妙之处在于不需要发送方和接收方额外协商纯靠比特序列的规则就能做到数据里的标志不会和真实标志混淆。不过现在设备上常见的HDLC基本都是Cisco私有的改良版增加了一个类型字段用于标识上层协议和标准的ISO HDLC略有差异。如果你在两台不同厂商的设备上对接串口链路常常会遇到封装不匹配的问题就是因为私有HDLC和标准HDLC格式不兼容。3.3 802.11无线帧为什么比有线帧多那么多地址Wi-Fi使用的802.11帧格式比以太网复杂不少。一个显著的差异是以太网帧只有目的MAC和源MAC两个地址而802.11的帧头里最多要放4个地址字段。这跟无线网络的工作模式有关。在有线网络里设备通过网线直接连到交换机帧的源和目的很清楚。但在Wi-Fi环境里数据帧经过的是无线信道存在三种角色发送数据的站点STA、接入点AP、以及AP背后的有线网络或分布式系统。一个无线帧从网卡发到APAP再转发出去整个过程涉及无线链路两端的地址和最终逻辑上的源和目的地址所以需要更多的地址字段来区分。以最常见的站点通过AP访问互联网的数据帧为例4个地址字段通常分别表示接收端地址RA、发送端地址TA、目的地址DA、源地址SA。无线网卡和AP的驱动会根据帧的收发方向正确填充这些字段。如果不了解这个背景直接在抓包里读无线帧的MAC地址很容易把RA和DA搞混导致判断错数据到底是谁发的、发给谁的。3.4 一张表看懂主流帧格式差异把几种常见数据链路层协议的帧格式放在一起对比差距一目了然。特性以太网PPPHDLC802.11无线寻址方式目的MAC源MAC不需要固定0xFF可选地址字段最多4个地址字段帧边界识别通过帧头物理信号特性0x7E标志字段0x7E标志字段比特填充通过帧头物理信号特性典型应用场景局域网/数据中心拨号/广域网/PPPoE串口链路/专线无线局域网是否支持VLAN支持802.1Q/QinQ否否支持802.11封装内可携带差错校验CRC32FCSFCSFCS这里要提醒一句如果一个技术人员只会看以太网帧格式遇到广域网链路或者无线抓包就会手足无措。建议在理解以太网的基础上把PPP和802.11的帧头结构也记牢实际工作中排查广域网专线或者Wi-Fi干扰问题时会省很多力气。4. 打开Wireshark看真实流量从十六进制流反推帧格式4.1 一个真实的以太网帧手工解析演示光看规范和格式说明印象总是不够深。我建议你动手抓一次包然后手工解析一个真实帧比背十遍字段定义都管用。下面用一个典型的以太网帧示例来说明手工解析的过程基于常见抓包工具的展示数据帧头从目的MAC开始。假设抓到的一段十六进制流部分截取是00 16 3e 00 11 22 00 1a 2b 3c 4d 5e 08 00 45 00 00 3c 00 01 00 00 40 06 ...手工解析步骤前6字节00 16 3e 00 11 22是目的MAC即00:16:3e:00:11:22接着6字节00 1a 2b 3c 4d 5e是源MAC即00:1a:2b:3c:4d:5e接下来2字节08 00值为0x0800说明载荷是IPv4数据包从偏移14字节开始属于IP数据包头部45 00 ...0x45表示IPv4、头部长度20字节帧尾还有4字节FCS不过抓包工具一般默认不显示或者标记为[correct]因为网卡已经把校验过的帧交给驱动了我在带新人时会让他们直接在纸上做这种手工解析把每个字节的归属标出来。做过三五遍之后再看Wireshark的自动解析结果就再也不会觉得那些字段是黑盒生成的了。4.2 带VLAN标签的帧多出来的4字节在哪生产环境里大量帧是带VLAN标签的。802.1Q规范的VLAN标签插在源MAC和EtherType之间共4字节。帧结构变成目的MAC6字节、源MAC6字节、VLAN标签4字节、EtherType2字节、载荷、FCS。由于多了4字节带VLAN标签的帧最大长度从1518变成1522字节。VLAN标签本身又分两部分前2字节是TPIDTag Protocol Identifier固定为0x8100表示这是一个VLAN标签后2字节是TCI其中包含3比特的优先级PCP、1比特的丢弃合格指示DEI和12比特的VLAN ID。12比特意味着VLAN ID范围是0到4095其中0和4095保留真正能用的VLAN ID是1到4094。现实运维里VLAN标签经常是故障排查的盲区。比如交换机上配置的是Access口却收到了带VLAN标签的帧这个帧要么被丢弃要么被当成未知帧处理又比如Trunk口允许的VLAN列表没配对帧就过不去。遇到这类问题抓包看TPID是不是0x8100、VLAN ID是多少往往比在交换机配置页面上翻半天更直接。4.3 抓包中常见的异常帧与排查思路抓包不只是看正常帧长什么样更重要的是能识别异常帧。实践里最常见的三类异常如下CRC错误帧Wireshark里能看到FCS校验失败的帧表现为连续丢包、重传增多。优先怀疑物理层问题比如网线老化、水晶头接触不良、光模块光功率异常。我处理过一起奇怪丢包事件排查一圈最后发现是网线有一段被机柜门夹过表皮看着没事内部线对已经受损。短帧Runt Frame小于64字节的帧通常是因为冲突或网卡故障。如果链路是半双工模式现在极少见了短帧往往意味着严重冲突。巨型帧Jumbo Frame超过1518字节的帧。如果是自己特意配置了巨帧链路两端和交换机必须都支持如果不是故意配置的出现超大帧很可能是网卡驱动bug或交换机MTU不匹配需要逐段检查MTU配置。一个很实用的排查习惯是在抓包工具里加上过滤条件比如eth.len 64看短帧或者eth.fcs.status 0看校验状态。快速过滤出病态帧比一条一条翻看报文高效得多。我曾经帮朋友排查办公室网络大量正常业务间歇性卡顿用这个过滤方法几分钟就发现某个端口在持续产生CRC错误帧最后定位到一台老旧的桌面交换机。5. 帧格式经常被搞错的几个点我的实战体会5.1 帧和包不是一回事我在论坛和社群里发现一个高频误区把帧和包混着用觉得反正都是数据一股脑发过去。实际上在排障场景下这两个概念区分不清会出大问题。举个例子两台设备ping不通抓包一看有request没response。这时候你要先判断request有没有到达对端对端的网卡有没有发出response帧如果发出来了response帧有没有回到源端这些判断每一步都要区分这是第2层的帧还是第3层的包。如果直接在Wireshark里只看包过滤器用的是icmp或ip看不到MAC层的交互情况而看帧用的是eth或wlan。过滤用对了才能看到网卡层面是否已经在丢弃某些帧。有个经典场景能说明帧和包的差别MTU问题。两台主机之间通信IP层的数据包大小超过了路径MTU中间路由器会回一个ICMP分片错误消息如果配置允许的话。但从链路层看每个帧都正常到达了。问题出在第3层的分片策略和第2层的帧格式没有关系。如果你停留在帧层面找原因翻遍FCS和MAC地址也找不到结论。5.2 MAC地址不是绝对唯一的本地管理地址了解一下很多人默认MAC地址全球唯一做实验时发现两台设备MAC一样就断定网卡坏了或者系统出bug了。实际上MAC地址的全球唯一性建立在厂商遵循IEEE分配规则的基础上但存在例外。最典型的是本地管理地址Locally Administered Address。IEEE规定MAC地址第一个字节的最低第2位即本地/全局位如果为1表示这是本地管理地址不受全球唯一性约束。很多软路由、虚拟机、嵌入式设备会生成本地管理地址甚至有些网卡驱动允许用户手动指定MAC。所以出现两台设备MAC相同未必是异常可能只是有人手动改过网卡地址。另外虚拟化环境里大量虚拟机共享一张物理网卡虚拟机的MAC通常由虚拟交换机自动生成如果配置不当也可能出现重复。处理这类问题时我的建议是不要拿MAC必须唯一当第一判断先查设备上的实际MAC是不是本地管理地址再查虚拟化平台的MAC生成策略。5.3 交换机不关心IP只埋头转发帧最后一个常被忽视的点交换机是典型的数据链路层设备它转发依据是MAC地址表不是IP路由表。路由器的路由表处理的是IP数据包交换机的MAC表处理的是数据帧。这带来一个很实用的排障经验如果你在一个二层网络里ping不通某个设备先别急着怀疑IP地址配置先看交换机的MAC地址表里有没有这个设备的MAC以及它从哪个端口学习到的。如果MAC表里压根没有这个地址说明这个设备在这个二层域内不可见可能根本没接入、网线没通、或者VLAN配错了。如果MAC表有但就是不通信再看IP层的配置。这个先从第2层查起的习惯能帮你省掉大量拿光纤打光笔测线路的笨办法。另外理解交换机的泛洪机制也很重要。交换机收到一个目的MAC未知的帧会向所有端口转发除了接收端口。这就是为什么偶尔能在抓包里看到本不该出现在某个链路上的帧——大概率是广播或未知单播泛洪。这不是故障而是二层转发机制的正常行为。最后分享一个我个人的操作习惯在实验室里搭建一个迷你网络用两台Linux主机和一个普通交换机手动跑一次ARP、Ping和HTTP请求分别在两端用抓包工具记录完整流程。把整个过程从以太网帧、ARP帧、IPv4数据包、TCP段的封装关系逐一对照看明白比看任何教科书都管用。数据链路层的帧格式看着细节多但只要亲手拆过一个真实帧往后所有协议头的学习都会快很多。