主板上明明是千兆网卡，为什么有时只跑出 100 Mbps 的速度？崭新的 650 W 金牌电源，为什么显卡一吃满就重启？机房旁边的房间为什么常年比别处暖几度？这些日常现象的背后，是两套大多数人从不深究的系统：承载数据的网络 I/O 流水线，以及让芯片活下去的电源与冷却链路。

本文是《计算机基础》系列的最终篇。这一次我们不再罗列规格表，而是跟着数据和能量走一遭：从墙上的双绞线，经过 PHY、MAC、DMA 引擎，一路进入内存；从墙上的插座，经过电源的转换电路，最终供给显卡上的 12 V 供电。沿途还会看到数据中心如何用 PUE 这个指标量化能源浪费，以及 UPS 如何在电网抖动时撑住整间机房。

系列导航

计算机基础深度解析系列（共 6 篇）：

1. CPU 与计算核心
2. 内存与高速缓存
3. 存储系统
4. 主板、显卡与扩展
5. 网络、电源与故障排查 （本文）
6. 深度补充：跨主题专题

第一部分：网卡到底是怎么工作的

很多人对网卡的印象只是"机箱后面那个口"。但这个口的背后是一整套独立的子系统：从双绞线上的电平到内核可以路由的数据包，全部在硬件里完成，几乎不需要 CPU 参与，速度还要稳稳跑满线速。

三层硬件流水线

之上还有一组硬件卸载引擎，它们才是 25/40/100 GbE 能跑得起来的原因：

• 校验和卸载——TCP/IP checksum 由硬件计算。
• TSO / LRO——发送侧分段卸载和接收侧大段聚合，把"按包处理"挪进硬件。CPU 把一段 64 KB 的数据丢给网卡，网卡自己拆成 44 个线上帧。
• RSS（接收侧扩展）——通过 Toeplitz 哈希把不同流分散到不同 CPU 核。没有它，一条 25 GbE 的流就能把单核打满，整台机器跟着卡死。
• VLAN 标签 与 SR-IOV——后者把一张物理网卡虚拟成多张"虚拟功能"，每个 VM 一张，绕开 hypervisor 的软件交换机。

那个经典的"千兆变百兆"陷阱

排查"千兆只跑 100 Mbps"，第一嫌疑永远是网线，不是配置。千兆以太网（1000BASE-T）需要四对线全部到位；老的 CAT5 标准只保证两对。市面上廉价跳线很多在标识上偷偷降级。修法是物理的，不是软件的：

1
2
3
4
5
6
7

# Linux：确认协商出来的速率
ethtool eth0 | grep -E "Speed|Duplex"
# Speed: 100Mb/s    <-- 网线就是元凶
# Duplex: Full

# 换好线后强制重新协商
ethtool -r eth0

有线网卡标准（2024 年现状）

Wi-Fi 标准

2024 年新装机首选 Wi-Fi 6 或 6E：AP 和终端普遍支持，6 GHz 频段还相对空旷。

第二部分：TCP，那段你看不见的对话

每一次网页请求、每一个 SSH 会话、每一条数据库查询，开头都是同一段三句话的问候仪式。看懂它，遇到连接超时时就能从"猜"变成"诊断"。

为什么是三次而不是两次？

直觉会说：“客户端打招呼，服务端回应，结束。” TCP 之所以非要第三次，是为了确认双向都能通：

1. SYN（客户端 → 服务端）：“我想跟你聊，我的初始序号是 x。”
2. SYN-ACK（服务端 → 客户端）：“收到（ack = x+1），我的初始序号是 y。”
3. ACK（客户端 → 服务端）：“你那边我也收到了（ack = y+1），开始吧。”

第二步之后，服务端才确认了客户端能发；第三步之后，双方才都确认了双向都通。少了第三步，服务端就停在 SYN_RCVD 状态——也就是经典 SYN flood 攻击利用的半开连接。

用 tcpdump 看一眼

1
2

# 抓一次 443 端口的握手
sudo tcpdump -ni any 'tcp port 443 and (tcp-syn|tcp-ack) != 0' -c 3

接下来三个只带标志位、没有载荷的包就是握手。之后会话切换为携带序号的数据段，靠这些序号实现按序交付与重传。

建连的代价

