2. 以太网物理层基础：从比特到信号
做链路训练，不懂物理层，那基本就是盲人摸象。我个人习惯，碰到吞吐异常，一定先从物理层排查。为什么？因为很多“软件问题”，说到底都是信号问题。
这章我们就把以太网物理层拆开看看。不搞复杂理论，就讲实际用得到的东西。
2.1 物理层在OSI模型里的位置
OSI七层模型，物理层是第一层，也是最底下那层。上面跑着千兆万兆的数据流，但真正在线缆上传输的，其实是电信号或者光信号。
物理层负责什么？说白了就三件事：
- 把数据变成信号（编码）
- 把信号发出去（传输）
- 从信号里拿回数据（解码）
你想想看，如果物理层没对齐，上层协议栈再牛也没用。我记得有次排查一个万兆网卡降速问题，折腾了三天驱动和协议栈，最后发现是光模块的物理层协商参数配错了。从那以后，我排查问题一定从物理层开始。
2.2 物理层的三个子层
千兆以上的以太网，物理层分成了三个子层。我把它们的关系整理了一下：
2.3 PCS层：编解码的门神
PCS全称Physical Coding Sublayer。它的核心工作就是编解码。
1000BASE-T用8B/10B编码——每8个数据位变成10个传输位。额外多了2位，用来做直流平衡和时钟同步。
10GBASE-T升级成64B/66B编码，效率更高。66位里只多2位同步头，编码效率从80%提升到了97%左右。
为什么要编码？
不编码直接发，连续相同的比特会让接收端时钟跑偏。时钟偏了，采样点就歪了，误码率直接飙升。这问题我在项目里见过太多次了。
实战经验：如果你看到链路线速正常但CRC错误暴增，多半是PCS层的编码同步出了问题。优先检查时钟恢复电路和参考时钟源。
2.4 PMA子层：串行化的核心
PMA负责把PCS送过来的并行数据串行化，送上SerDes通道。反过来，也从SerDes里把串行信号恢复成并行数据。
PMA最关键的功夫是时钟数据恢复。发端没有单独送时钟，接收端全靠数据信号里的跳变沿来恢复时钟。信号质量差、抖动大，CDR就锁不住。
- CDR锁不住 → 链路建立失败
- CDR抖动大 → 误码率升高
- CDR锁定慢 → 链路训练时间延长
我之前调试过一个板卡，千兆能通但万兆死活起不来。最后定位到是PCB走线阻抗不连续，导致PMA的CDR锁定不稳定。调整了一下PCB走线，问题就解决了。
2.5 PMD子层：与线缆打交道
PMD是最接近物理介质的那一层。它决定了你的接口类型：
| 标准 | PMD接口 | 速率 | 传输介质 |
|---|---|---|---|
| 1000BASE-T | RJ45 | 1 Gbps | Cat5e双绞线 |
| 10GBASE-T | RJ45 | 10 Gbps | Cat6a/7双绞线 |
| 10GBASE-SR | SFP+ | 10 Gbps | 多模光纤 |
| 25GBASE-SR | SFP28 | 25 Gbps | 多模光纤 |
PMD层直接和线缆、光模块打交道。链路训练时，很多眼图不过、信号裕量不够的问题，都出在PMD和介质连接处。
2.6 Auto-Negotiation：让两端先聊起来
Auto-Negotiation（AN）是链路训练的“前哨战”。两端设备上电后，先通过FLP（快速链路脉冲）交换能力信息——我支持什么速率、什么双工模式。
- 发FLP：设备上电后持续发出快速链路脉冲
- 收FLP：接收端检测到FLP，解析对方能力
- 找共同点：双方协商出最高共同速率
- 确认：互发应答，完成协商
AN的成功依赖于FLP能被正确识别。信号太弱、噪声太大，FLP就丢了。我在调试过程中见过一种情况——一个端口AN失败但用强制模式就能通，后来发现是PHY的AN寄存器配置错了。
要点：AN失败不一定说明硬件坏了。很多情况下是两端PHY的AN能力集没有交集，或者线缆质量太差导致FLP不能被正确解析。
2.7 EEE模式：省电与吞吐的矛盾
EEE（Energy Efficient Ethernet）是IEEE 802.3az定义的低功耗模式。没有数据时，链路进入LPI（低功耗空闲）状态，关闭部分电路省电。有数据时再唤醒。
EEE状态切换：
- Active：正常收发数据
- LPI：低功耗空闲，定期发刷新信号维持链路
- Wake：从LPI恢复到Active的过渡状态
问题就在唤醒这个环节。从LPI到Active需要时间。频繁的休眠唤醒，会产生额外的延迟和丢帧。有些交换机为了省电，把EEE参数设得很激进，结果导致吞吐量断崖式下降。
在实际项目中，我建议这样处理：
- 在延迟敏感的应用中禁用EEE
- 必须开启EEE时，要调整LPI退避时间和唤醒时间
- 检查两端设备是否支持同样的EEE时序参数
注意：EEE和Auto-Negotiation是关联的。AN完成后才能协商EEE能力。如果AN出问题，EEE协商也会失败。很多工程师排查吞吐问题时，只盯着高层协议，完全没意识到是物理层的EEE模式搞的鬼。
2.8 物理层对吞吐的直接影响
物理层的问题，最终都会反映在吞吐上：
| 物理层异常 | 对吞吐的影响 | 典型现象 |
|---|---|---|
| PCS编码错误 | CRC错误增加，重传率上升 | ping时延抖动 |
| PMA/SerDes失锁 | 链路反复断连 | ifconfig看到RX errors |
| PMD信号质量差 | 协商速率降级 | 万兆卡工作在千兆 |
| AN协商失败 | 链路不通 | 网卡状态为down |
| EEE频繁唤醒 | 吞吐量骤降30%~50% | 低流量正常，高流量卡顿 |
这张表我建议你截图存着。以后排查吞吐异常，先把物理层这几个项过一遍，很多问题就定位清楚了。
2.9 小结：物理层决定了链路上的限
这一章我们聊了物理层的三层架构、AN和EEE的基本原理。核心一句话：链路训练成功的前提，是物理层三个子层全部正常工作。
我自己排查吞吐类问题的顺序，永远先看物理层状态。链路没协商好、信号质量差、编解码有错，上层协议跑得再快也没用。希望这章能帮你理清物理层的脉络，后面几章我们会深入链路训练的具体流程和异常排查。