书接上文，说是初探，笔者也不准备二探，准备用一弹的篇幅浅谈下链路层相关内容。后续涉及其他内容时，如有必要，再对链路层进行稍稍深入的介绍。
插播条冷知识——空灵狮子鱼
目前已知深海鱼深度记录（来自海底8178m的微笑，你是要下地啊！）
回到正题，全系列会按照原书结构对网络协议由底层向顶层依次介绍。
先看图，图中可看出，四层协议，如果脱离链路层提供的最基本的硬件实现，那剩下三兄弟就只能是空中楼阁。
图中与链路层直连的三个箭头，分别表示链路层三个主要目的：（1）为IP模块发送接收数据报；（2）为ARP模块发送接收ARP请求与应答；（3）为RARP模块发送接收RARP请求与应答；它始终兢兢业业地为上层提供可靠地服务。
随手拿起一盒路由器，它内部就封装着“链路层”。接下来笔者对常见链路层进行介绍。
首先，就是以太网，这是极其常见的一种局域网技术。由于这项技术出现早，再配合业界巨头的推动，它很快成为标准。但遗憾的是，IEEE后续亦公布一个稍有不同的标准集（IEEE 802标准集），于是局域网中就需要兼容两种帧格式的封装，见下图。
笔者一个一个和大家坐在摇椅上慢慢聊……
首先是最简洁那个，即以太网标准，现在大多数局域网的事实标准（之所以它会成为事实标准，是因为懒是人类原罪，大家都不想对“遗产”大动干戈）。上图中三种类型帧格式的实际内容均是以一对48bit（6字节）的地址（目的地址和源地址）开头，它们被称为硬件地址，也就是我们所熟知的MAC地址（上文提及的ARP、RARP提供的就是物理地址与IP地址相互映射的服务）。区别始于后续两个字节，以太网帧格式定义的是类型字段（用于区分上层协议，即IP、ARP、RARP等），紧接着类型字段后，以太网帧格式中很干脆地接续上数据。简洁、高效，但不够全面。
于是，我们把目光拉到第二种帧格式，即802.3 LLC标准。与上段文字相比，第一点不同在于MAC地址后跟随的类型字段变成长度字段（帧信息进一步完善，该长度指后续数据的字节长度，不包括FCS即检验和字段），紧随长度字段的即3字节LLC（Logical Link
Control，逻辑链路控制）字段。此处我们暂停，稍作扩展，解释两个名词LLC和MAC——其实网络链路层于802.3标准下能够被进一步细化为两个子层：
[if !supportLists]1. [endif]LLC即逻辑链路控制子层，负责识别网络层协议，并对其进行封装与分用，为上层提供处理任何类型MAC层的方法，面向上层负责。LLC包括目的服务访问点（DSAP）、源服务访问点（SSAP）、Ctrl字段。前两者被称为SAP，用于完成以太网中类型字段识别上层协议的工作。Ctrl字段定义数据通信操作类型（值为1——无连接；值为2——面向连接；值为3——无连接应答响应服务。Tips：不继续展开，因已超纲，笔者力有不逮）。
[if !supportLists]2. [endif]MAC介质访问控制子层（一直说MAC，不知道大家有木有去思考过它是啥？反正笔者以前没想过），负责数据帧的封装、卸载及相应动作，面向底层即物理层负责。
LLC标准貌似已解决所有问题，然而问题总是伴随着问题的解决——替代类型字段作用的SAP太短（短？我招谁惹谁了……），能标识的类型有限，于是第三种帧格式粉墨登场，即802.3
SNAP标准。于全新的帧格式中新增5字节SNAP（实际属于LLC进一步细化的子层）字段，然后在她身后跟着可怜兮兮被冷落许久的数据。SNAP作为LLC的升级扩展，使用SNAP时，我们需要把LLC子层的服务访问点（DSAP）、源服务访问点（SSAP）均设值为0xaa，并且把Ctrl字段设值为3。SNAP中包含俩字段，TYPE字段用于标识更多的上层协议类型，OUI字段代表不同组织（笔者洪兴的，你们搁哪混的？）。
数据帧最后是FCS检验和字段，有关她的算法，笔者会单独开篇。
上图中PR（Preamble，同步位，用于收发双方时钟同步，同时也指明传输速率)、SD（分隔位，表示本人以后才是真实帧数据）字段，大家无需过多纠结（知道太多对你没好处，当然你要一头扎进去笔者也是支持的）。
呃，下大雪，要上班，想一篇完结，很无力，只能分上下篇咯……
下篇预告：串行链路SLIP、回环接口与MTU