每次新建 TCP 连接，都要先花一个 RTT 在握手上才开始传数据。同机房的服务（RTT = 0.5 ms）这点开销几乎看不见；跨太平洋的 API 调用（RTT = 100 ms）这就是延迟的大头。这也正是 HTTP/2 把多个请求复用到一条连接、HTTP/3（QUIC）把 TLS 握手合并进同一个 RTT 的根本原因。

第三部分：网络拓扑——成本与可靠性的取舍

把 4 台、40 台、4000 台节点连起来，怎么连？经典答案有六种，各有各的带宽与失效特性：

胖树是让超大规模数据中心成为可能的关键架构。在传统树里，越往上越收敛：48 台服务器汇聚到一条 10 Gb 上联，每台实际只能拿到名义带宽的 1/48。胖树把每一层的总带宽做成相等的，扩容靠加 spine，而不是去买更猛的单台交换机。

第四部分：网络寻址——真正需要懂的那几个概念

127.0.0.1——回环地址

127.0.0.1 是你的机器跟自己说话用的地址。发往这里的数据包根本不会经过物理网卡，而是在内核网络栈内部短路完成。所以即使拔掉网线，curl http://localhost:8080 仍然能用。整个 127.0.0.0/8 段都是回环——127.0.0.1、127.5.6.7 都是。

0.0.0.0——“任意接口”

0.0.0.0 在不同上下文里有两种角色：

• 作为绑定地址（服务端）：“监听我所有的接口——eth0、wlan0、lo 全都听。” Flask 里的 app.run(host='0.0.0.0') 就是这个意思。
• 作为路由目标：“默认路由”，在路由表里写作 0.0.0.0/0。

最常见的误解是把 0.0.0.0 当成可以 curl 或 ping 的目标。它不是——它不是一个目的地址，而是一个"任意"通配符。

端口——服务的复用机制

一个 IP 地址能同时承载成千上万的服务，靠的是端口号（16 位，0–65535）做区分。前 1024 是"知名端口"：

那个永恒的谜题"ping 通了但网站打不开"，答案是：ping 走的是 ICMP（不涉及端口），而 HTTP 需要有进程实际绑定在 TCP/80 上。主机是通的，只是服务没开，或者服务绑在了 127.0.0.1 而不是 0.0.0.0。

1
2
3
4

# 看服务到底监听在哪
ss -tnlp | grep nginx
# LISTEN 0  511   0.0.0.0:80   ...   <-- 对
# LISTEN 0  511   127.0.0.1:80 ...   <-- 仅本机能连

NAT——4 亿地址服务 300 亿设备的把戏

IPv4 地址总共约 42 亿，远不够现在所有设备用。网络地址转换（NAT）是让数学成立的取巧手段：家里所有设备共享一个公网 IP，路由器在出口处改写源地址，回包时反向映射回内部设备。

内网: 192.168.1.100:54321  --SNAT-->  公网IP:60001  -->  8.8.8.8:53
内网: 192.168.1.101:33333  --SNAT-->  公网IP:60002  -->  1.1.1.1:443

路由器把映射表保存在内存中，长时间不活动的条目会被超时清掉。这就是为什么挂着不动的 SSH 会话有时会无声无息地死掉——NAT 表把它忘了。

DNS——网络的通讯录

机器靠 IP 路由，但人记不住数字。DNS 是把 www.example.com 解析成 93.184.216.34 的递归查找链：

1. 浏览器缓存 → 2. 操作系统缓存（先查 /etc/hosts） → 3. 递归解析器（你的 ISP 或 1.1.1.1） → 4. 根服务器 → .com 顶级域 → example.com 权威服务器 → 返回 A 记录。

CDN 就是利用了这一点——同一个名字在不同地区返回不同 IP。这也是 www.netflix.com 在你这里指向附近节点、而不是加州源站的原因。

第五部分：虚拟机网络模式

在 VMware、VirtualBox 或 KVM 里跑虚拟机时，hypervisor 必须决定虚拟 NIC 怎么接到外部世界。三种经典模式：

桥接（Bridged）——VM 是局域网里的一等公民

hypervisor 暴露一个虚拟交换机，把 guest 的网卡桥接到物理网络上。VM 从你家路由器拿一个 DHCP 地址（192.168.1.x），跟宿主机平起平坐，局域网其他设备能直接 ping 到它。

