简介这是一份聚焦网络基础物理层与数据交换原理的DOCX学习资料面向网络入门者、嵌入式开发学习者以及需要夯实TCP/IP底层概念的读者。内容围绕数据封装与解封装全过程展开对比电路交换、报文交换、分组交换的差异并延伸到网线、网卡、协议栈三要素以及同轴电缆、双绞线、光纤等常见传输介质。文中还结合以太网10BASE5标准、共享型网络、冲突域与CSMA/CD机制解释先听后发、边听边发、冲突停发和随机延迟后重发的思路并说明多设备共享链路时的传输公平性与分片转发问题适合梳理概念与复习底层通信流程。压缩包共1个DOCX文件约3.46MB查阅方便也可直接做学习笔记。已有106人学习可帮助读者建立从应用层数据到物理层比特流的完整认识理解封装如快递包裹、逐层拆解校验的过程。1. 物理层不是“玄学”从一根网线开始把网络基础打穿很多人学网络从 TCP/IP 四层模型开始学到物理层就一句“传输比特流”带过结果一上设备就翻车网线接了不通、抓包看不到任何东西、同轴电缆上一多接设备就全部变慢。这份《网络基础物理层详细讲解.docx》的价值就在于它没有停在概念层而是把电路交换、报文交换、分组交换的区别以及同轴电缆、双绞线、光纤这些介质怎么影响实际传输一条线串了下来最后落到以太网标准和 CSMA/CD 的工作机制上。如果你正在做嵌入式联网、工业现场布线或者单纯想把 tcpip 协议栈底下的那层“黑匣子”拆开看看这份资料适合当成第一遍通读的底稿。2. 拆解三种数据交换为什么最后活下来的是分组交换2.1 电路交换、报文交换、分组交换的本质差异物理层之上最先要理解的问题是两台设备之间到底怎么把数据送过去。资料里把交换方式分了三类这个分类不是考试名词而是直接决定了你后面看到的网络行为。电路交换的思路最直白——通信之前先建立一条逻辑电路这条线路在通信期间只归你使用别人无法占用。好处是传输稳定、时延固定坏处也很明显不通信的时候线路仍然被占着别人用不了。这就是早期电话网的做法放到今天看它的问题不是技术落后而是资源利用率太低。你在嵌入式场景里如果用过某些专线式的串口通信其实本质上就是电路交换的思维链路建立后独占可靠但浪费。报文交换为了解决共享问题引入了“标识”的概念。多台设备同时想用同一条线路时各自把要发的数据加上标识再送出去接收端根据标识区分是谁的数据。这样一来线路可以共享了但报文大小不受限制一个大报文会把线路占很久别的设备只能干等转发公平性无从谈起。分组交换是在报文交换基础上加了一个关键约束把数据切成分片每个分片有大小上限同时带上标识说明从哪台设备到哪台设备。资料里说得很清楚——“我们规定一个大小固定值每次只传输这么大的值”。这一刀切下去解决了数据紊乱也让多设备共享链路成为可能。但分组交换不是没有代价分片带来额外报头开销路径不同可能导致乱序实时性要求高的场景反而不如电路交换稳。下面这张表把三者在实际工程里的差异拉平来看交换方式是否独占链路数据单位时延特征典型场景电路交换是比特流固定、可预测传统语音、专线报文交换否整段报文波动大早期电报、部分工业总线分组交换否定长/变长分片统计复用、有抖动以太网、IP 网络选型理由不需要背记住一句话就行只要你的设备要接入现代以太网底层跑的就是分组交换分组大小和报头开销会直接影响你的有效吞吐。后面配网卡、调 MTU 的时候这个认知会反复用到。2.2 用一段 Python 模拟分片与标识看清转发逻辑光看文字容易飘实际动手把分组交换的核心逻辑跑一遍印象会深很多。下面这段代码模拟的是一条链路上有多台设备要发数据每个数据被切成分片并打上源/目的标识接收端按标识重组。重点不在代码本身而在分片大小和标识字段怎么影响“谁先被转发”。# 模拟分组交换中的分片与标识转发 # 重点观察分片大小如何影响转发顺序和公平性 FRAGMENT_SIZE 4 # 每个分片的最大数据单元可改成 2/8/16 观察差异 devices { A: 来自设备A的应用数据需要发往设备D, B: 来自设备B的一小段控制指令, C: 来自设备C的日志上报数据长度介于两者之间 } def fragment(src, payload): 把原始数据按固定大小切片并打上源设备标识 fragments [] for i in range(0, len(payload), FRAGMENT_SIZE): chunk payload[i:i FRAGMENT_SIZE] # 标识字段源 分片序号接收端靠它重组 fragments.append({src: src, seq: i // FRAGMENT_SIZE, data: chunk}) return fragments def forward_round_robin(fragment_list): 轮询转发模拟多设备共享链路时的基本公平调度 queues {src: frags[:] for src, frags in fragment_list.items()} order [] while any(queues.values()): for src in queues: if queues[src]: order.append(queues[src].pop(0)) return order frag_dict {src: fragment(src, payload) for src, payload in devices.items()} forwarded forward_round_robin(frag_dict) for f in forwarded: print(f[{f[src]} #{f[seq]}] {f[data]})这段代码要做三件事第一FRAGMENT_SIZE决定了每个分片能带多少数据改小会让报头占比升高、分片数量变多第二fragment里的seq相当于分组交换里的序号标识接收端靠它判断顺序第三转发用轮询而不是谁先来谁先走是在模拟链路共享时的基本公平性。你如果真跑一遍把FRAGMENT_SIZE从 4 改成 16会看到 C 设备的长数据被切得更少A 的短数据反而排到了后面——这就是资料里说的“数据大小不一致时出现不公平”的具体表现。实际以太网里解决这个问题靠的是更复杂的队列调度但根子就在这里。2.3 分片带来的现实参数MTU 与报头开销分组交换落到以太网上最直接的参数就是 MTU最大传输单元。默认 1500 字节不是随便定的它和以太网帧格式、物理介质特性都有关系。资料里没有展开 MTU 计算但在嵌入式网络配置里这是绕不开的。常见做法是这样如果你的设备走以太网MTU 保持 1500如果中间经过某种封装比如 VLAN 标签、隧道有效 MTU 会变小分片策略要跟着调。一个以太网帧的报头包括目的 MAC6 字节、源 MAC6 字节、类型2 字节加上帧校验 4 字节实际每帧额外开销至少 18 字节。按 1500 字节有效载荷算报头占比大约 1.2%但如果你把分片设成 64 字节报头占比立刻冲到 20% 以上有效吞吐明显下降。这也是为什么调小分片能降低单次转发时延却会牺牲带宽利用率——参数没有绝对好坏看你的场景更在意哪一头。提示嵌入式设备上报小数据包时不要盲目把 MTU 调大。链路中间如果有交换机不支持巨帧大包会被丢弃或分片表现就是“能 ping 通但传文件就断”。3. 封装与解封装数据从应用到比特流到底经历了什么3.1 封装是从上到下解封装是从下到上资料里用快递包裹打比方快递盒里塞了很多东西接收方真正要的只是里面的小物件那个小物件就像应用层数据。封装就是一层层套盒子解封装就是一层层拆盒子。这个比方不新鲜但关键细节在于每一层加的“盒子”里装的不是废话而是下一层需要读的控制信息。从应用数据往下走传输层加端口号TCP/UDP 头网络层加 IP 地址IP 头数据链路层加 MAC 地址和帧校验以太网帧头帧尾物理层把整个帧变成 010101 的电信号或光信号送上网线。反过来接收端从物理层收到比特流网卡按帧格式切出来检查目的 MAC 是不是自己是就往上送网络层看目的 IP传输层看端口最后应用层拿到数据。这个过程里任何一层剥错了上层就拿到垃圾数据。真正需要动手确认的是封装顺序不是理论你在 Linux 上用抓包工具看到的每一层头部就是封装留下的痕迹。下一节用 Scapy 构造一个完整以太网帧把“套盒子”的过程变成可观察的字节。3.2 用 Scapy 构造以太网帧看清每层头部# 用 Scapy 构造一个完整的以太网帧逐层观察封装结果 # 运行前需安装pip install scapy from scapy.all import Ether, IP, UDP, Raw # 逐层封装以太网头 - IP 头 - UDP 头 - 应用数据 pkt ( Ether(dstff:ff:ff:ff:ff:ff, src00:11:22:33:44:55, type0x0800) / IP(src192.168.1.10, dst192.168.1.20, ttl64) / UDP(sport5000, dport6000) / Raw(loadbhello-physical-layer) ) # 打印各层头部字段确认封装顺序 pkt.show() # 输出原始字节观察物理层最终要发送的 0101 序列长度 raw_bytes bytes(pkt) print(帧总长度字节:, len(raw_bytes)) print(前 14 字节以太网头:, raw_bytes[:14].hex())这段代码的重点是pkt.show()的输出你会看到 Ether 层、IP 层、UDP 层、Raw 层依次排列和资料里“从上层到下层”的顺序完全对应。type0x0800是告诉网卡“里面装的是 IPv4”换成 0x0806 就是 ARP。ttl64是 IP 头的生存时间每过一个路由器减一减到零就丢弃这个字段在排查环路时很有用。最后打印的帧总长度里以太网头 14 字节、IP 头 20 字节、UDP 头 8 字节剩下才是应用数据——报头开销一目了然。如果你把这段字节流真的从网卡发出去scapy 的sendp对端抓包看到的就是同样的结构前提是物理链路和网卡驱动都正常。物理层出问题的时候这段代码会在发送阶段直接报错反而成了快速判断“到底是协议栈问题还是链路问题”的手段。3.3 网卡、协议栈与传输介质的最小三要素资料里有一句话很关键网络诞生后网线、网卡、协议栈称为“想要完成最小网络的三要素”。这句话放到嵌入式开发里就是排查顺序——先看物理链路网线/接口再看网卡驱动和 MAC 控制器最后看协议栈配置。网线负责比特流传输网卡负责把比特流和帧互相转换协议栈负责按层解析。现在大多数设备的 TCP/IP 协议栈是集成好的只要网卡能工作协议栈通常不会出大问题反过来物理层接触不良、线序错误、光模块不匹配协议栈再怎么配也通不了。我一般排查联网故障时第一步永远是看物理层指示灯和链路状态而不是先去翻 IP 配置。注意有些嵌入式板卡的网卡 PHY 芯片需要正确配置自协商如果对端交换机强制了百兆全双工而本端还在自协商链路可能起来但丢包严重。这种问题抓包看不出来只能靠 ethtool 看协商结果。4. 以太网标准与 CSMA/CD同轴电缆时代的遗产为什么还要学4.1 10BASE5 拆解一个标准名里藏了三个参数资料里出现了 10BASE5这个命名不是乱码每个部分都有含义10 表示每秒 10M10 MbpsBASE 表示基带传输在同轴电缆上进行曼彻斯特编码5 表示传输距离 500 米。把这个标准拆开看你就明白早期以太网的设计约束速度低、距离有限、编码方式决定了信号频谱。同轴电缆时代的网络叫共享型网络所有设备挂在同一根线上数据发出去所有设备都能收到没有私密性可言。更要命的是冲突问题两台设备同时发送信号在线上叠加谁都读不出来。这个范围就叫冲突域。设备越多冲突概率越高传输越慢冲突域也就越大。资料里说“设备越多传输越慢冲突域也就越大”这句话在今天看依然成立——你把一堆设备塞进同一个冲突域比如一个不划分 VLAN 的 hub 环境性能下降是必然的。4.2 CSMA/CD 的四步动作与退避算法CSMA/CD载波侦听多路访问/冲突检测是共享型以太网解决冲突的核心机制资料里把它拆成四步先听后发、边听边发、冲突停发、随机延迟后重发。这四步放到实际链路上理解第一设备发送前先听线上有没有电压摆动线静止才发第二发送过程中继续听因为可能别的设备也同时判断线是静的然后一起发第三一旦检测到冲突立刻停止发送避免继续浪费带宽第四用退避算法算一个随机延迟等一段时间再重试。资料里举例说“计算一个值比如 10s10s 内不往线上发10s 后再次去听线上是否还是被占用”这是简化说法实际二进制指数退避的等待时间随冲突次数增加而翻倍目的是让冲突设备错开重试时机。下面这段伪代码把 CSMA/CD 的判断逻辑写清楚方便你对照资料理解# CSMA/CD 简化逻辑用于理解四步动作的先后关系 import random def csma_cd(link_busy, collision_count): # 第一步先听后发 if link_busy: return 等待链路空闲 # 第二步边听边发发送过程中可能检测到冲突 collision_detected random.random() 0.2 # 模拟冲突概率 if collision_detected: # 第三步冲突停发 # 第四步二进制指数退避等待时间随冲突次数翻倍 backoff random.randint(0, 2 ** min(collision_count, 10) - 1) return f冲突退避 {backoff} 个时间片后重试 return 发送成功 # 模拟连续冲突后的退避窗口变化 for n in range(5): print(f第 {n} 次冲突后:, csma_cd(link_busyFalse, collision_countn))这段代码里2 ** min(collision_count, 10)对应退避窗口上限随冲突次数指数增长上限截在 10 次是为了避免窗口无限大。实际以太网里这个机制在双绞线交换式网络普及后已经基本不触发——因为交换机每个端口是独立冲突域全双工模式下根本不会冲突。但理解它仍有价值第一它解释了为什么早期共享式 hub 网络性能差第二嵌入式设备如果工作在半双工模式冲突计数会直接反映链路质量。4.3 冲突域与广播域的边界在交换机上怎么确认冲突域和广播域是两个容易混的概念。冲突域是物理层信号互相碰撞的范围广播域是广播帧能到达的范围。交换机每个端口隔离冲突域但不隔离广播域路由器两边既隔离冲突域也隔离广播域。资料里提到冲突域但没展开广播域实际配网时这两个都要看。在 Linux 设备上确认冲突域边界最直接的方法是看接口的双工模式和错误计数# 查看网卡协商速率、双工模式、链路状态 ethtool eth0 # 查看冲突和丢弃计数冲突计数非零说明可能存在半双工或共享链路 ip -s link show eth0 # 查看当前接口是否处于全双工Full还是半双工Half ethtool eth0 | grep -E Speed|Duplex|Link detectedethtool eth0输出里的Duplex: Full表示全双工此时不会发生冲突如果显示Half说明链路按半双工在工作CSMA/CD 机制仍然生效。ip -s link show eth0里的collisions计数如果持续增长基本可以断定链路上有半双工设备或者线缆质量问题。我遇到过现场交换机端口被手动设成半双工、终端自协商成千兆全双工的情况表现是时通时断、大包必丢最后就是靠这两个命令定位的。5. 传输介质选型与端接同轴、双绞、光纤的工程参数5.1 同轴电缆、双绞线、光纤的对比与耦合器用法资料里列了三种介质同轴电缆、双绞线、光纤。选型时不能只看“哪个快”要把距离、成本、抗干扰、施工难度一起算。同轴电缆早期用于有线电视网络多设备互联时可以用耦合器每个接口下接一个设备一根线上承载多个设备。它的优点是屏蔽性好、传输距离远缺点是贵、布线笨重而且共享型结构带来冲突问题。双绞线分 UTP非屏蔽和 STP屏蔽5 类、6 类指的是线缆类别类别越高支持带宽越高。资料里特别提到“双绞线如果是千兆那么八根线都用了”——百兆只用到 4 根1、2、3、6千兆必须 8 根全接这也是现场做水晶头时最容易翻车的地方按百兆线序做完插到千兆口上要么降速到百兆要么直接不通。光纤抗干扰最强、距离最远但端接和光模块成本高适合骨干链路和强电磁环境。把关键参数拉成表介质典型距离抗干扰成本常见坑同轴电缆500 米10BASE5较好高共享冲突、耦合器接触不良双绞线 UTP100 米一般低千兆需 8 芯全接、线序错双绞线 STP100 米较好中屏蔽层需正确接地光纤几公里到几十公里强高光模块波长不匹配、端面污染5.2 千兆双绞线的线序与验证命令双绞线做头子这件事翻车率远比想象中高。百兆只用 1、2、3、6 四根千兆必须 8 根全通而且线序要按 T568B 或 T568A 统一。常见错误是两端线序不一致——一端 T568B、另一端 T568A短距离百兆可能还能通千兆直接协商不上。验证方法不用拆线用 ethtool 看协商结果就够了# 确认是否协商到千兆全双工 ethtool eth0 | grep -E Speed|Duplex # 如果只协商到 100Mb/s检查网线是否 8 芯全通 # 查看支持的模式确认网卡本身支持千兆 ethtool eth0 | grep -A 5 Supported link modes如果Speed显示100Mb/s而网卡和交换机都支持千兆第一嫌疑就是线缆——要么只接了 4 芯要么某对线接触不良。资料里“八根线都用了”这句话看着平淡现场就是靠它省下换交换机的时间。5.3 光纤链路的基本检查项光纤部分资料里没有展开但工程上最少要知道三个检查点光模块波长要两端匹配比如 1310nm 对 1310nm、端面清洁度直接影响误码、收发要成对TX 接 RX。嵌入式设备用光口时链路起不来先看光模块有没有被识别再看收光功率是否在范围内。这些参数网管交换机上能读到普通设备就得靠光功率计。提示光纤链路“时通时断”且伴随 CRC 错误增长优先查端面污染和弯折半径不要先怀疑协议栈。6. 从抓包到验证把物理层问题定位到具体帧6.1 用 tcpdump 观察帧长度与链路层异常学到这一步最值得养成的习惯是遇到网络问题先抓包看物理层和链路层有没有异常帧。tcpdump 默认只看三层以上加-e才能看到链路层头部。# 抓取 eth0 上前 20 个包显示链路层头部和帧长度 tcpdump -i eth0 -e -c 20 # 只看 ARP 和以太网广播排查链路层通信是否正常 tcpdump -i eth0 -e arp or ether broadcast # 统计 10 秒内出现的帧长度分布异常短帧可能是碰撞碎片 tcpdump -i eth0 -e -c 100 -w /tmp/cap.pcap-e输出里的src和dstMAC 地址、ethertype字段就是封装时加的链路层头。如果看到大量小于 64 字节的帧以太网最小帧长很可能是早期冲突留下的碎片如果 ARP 请求发出去没有回应问题可能不在 IP 层而在物理链路或交换机端口隔离。先用抓包确认“帧有没有发出去、有没有回来”再往上查协议比一上来就 ping 网关有效得多。6.2 一个完整的排查路径从链路指示灯到协议栈把前面几章的工具串成一条排查路径遇到“设备连不上网”可以按这个顺序走第一步看物理层指示灯和ethtool eth0的Link detected确认链路是否 up第二步看协商速率和双工模式排除半双工冲突第三步用ip -s link看 RX/TX 错误和丢包计数判断线缆质量第四步用 tcpdump 抓 ARP确认链路层能不能通第五步再看 IP 配置和路由。这个顺序的道理在于物理层不通上面配什么都是白搭物理层通了但错误计数高说明线缆或接口有问题换线比调协议快。6.3 最后的技巧用 ping 的包长反推 MTU 和链路质量分享一个我常用的笨办法用不同包长的 ping 去探链路。ping -s 1472刚好对应 1500 字节 MTU1472 数据 8 ICMP 头 20 IP 头如果能通说明路径 MTU 至少 1500如果大包不通、小包通基本就是 MTU 或分片问题。再配合ping -f禁止分片能进一步确认。这个技巧不需要额外工具嵌入式设备上只要有 ping 就能用定位物理层和链路层问题时比翻文档快得多。从那以后我每次接手一个新的嵌入式联网设备都强制自己先跑一遍ethtool加一次 ARP 抓包确认物理层和链路层没有暗病再去看 IP 和上层协议。这个习惯帮我省下过太多次“以为是协议栈 bug、结果是网线只接了 4 芯”的时间。希望这份资料和你自己动手跑的这几段代码能帮你在下次遇到网络不通时第一反应是去看物理层而不是先怀疑人生。本文还有配套的精品资源点击获取
简介这是一份聚焦网络基础物理层与数据交换原理的DOCX学习资料面向网络入门者、嵌入式开发学习者以及需要夯实TCP/IP底层概念的读者。内容围绕数据封装与解封装全过程展开对比电路交换、报文交换、分组交换的差异并延伸到网线、网卡、协议栈三要素以及同轴电缆、双绞线、光纤等常见传输介质。文中还结合以太网10BASE5标准、共享型网络、冲突域与CSMA/CD机制解释先听后发、边听边发、冲突停发和随机延迟后重发的思路并说明多设备共享链路时的传输公平性与分片转发问题适合梳理概念与复习底层通信流程。压缩包共1个DOCX文件约3.46MB查阅方便也可直接做学习笔记。已有106人学习可帮助读者建立从应用层数据到物理层比特流的完整认识理解封装如快递包裹、逐层拆解校验的过程。1. 物理层不是“玄学”从一根网线开始把网络基础打穿很多人学网络从 TCP/IP 四层模型开始学到物理层就一句“传输比特流”带过结果一上设备就翻车网线接了不通、抓包看不到任何东西、同轴电缆上一多接设备就全部变慢。这份《网络基础物理层详细讲解.docx》的价值就在于它没有停在概念层而是把电路交换、报文交换、分组交换的区别以及同轴电缆、双绞线、光纤这些介质怎么影响实际传输一条线串了下来最后落到以太网标准和 CSMA/CD 的工作机制上。如果你正在做嵌入式联网、工业现场布线或者单纯想把 tcpip 协议栈底下的那层“黑匣子”拆开看看这份资料适合当成第一遍通读的底稿。2. 拆解三种数据交换为什么最后活下来的是分组交换2.1 电路交换、报文交换、分组交换的本质差异物理层之上最先要理解的问题是两台设备之间到底怎么把数据送过去。资料里把交换方式分了三类这个分类不是考试名词而是直接决定了你后面看到的网络行为。电路交换的思路最直白——通信之前先建立一条逻辑电路这条线路在通信期间只归你使用别人无法占用。好处是传输稳定、时延固定坏处也很明显不通信的时候线路仍然被占着别人用不了。这就是早期电话网的做法放到今天看它的问题不是技术落后而是资源利用率太低。你在嵌入式场景里如果用过某些专线式的串口通信其实本质上就是电路交换的思维链路建立后独占可靠但浪费。报文交换为了解决共享问题引入了“标识”的概念。多台设备同时想用同一条线路时各自把要发的数据加上标识再送出去接收端根据标识区分是谁的数据。这样一来线路可以共享了但报文大小不受限制一个大报文会把线路占很久别的设备只能干等转发公平性无从谈起。分组交换是在报文交换基础上加了一个关键约束把数据切成分片每个分片有大小上限同时带上标识说明从哪台设备到哪台设备。资料里说得很清楚——“我们规定一个大小固定值每次只传输这么大的值”。这一刀切下去解决了数据紊乱也让多设备共享链路成为可能。但分组交换不是没有代价分片带来额外报头开销路径不同可能导致乱序实时性要求高的场景反而不如电路交换稳。下面这张表把三者在实际工程里的差异拉平来看交换方式是否独占链路数据单位时延特征典型场景电路交换是比特流固定、可预测传统语音、专线报文交换否整段报文波动大早期电报、部分工业总线分组交换否定长/变长分片统计复用、有抖动以太网、IP 网络选型理由不需要背记住一句话就行只要你的设备要接入现代以太网底层跑的就是分组交换分组大小和报头开销会直接影响你的有效吞吐。后面配网卡、调 MTU 的时候这个认知会反复用到。2.2 用一段 Python 模拟分片与标识看清转发逻辑光看文字容易飘实际动手把分组交换的核心逻辑跑一遍印象会深很多。下面这段代码模拟的是一条链路上有多台设备要发数据每个数据被切成分片并打上源/目的标识接收端按标识重组。重点不在代码本身而在分片大小和标识字段怎么影响“谁先被转发”。# 模拟分组交换中的分片与标识转发 # 重点观察分片大小如何影响转发顺序和公平性 FRAGMENT_SIZE 4 # 每个分片的最大数据单元可改成 2/8/16 观察差异 devices { A: 来自设备A的应用数据需要发往设备D, B: 来自设备B的一小段控制指令, C: 来自设备C的日志上报数据长度介于两者之间 } def fragment(src, payload): 把原始数据按固定大小切片并打上源设备标识 fragments [] for i in range(0, len(payload), FRAGMENT_SIZE): chunk payload[i:i FRAGMENT_SIZE] # 标识字段源 分片序号接收端靠它重组 fragments.append({src: src, seq: i // FRAGMENT_SIZE, data: chunk}) return fragments def forward_round_robin(fragment_list): 轮询转发模拟多设备共享链路时的基本公平调度 queues {src: frags[:] for src, frags in fragment_list.items()} order [] while any(queues.values()): for src in queues: if queues[src]: order.append(queues[src].pop(0)) return order frag_dict {src: fragment(src, payload) for src, payload in devices.items()} forwarded forward_round_robin(frag_dict) for f in forwarded: print(f[{f[src]} #{f[seq]}] {f[data]})这段代码要做三件事第一FRAGMENT_SIZE决定了每个分片能带多少数据改小会让报头占比升高、分片数量变多第二fragment里的seq相当于分组交换里的序号标识接收端靠它判断顺序第三转发用轮询而不是谁先来谁先走是在模拟链路共享时的基本公平性。你如果真跑一遍把FRAGMENT_SIZE从 4 改成 16会看到 C 设备的长数据被切得更少A 的短数据反而排到了后面——这就是资料里说的“数据大小不一致时出现不公平”的具体表现。实际以太网里解决这个问题靠的是更复杂的队列调度但根子就在这里。2.3 分片带来的现实参数MTU 与报头开销分组交换落到以太网上最直接的参数就是 MTU最大传输单元。默认 1500 字节不是随便定的它和以太网帧格式、物理介质特性都有关系。资料里没有展开 MTU 计算但在嵌入式网络配置里这是绕不开的。常见做法是这样如果你的设备走以太网MTU 保持 1500如果中间经过某种封装比如 VLAN 标签、隧道有效 MTU 会变小分片策略要跟着调。一个以太网帧的报头包括目的 MAC6 字节、源 MAC6 字节、类型2 字节加上帧校验 4 字节实际每帧额外开销至少 18 字节。按 1500 字节有效载荷算报头占比大约 1.2%但如果你把分片设成 64 字节报头占比立刻冲到 20% 以上有效吞吐明显下降。这也是为什么调小分片能降低单次转发时延却会牺牲带宽利用率——参数没有绝对好坏看你的场景更在意哪一头。提示嵌入式设备上报小数据包时不要盲目把 MTU 调大。链路中间如果有交换机不支持巨帧大包会被丢弃或分片表现就是“能 ping 通但传文件就断”。3. 封装与解封装数据从应用到比特流到底经历了什么3.1 封装是从上到下解封装是从下到上资料里用快递包裹打比方快递盒里塞了很多东西接收方真正要的只是里面的小物件那个小物件就像应用层数据。封装就是一层层套盒子解封装就是一层层拆盒子。这个比方不新鲜但关键细节在于每一层加的“盒子”里装的不是废话而是下一层需要读的控制信息。从应用数据往下走传输层加端口号TCP/UDP 头网络层加 IP 地址IP 头数据链路层加 MAC 地址和帧校验以太网帧头帧尾物理层把整个帧变成 010101 的电信号或光信号送上网线。反过来接收端从物理层收到比特流网卡按帧格式切出来检查目的 MAC 是不是自己是就往上送网络层看目的 IP传输层看端口最后应用层拿到数据。这个过程里任何一层剥错了上层就拿到垃圾数据。真正需要动手确认的是封装顺序不是理论你在 Linux 上用抓包工具看到的每一层头部就是封装留下的痕迹。下一节用 Scapy 构造一个完整以太网帧把“套盒子”的过程变成可观察的字节。3.2 用 Scapy 构造以太网帧看清每层头部# 用 Scapy 构造一个完整的以太网帧逐层观察封装结果 # 运行前需安装pip install scapy from scapy.all import Ether, IP, UDP, Raw # 逐层封装以太网头 - IP 头 - UDP 头 - 应用数据 pkt ( Ether(dstff:ff:ff:ff:ff:ff, src00:11:22:33:44:55, type0x0800) / IP(src192.168.1.10, dst192.168.1.20, ttl64) / UDP(sport5000, dport6000) / Raw(loadbhello-physical-layer) ) # 打印各层头部字段确认封装顺序 pkt.show() # 输出原始字节观察物理层最终要发送的 0101 序列长度 raw_bytes bytes(pkt) print(帧总长度字节:, len(raw_bytes)) print(前 14 字节以太网头:, raw_bytes[:14].hex())这段代码的重点是pkt.show()的输出你会看到 Ether 层、IP 层、UDP 层、Raw 层依次排列和资料里“从上层到下层”的顺序完全对应。type0x0800是告诉网卡“里面装的是 IPv4”换成 0x0806 就是 ARP。ttl64是 IP 头的生存时间每过一个路由器减一减到零就丢弃这个字段在排查环路时很有用。最后打印的帧总长度里以太网头 14 字节、IP 头 20 字节、UDP 头 8 字节剩下才是应用数据——报头开销一目了然。如果你把这段字节流真的从网卡发出去scapy 的sendp对端抓包看到的就是同样的结构前提是物理链路和网卡驱动都正常。物理层出问题的时候这段代码会在发送阶段直接报错反而成了快速判断“到底是协议栈问题还是链路问题”的手段。3.3 网卡、协议栈与传输介质的最小三要素资料里有一句话很关键网络诞生后网线、网卡、协议栈称为“想要完成最小网络的三要素”。这句话放到嵌入式开发里就是排查顺序——先看物理链路网线/接口再看网卡驱动和 MAC 控制器最后看协议栈配置。网线负责比特流传输网卡负责把比特流和帧互相转换协议栈负责按层解析。现在大多数设备的 TCP/IP 协议栈是集成好的只要网卡能工作协议栈通常不会出大问题反过来物理层接触不良、线序错误、光模块不匹配协议栈再怎么配也通不了。我一般排查联网故障时第一步永远是看物理层指示灯和链路状态而不是先去翻 IP 配置。注意有些嵌入式板卡的网卡 PHY 芯片需要正确配置自协商如果对端交换机强制了百兆全双工而本端还在自协商链路可能起来但丢包严重。这种问题抓包看不出来只能靠 ethtool 看协商结果。4. 以太网标准与 CSMA/CD同轴电缆时代的遗产为什么还要学4.1 10BASE5 拆解一个标准名里藏了三个参数资料里出现了 10BASE5这个命名不是乱码每个部分都有含义10 表示每秒 10M10 MbpsBASE 表示基带传输在同轴电缆上进行曼彻斯特编码5 表示传输距离 500 米。把这个标准拆开看你就明白早期以太网的设计约束速度低、距离有限、编码方式决定了信号频谱。同轴电缆时代的网络叫共享型网络所有设备挂在同一根线上数据发出去所有设备都能收到没有私密性可言。更要命的是冲突问题两台设备同时发送信号在线上叠加谁都读不出来。这个范围就叫冲突域。设备越多冲突概率越高传输越慢冲突域也就越大。资料里说“设备越多传输越慢冲突域也就越大”这句话在今天看依然成立——你把一堆设备塞进同一个冲突域比如一个不划分 VLAN 的 hub 环境性能下降是必然的。4.2 CSMA/CD 的四步动作与退避算法CSMA/CD载波侦听多路访问/冲突检测是共享型以太网解决冲突的核心机制资料里把它拆成四步先听后发、边听边发、冲突停发、随机延迟后重发。这四步放到实际链路上理解第一设备发送前先听线上有没有电压摆动线静止才发第二发送过程中继续听因为可能别的设备也同时判断线是静的然后一起发第三一旦检测到冲突立刻停止发送避免继续浪费带宽第四用退避算法算一个随机延迟等一段时间再重试。资料里举例说“计算一个值比如 10s10s 内不往线上发10s 后再次去听线上是否还是被占用”这是简化说法实际二进制指数退避的等待时间随冲突次数增加而翻倍目的是让冲突设备错开重试时机。下面这段伪代码把 CSMA/CD 的判断逻辑写清楚方便你对照资料理解# CSMA/CD 简化逻辑用于理解四步动作的先后关系 import random def csma_cd(link_busy, collision_count): # 第一步先听后发 if link_busy: return 等待链路空闲 # 第二步边听边发发送过程中可能检测到冲突 collision_detected random.random() 0.2 # 模拟冲突概率 if collision_detected: # 第三步冲突停发 # 第四步二进制指数退避等待时间随冲突次数翻倍 backoff random.randint(0, 2 ** min(collision_count, 10) - 1) return f冲突退避 {backoff} 个时间片后重试 return 发送成功 # 模拟连续冲突后的退避窗口变化 for n in range(5): print(f第 {n} 次冲突后:, csma_cd(link_busyFalse, collision_countn))这段代码里2 ** min(collision_count, 10)对应退避窗口上限随冲突次数指数增长上限截在 10 次是为了避免窗口无限大。实际以太网里这个机制在双绞线交换式网络普及后已经基本不触发——因为交换机每个端口是独立冲突域全双工模式下根本不会冲突。但理解它仍有价值第一它解释了为什么早期共享式 hub 网络性能差第二嵌入式设备如果工作在半双工模式冲突计数会直接反映链路质量。4.3 冲突域与广播域的边界在交换机上怎么确认冲突域和广播域是两个容易混的概念。冲突域是物理层信号互相碰撞的范围广播域是广播帧能到达的范围。交换机每个端口隔离冲突域但不隔离广播域路由器两边既隔离冲突域也隔离广播域。资料里提到冲突域但没展开广播域实际配网时这两个都要看。在 Linux 设备上确认冲突域边界最直接的方法是看接口的双工模式和错误计数# 查看网卡协商速率、双工模式、链路状态 ethtool eth0 # 查看冲突和丢弃计数冲突计数非零说明可能存在半双工或共享链路 ip -s link show eth0 # 查看当前接口是否处于全双工Full还是半双工Half ethtool eth0 | grep -E Speed|Duplex|Link detectedethtool eth0输出里的Duplex: Full表示全双工此时不会发生冲突如果显示Half说明链路按半双工在工作CSMA/CD 机制仍然生效。ip -s link show eth0里的collisions计数如果持续增长基本可以断定链路上有半双工设备或者线缆质量问题。我遇到过现场交换机端口被手动设成半双工、终端自协商成千兆全双工的情况表现是时通时断、大包必丢最后就是靠这两个命令定位的。5. 传输介质选型与端接同轴、双绞、光纤的工程参数5.1 同轴电缆、双绞线、光纤的对比与耦合器用法资料里列了三种介质同轴电缆、双绞线、光纤。选型时不能只看“哪个快”要把距离、成本、抗干扰、施工难度一起算。同轴电缆早期用于有线电视网络多设备互联时可以用耦合器每个接口下接一个设备一根线上承载多个设备。它的优点是屏蔽性好、传输距离远缺点是贵、布线笨重而且共享型结构带来冲突问题。双绞线分 UTP非屏蔽和 STP屏蔽5 类、6 类指的是线缆类别类别越高支持带宽越高。资料里特别提到“双绞线如果是千兆那么八根线都用了”——百兆只用到 4 根1、2、3、6千兆必须 8 根全接这也是现场做水晶头时最容易翻车的地方按百兆线序做完插到千兆口上要么降速到百兆要么直接不通。光纤抗干扰最强、距离最远但端接和光模块成本高适合骨干链路和强电磁环境。把关键参数拉成表介质典型距离抗干扰成本常见坑同轴电缆500 米10BASE5较好高共享冲突、耦合器接触不良双绞线 UTP100 米一般低千兆需 8 芯全接、线序错双绞线 STP100 米较好中屏蔽层需正确接地光纤几公里到几十公里强高光模块波长不匹配、端面污染5.2 千兆双绞线的线序与验证命令双绞线做头子这件事翻车率远比想象中高。百兆只用 1、2、3、6 四根千兆必须 8 根全通而且线序要按 T568B 或 T568A 统一。常见错误是两端线序不一致——一端 T568B、另一端 T568A短距离百兆可能还能通千兆直接协商不上。验证方法不用拆线用 ethtool 看协商结果就够了# 确认是否协商到千兆全双工 ethtool eth0 | grep -E Speed|Duplex # 如果只协商到 100Mb/s检查网线是否 8 芯全通 # 查看支持的模式确认网卡本身支持千兆 ethtool eth0 | grep -A 5 Supported link modes如果Speed显示100Mb/s而网卡和交换机都支持千兆第一嫌疑就是线缆——要么只接了 4 芯要么某对线接触不良。资料里“八根线都用了”这句话看着平淡现场就是靠它省下换交换机的时间。5.3 光纤链路的基本检查项光纤部分资料里没有展开但工程上最少要知道三个检查点光模块波长要两端匹配比如 1310nm 对 1310nm、端面清洁度直接影响误码、收发要成对TX 接 RX。嵌入式设备用光口时链路起不来先看光模块有没有被识别再看收光功率是否在范围内。这些参数网管交换机上能读到普通设备就得靠光功率计。提示光纤链路“时通时断”且伴随 CRC 错误增长优先查端面污染和弯折半径不要先怀疑协议栈。6. 从抓包到验证把物理层问题定位到具体帧6.1 用 tcpdump 观察帧长度与链路层异常学到这一步最值得养成的习惯是遇到网络问题先抓包看物理层和链路层有没有异常帧。tcpdump 默认只看三层以上加-e才能看到链路层头部。# 抓取 eth0 上前 20 个包显示链路层头部和帧长度 tcpdump -i eth0 -e -c 20 # 只看 ARP 和以太网广播排查链路层通信是否正常 tcpdump -i eth0 -e arp or ether broadcast # 统计 10 秒内出现的帧长度分布异常短帧可能是碰撞碎片 tcpdump -i eth0 -e -c 100 -w /tmp/cap.pcap-e输出里的src和dstMAC 地址、ethertype字段就是封装时加的链路层头。如果看到大量小于 64 字节的帧以太网最小帧长很可能是早期冲突留下的碎片如果 ARP 请求发出去没有回应问题可能不在 IP 层而在物理链路或交换机端口隔离。先用抓包确认“帧有没有发出去、有没有回来”再往上查协议比一上来就 ping 网关有效得多。6.2 一个完整的排查路径从链路指示灯到协议栈把前面几章的工具串成一条排查路径遇到“设备连不上网”可以按这个顺序走第一步看物理层指示灯和ethtool eth0的Link detected确认链路是否 up第二步看协商速率和双工模式排除半双工冲突第三步用ip -s link看 RX/TX 错误和丢包计数判断线缆质量第四步用 tcpdump 抓 ARP确认链路层能不能通第五步再看 IP 配置和路由。这个顺序的道理在于物理层不通上面配什么都是白搭物理层通了但错误计数高说明线缆或接口有问题换线比调协议快。6.3 最后的技巧用 ping 的包长反推 MTU 和链路质量分享一个我常用的笨办法用不同包长的 ping 去探链路。ping -s 1472刚好对应 1500 字节 MTU1472 数据 8 ICMP 头 20 IP 头如果能通说明路径 MTU 至少 1500如果大包不通、小包通基本就是 MTU 或分片问题。再配合ping -f禁止分片能进一步确认。这个技巧不需要额外工具嵌入式设备上只要有 ping 就能用定位物理层和链路层问题时比翻文档快得多。从那以后我每次接手一个新的嵌入式联网设备都强制自己先跑一遍ethtool加一次 ARP 抓包确认物理层和链路层没有暗病再去看 IP 和上层协议。这个习惯帮我省下过太多次“以为是协议栈 bug、结果是网线只接了 4 芯”的时间。希望这份资料和你自己动手跑的这几段代码能帮你在下次遇到网络不通时第一反应是去看物理层而不是先怀疑人生。本文还有配套的精品资源点击获取
