简介：这份文档面向网络初学者与嵌入式开发入门者，系统梳理网络基础中物理层与数据交换的核心概念，帮助读者建立从比特流到协议栈的完整认知框架。内容围绕数据封装与解封装的全过程展开，对比电路交换、报文交换与分组交换的差异，并讲解同轴电缆、双绞线、光纤等传输介质及以太网标准、冲突域与CSMA/CD机制，配合快递包裹式比喻降低理解门槛。资源包共1个docx文件，约3.46MB，以图文笔记形式组织，便于按章节查阅与复习。已有104人学习，适合需要夯实网络底层原理、准备嵌入式网络开发或面试复盘的技术人员参考，可从中获得数据交换方式的对比思路、封装流程的直观理解以及物理层常见介质与以太网规范的要点整理。
1. 从一根同轴电缆说起：这份网络基础笔记到底补的是哪块底
很多人学 Ethernet 和 tcpip 是从三次握手、四次挥手开始的，协议栈背得滚瓜烂熟，真到板子上抓包却一脸问号：为什么两块开发板接在同一个交换机上，ping 的延迟忽高忽低？为什么换了一根线，链路就起不来？问题往往不在 TCP，而在更下面那层——物理层和链路层。这份《网络基础物理层详细讲解》文档，讲的就是这层“黑匣子”：数据怎么从应用层一路封装成 0101 比特流、怎么通过网卡和传输介质发出去、电路交换/报文交换/分组交换到底差在哪、同轴电缆上的冲突域和 CSMA/CD 是怎么工作的。它适合刚接触嵌入式网络、想搞懂“网线里到底跑的是什么”的从业者，也适合带新人时当一份能照着讲的底稿。文档不是协议手册，而是把封装解封装、交换方式、传输介质三件事串成一条线，读完你能对着自己的板子说清楚每一层在干什么。
2. 三种数据交换方式：电路、报文、分组到底怎么选
2.1 电路交换：先占线再说话，代价是独占
电路交换的核心动作是“建立连接—传输—释放连接”。通信双方在真正发数据之前，先维护一条逻辑电路，这条线路只传你的数据，不传别人的。好处是路径固定、时延稳定、顺序有保证；坏处也很直接：某一时刻不通信了，这条逻辑电路还占着，别人用不了。文档里把这个缺点点得很透——它不是“慢”，而是“占着茅坑不拉屎”式的资源浪费。
放到嵌入式场景里理解：电路交换像你打电话，拨通之后这条话路就归你，哪怕你沉默十秒，别人也打不进来。传统电话网就是典型电路交换。它的选型理由只有一个——对连续性、实时性要求极高且流量稳定的场景。但凡你的数据是突发的、间歇的，电路交换的利用率就会很难看。
2.2 报文交换：加标识解决混乱，但大小不受控
报文交换要解决的是“多台设备想同时用同一条线路”的问题。做法是给每份数据加一个标识，接收端根据标识判断这份数据从哪来、到哪去，这样多路数据混在一条链路上也不会传乱。文档里说得很直白：为了提升效率，采用标识，每个人把自己要传输的数据加个标识。
但报文交换留了个尾巴——整份报文作为一个单位转发，大小没有上限。一份大报文在中间节点排队时，会把后面的小报文堵住，这就是存储转发带来的时延抖动。对嵌入式设备来说，内存本来就紧张，一个不受控的大报文足以把接收缓冲区撑爆。所以报文交换更像一个“能用但不精细”的中间形态，真正落地的是它的升级版。
2.3 分组交换：定长分片 + 标识，把公平性拉回来
分组交换在报文交换的基础上多做了一件事：给每个数据段定一个大小上限，先做分片，每片带标识，标明从哪个设备到哪个设备。文档原话是“将每个数据的大小进行定义，先做一个分片，每个数据段的值是有一个上限值的，同时加一个标识”。这样多台设备就能共用同一条链路，数据紊乱的问题解决了。
但分片之后又冒出一个新问题——不公平。数据大小不一致时，大流量会把小流量挤掉。解决办法是规定一个固定值，每次只传这么大的值，也就是定长分组。到这里，物理层接手：分组加上报头，通过网卡/口传输，走传输介质，最终在线上跑的都是 010101 的比特流。
三种方式放一张表对比，选型时对着看：
| 交换方式 | 是否建立连接 | 数据单位 | 资源占用 | 典型问题 | 适用场景 |
|---|---|---|---|---|---|
| 电路交换 | 是，先建后传 | 连续比特流 | 独占，空闲也占 | 利用率低 | 实时连续、流量稳定 |
| 报文交换 | 否 | 整份报文，无上限 | 存储转发 | 大报文阻塞、时延抖动 | 早期电报类、非实时 |
| 分组交换 | 否 | 定长分片 + 标识 | 统计复用 | 分片重组、公平性调度 | 现代数据网络主流 |
提示：分组交换的“定长”不是指所有网络都用同一长度，而是每段有上限、按固定规则切分。理解这一点，后面看以太网帧格式才不会把 MTU 和分片长度搞混。
3. 封装与解封装：一个快递包裹的完整旅程
3.1 封装是从上往下套盒子
文档用快递包裹打比方：包装盒里塞了很多东西，最终对方要的只是里面的小物件，这个小物件就像应用层的数据。封装就是从上层到下层，一层层往下套盒子——应用层数据交给传输层加端口头，交给网络层加 IP 头，交给链路层加帧头帧尾，最后到物理层变成比特流发出去。
这个比喻的价值在于让你记住方向：封装是自上而下，每层只关心自己那层的头，不关心上层数据长什么样。嵌入式里写网卡驱动时，你操作的就是最外面那层“盒子”——把上层递下来的缓冲区前面预留好帧头空间，填好目的 MAC、源 MAC、类型字段，再交给 DMA 发出去。
3.2 解封装是从下往上拆，逐层校验
接收端反过来：物理层收到比特流，链路层按帧边界切出来校验 FCS，网络层看 IP 头判断是不是给自己的，传输层按端口号分发给对应应用，最后应用层拿到那个“小物件”。文档说“对于接收者而言，只是把数据拆开看看，没问题就行了”，这句话背后其实藏着校验动作——每层拆的时候都要检查本层的头是否合法，不合法就丢弃，不会往上递。
用一段伪代码把封装过程落到纸面上，方便对照自己的驱动代码：
/* 以以太网发送一帧为例，展示封装顺序，非完整驱动 */ struct eth_hdr { uint8_t dst_mac[6]; /* 目的 MAC，链路层寻址 */ uint8_t src_mac[6]; /* 源 MAC */ uint16_t ethertype; /* 上层协议类型，如 0x0800 表示 IPv4 */ }; int eth_send(uint8_t *payload, uint16_t len) { uint8_t *frame = alloc_frame(len + sizeof(struct eth_hdr) + 4); if (!frame) return -1; struct eth_hdr *hdr = (struct eth_hdr *)frame; memcpy(hdr->dst_mac, dst, 6); /* 填目的地址 */ memcpy(hdr->src_mac, own, 6); /* 填源地址 */ hdr->ethertype = htons(0x0800); /* 标明上层是 IP */ memcpy(frame + sizeof(struct eth_hdr), payload, len); /* 装上层数据 */ append_fcs(frame, len + sizeof(struct eth_hdr)); /* 尾部加校验 */ return nic_transmit(frame, len + sizeof(struct eth_hdr) + 4); /* 交给网卡 */ }逻辑说明：这段代码把“套盒子”拆成三步——先在最前面留出帧头并填好寻址信息，再把上层递下来的 payload 原样拷进去，最后在尾部补 FCS 校验。参数上，ethertype决定接收端把数据交给哪个上层协议，填错就会出现“包发出去了但对端不认”的现象；len是上层数据长度，不含帧头帧尾，计算缓冲区大小时千万别漏掉那 4 字节 FCS，这是新手最常见的越界来源。
3.3 最小网络三要素：网线、网卡、协议栈
文档给了一个很实用的归纳：网络诞生前是刻录，网络诞生后是网线、网卡、协议栈，这三样凑齐才叫一个能跑起来的最小网络。网线上跑的是比特流，网卡负责数模转换和链路层收发，协议栈（现在几乎都是 tcp/ip，集成在设备里）负责上面几层的拆装。只要你买的设备跟网络相关，基本都支持 tcp/ip，这句话对嵌入式选型很有参考价值——很多 SoC 自带 MAC，外接一个 PHY 就能起以太网，协议栈用现成的 lwIP 之类即可，不必从零造。
4. 传输介质与冲突域：同轴、双绞线、光纤怎么挑
4.1 同轴电缆：共享型网络与它的历史包袱
同轴电缆是早期有线电视那套线路，要实现多设备互联，可以用耦合器，每个接口下接一个设备，画出来就是一根线上挂多个设备。文档点出它的本质：同轴电缆中所有设备共享一根网络线，称为共享型网络。缺点两条——传输速度慢，没有私密性可言。
以太网标准里有个经典命名 10BASE5：10 表示每秒传 10M，BASE 表示基于某种标准在同轴电缆上进行曼彻斯特编码传输，5 表示传输距离 500 米。这套命名规则值得记住，后面看到 100BASE-TX、1000BASE-SX 就能拆开读：速率、编码/介质类型、距离或介质代号。
共享型网络带来的直接后果是冲突域。设备互相传输会产生数据碰撞，数据在这个范围内碰撞，这个范围就叫冲突域。设备越多，冲突域越大，传输越慢。这是同轴电缆被淘汰的根本原因，不是单纯因为贵。
4.2 CSMA/CD：先听后发、边听边发、冲突停发、随机重发
避免冲突靠 CSMA/CD，载波侦听多路访问/冲突检测。文档把四步讲得很清楚：
- 先听后发：设备先去听线上有没有电压摆动值，线是静止的才开始发。
- 边听边发：发送过程中持续监听，因为可能两台设备同时听到线静止，同时开发。
- 冲突停发：一旦检测到线上有电压摆动（说明别人也在发），立即停止发送。
- 随机延迟后重发：用退避算法算一个值，比如 10 秒内不发，10 秒后再去听线是否被占用，空闲再发。
这四步里最容易翻车的是退避时间的理解。退避不是固定 10 秒，而是一个随机区间，冲突次数越多区间越大，目的是让同时冲突的设备错开重试，避免再次撞车。嵌入式里如果自己实现简易链路层，退避参数设小了会反复冲突、吞吐骤降，设大了又浪费带宽，常见做法是按冲突次数做二进制指数退避。
4.3 双绞线与光纤：从 UTP/STP 到千兆八线全用
双绞线分 UTP 非屏蔽和 STP 屏蔽两种，5 类、6 类指的是双绞线的类型。文档特别提了一句：双绞线如果是千兆，那么八根线都用了。这句话是实操里的关键——百兆只用了 4 根（1、2、3、6），千兆要把 8 根全接上，做水晶头时少压一根，链路就协商不到千兆，甚至直接 down。这是血泪经验级别的细节，很多现场“网线是好的但速率上不去”就是压线顺序或线序不对。
光纤部分文档只起了个头，但选型逻辑可以补全：同轴已基本退出数据网络，双绞线适合短距离（百米内）桌面和板级互联，光纤适合长距离、抗干扰要求高的场景。嵌入式板子上如果只有 RJ45，先确认变压器和 PHY 支持的最高速率，再决定用 5 类还是 6 类线，别拿超规格线材去配一个百兆 PHY，钱花了速率还是百兆。
5. 避坑与排查：物理层最容易翻车的五个地方
5.1 现象：链路灯亮但 ping 不通
原因：链路层 up 只说明物理连接建立，不代表帧能正确收发。常见是 MAC 地址配错、VLAN 没对上，或者收发方向搞反。解决：先用抓包工具看本机有没有发出 ARP 请求，再看对端有没有回。发得出去收不回来，重点查对端 MAC 和交换机端口配置；根本发不出去，查网卡发送描述符和 DMA 配置。
5.2 现象：千兆协商成百兆
原因：双绞线八根没全接、线序错误，或者水晶头压接不良。文档明确说千兆八根线都用。解决：用测线仪逐根测通断，重点看 4、5、7、8 这四根；换一根成品六类线对比验证，排除是线材还是压接问题。
5.3 现象：多设备共享链路时吞吐忽高忽低
原因：冲突域过大，CSMA/CD 退避频繁触发，或者分片大小设置不合理导致大流量挤占小流量。解决：能换交换机的场景就别用共享型拓扑，交换机能隔离冲突域；必须共享时，检查退避参数和分组定长值，把单次传输上限压下来，减少单设备长时间占线。
5.4 现象：大报文接收时缓冲区溢出、数据丢尾
原因：报文交换思维残留，没做分片或分片上限设得比接收缓冲区还大。解决：按分组交换的思路给每段定上限，接收端预留重组空间；驱动里检查 DMA 描述符数量和单缓冲大小是否匹配 MTU，别让一个超长帧把环形缓冲区绕一圈覆盖掉未处理数据。
5.5 现象：封装后发出的帧对端不认
原因：ethertype填错、FCS 计算范围漏了帧头，或者字节序没转换。解决：对照抓包结果逐字段核对，重点看类型字段是不是网络字节序、FCS 是否覆盖了从目的 MAC 到 payload 末尾的全部内容。这类问题用抓包工具一看帧结构就现形，比盲改代码快得多。
6. 把这份笔记用起来：从读懂到能对着板子讲
文档本身是讲解型材料，不是代码包，所以“用起来”的重点不是跑脚本，而是把它变成你调试时的对照表。我的习惯是：拿到一块新板子，先按文档的三要素清单过一遍——网线通不通、网卡 PHY 有没有起来、协议栈有没有跑通，三样缺一样就先别往上查 TCP。然后拿三种交换方式的表对照当前业务：如果是周期性小数据采集，分组交换的定长思路最合适；如果是音视频流这类连续业务，才去考虑电路交换式的资源预留。
验证方法上，可以做一个最小实验：两块板子直连，一端持续发定长分组，另一端统计收包数和乱序数，逐步调大单包长度，观察在哪个长度上开始丢包——这个临界值基本就是你链路和缓冲区的真实上限，比看手册上的理论值靠谱。再抓一次完整封装过程的包，从以太网帧头一路看到应用层数据，把每一层的头字段和文档里的描述对上，对不上的地方就是你没吃透的地方。
有个细节我踩过：早期总以为“封装”只是加头，忽略了尾部 FCS 和帧间间隔，结果自己拼的帧在真实网卡上就是发不出去，查了半天才发现是帧长度不满足最小帧要求。从那以后我每次碰链路层代码，都强制先用抓包工具看一眼真实帧长和字段布局，再动手改。这份文档的价值就在于它把这条从比特流到应用数据的链路讲成了一条能走通的线，而不是散落的知识点。希望帮到你。
本文还有配套的精品资源，点击获取