适用场景：搭一个测试 Web 服务器，要让同事从局域网访问。

NAT——VM 躲在私有的虚拟路由器后面

hypervisor 自己充当一个小路由器。VM 拿一个独立子网的地址（VMware 默认 192.168.182.x），出站流量被双重 NAT：先由 hypervisor 转成宿主机 IP，再由家里路由器转成公网 IP。

适用场景：既要隔离又要联网。几乎所有日常开发 VM 都该选这个。

仅主机（Host-only）——彻底隔离

guest 和宿主机之间一根虚拟网线，外面什么都不接。没有外网，也没有局域网。适合恶意软件分析、断网测试、运行那些"绝对不能对外暴露"的数据库。

第六部分：网络故障——从下往上排

网络问题分七层，但排查顺序跟画图的方向相反：从最底层（线缆、链路、IP）开始往上摸（TCP、TLS、应用）。

第 7 层  应用       curl 能跑通吗？URL 写对了？认证？
第 6 层  表示       TLS 证书有效？SNI 对吗？
第 4 层  传输       端口开了？防火墙？服务绑到 0.0.0.0 了吗？
第 3 层  网络       网关 ping 得通吗？路由表正常吗？
第 2 层  数据链路   交换机端口灯亮吗？双工对了吗？
第 1 层  物理       网线插好了？是 CAT5e 吗？没被压坏？

案例 1：ping 通，但网站打不开

主机响应了 ICMP，第 1–3 层没问题，断点在第 4 层或更高。

1
2
3
4
5
6
7
8

# 80 端口有进程在监听吗？
ss -tnlp | grep ':80 '

# 从外部能连进去吗？
nc -zv example.com 80

# 服务自己怎么说？
journalctl -u nginx -n 50

最常见的几种原因：nginx 没启动；nginx 启动了但绑在 127.0.0.1；防火墙挡了 80 端口；AWS 安全组没放行 HTTP 入站。

案例 2：域名解析失败

1
2
3

ping 8.8.8.8                  # 验证 IP 层连通
dig www.example.com           # 直接试 DNS
cat /etc/resolv.conf          # 配置的解析器还正常吗

如果 8.8.8.8 通但 DNS 不通，配置的解析器坏了。手动改成 1.1.1.1 或 8.8.8.8 重试。

案例 3：NAT 模式的 VM 上不了网

1
2
3
4
5

ip addr           # DHCP 给虚拟子网内的 IP 了吗？
ip route          # 默认路由是不是虚拟网关（一般是 .2）？
ping 192.168.182.2  # 虚拟 NAT 网关
ping 8.8.8.8        # 直接 ping IP，绕开 DNS
ping example.com    # 上一步通这一步不通 → DNS 问题

最常见的修法是：在宿主机上重启 VMware NAT 服务，或把 /etc/resolv.conf 改成 nameserver 8.8.8.8。

hosts 文件——本地的 DNS 覆盖

/etc/hosts（Windows 下是 C:\Windows\System32\drivers\etc\hosts）会先于任何 DNS 查询被检查。它就是一个简单的文本表，把 IP 映射到名字：

127.0.0.1     dev.example.com
127.0.0.1     api.example.com
0.0.0.0       ads.tracker.example

前两行把开发用域名指向本机；第三行是最朴素的广告屏蔽——访问那些名字时会跑去 0.0.0.0，无声无息地失败。改完之后要清 OS 的 DNS 缓存：

1
2
3
4
5
6

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
# Linux（systemd-resolved）
sudo systemd-resolve --flush-caches

第七部分：电源——最容易被低估的那个零件

电源是唯一一个跟所有其他组件都打交道的部件。一个不稳的电源会制造出一切看起来像内存故障、显卡故障、主板故障的现象——就是看不出像电源故障。但偏偏大多数装机攻略只把它当成一个"瓦数"。

“80 PLUS"到底量的是什么

电源的标称功率说的是它能输出多少给系统；而效率说的是它从墙上 AC 转换成 12 V / 5 V / 3.3 V 三组直流的过程中浪费了多少。80 PLUS 认证就是在四个负载点上给这个转换打分。

从这些曲线里能读出几个不那么直观的结论：

