一文读懂数据链路层：从帧封装到以太网交换机排障

1. 链路层到底管什么先想清楚这一层的边界聊网络协议栈很多人习惯从上往下背应用层、传输层、网络层、链路层……但实际遇到问题的时候链路层往往是最后被想起、却最先需要排查的一层。尤其是当你抓包看到满屏的以太网帧或者交换机端口指示灯狂闪但业务就是不通这个时候不把链路层搞明白基本就只能在网络层以上瞎猜。链路层的定位其实很朴素它负责在相邻两个节点之间的物理链路上把网络层交下来的 IP 数据报封装成“帧”可靠地送到对端。注意“相邻”两个字链路层不关心你从北京到上海要经过多少跳它只关心从一个设备到它紧挨着的下一个设备这一段路怎么把数据送过去。就好比你要从小区门口到高铁站链路层管的是从你家单元门到小区门口这一段路怎么走至于高铁怎么开、中间停几站那不是它的事。这一段路要解决的实际问题有三类。第一数据以什么格式组织让接收方能认出“这是一个完整的帧”——这是封装成帧的问题。第二如果数据里恰巧出现了和帧边界标志一样的字节怎么避免被误判成帧边界——这是透明传输的问题。第三数据在传输过程中受干扰变了样接收方怎么发现——这是差错检测的问题。这三件事统称链路层的三个基本问题后面我会一个个拆开讲。另外链路层面对的物理信道也分两种。一种是点对点信道一头连一个设备没有第三方来抢常见于早期拨号上网、运营商专线这类场景典型协议是 PPP。另一种是广播信道同一段线路上挂着多台设备大家都听得到但谁能发、什么时候发就得靠规矩来协调典型场景是早期的总线型以太网和现在的 Wi-Fi典型协议机制是 CSMA/CD有线和 CSMA/CA无线。这两种信道看起来都是“一根线”但解决的核心问题的难度完全不同前者主要是让两个设备能“对齐”后者则是要管理一群设备的“发言权”。搞清楚链路层的边界再看它的核心机制就容易多了链路层不是为了实现“全球互联”它只服务于物理上相邻的这一次跳转。但正是因为每一跳的可靠性、每一跳的帧格式、每一跳的差错处理都稳定了上层那些复杂的路由算法和端到端传输协议才有了可依赖的基础。这就像盖楼链路层是地基地基不牢楼上的 IP 寻址、TCP 可靠传输再花哨也白搭。2. 三个基本问题拆开讲封装、透明传输、差错检测2.1 封装成帧给数据画上“起跑线”和“终点线”链路层拿到网络层下发的 IP 数据报之后第一件事就是给它加头加尾组装成一个帧。帧的结构通常由三部分组成帧首部、数据部分、帧尾部。帧首部里有目的 MAC 地址、源 MAC 地址、类型字段等帧尾部最关键的是 FCS帧检验序列用来做差错检测。这里有一个最直观也最容易忽略的问题接收方怎么知道一个帧从哪里开始、到哪里结束如果链路层不说明这个问题接收方因为收到的是一串没有边界的比特流根本没法判断哪几个比特属于同一个帧。解决思路有好几种。最常见的是“帧首尾定界符”方案像 PPP 协议用 0x7E 作为帧边界标志发送端在帧开头和结尾各放一个 0x7E接收端只要扫到 0x7E 就知道一个帧开始或结束。另一种是“固定长度”方案比如某些协议规定帧长固定为多少字节接收方按长度切分即可。以太网则走的是第三种思路它通过在帧前设置前导码来同步时钟再由帧首部的目的 MAC 地址字段来隐式确认帧的开始帧结束则由发送方停止发送来体现因为以太网是持续比特流的传输方式接收方通过硬件检测到载波消失来判定帧结束。不过如果一帧的数据特别长接收方的缓冲区不够怎么办或者数据被截断了怎么办所以实际协议里往往还带一个“长度/类型”字段比如 IEEE 802.3 以太网帧里大于等于 0x0600 的值表示类型小于等于 0x05DC1500的值表示长度。早期有人用长度字段来判断帧的完整性后来基本以类型为主以太网的最小帧和最大帧长度反而是由协议规范直接约束的。2.2 透明传输数据里出现“边界符号”怎么办封装成帧有了边界标志之后麻烦来了如果用户数据里碰巧出现了和定界符一模一样的字节怎么办比如 PPP 的定界符是 0x7E如果我要传的数据里正好有个字节也是 0x7E接收方扫到这个位置就会误以为帧结束了后面的数据全被当成垃圾丢弃帧被“腰斩”了。这个问题的本质是链路层协议要让上层“透明”地看到传输能力意思是上层给我的数据我原封不动地传过去不能因为你内部用 0x7E 做边界就让我传不了这个字节。解决办法是“字节填充”也叫字符填充。PPP 的填充规则很简单发送端扫描数据部分遇到 0x7E 就转义成 0x7D 0x5E遇到 0x7D 就转义成 0x7D 0x5D接收端再反向还原。这样边界标志在数据里就永远不会“裸突”你传二进制数据也好、传文本也好链路层一概不care。以太网不需要这个机制因为它没有用特殊字节做定界符。但这不代表以太网就不需要处理类似问题它另有一套办法——最小帧长限制和载波监听机制配合使用从物理层的角度规避了“短帧被当成噪声”的边界歧义。所以你看同样是解决透明传输问题不同协议的解法不同但目标一致让你传啥我就传啥别因为协议自身的限制把数据改坏了。2.3 差错检测CRC 到底是怎么算的为什么它比校验和多传输过程中信号会受到干扰哪怕某一段光纤的衰耗大一点、某根网线有轻微破损都可能导致比特翻转。链路层的职责之一就是把这种“静默损坏”给揪出来。最简单粗暴的办法是校验和比如把数据按字节累加得到一个 sum 附在帧尾接收端同样累加对比。这种方式实现简单但检测能力弱多位翻转时容易出现漏检。实际链路层普遍用的是 CRC循环冗余校验。它的原理可以这样理解把要发送的数据看成一个二进制多项式比如一串数据比特位 1011001 就对应多项式 (x^6 x^4 x^3 1)。发送方把这个多项式乘以 (x^r)r 取决于生成多项式的阶数再用一个约定的生成多项式 G(x) 去做模 2 除法得到的余数就是 FCS附加到数据后面发出去。接收方收到“数据FCS”之后用同样的生成多项式再除一次。如果余数为 0就认为没出错余数不为 0说明传输过程中出了差错。这里的关键在于CRC 的检错能力取决于生成多项式的选取。常见的 CRC-32 生成多项式是 (x^{32}x^{26}x^{23}x^{22}x^{16}x^{12}x^{11}x^{10}x^{8}x^{7}x^{5}x^{4}x^{2}x1)它能检测出所有长度小于等于 32 位的突发错误以及绝大多数更长的突发错误比简单的校验和强了好几个数量级。有人可能会问既然 CRC 这么强为什么还要搞可靠传输机制因为 CRC 只能让接收方“知道出错了”但不能让接收方“纠正错误”——它没有能力把错的比特改回来更没法决定是重传还是丢弃。只知道“这帧坏了”是不够的后续怎么处理要看这一层配置的是简单丢弃、还是向上层报告、还是由协议栈上层去触发重传。以太网的数据链路层通常只做“检错丢弃”不负责重传重传是 TCP 这类传输层协议的活。这一点特别容易理解混淆你得记清楚链路层帧的差错检测不等于链路层的可靠传输。3. 点对点链路与 PPP两个设备怎么“对齐”3.1 PPP 为什么存在拨号上网时代留下的务实方案如果把广播信道比作一个热闹的菜市场那点对点信道就是两个人之间的私人电话线一条线只连接两个端点不存在第三方来抢信道。这种场景下“谁能发消息”不是一个问题因为就两个设备想发就发。问题变成了两个设备怎么约定帧格式、怎么进行链路管理、怎么认证身份。PPPPoint-to-Point Protocol点对点协议就是为这种场景设计的。它最著名的历史和拨号上网深度绑定当年调制解调器拨号到 ISP 的接入服务器走的就是 PPP。它的设计目标很实际在一根串行线路上支持多种网络层协议IP 也好、IPX 也好同时要能进行链路状态管理、可选的认证、以及上面说的字节填充透明传输。PPP 帧格式比以太网复杂一点但也不难记标志字段 0x7E、地址字段固定为 0xFF、控制字段固定为 0x03协议字段表示上层是什么协议比如 0x0021 是 IP0xC021 是 LCP0x8021 是 NCP 中的 IPCP信息部分就是上层协议的数据最后是 FCS 和结束标志 0x7E。其中地址和控制字段在现代 PPP 实现里其实没什么信息量保留它们更多是为了兼容早期 HDLC 帧结构。3.2 PPP 协议栈LCP、NCP、认证机制的关系PPP 不是孤立的一个协议而是一个协议族。链路建立初期先用 LCP链路控制协议来做协商双方确认 MRU最大接收单元、认证协议类型、是否开启压缩等。LCP 协商成功后链路进入可用状态这时再用 NCP网络控制协议来配置网络层参数其中最常见的是 IPCP——它负责给对端分配 IP 地址、协商 DNS 等。等到这些配置完成后IP 数据报才能在上面跑。链路正常结束时也要通过 LCP 的 Terminate 报文来有序拆除避免两边处于混沌状态。PPP 还支持 PAP 和 CHAP 两种认证方式。PAP 是明文传输用户名密码简单但不安全基本可以理解为“裸奔”。CHAP 用三次握手加哈希算法不在线路上传明文密码安全性好得多。实际组网里如果企业专线用 PPPoE把 PPP 跑在以太网之上宽带拨号大多走的是 CHAP 或更完善的扩展认证方式。你对 PPP 的理解如果只停留在“拨号上网”那就低估它了到现在运营商的很多接入网、以及部分二层专线场景里PPP 的升级版本和衍生协议仍然活跃着。3.3 为什么现在交换机网线直连很少提 PPP你可能会疑惑现在两台电脑用网线直连或者接交换机怎么没人配置 PPP因为以太网取代了那个位置。以太网的设计思路和 PPP 完全不同它不关心两台设备之间的“对齐”协商自动协商可以搞定速率和双工更关心如何高效地支持多点接入和即插即用。从网络工程师的角度讲绝大多数情况下你见到的“链路层”都是以太网PPP 主要是运营商、拨号以及特定专线场景里才需要关心的东西。但理解 PPP 的意义在于它能帮你建立起“链路层要主动管理和维护链路状态”的认知而以太网把这层管理变得更透明、更自动。4. 广播信道与以太网大家都说话怎么不打架4.1 CSMA/CD 的完整过程先听后发、边发边听早期以太网用同轴电缆做总线型拓扑多台设备挂在同一条通信介质上一台发其他全部听得到这就是“广播信道”。在这种配置下最核心的问题是如果两台设备同时往总线上发数据信号就会叠加导致互相干扰也就是冲突。解决冲突的经典算法是 CSMA/CD载波监听多点接入/碰撞检测通俗说就是“先听后说边听边说”。流程拆开看是四步先听后发发送前先监听信道上有没有别的设备在发送。如果信道忙就等信道空闲就发送。这就避免了“没看路就过马路”的撞车。边发边听发送过程中持续监听信道看有没有其他设备同时也在发导致信号电压异常。如果检测到碰撞立即停止发送。冲突停发检测到碰撞后发送方要发送一个强干扰信号阻塞信号确保所有设备都能感知到冲突。随机重发等待一段随机时间后重新尝试发送。随机时间怎么定用的是二进制指数退避第一次冲突随机等 0 或 1 个时隙第二次在 0、1、2、3 中随机选依次翻倍直到 16 次冲突就放弃。这里的时隙长度在标准以太网中是 512 比特时间也就是 51.2 微秒。为什么是 512 比特时间这就要说到最短帧长的由来了。4.2 最短帧长 64 字节的秘密它和“争用期”强相关假设一台设备 A 刚发了几个比特信道上暂时没检测到冲突但其实最远端的设备 B 也同时开始发了。A 要能检测到这次冲突必须满足一个条件A 发送的时间要足够长长到冲突信号能从 B 传回 A而 A 还在发送中。这个“往返时间”叫作争用期标准以太网把它定为 51.2 微秒对应 10 Mbit/s 下就是 64 字节的数据发送时间。所以以太网规定任何帧的最小长度必须是 64 字节从目的地址到 FCS。如果上层数据太少发不满 64 字节就要在数据字段里填充padding。这样一来A 只要发够了 64 字节还没检测到冲突就可以完全确定“我刚才发送的前半段没有被撞车”因为最坏情况下冲突信号也应该在争用期内传回来了。这 64 字节的规定不是随便拍脑袋定出来的它是物理层传输距离、链路速率和冲突检测机制之间平衡的结果。后来以太网速度从 10M 升到 100M、1000M、10G但最小帧长依然保留 64 字节靠调整网络直径和物理层编码来适应。4.3 局域网里的“组播/广播/单播”和 MAC 地址广播信道上所有设备都能收到帧但真正应该处理这个帧的只有一个或一组设备。这个“谁应该收”的判断依据就是目的 MAC 地址。MAC 地址共 48 位前 24 位是 OUI组织唯一标识符由 IEEE 分配给设备厂商后 24 位是厂商自行分配的编号。所以正常情况下全球的 MAC 地址不会重复。MAC 地址中第一个字节的最低位如果是 0表示单播地址如果是 1表示组播地址全 1 则是广播地址 FF-FF-FF-FF-FF-FF。当一台设备收到目的 MAC 与自己不符的帧时直接丢弃符合时才交给上层。这个过滤逻辑让广播信道上的通信有了秩序不是每个人都要处理每一条消息只有“点名到”的才需要响应。这一点也是后面交换机能提升效率的基础——交换机就是利用 MAC 地址来精确转发不让无关设备收到不相关的帧。5. ARP通过 IP 找 MAC网络层和链路层唯一的“接头暗号”5.1 为什么要 ARPIP 是“门牌号”MAC 是“身份证号”在网络层数据报的源和目的写的是 IP 地址但数据报落到链路层封装成帧时帧头填的目的地址必须是 MAC 地址。问题来了我知道对方 IP 是 192.168.1.10但它的 MAC 地址是什么打个比方IP 地址像门牌号它标识了一个主机在整个网络中的位置MAC 地址像身份证号它标识的是硬件本身。你想给同一个小区的某户送快递你哪怕知道他的门牌号还是得知道这栋楼每个单元的物理位置对应到 MAC 地址才能真正把快递递到人手上。ARP地址解析协议就是你查“门牌号对应的身份证号”的过程。5.2 ARP 的工作流程和缓存机制ARP 的核心流程特别简单发送方在局域网内广播一个 ARP 请求报文内容是“谁的 IP 是 192.168.1.10请把你的 MAC 地址告诉我”。局域网内所有主机都能收到这条广播只有 IP 匹配的主机会回复一个 ARP 应答把自己的 MAC 地址单播回去。发送方拿到这个 MAC 地址之后把它写入 ARP 缓存表并在内存里保留一段时间避免每次都广播。缓存时间在主流操作系统里通常为几十秒到几分钟不等。这个“时效”设计很关键MAC 地址可能因为网卡更换、虚拟机迁移等而变化如果缓存永久有效你拿着过期的 IP-MAC 映射去发帧帧就会投递给错误的设备。另外ARP 有一个必须注意的坑ARP 报文本身没有认证机制局域网里的恶意设备可以伪造 ARP 应答来“声明”自己是某个 IP 的拥有者这就会导致流量被劫持也就是常说的 ARP 欺骗攻击。实际网络维护中对网关等重要设备做静态 ARP 绑定是很多安全基线检查的强制要求。5.3 ARP 只在同一链路内有效ARP 有个边界条件它只在同一广播域内工作。如果你要访问的主机不在同一个局域网IP 层会告诉你“目的主机需要通过路由器转发”这时 ARP 解析的就不是目的主机的 MAC 地址而是下一跳路由器那个接口的 MAC 地址。因为对链路层来说帧只负责送“到下一站”不管后面的路。理解这个边界对排查“能 ping 通网关却 ping 不通外网”的问题特别重要——很多时候问题就出在网关设备的 ARP 缓存异常上。6. 以太网交换机从共享信道到隔离冲突域6.1 交换机是怎么“自学”的MAC 地址表的建立和维护早期总线型以太网用 CSMA/CD 解决冲突缺点很明显信道上设备越多发生冲突的概率越大整个网络的吞吐率惨不忍睹。交换机出现后情况彻底变了交换机每个端口后面只连一台设备或另一个交换机的一个端口一条链路只被两个端口独享冲突域被隔离到“点对点”的粒度。同一交换机的不同端口可以同时收发数据互不干扰。交换机内部维护一张 MAC 地址表记录“MAC 地址 → 交换机端口”的映射。这张表不是管理员手写的而是交换机自动学习得到的当某个帧从端口 3 进来交换机读取帧的源 MAC 地址把“该 MAC 地址对应端口 3”记录到表中并启动一个老化计时器常见的老化时间默认是几十分钟到几百秒具体看厂商和配置。下次只要有发往这个 MAC 地址的帧交换机就不需要广播了直接从端口 3 发出去。处理流程分三种已知单播直接转发未知单播目的地 MAC 不在表里就泛洪到除入端口以外的所有端口收到组播和广播帧同样泛洪。这样做的好处是效率高坏处是广播帧仍会传播到所有端口——交换机隔离了冲突域但没有隔离广播域。一个广播帧会在同一台交换机上传播到所有端口多台交换机互联时广播域还会被继续扩大这就是后来 VLAN 技术要解决的问题不过那是虚拟局域网篇的内容链路层基础篇先不展开。6.2 环路问题是二层网络最大的坑广播风暴和生成树协议交换机之间一旦形成物理环路麻烦就来了。由于广播帧会被泛洪从 A 交换机发往 B 交换机的广播帧B 又会把它发回 AA 再发给 B……这个帧在环里永远转圈瞬间就会把交换机 CPU 和链路带宽打满整个二层网络瘫痪这就是广播风暴。更隐蔽的是 MAC 地址表抖动同一个 MAC 地址一会儿在端口 1 出现、一会儿在端口 2 出现交换机学到的表项反复横跳导致帧被转发到错误的方向。解决环路的标准手段是生成树协议STPSpanning Tree Protocol。它的思路是在物理上存在环路的网络里通过算法逻辑上阻塞某些冗余端口把拓扑修剪成一棵没有环的树任何两个交换机之间只有一条逻辑通路。链路故障时阻塞端口会被自动激活实现冗余备份。实际配置中要注意直接粗暴地拔掉冗余线路可以暂时抑制广播风暴但不解决根因必须靠 STP/RSTP快速生成树来管理环路。部分场景也会用环路保护、UDLD 这类机制来做增强但生成树本身的角色选举、端口状态迁移还是需要理解的。7. 实操现场记录一次二层网络“通但不能上网”的完整排查有一次帮某公司整理一个几十台机器的小型办公网络现象很典型所有机器都能互相 ping 通网关也 ping 通但访问外网就是偶发超时。一开始我们怀疑是路由器或 DNS 的问题排查了一圈没头绪后来把目光拉回链路层发现根因很隐蔽。巡线检查时发现有一台接入交换机通过一根长网线接到了另一台交换机上而那台交换机恰好开启了一个快速上联口回连到主交换机这等于物理上形成了一个环路。没有启用 RSTP广播帧在两级交换机之间不断兜圈广播流量挤占了大量带宽导致正常的帧被延迟处理。处理办法很简单拔掉那根冗余网线后网络立刻恢复稳定随后在交换机上强制开启 RSTP并配置根桥优先级杜绝以后再发生类似问题。这个案例里有个值得记住的经验二层不通先看 MAC 地址表和学习是否正常二层“通但慢”优先怀疑环路和广播流量。如果你有网管软件可以在交换机上执行命令查看端口流量统计看广播包的占比是不是异常高——如果广播包占比超过正常水平且持续增长多半就是环路或者有网卡故障设备在疯狂发包。另外说一下CRC 错误帧过多也是很常见的问题。排查时先看交换机的错误计数器如果某个端口 CRC 错误数持续上涨通常说明连接这条端口的线缆存在质量问题、接头接触不良或近端有强干扰源。遇到这种情况直接换一条已知良好的成品网线一般就能解决。别去纠结什么参数调优物理层的钱不能省劣质线材带来的隐性丢包比任何协议配置错误都难查。8. 链路层的排障工具清单与经验速查表排障时我用得最多的命令和工具就三类看 MAC 地址表的交换机命令、抓包分析的 Wireshark 过滤器、以及操作系统的 ARP 命令。先把这些基础工具用熟比你背一百个协议细节都管用。本机查看 ARP 缓存Windows 用 arp -aLinux 用 ip neigh show。当确认 IP 通但 MAC 不对时果断清缓存Windows 下 arp -dLinux 下 ip neigh flush all。要注意操作权限普通用户执行这些命令可能被拒绝。清完之后重新触发一次通信看看 ARP 是否能正确地学习到新映射。交换机上查看 MAC 地址表不同厂商命令不一样但思路相同。某类主流交换机的命令是 show mac address-table你重点看这个 MAC 是从哪个端口学到的、老化时间还剩多少。如果设备明明连在 Access 口上MAC 却从另一个端口学到基本可以推断有环路或者接线错误。再配合 show interface status、show interfaces counters 来检查端口速率、状态和错误包计数一套组合拳下来大多数链路层问题能定位到八九不离十。Wireshark 里建议直接抓以太网头先过滤 arp 看解析过程再过滤 icmp 看连通性。遇到“arp 请求发出去了但没人应答”的情况通常说明目标主机不在同一广播域或者目标主机的防火墙过滤了 ARP 报文虽然比较少见但确实存在。遇到“arp 应答正常但 icmp 超时”那问题可能就不在链路层而在上层防火墙或路由策略了。最后整理一个我自己常用的速查表分享给新人排查链路层问题时对着检查现象可能原因排查动作网线插上但端口灯不亮线缆损坏、对端端口禁用、速率不匹配换线、检查端口 shutdown 状态端口灯亮但 ping 不通VLAN 配置错误、交换机 MAC 地址表异常检查接口类型、查看 MAC 表网络慢且广播包极高二层环路、故障网卡疯狂发包检查生成树状态、端口流量统计CRC 错误数持续增长线缆质量问题、接头氧化、近端干扰更换线缆、清洁接头ARP 解析异常ARP 欺骗、缓存过期、IP 冲突静态绑定、清 ARP 缓存时通时不通双工不匹配、网线劣质、端口协商失败固定速率/双工、换线9. 关于链路层的一些个人体会链路层是整个网络体系里最“硬”的一层因为它直接和物理硬件打交道很多问题用协议分析不如用示波器和巡线来得直接。我踩过几次坑之后的感受是遇到二层问题先假设“物理层是好的、线缆是好的”是最大的误区。实际工作中一半以上的链路层故障最后的根因都落在线缆质量、接头松动、端口协商异常这些“不优雅”的地方而不是协议本身出了问题。理解链路层的三个基本问题时我建议你把“帧”这个单位时刻放在心里链路层的一切工作都围绕帧的构造、校验、转发和丢弃来展开。如果你能从“数据报和帧的区别”出发把网络层“尽力而为”的交付和链路层“一跳一跳”的封装关系梳理清楚那么这个系列的知识就真正打通了。后面再往上聊传输层的可靠传输、应用层的各种协议你回头看链路层的这些机制会更有“底层自信”。