讲以太网协议绕不开数据链路层而数据链路层里最绕的两个概念就是MAC子层和LLC子层。很多人学到这里就开始犯迷糊明明都是数据链路层的“子层”为什么要拆成两个它们各自到底管什么跟网卡、IP地址、交换机之间又是什么关系我先给结论如果你只记住了IP地址和MAC地址那只是看到了数据链路层的“门牌”要真正理解以太网为什么能在一根网线上跑起来、交换机怎么转发帧、Wireshark抓包看到的那些字段到底谁在填你必须把MAC子层和LLC子层的分工彻底搞明白。这篇就把这两个子层拆开讲透把帧结构、寻址、差错控制这些“看不见的手”用图和实际场景说明白。适合刚啃完计算机网络教材、准备面试的学生也适合整天跟网络设备打交道但没细抠过原理的运维朋友。1. 先从数据链路层的基本功能说起1.1 数据链路层到底在解决什么问题数据链路层位于物理层之上、网络层之下。物理层负责把比特流变成电信号、光信号发射到线路上但它不关心这些比特有没有出错、发给谁。数据链路层的工作就是在物理层提供的“裸比特流”之上把这些比特组织成有结构的“帧”然后负责把帧从一个节点可靠地送到相邻节点。你可以把物理层想象成一条粗水管水只管流至于这水是给谁家的、水里有没有掺杂质它一概不管。数据链路层就是在水管的出口装了一套“智能分拣系统”把水按照户主分组、贴上标签、检查有没有漏水、确保顺序不乱。具体来说数据链路层有四个基本功能组帧把网络层下来的IP数据报封装成帧加上帧头帧尾让接收方知道从哪里开始、到哪里结束。物理寻址在帧头中加入发送方和接收方的物理地址MAC地址保证帧能到达正确的下一跳设备。流量控制协调发送方和接收方的处理速度避免快的把慢的“冲垮”。差错控制通过校验和、海明码等技术检测甚至纠正传输过程中的比特错误。这四个功能看起来不少但如果让它们挤在一个协议里做设计上会很别扭有的功能跟具体的物理传输介质强相关比如以太网的冲突检测机制有的功能则希望能在不同网络技术之间通用比如面向连接的可靠传输。于是IEEE 802委员会在制定局域网标准时把数据链路层分成了两个子层MAC子层和LLC子层。1.2 为什么要把数据链路层拆成MAC和LLC两个子层在互联网真正普及之前局域网的标准并不统一有以太网、令牌环网、FDDI光纤网等。它们的传输介质、访问控制方式完全不同但作为数据链路层它们都必须向上层的网络层提供类似的服务比如发送和接收数据报。这就产生了一个矛盾既要照顾各种物理网络的差异又要给上层提供一个统一的接口。IEEE 802标准的设计者们的解法很优雅把跟物理介质直接打交道、差异最大的部分独立出来叫MAC子层Media Access Control介质访问控制把跟上层接口、通用逻辑相关的部分独立出来叫LLC子层Logical Link Control逻辑链路控制。这样拆分有什么好处好处是巨大的。MAC子层可以针对不同的物理网络单独设计比如以太网用CSMA/CD后来演进为全双工后不再需要、WiFi用CSMA/CA它们是两套完全不同的MAC逻辑但LLC子层可以完全不变。上层网络协议比如IP只需要跟LLC打交道不需要关心底层是以太网还是WiFi。这就是数据链路层内部的“接口隔离”。打个比方MAC子层像快递公司的干线运输网络每个运输队有自己的调度规则LLC子层像快递公司的客服前台不管干线运输队怎么换你寄快递都是填同一张面单。上层网络层只面对固定的前台不需要关心背后是汽车还是飞机。2. MAC子层以太网的心脏2.1 MAC子层管什么寻址、成帧、介质访问MAC是Media Access Control的缩写翻译成“介质访问控制”略显生硬但它准确说出了这个子层的核心职责控制如何访问共享介质、如何在介质上传输帧。MAC子层的第一项职责是物理寻址。它负责分配和维护设备在全球唯一的MAC地址——也就是网卡出厂时烧录的那串48位十六进制地址比如3C:52:82:4B:2F:9A。数据在网络上传输时MAC子层负责把源MAC地址和目的MAC地址封装进帧头。MAC子层的第二项职责是组帧与帧检测。它规定了以太网帧的格式前导码、帧起始定界符、目的地址、源地址、类型/长度字段、数据、帧校验序列。帧的格式不是随便定的这里面每一个字段都有讲究后面我会详细拆帧说明。MAC子层的第三项职责是介质访问控制。早期以太网是总线型拓扑所有设备共享一根同轴电缆同一时刻只能允许一台设备发送数据。MAC子层要负责解决“谁先发、谁后发”的问题这就是著名的CSMA/CD协议载波监听多路访问/冲突检测。虽然现代以太网已经普遍使用交换机实现全双工通信不再需要CSMA/CD但理解这段历史对理解MAC子层的职责定位非常有帮助。2.2 以太网MAC帧格式逐字段拆解以太网帧是我们抓包最常看到的帧格式。以最常见的Ethernet II帧DIX帧为例标准格式如下---------------------------------------------------------------------------------------------------------------- | 前导码 7字节 | SFD 1字节 | 目的MAC 6字节 | 源MAC 6字节 | 类型 2字节 | 数据 46-1500字节| FCS 4字节 | ----------------------------------------------------------------------------------------------------------------这里我逐个字段说清楚很多做过抓包的人可能也没完全注意过细节前导码Preamble7字节包含56比特的交替1和0用于让接收方的时钟同步。注意它不算在帧的长度统计里是物理层添加的“热身”数据。帧起始定界符SFD1字节10101011最后两位的连续1告诉接收方“注意后面开始就是真正的帧头了。”目的MAC地址6字节接收方网卡会检查这个字段如果不是发给自己的单播地址、也不是组播/广播地址就丢弃这个帧。源MAC地址6字节发送方网卡的MAC地址。类型/长度字段2字节Ethernet II帧中这个字段表示上层协议类型比如0x0800是IPv40x0806是ARP0x86DD是IPv6。这个字段非常关键它决定了接收方把数据部分交给哪个上层协议处理。数据46-1500字节承载上层数据。最小46字节是因为以太网规定帧的最小长度是64字节从目的地址到FCS如果数据不足46字节要补齐。这个最小长度的设计是为了在共享式以太网中保证CSMA/CD的冲突检测机制有效。帧校验序列FCS4字节使用CRC32算法对整个帧从目的地址到数据末尾计算校验值接收方用同样的算法计算后比对如果不同则丢弃该帧。这里补充一个很多人容易混淆的点我们常说的MTU是1500字节它指的是“数据”字段的最大值。如果IP层下来的数据报超过1500字节IP层会先分片再由MAC层逐片封装成帧发送。2.3 MAC地址全球唯一如何在局域网里工作MAC地址是48位二进制数通常写成12位十六进制数用冒号或短横线分隔。前24位是OUI组织唯一标识符由IEEE分配给各个硬件厂商比如思科的OUI前缀之一就是00:00:0C华为的常见前缀有00:E0:FC。后24位由厂商自行分配保证同一厂商生产的网卡MAC地址不会重复。MAC地址在数据链路层的工作方式跟IP地址完全不同。IP地址是逻辑地址它描述了设备在网络拓扑中的位置数据包转发时IP地址会保持不变但MAC地址逐跳改变。MAC地址是物理地址它只在同一个广播域内有效交换机根据MAC地址表做转发决策。实际通信时是这样协作的主机A要访问主机B已知B的IP地址但不知道B的MAC地址会先发送ARP广播查询“谁的IP是192.168.1.2请告诉我的MAC地址。”主机B收到广播后回复自己的MAC。然后A把B的MAC作为目的MAC封装进帧把B的IP封装进IP包帧到了交换机后交换机查MAC地址表知道B在哪个端口于是只把帧从这个端口转发出去。这就是局域网内通信的基本流程。2.4 交换机如何利用MAC子层工作交换机工作在数据链路层本质上是多端口网桥。它做的事情是收到一个帧读取目的MAC地址查自己的MAC地址表然后把帧从对应的端口转发出去。MAC地址表是交换机自主学习建立的。学习过程是这样的交换机收到一个帧先把源MAC地址和接收端口记录下来形成一张“MAC地址-端口”的映射表。之后再有帧要转发到这个MAC地址时交换机查表找到对应端口精准转发。如果查不到目的MAC交换机会把这个帧从除了接收端口以外的所有端口广播出去这就是泛洪。很多人排查网络故障时喜欢清零交换机的MAC地址表原因是老化时间到了之后表项自动删除或者网络拓扑发生变化导致表项错误。我自己调试交换机时有个经验如果发现某台主机换个交换机端口后还能通信但数据总是慢半拍十有八九是MAC地址表没有及时老化这时候用clear mac address-table dynamic清理一下就好了。还有一个值得说透的细节交换机对广播帧目的MAC全F永远做泛洪操作因为广播帧本来就是发给局域网内所有设备的。大量广播帧占满带宽就是我们常说的“广播风暴”这是二层网络设计需要警惕的问题。3. LLC子层数据链路层的“接驳窗口”3.1 LLC子层不是用来解决“谁能发数据”的很多人学完MAC子层后以为LLC子层很鸡肋大多数实际应用尤其是TCP/IP协议栈中用的Ethernet II帧根本没有LLC头看起来LLC子层好像没什么存在感。但这是理解上的偏差。LLC子层解决的问题是如何在同一种物理网络技术上承载多种网络层协议。MAC子层完成了寻址和收发帧但它不管帧里的数据应该交给哪个上层协议处理。在Ethernet II帧里这个工作由“类型”字段完成在IEEE 802.3带LLC头帧里这个工作由LLC子层的DSAP目的服务访问点字段完成。LLC发挥了承上启下的作用对上LLC提供统一的服务接口给网络层不管下面是以太网、WiFi还是令牌环网络层的软件都不需要改动对下LLC利用MAC子层提供的服务完成帧的发送和接收。这就是IEEE 802.2 LLC标准的核心价值。3.2 LLC帧格式与三种服务类型LLC帧头长度是8字节IEEE 802.2格式标准格式如下-------------------------------------------------------------------------------------------------------------------------------- | DSAP 1字节 | SSAP 1字节 | Control 1-2字节| 上层数据 | | | | | --------------------------------------------------------------------------------------------------------------------------------DSAP目的服务访问点1字节。标识接收方上层的协议类型例如0x06代表IP协议0xE0代表IPX协议0xAA代表SNAP扩展格式。SSAP源服务访问点1字节。标识发送方上层的协议类型。Control字段1或2字节包含帧的类型信息I帧、S帧或U帧。LLC定义了三种服务类型面向不同需求的通信场景无确认无连接服务类型1数据报风格发送不管对方收到没有不建立连接不确认效率高。IP协议叠加以太网时就是用的这种服务。面向连接服务类型2建立逻辑连接、流量控制、差错恢复类似TCP的功能。在局域网里用得不多因为这种可靠性通常由传输层完成链路层再做一遍显得冗余。有确认无连接服务类型3每次发送都需要对方确认但不建立连接。适合某些需要确认但又不想维护连接状态的工业控制协议。从这三种服务类型也能看出来LLC本身具备一定的可靠传输能力但在实际互联网通信中这种能力基本被传输层的TCP取代了所以LLC看起来越来越“透明”。3.3 SNAP让LLC也能兼容Ethernet II的世界这里有个非常经典的问题LLC帧头的DSAP只有1字节能表示的协议号有限而且它跟Ethernet II的“类型”字段不是一回事。为了兼容IEEE又定义了SNAPSubnetwork Access Protocol子网访问协议扩展。SNAP的格式是在LLC头部后面增加5字节3字节的厂商代码Organizationally Unique IdentifierOUI 2字节的以太类型。当DSAP为0xAA、SSAP为0xAA、Control字段为0x03时表示后面跟着SNAP头。SNAP里的2字节类型字段与Ethernet II的Type字段一致所以它可以无缝承载IP协议。这就能解释为什么IEEE 802.3帧能跑IP协议。ISO的NSAP地址、IPX、AppleTalk等协议都能封装在LLC/SNAP帧里传输。理解这个层级关系你才能在Wireshark里看懂那些带LLC标签的帧它往往意味着这是IEEE 802.3封装格式而不是普通的Ethernet II。3.4 MAC与LLC的协作一次完整的数据发送为了把MAC和LLC的分工看得更清楚我模拟一个最简单场景主机AIP地址192.168.1.10MAC地址AA:AA:AA:AA:AA:AA发送一个IP数据报到主机BIP地址192.168.1.20MAC地址BB:BB:BB:BB:BB:BB。第一步IP层把数据包交给LLC子层。LLC加上DSAP/SSAP/Control头如果使用Ethernet II帧格式则没有这一步替换为Type字段通过SAP标识上层协议为IP。第二步LLC调用MAC子层的服务原语把数据块往下传。MAC子层在其前面加上目的MAC和源MAC地址后面加上FCS校验序列组装成一个完整的以太网帧然后交给物理层发送。第三步到达主机B后MAC子层先检查目的MAC地址是否匹配确认匹配后用同样的CRC算法校验FCS校验通过则剥掉MAC帧头把剩余数据上交给LLC子层。第四步LLC查看DSAP字段知道这是IP协议的数据于是把数据块向上交给IP层处理。这个流程里LLC完全不关心数据是怎么被发送出去的是CSMA/CD还是交换机直连MAC也完全不关心数据是谁发来的IP、ARP还是其他协议。这就是分层协作的精髓。4. 海明码数据链路层里的纠错利器4.1 为什么要在链路层讨论海明码上面提到的FCS使用的是CRC32它只能检测错误不能纠正错误。但在一些特殊场景比如卫星链路、无线链路或者高噪声环境重传代价太高如果链路层能直接纠错效率会提升很多。海明码就是一种能够单比特纠错的编码方式它通过精心设计的冗余校验位让接收方不仅能发现有没有错还能定位错在哪一位并自行纠正。海明码虽然不是今天以太网MAC子层的主要差错控制方式但它是理解纠错原理最好的教材也仍然是很多教材关于数据链路层差错控制的核心内容。题目里的热词提到了“数据链路层海明码”这里把它讲透是值得的。4.2 海明码原理用生活化的例子理解“监督小组”海明码的核心思想大致可以这样说在原始数据位中间按照2的幂次位置插入若干校验位每个校验位负责监督一组特定的数据位。这样数据的任何一个比特发生翻转都会导致多个校验位的结果不一致根据校验结果就能反推出错误位的位置。你把它想象成班级值日分组每个值日生负责监督一组同学有没有缺勤同学之间分组有交集。当有人缺勤时多个值日生都会报告“我们组少人”。根据哪几个值日生报了缺勤就能倒推是哪位同学缺勤。海明码就是把这个分组逻辑设计得足够巧妙使得每个错误的比特对应一组唯一的校验位变化模式。海明码的核心公式如果有k个校验位它们最多能覆盖2^k - 1个比特位置校验位加数据位。所以对于n位数据需要满足2^k n k 1。比如发送8位数据需要4个校验位因为2^416 84113发送4位数据则需要3个校验位因为2^38 4318。4.3 海明码编码实操从计算到收发完整走一遍我这里用一个4位数据1010做示例手把手走一遍海明码编码和纠错过程。第一步确定校验位位置。校验位放在2^01、2^12、2^24、2^38……这些位置。4位数据需要3个校验位所以码字一共是7位布局如下位置 7 6 5 4 3 2 1 数据 1 0 1 P3 0 P2 P1其中位置1、2、4是校验位P1、P2、P3位置3、5、6、7是原始数据位注意顺序这里我把数据按照高位到低位填入剩余位置。第二步计算校验位的值。海明码的分组规则是第i个校验位负责所有二进制位置表示中第i位为1的那些位置。P1位置1负责位置1、3、5、7这些位置的原始数据是位置30位置51位置71取偶校验保证1的个数为偶数P1 0 ⊕ 1 ⊕ 1 0。P2位置2负责位置2、3、6、7位置30位置60位置71P2 0 ⊕ 0 ⊕ 1 1。P3位置4负责位置4、5、6、7位置51位置60位置71P3 1 ⊕ 0 ⊕ 1 0。所以完整的海明码字是1 0 1 0 0 1 0位置7到位置1。第三步模拟纠错。假设位置5的数据在传输中翻转为0接收方收到1 0 0 0 0 1 0。接收方重新计算校验结果P1校验位置1、3、5、70 ⊕ 0 ⊕ 0 ⊕ 1 1结果不为0说明有错。P2校验位置2、3、6、71 ⊕ 0 ⊕ 0 ⊕ 1 0结果正常。P3校验位置4、5、6、70 ⊕ 0 ⊕ 0 ⊕ 1 1结果不为0。把出错的校验位按二进制组合P31P20P11得到数值101即十进制的5。错误位置就是第5位。把第5位翻转回来就完成了纠错。这就是海明码“单比特纠错”的完整过程。4.4 海明码的现实意义与限制在真实以太网中海明码并不在MAC子层的帧结构里帧尾用的是CRC32检测。但在无线环境、内存校验ECC内存、存储系统RAID阵列等场景海明码或它的变体仍然大量应用。ECC内存能纠正单比特错误、检测双比特错误用的就是海明码的扩展思想。海明码的核心限制有两个一是只能纠单比特错如果两个比特同时翻转它会误判甚至纠错成第三处错误二是冗余开销大8位数据加4位校验位冗余率50%这在高速高带宽场景下不可接受。所以现代以太网选择CRC检测加重传的机制而不是海明码纠错。作为工程师理解海明码的好处在于建立“用冗余换可靠性”的直觉。到了射频、卫星通信或者数据中心的光模块误码率分析你会再次遇到这种纠错思想那时候你会发现数据链路层的基础概念是一切上层可靠传输的基石。5. 实战用Wireshark把MAC和LLC“看图说话”5.1 抓包准备工作三分钟开启回声包分析讲再多理论不如一次抓包看得明白。我建议你打开Wireshark抓一个ping包操作很简单打开Wireshark选择要监听的网卡在过滤器里输入icmp然后在命令行或终端里对一台内网主机执行ping 192.168.1.1用你自己的网关IP。抓几个包后停止点击第一个ICMP Echo Request请求包看Wireshark的中部面板。你会看到这样的大致结构Ethernet II Destination: ... Source: ... Type: IPv4 (0x0800) Internet Protocol Version 4 Internet Control Message Protocol如果你用的普通以太网帧Ethernet II这里不会有LLC层。但如果你在一些特殊环境捕获到IEEE 802.3帧中间就会多出一层IEEE 802.3 Ethernet Destination: ... Source: ... Length: ... Logical Link Control DSAP: IP (0x06) SSAP: IP (0x06) Control: Unnumbered (0x03) Internet Protocol Version 4这两种结构的差异恰好就是MAC子层与LLC子层分工的生动演示。5.2 从抓包结果里反推MAC和LLC的协作关系拿Ethernet II帧来说Wireshark显示的Type: IPv4 (0x0800)其实承担的就是LLC子层的职责——告诉上层这是IP数据包。这个Type字段在TCP/IP协议族里是如此重要以至于大家都直接用了Ethernet II帧而很少用带LLC头的IEEE 802.3帧。那LLC子层是不是就真的没用了也不是。在以下场景中LLC依然活跃WiFi网络802.11帧的封装中广泛使用LLC/SNAP格式。工业总线、车载网络一些控制协议栈使用LLC的类型2服务实现可靠传输。多协议共存的老旧网络某些遗留系统使用IPX/SPX或AppleTalk它们依赖LLC来标识协议类型。我在抓WiFi包时经常看到这样的帧IEEE 802.11 QoS Data Logical Link Control DSAP: SNAP (0xAA) SSAP: SNAP (0xAA) Control: 0x03 Organization Code: 00:00:00 Type: IPv4 (0x0800)这就是LLC子层在WiFi协议栈中真实工作的证据。5.3 实际排障案例一个“二层不通”的定位过程说一个我自己的排障经历。有一次客户端反馈办公室内所有电脑都能上网但有一台新装的服务器就是ping不通。我先ping网关发现在服务器上ping网关也不通说明问题不是出在IP配置上。我用arp -a查看ARP表发现这台服务器的ARP表里没有网关的MAC地址条目这说明它发出的ARP请求没有得到回应。然后用Wireshark在交换机镜像端口抓包发现了关键信息服务器的MAC地址开头是00:1B:17但服务器网卡的MAC地址被管理员手动改成了一串自定义的地址而且跟另一台设备重复了。交换机MAC地址表里同时存在两条相同MAC对应不同端口的记录交换机在转发帧时就出现了表项震荡。把服务器的MAC地址恢复为出厂值后网络立刻通了。这个案例里用到的基础知识就是MAC子层的寻址机制和交换机MAC地址表的学习原则——二层网络排障时先从MAC层找问题往往比直接看IP层更高效。6. 常见问题与排查技巧速查6.1 MAC子层和LLC子层的常见困惑整理几个我见过的高频问题这里直接答一次。问Ethernet II帧里没有LLC头是不是LLC子层就不存在了答LLC子层的功能依然存在只是它的“上层协议标识”职责被Ethernet II帧的Type字段替代了。严格来说现代TCP/IP协议栈在以太网上几乎不使用IEEE 802.2 LLC/SNAP封装但在WiFi网络中LLC依然存在。问MAC地址和IP地址到底谁先谁后答从网络栈的角度看IP层在数据包上写好源目IP然后交给链路层。链路层用ARP把目的IP解析成MAC地址再把MAC地址封装进帧。接收方收到帧后MAC层先通过目的MAC判断是否收帧IP层再通过目的IP判断是否收包。问交换机到底改不改MAC地址答从主机到交换机再到对端主机的过程中MAC地址是不断替换的路由器转发数据包到另一网段时会改写源MAC和目的MAC交换机转发帧时不改MAC地址只查表转发。逐跳MAC变化、端到端IP不变这个原则千万不要记反。问CRC32和海明码哪个更常用答以太网帧的校验用的是CRC32只检错不纠错发现错误就丢弃。海明码能纠错但开销大适合无线、存储等场景。两者理念不同不存在谁一定更好的问题。6.2 二层排障的实用技巧清单我在处理实际网络问题时有一个相对固定的排查套路分享出来供参考第一步看链路状态。用ip link或ethtool查看物理链路是否正常网卡有没有协商上千兆或百兆。物理层不通后面所有问题都无从谈起。第二步看MAC地址表。在交换机上执行show mac address-table确认设备是否成功学习到MAC地址。如果学不到说明二层链路或者对端设备有问题。第三步看ARP表。在终端上执行arp -a查看网关MAC是否解析成功。ARP失败的话问题大概率在二层隔离或VLAN配置上。第四步抓包看帧结构。用Wireshark抓包看是否有大量FCS errors、CRC errors、alignment problems。这类错误通常意味着物理链路质量差或网卡硬件故障。第五步检查广播域。如果二层环路导致广播风暴交换机的CPU占用率会飙升。这时候用show spanning-tree检查STP状态并找出环路端口。6.3 一个容易被忽略的细节MTU与最小帧长以太网MTU是1500字节。但很多人忽略了最小帧长是64字节这件事。为什么要有最小帧长因为早期共享式以太网依赖CSMA/CD检测冲突发送方必须保证在发送完一帧之前信号能到达最远端的节点并返回冲突信号。如果帧太短发送方可能已经发完了才收到冲突信号导致冲突检测失败。以太网设计时保证最大冲突域直径内64字节的发送时间大于两倍单程传播时延所以最小帧长为64字节。在纯交换式全双工以太网里不存在冲突理论上最小帧长可以放宽。但为了兼容所有设备这个标准一直保留至今。如果你在做网络性能调优、MTU调整测试记得不要仅仅改IP层的MTU还要考虑帧长是否超过交换机端口允许的最大帧长很多交换机默认允许9216字节的巨型帧但需要显式配置端口策略。7. 这件事对学习网络协议栈的启示把MAC子层和LLC子层真正理解透之后再回头看整个网络协议栈你会有一种“通透感”。你会发现很多在网络层、传输层反复出现的设计思路其实在数据链路层都见过雏形。比如说IP地址的“端到端不变”与MAC地址的“逐跳变化”恰好对应了网络层的路由思想与链路层的交换思想TCP的滑动窗口流量控制在LLC的类型2服务里也有类似的机制只不过TCP在端到端尺度上运行LLC在相邻节点尺度上运行海明码用冗余位换取纠错能力传输层的校验和则是另一种“控制冗余”的思路。所以学习网络协议栈不要只背层次图。每一层解决的是不同尺度上的问题物理层解决比特怎么变成信号数据链路层解决帧怎么在相邻节点间传输网络层解决包怎么在互联网上找到目的地传输层解决报文怎么在端到端之间可靠交付。理解每个子层、每个字段为什么存在比记住它叫什么更重要。结合我自己这些年的经验我还要多说一句如果你去面试网络相关的岗位被问到“MAC子层和LLC子层分别负责什么”这类基础问题时千万不要只背“介质访问控制”和“逻辑链路控制”这两个名词。能清晰地讲出它们被拆分的原因、各自服务的对象、在抓包中的表现、以及真实网络中的协作流程才是面试官真正想听到的回答。原理不是用来背的是用来推导的。你把这篇里的思路顺一遍遇到类似问题基本都接得住。 数据链路层拆解：MAC子层与LLC子层的分工与协作
讲以太网协议绕不开数据链路层而数据链路层里最绕的两个概念就是MAC子层和LLC子层。很多人学到这里就开始犯迷糊明明都是数据链路层的“子层”为什么要拆成两个它们各自到底管什么跟网卡、IP地址、交换机之间又是什么关系我先给结论如果你只记住了IP地址和MAC地址那只是看到了数据链路层的“门牌”要真正理解以太网为什么能在一根网线上跑起来、交换机怎么转发帧、Wireshark抓包看到的那些字段到底谁在填你必须把MAC子层和LLC子层的分工彻底搞明白。这篇就把这两个子层拆开讲透把帧结构、寻址、差错控制这些“看不见的手”用图和实际场景说明白。适合刚啃完计算机网络教材、准备面试的学生也适合整天跟网络设备打交道但没细抠过原理的运维朋友。1. 先从数据链路层的基本功能说起1.1 数据链路层到底在解决什么问题数据链路层位于物理层之上、网络层之下。物理层负责把比特流变成电信号、光信号发射到线路上但它不关心这些比特有没有出错、发给谁。数据链路层的工作就是在物理层提供的“裸比特流”之上把这些比特组织成有结构的“帧”然后负责把帧从一个节点可靠地送到相邻节点。你可以把物理层想象成一条粗水管水只管流至于这水是给谁家的、水里有没有掺杂质它一概不管。数据链路层就是在水管的出口装了一套“智能分拣系统”把水按照户主分组、贴上标签、检查有没有漏水、确保顺序不乱。具体来说数据链路层有四个基本功能组帧把网络层下来的IP数据报封装成帧加上帧头帧尾让接收方知道从哪里开始、到哪里结束。物理寻址在帧头中加入发送方和接收方的物理地址MAC地址保证帧能到达正确的下一跳设备。流量控制协调发送方和接收方的处理速度避免快的把慢的“冲垮”。差错控制通过校验和、海明码等技术检测甚至纠正传输过程中的比特错误。这四个功能看起来不少但如果让它们挤在一个协议里做设计上会很别扭有的功能跟具体的物理传输介质强相关比如以太网的冲突检测机制有的功能则希望能在不同网络技术之间通用比如面向连接的可靠传输。于是IEEE 802委员会在制定局域网标准时把数据链路层分成了两个子层MAC子层和LLC子层。1.2 为什么要把数据链路层拆成MAC和LLC两个子层在互联网真正普及之前局域网的标准并不统一有以太网、令牌环网、FDDI光纤网等。它们的传输介质、访问控制方式完全不同但作为数据链路层它们都必须向上层的网络层提供类似的服务比如发送和接收数据报。这就产生了一个矛盾既要照顾各种物理网络的差异又要给上层提供一个统一的接口。IEEE 802标准的设计者们的解法很优雅把跟物理介质直接打交道、差异最大的部分独立出来叫MAC子层Media Access Control介质访问控制把跟上层接口、通用逻辑相关的部分独立出来叫LLC子层Logical Link Control逻辑链路控制。这样拆分有什么好处好处是巨大的。MAC子层可以针对不同的物理网络单独设计比如以太网用CSMA/CD后来演进为全双工后不再需要、WiFi用CSMA/CA它们是两套完全不同的MAC逻辑但LLC子层可以完全不变。上层网络协议比如IP只需要跟LLC打交道不需要关心底层是以太网还是WiFi。这就是数据链路层内部的“接口隔离”。打个比方MAC子层像快递公司的干线运输网络每个运输队有自己的调度规则LLC子层像快递公司的客服前台不管干线运输队怎么换你寄快递都是填同一张面单。上层网络层只面对固定的前台不需要关心背后是汽车还是飞机。2. MAC子层以太网的心脏2.1 MAC子层管什么寻址、成帧、介质访问MAC是Media Access Control的缩写翻译成“介质访问控制”略显生硬但它准确说出了这个子层的核心职责控制如何访问共享介质、如何在介质上传输帧。MAC子层的第一项职责是物理寻址。它负责分配和维护设备在全球唯一的MAC地址——也就是网卡出厂时烧录的那串48位十六进制地址比如3C:52:82:4B:2F:9A。数据在网络上传输时MAC子层负责把源MAC地址和目的MAC地址封装进帧头。MAC子层的第二项职责是组帧与帧检测。它规定了以太网帧的格式前导码、帧起始定界符、目的地址、源地址、类型/长度字段、数据、帧校验序列。帧的格式不是随便定的这里面每一个字段都有讲究后面我会详细拆帧说明。MAC子层的第三项职责是介质访问控制。早期以太网是总线型拓扑所有设备共享一根同轴电缆同一时刻只能允许一台设备发送数据。MAC子层要负责解决“谁先发、谁后发”的问题这就是著名的CSMA/CD协议载波监听多路访问/冲突检测。虽然现代以太网已经普遍使用交换机实现全双工通信不再需要CSMA/CD但理解这段历史对理解MAC子层的职责定位非常有帮助。2.2 以太网MAC帧格式逐字段拆解以太网帧是我们抓包最常看到的帧格式。以最常见的Ethernet II帧DIX帧为例标准格式如下---------------------------------------------------------------------------------------------------------------- | 前导码 7字节 | SFD 1字节 | 目的MAC 6字节 | 源MAC 6字节 | 类型 2字节 | 数据 46-1500字节| FCS 4字节 | ----------------------------------------------------------------------------------------------------------------这里我逐个字段说清楚很多做过抓包的人可能也没完全注意过细节前导码Preamble7字节包含56比特的交替1和0用于让接收方的时钟同步。注意它不算在帧的长度统计里是物理层添加的“热身”数据。帧起始定界符SFD1字节10101011最后两位的连续1告诉接收方“注意后面开始就是真正的帧头了。”目的MAC地址6字节接收方网卡会检查这个字段如果不是发给自己的单播地址、也不是组播/广播地址就丢弃这个帧。源MAC地址6字节发送方网卡的MAC地址。类型/长度字段2字节Ethernet II帧中这个字段表示上层协议类型比如0x0800是IPv40x0806是ARP0x86DD是IPv6。这个字段非常关键它决定了接收方把数据部分交给哪个上层协议处理。数据46-1500字节承载上层数据。最小46字节是因为以太网规定帧的最小长度是64字节从目的地址到FCS如果数据不足46字节要补齐。这个最小长度的设计是为了在共享式以太网中保证CSMA/CD的冲突检测机制有效。帧校验序列FCS4字节使用CRC32算法对整个帧从目的地址到数据末尾计算校验值接收方用同样的算法计算后比对如果不同则丢弃该帧。这里补充一个很多人容易混淆的点我们常说的MTU是1500字节它指的是“数据”字段的最大值。如果IP层下来的数据报超过1500字节IP层会先分片再由MAC层逐片封装成帧发送。2.3 MAC地址全球唯一如何在局域网里工作MAC地址是48位二进制数通常写成12位十六进制数用冒号或短横线分隔。前24位是OUI组织唯一标识符由IEEE分配给各个硬件厂商比如思科的OUI前缀之一就是00:00:0C华为的常见前缀有00:E0:FC。后24位由厂商自行分配保证同一厂商生产的网卡MAC地址不会重复。MAC地址在数据链路层的工作方式跟IP地址完全不同。IP地址是逻辑地址它描述了设备在网络拓扑中的位置数据包转发时IP地址会保持不变但MAC地址逐跳改变。MAC地址是物理地址它只在同一个广播域内有效交换机根据MAC地址表做转发决策。实际通信时是这样协作的主机A要访问主机B已知B的IP地址但不知道B的MAC地址会先发送ARP广播查询“谁的IP是192.168.1.2请告诉我的MAC地址。”主机B收到广播后回复自己的MAC。然后A把B的MAC作为目的MAC封装进帧把B的IP封装进IP包帧到了交换机后交换机查MAC地址表知道B在哪个端口于是只把帧从这个端口转发出去。这就是局域网内通信的基本流程。2.4 交换机如何利用MAC子层工作交换机工作在数据链路层本质上是多端口网桥。它做的事情是收到一个帧读取目的MAC地址查自己的MAC地址表然后把帧从对应的端口转发出去。MAC地址表是交换机自主学习建立的。学习过程是这样的交换机收到一个帧先把源MAC地址和接收端口记录下来形成一张“MAC地址-端口”的映射表。之后再有帧要转发到这个MAC地址时交换机查表找到对应端口精准转发。如果查不到目的MAC交换机会把这个帧从除了接收端口以外的所有端口广播出去这就是泛洪。很多人排查网络故障时喜欢清零交换机的MAC地址表原因是老化时间到了之后表项自动删除或者网络拓扑发生变化导致表项错误。我自己调试交换机时有个经验如果发现某台主机换个交换机端口后还能通信但数据总是慢半拍十有八九是MAC地址表没有及时老化这时候用clear mac address-table dynamic清理一下就好了。还有一个值得说透的细节交换机对广播帧目的MAC全F永远做泛洪操作因为广播帧本来就是发给局域网内所有设备的。大量广播帧占满带宽就是我们常说的“广播风暴”这是二层网络设计需要警惕的问题。3. LLC子层数据链路层的“接驳窗口”3.1 LLC子层不是用来解决“谁能发数据”的很多人学完MAC子层后以为LLC子层很鸡肋大多数实际应用尤其是TCP/IP协议栈中用的Ethernet II帧根本没有LLC头看起来LLC子层好像没什么存在感。但这是理解上的偏差。LLC子层解决的问题是如何在同一种物理网络技术上承载多种网络层协议。MAC子层完成了寻址和收发帧但它不管帧里的数据应该交给哪个上层协议处理。在Ethernet II帧里这个工作由“类型”字段完成在IEEE 802.3带LLC头帧里这个工作由LLC子层的DSAP目的服务访问点字段完成。LLC发挥了承上启下的作用对上LLC提供统一的服务接口给网络层不管下面是以太网、WiFi还是令牌环网络层的软件都不需要改动对下LLC利用MAC子层提供的服务完成帧的发送和接收。这就是IEEE 802.2 LLC标准的核心价值。3.2 LLC帧格式与三种服务类型LLC帧头长度是8字节IEEE 802.2格式标准格式如下-------------------------------------------------------------------------------------------------------------------------------- | DSAP 1字节 | SSAP 1字节 | Control 1-2字节| 上层数据 | | | | | --------------------------------------------------------------------------------------------------------------------------------DSAP目的服务访问点1字节。标识接收方上层的协议类型例如0x06代表IP协议0xE0代表IPX协议0xAA代表SNAP扩展格式。SSAP源服务访问点1字节。标识发送方上层的协议类型。Control字段1或2字节包含帧的类型信息I帧、S帧或U帧。LLC定义了三种服务类型面向不同需求的通信场景无确认无连接服务类型1数据报风格发送不管对方收到没有不建立连接不确认效率高。IP协议叠加以太网时就是用的这种服务。面向连接服务类型2建立逻辑连接、流量控制、差错恢复类似TCP的功能。在局域网里用得不多因为这种可靠性通常由传输层完成链路层再做一遍显得冗余。有确认无连接服务类型3每次发送都需要对方确认但不建立连接。适合某些需要确认但又不想维护连接状态的工业控制协议。从这三种服务类型也能看出来LLC本身具备一定的可靠传输能力但在实际互联网通信中这种能力基本被传输层的TCP取代了所以LLC看起来越来越“透明”。3.3 SNAP让LLC也能兼容Ethernet II的世界这里有个非常经典的问题LLC帧头的DSAP只有1字节能表示的协议号有限而且它跟Ethernet II的“类型”字段不是一回事。为了兼容IEEE又定义了SNAPSubnetwork Access Protocol子网访问协议扩展。SNAP的格式是在LLC头部后面增加5字节3字节的厂商代码Organizationally Unique IdentifierOUI 2字节的以太类型。当DSAP为0xAA、SSAP为0xAA、Control字段为0x03时表示后面跟着SNAP头。SNAP里的2字节类型字段与Ethernet II的Type字段一致所以它可以无缝承载IP协议。这就能解释为什么IEEE 802.3帧能跑IP协议。ISO的NSAP地址、IPX、AppleTalk等协议都能封装在LLC/SNAP帧里传输。理解这个层级关系你才能在Wireshark里看懂那些带LLC标签的帧它往往意味着这是IEEE 802.3封装格式而不是普通的Ethernet II。3.4 MAC与LLC的协作一次完整的数据发送为了把MAC和LLC的分工看得更清楚我模拟一个最简单场景主机AIP地址192.168.1.10MAC地址AA:AA:AA:AA:AA:AA发送一个IP数据报到主机BIP地址192.168.1.20MAC地址BB:BB:BB:BB:BB:BB。第一步IP层把数据包交给LLC子层。LLC加上DSAP/SSAP/Control头如果使用Ethernet II帧格式则没有这一步替换为Type字段通过SAP标识上层协议为IP。第二步LLC调用MAC子层的服务原语把数据块往下传。MAC子层在其前面加上目的MAC和源MAC地址后面加上FCS校验序列组装成一个完整的以太网帧然后交给物理层发送。第三步到达主机B后MAC子层先检查目的MAC地址是否匹配确认匹配后用同样的CRC算法校验FCS校验通过则剥掉MAC帧头把剩余数据上交给LLC子层。第四步LLC查看DSAP字段知道这是IP协议的数据于是把数据块向上交给IP层处理。这个流程里LLC完全不关心数据是怎么被发送出去的是CSMA/CD还是交换机直连MAC也完全不关心数据是谁发来的IP、ARP还是其他协议。这就是分层协作的精髓。4. 海明码数据链路层里的纠错利器4.1 为什么要在链路层讨论海明码上面提到的FCS使用的是CRC32它只能检测错误不能纠正错误。但在一些特殊场景比如卫星链路、无线链路或者高噪声环境重传代价太高如果链路层能直接纠错效率会提升很多。海明码就是一种能够单比特纠错的编码方式它通过精心设计的冗余校验位让接收方不仅能发现有没有错还能定位错在哪一位并自行纠正。海明码虽然不是今天以太网MAC子层的主要差错控制方式但它是理解纠错原理最好的教材也仍然是很多教材关于数据链路层差错控制的核心内容。题目里的热词提到了“数据链路层海明码”这里把它讲透是值得的。4.2 海明码原理用生活化的例子理解“监督小组”海明码的核心思想大致可以这样说在原始数据位中间按照2的幂次位置插入若干校验位每个校验位负责监督一组特定的数据位。这样数据的任何一个比特发生翻转都会导致多个校验位的结果不一致根据校验结果就能反推出错误位的位置。你把它想象成班级值日分组每个值日生负责监督一组同学有没有缺勤同学之间分组有交集。当有人缺勤时多个值日生都会报告“我们组少人”。根据哪几个值日生报了缺勤就能倒推是哪位同学缺勤。海明码就是把这个分组逻辑设计得足够巧妙使得每个错误的比特对应一组唯一的校验位变化模式。海明码的核心公式如果有k个校验位它们最多能覆盖2^k - 1个比特位置校验位加数据位。所以对于n位数据需要满足2^k n k 1。比如发送8位数据需要4个校验位因为2^416 84113发送4位数据则需要3个校验位因为2^38 4318。4.3 海明码编码实操从计算到收发完整走一遍我这里用一个4位数据1010做示例手把手走一遍海明码编码和纠错过程。第一步确定校验位位置。校验位放在2^01、2^12、2^24、2^38……这些位置。4位数据需要3个校验位所以码字一共是7位布局如下位置 7 6 5 4 3 2 1 数据 1 0 1 P3 0 P2 P1其中位置1、2、4是校验位P1、P2、P3位置3、5、6、7是原始数据位注意顺序这里我把数据按照高位到低位填入剩余位置。第二步计算校验位的值。海明码的分组规则是第i个校验位负责所有二进制位置表示中第i位为1的那些位置。P1位置1负责位置1、3、5、7这些位置的原始数据是位置30位置51位置71取偶校验保证1的个数为偶数P1 0 ⊕ 1 ⊕ 1 0。P2位置2负责位置2、3、6、7位置30位置60位置71P2 0 ⊕ 0 ⊕ 1 1。P3位置4负责位置4、5、6、7位置51位置60位置71P3 1 ⊕ 0 ⊕ 1 0。所以完整的海明码字是1 0 1 0 0 1 0位置7到位置1。第三步模拟纠错。假设位置5的数据在传输中翻转为0接收方收到1 0 0 0 0 1 0。接收方重新计算校验结果P1校验位置1、3、5、70 ⊕ 0 ⊕ 0 ⊕ 1 1结果不为0说明有错。P2校验位置2、3、6、71 ⊕ 0 ⊕ 0 ⊕ 1 0结果正常。P3校验位置4、5、6、70 ⊕ 0 ⊕ 0 ⊕ 1 1结果不为0。把出错的校验位按二进制组合P31P20P11得到数值101即十进制的5。错误位置就是第5位。把第5位翻转回来就完成了纠错。这就是海明码“单比特纠错”的完整过程。4.4 海明码的现实意义与限制在真实以太网中海明码并不在MAC子层的帧结构里帧尾用的是CRC32检测。但在无线环境、内存校验ECC内存、存储系统RAID阵列等场景海明码或它的变体仍然大量应用。ECC内存能纠正单比特错误、检测双比特错误用的就是海明码的扩展思想。海明码的核心限制有两个一是只能纠单比特错如果两个比特同时翻转它会误判甚至纠错成第三处错误二是冗余开销大8位数据加4位校验位冗余率50%这在高速高带宽场景下不可接受。所以现代以太网选择CRC检测加重传的机制而不是海明码纠错。作为工程师理解海明码的好处在于建立“用冗余换可靠性”的直觉。到了射频、卫星通信或者数据中心的光模块误码率分析你会再次遇到这种纠错思想那时候你会发现数据链路层的基础概念是一切上层可靠传输的基石。5. 实战用Wireshark把MAC和LLC“看图说话”5.1 抓包准备工作三分钟开启回声包分析讲再多理论不如一次抓包看得明白。我建议你打开Wireshark抓一个ping包操作很简单打开Wireshark选择要监听的网卡在过滤器里输入icmp然后在命令行或终端里对一台内网主机执行ping 192.168.1.1用你自己的网关IP。抓几个包后停止点击第一个ICMP Echo Request请求包看Wireshark的中部面板。你会看到这样的大致结构Ethernet II Destination: ... Source: ... Type: IPv4 (0x0800) Internet Protocol Version 4 Internet Control Message Protocol如果你用的普通以太网帧Ethernet II这里不会有LLC层。但如果你在一些特殊环境捕获到IEEE 802.3帧中间就会多出一层IEEE 802.3 Ethernet Destination: ... Source: ... Length: ... Logical Link Control DSAP: IP (0x06) SSAP: IP (0x06) Control: Unnumbered (0x03) Internet Protocol Version 4这两种结构的差异恰好就是MAC子层与LLC子层分工的生动演示。5.2 从抓包结果里反推MAC和LLC的协作关系拿Ethernet II帧来说Wireshark显示的Type: IPv4 (0x0800)其实承担的就是LLC子层的职责——告诉上层这是IP数据包。这个Type字段在TCP/IP协议族里是如此重要以至于大家都直接用了Ethernet II帧而很少用带LLC头的IEEE 802.3帧。那LLC子层是不是就真的没用了也不是。在以下场景中LLC依然活跃WiFi网络802.11帧的封装中广泛使用LLC/SNAP格式。工业总线、车载网络一些控制协议栈使用LLC的类型2服务实现可靠传输。多协议共存的老旧网络某些遗留系统使用IPX/SPX或AppleTalk它们依赖LLC来标识协议类型。我在抓WiFi包时经常看到这样的帧IEEE 802.11 QoS Data Logical Link Control DSAP: SNAP (0xAA) SSAP: SNAP (0xAA) Control: 0x03 Organization Code: 00:00:00 Type: IPv4 (0x0800)这就是LLC子层在WiFi协议栈中真实工作的证据。5.3 实际排障案例一个“二层不通”的定位过程说一个我自己的排障经历。有一次客户端反馈办公室内所有电脑都能上网但有一台新装的服务器就是ping不通。我先ping网关发现在服务器上ping网关也不通说明问题不是出在IP配置上。我用arp -a查看ARP表发现这台服务器的ARP表里没有网关的MAC地址条目这说明它发出的ARP请求没有得到回应。然后用Wireshark在交换机镜像端口抓包发现了关键信息服务器的MAC地址开头是00:1B:17但服务器网卡的MAC地址被管理员手动改成了一串自定义的地址而且跟另一台设备重复了。交换机MAC地址表里同时存在两条相同MAC对应不同端口的记录交换机在转发帧时就出现了表项震荡。把服务器的MAC地址恢复为出厂值后网络立刻通了。这个案例里用到的基础知识就是MAC子层的寻址机制和交换机MAC地址表的学习原则——二层网络排障时先从MAC层找问题往往比直接看IP层更高效。6. 常见问题与排查技巧速查6.1 MAC子层和LLC子层的常见困惑整理几个我见过的高频问题这里直接答一次。问Ethernet II帧里没有LLC头是不是LLC子层就不存在了答LLC子层的功能依然存在只是它的“上层协议标识”职责被Ethernet II帧的Type字段替代了。严格来说现代TCP/IP协议栈在以太网上几乎不使用IEEE 802.2 LLC/SNAP封装但在WiFi网络中LLC依然存在。问MAC地址和IP地址到底谁先谁后答从网络栈的角度看IP层在数据包上写好源目IP然后交给链路层。链路层用ARP把目的IP解析成MAC地址再把MAC地址封装进帧。接收方收到帧后MAC层先通过目的MAC判断是否收帧IP层再通过目的IP判断是否收包。问交换机到底改不改MAC地址答从主机到交换机再到对端主机的过程中MAC地址是不断替换的路由器转发数据包到另一网段时会改写源MAC和目的MAC交换机转发帧时不改MAC地址只查表转发。逐跳MAC变化、端到端IP不变这个原则千万不要记反。问CRC32和海明码哪个更常用答以太网帧的校验用的是CRC32只检错不纠错发现错误就丢弃。海明码能纠错但开销大适合无线、存储等场景。两者理念不同不存在谁一定更好的问题。6.2 二层排障的实用技巧清单我在处理实际网络问题时有一个相对固定的排查套路分享出来供参考第一步看链路状态。用ip link或ethtool查看物理链路是否正常网卡有没有协商上千兆或百兆。物理层不通后面所有问题都无从谈起。第二步看MAC地址表。在交换机上执行show mac address-table确认设备是否成功学习到MAC地址。如果学不到说明二层链路或者对端设备有问题。第三步看ARP表。在终端上执行arp -a查看网关MAC是否解析成功。ARP失败的话问题大概率在二层隔离或VLAN配置上。第四步抓包看帧结构。用Wireshark抓包看是否有大量FCS errors、CRC errors、alignment problems。这类错误通常意味着物理链路质量差或网卡硬件故障。第五步检查广播域。如果二层环路导致广播风暴交换机的CPU占用率会飙升。这时候用show spanning-tree检查STP状态并找出环路端口。6.3 一个容易被忽略的细节MTU与最小帧长以太网MTU是1500字节。但很多人忽略了最小帧长是64字节这件事。为什么要有最小帧长因为早期共享式以太网依赖CSMA/CD检测冲突发送方必须保证在发送完一帧之前信号能到达最远端的节点并返回冲突信号。如果帧太短发送方可能已经发完了才收到冲突信号导致冲突检测失败。以太网设计时保证最大冲突域直径内64字节的发送时间大于两倍单程传播时延所以最小帧长为64字节。在纯交换式全双工以太网里不存在冲突理论上最小帧长可以放宽。但为了兼容所有设备这个标准一直保留至今。如果你在做网络性能调优、MTU调整测试记得不要仅仅改IP层的MTU还要考虑帧长是否超过交换机端口允许的最大帧长很多交换机默认允许9216字节的巨型帧但需要显式配置端口策略。7. 这件事对学习网络协议栈的启示把MAC子层和LLC子层真正理解透之后再回头看整个网络协议栈你会有一种“通透感”。你会发现很多在网络层、传输层反复出现的设计思路其实在数据链路层都见过雏形。比如说IP地址的“端到端不变”与MAC地址的“逐跳变化”恰好对应了网络层的路由思想与链路层的交换思想TCP的滑动窗口流量控制在LLC的类型2服务里也有类似的机制只不过TCP在端到端尺度上运行LLC在相邻节点尺度上运行海明码用冗余位换取纠错能力传输层的校验和则是另一种“控制冗余”的思路。所以学习网络协议栈不要只背层次图。每一层解决的是不同尺度上的问题物理层解决比特怎么变成信号数据链路层解决帧怎么在相邻节点间传输网络层解决包怎么在互联网上找到目的地传输层解决报文怎么在端到端之间可靠交付。理解每个子层、每个字段为什么存在比记住它叫什么更重要。结合我自己这些年的经验我还要多说一句如果你去面试网络相关的岗位被问到“MAC子层和LLC子层分别负责什么”这类基础问题时千万不要只背“介质访问控制”和“逻辑链路控制”这两个名词。能清晰地讲出它们被拆分的原因、各自服务的对象、在抓包中的表现、以及真实网络中的协作流程才是面试官真正想听到的回答。原理不是用来背的是用来推导的。你把这篇里的思路顺一遍遇到类似问题基本都接得住。