• 效率峰值在 40–70 % 负载之间。 200 W 的整机配 1000 W 电源，长期工作在 20 % 负载——曲线最差的那一段。买太大不只是浪费首次开销。
• 钛金只在两端比金牌明显好。 50 % 负载下金牌（90 %）和钛金（94 %）只差 4 个百分点。在 10 % 负载——服务器整夜空转的那种——钛金才拉开。
• 省下来的电费实在但有限。 400 W 的整机每天开 8 小时，电价 0.6 元/度，白牌电源比金牌每年多浪费约 56 W，折合约 350 元。金牌一般贵 200 元左右，能用 7–10 年——这笔账很容易算。

怎么算电源功率才对

老规矩是 (CPU TDP + GPU TDP + 100 W) × 1.3。这个 1.3 倍包含了瞬态尖峰（现代显卡可以在毫秒尺度上飙到 TDP 的 1.3 倍）、效率损耗，以及让长期负载落在曲线甜点区的余量。

模组化与非模组

三种形态：

• 非模组——所有线固定不可拆。最便宜，理线最丑。
• 半模组——一定会用的 24 pin 和 CPU 8 pin 固定，PCIe 和 SATA 可拆。对绝大多数装机来说是最划算的选择。
• 全模组——所有线都可以拆。多花 100–200 元，换来更整洁的 SFF 装机和更易更换的线材。

一条经常被忽略的安全提醒：不同品牌、不同型号的电源，模组线绝对不要混用。 电源端的针脚定义没有统一标准，把 EVGA 的线插到 Corsair 电源上，可能让 12 V 经 5 V 电路短路，把整机烧掉。

第八部分：组件功耗的层次结构

明白了哪些组件真正主导功耗预算，配电源就不再凭感觉。

两个核心结论：

1. CPU 和 GPU 加起来占峰值的 80–95 %。 内存、SSD、主板、风扇都是零头。配电源时按 CPU TDP + GPU TDP 算，再给其他东西加 100 W 余量就够了。
2. 空载与满载的比值惊人，尤其是 GPU。 RTX 4090 空载约 18 W，满载 450 W——25 倍的摆幅。这就是为什么风扇噪音随负载变化、为什么 GPU 降压比 CPU 降压收益大得多。

一个实用的诊断技巧：如果系统每次都在某些游戏场景或渲染场景下重启，要怀疑的是电源的瞬态响应能力，而不是它的平均功率。现代显卡毫秒级别能冲到 TDP 的 1.3–1.5 倍，临界电源能撑住平均值，却撑不住尖峰，被过流保护打跳。

第九部分：数据中心 PUE——每一瓦电去了哪里

一间机房不过是把同样的问题放大：从电表上进来的电，到底有多少真正落到了芯片上？业界用 PUE（Power Usage Effectiveness）来衡量：

PUE = 1.0 是理论极限：每一瓦从电网进来的电都用来做计算了。现实长这样：

典型 PUE = 1.5 的数据中心，电力分布是：

• 67 % 给 IT 设备——服务器、存储、网络。这才是你要的东西。
• 25 % 给制冷——冷水机、CRAC、风机。热负荷越大，这块越大。
• 5 % 给配电转换——UPS 损耗、PDU 损耗、变压器损耗。
• 3 % 给照明、安保和其他建筑负荷。

超大规模运营商已经把这个数字压得非常低。Google 2024 年全机队 12 个月滚动 PUE 是 1.10，最先进的设施（浸没式冷却，无冷水机）逼近 1.03。改进来自：

• 提高进风温度——冷通道从 18 °C 提到 27 °C，制冷负荷直接腰斩。
• 自然冷却——大部分时间用室外空气（北方设施甚至用海水），不开压缩机。
• 气流管理——冷热通道封闭、盲板、密封地板格栅。
• 更高电压配电——415 V 三相直送机柜，比 208 V 少一次转换。
• 液冷与浸没式冷却——给最密的 GPU 机柜彻底换掉空气这种换热介质。

PUE 也解释了为什么超大规模数据中心的选址那么讲究：冰岛、俄勒冈、瑞典北部，全年大半时间几乎免费制冷。

第十部分：UPS——撑住那一瞬

电网哪怕只眨一下眼——30 毫秒——就足以让一台没保护的服务器崩溃。UPS（不间断电源）就是横在电网故障与柴油发电机启动之间的能量缓冲。

三种 UPS 拓扑

• 后备式（standby）——平时直接走市电，停电或电压跌落时继电器切到逆变器。切换时间 4–10 ms。便宜，家用电脑够用。
• 在线互动式（line-interactive）——多了一个自耦变压器，能在不动电池的前提下纠正中等程度的电压波动。切换时间 2–4 ms。小机房常见。
• 在线双变换（online double-conversion）——负载始终挂在逆变器上：AC → DC（整流） → 直流母线 → DC → AC（逆变）。电池浮充在直流母线上。切换时间 0 ms——负载根本感觉不到电网消失了。数据中心标配。

一座真正的数据中心，完整的供电链路

1. 市电 进入（认真的还会从另一座变电站拉一路备电）。
2. ATS（自动转换开关）夹在市电与发电机之间。
3. 柴油发电机 在 ATS 检测到市电丢失后 10–30 秒内启动到位。
4. 在线 UPS 撑过那 10–30 秒。新设计普遍换成锂电（VRLA 寿命的 3 倍，占地一半）。
5. PDU（电源分配单元）把高电流主干分到每个机柜的支路。
6. 服务器电源——通常配两台，分别接独立母线（A 路 / B 路），保证单台 UPS 或 PDU 故障不会拖垮机柜。

这就是为什么超大规模站点要做多层 N+1 冗余：市电、发电机、UPS、PDU、服务器电源。任意一层单点故障对外不可见；同一层两个同时故障也能扛住。真正的全站事故，几乎都是多层故障级联——而且十有八九是人为操作失误，不是设备失效。

电池能撑多久

续航是负载和电池组容量的函数，跟 UPS 标称功率没什么关系：

• 5 kVA 的 UPS 满载（5 kW），内置小电池：5–10 分钟。
• 同一台 UPS 半载：约 25 分钟（电池放电是非线性的）。
• 外置电池柜可以撑数小时，但通常只配到"够发电机启动并稳定即可”——典型设计目标是 15 分钟。

第十一部分：常见硬件故障——分诊指南

修了十年别人的电脑之后会发现，几乎所有问题都集中在那几种失效模式上。

开机故障

“重插内存"这种玄学动作其实有物理依据：温度循环让 DIMM 慢慢从插槽里"走"出来，金手指上还会氧化。拔下来再插回去，就把接触面擦干净了，恢复了低阻接触。

存储和显卡

• SSD 突然变慢——查剩余空间（消费级 SSD 在剩余 < 10 % 时垃圾回收会拖慢）、确认 TRIM 启用、看 SMART 的"磨损均衡计数”。
• 显卡花屏——多半是过热或供电不稳。重插 PCIe 供电；显存降频 200 MHz 试试。
• 显卡识别不到——插错 PCIe 槽（要插最上面的 x16，不要插芯片组挂的副槽）、忘接供电、花哨机箱里 riser 线挂了。
• M.2 NVMe 不见了——主板 M.2 槽常和某个 SATA 口共享通道；查手册的"共享通道"提示。

网络

• 频繁掉线——查对端、换跳线、更新网卡驱动。
• Wi-Fi 慢——从 2.4 GHz 切到 5 GHz；用 Wi-Fi 分析仪找空闲信道；排查微波炉、蓝牙干扰。
• 拿不到 DHCP——确认网线灯亮、ip addr 看是不是 APIPA 地址（169.254.x.x）、重启 DHCP 客户端。

系列总结

整个系列的内容，可以浓缩成五句话：

1. CPU 是串行任务的瓶颈，GPU 是并行任务的瓶颈，其他一切都在喂它们。
2. 内存层次（寄存器 → L1/L2/L3 → DRAM → NVMe → HDD）跨了七个数量级的延迟，好的代码尊重局部性。
3. 存储是带宽、IOPS 和寿命的综合，正确答案永远取决于负载。
4. 总线（PCIe）、接口（USB、Thunderbolt）、主板的 VRM，决定了硅片到底能发挥几成实力。
5. 网络与电源是装机时最少有人深入研究、却最容易制造出怪异故障的两套系统。

如果只能记一条：瓶颈很少出现在你最先去看的地方。 用工具去测，相信数字，不要相信规格表。

下一篇（深度补充）会回到本系列只蜻蜓点水的问题：缓存一致性协议、NUMA、芯片级虚拟化、能效边界。