1 数据中心网络硬件要看清什么
数据中心网络把服务器里的计算、内存与存储连接起来。CPU 执行任务，内存暂存正在使用的数据，SSD 保存持久数据，网卡把主机中的数据送上链路，交换机再把它送往其他服务器。这条路径里，任何部件处理得慢，都可能让应用等待。采购了 100 Gb/s 网卡，不等于应用就能持续传输 100 Gb/s；CPU 处理能力、内存带宽、PCIe 连接、交换机出口和对端存储都可能成为限制。
本课把网络设备当成真实的硬件来看：面板有多少端口，端口对应哪些芯片，光模块如何插入笼子，线缆通向哪里，电源与风扇能否支撑工作。机架顶部交换机常称 ToR，意思是机架顶端交换机，但实际也能装在机架中部。它通常连接本机架服务器，再通过上行链路连接其他交换机。这里的“顶部”是部署习惯，不能用来推断设备性能。
观察服务器时，可以从 1 台配有 CPU、256 GB 内存、若干 NVMe SSD 和 2 个 100 Gb/s 网口的机器开始。NVMe SSD 和网卡都可能经 PCIe 与主机连接，数据却不一定必须先落盘再发送。内存里的计算结果也能直接形成网络流量。反过来，网络数据到达后，可能只在内存中短暂停留。因此，不能用 SSD 的顺序读速率解释所有网络吞吐问题，也不能只增加 CPU 核数就认定网络会变快。
观察交换机时，要区分管理与转发。管理 CPU 负责配置、监控和协议等任务，专用交换芯片承担大部分常规报文转发。设备标注的管理内存容量，并不等于报文缓冲容量。某设备有 16 GB 管理内存，也不能据此声称能缓存 16 GB 业务流量。读取规格时，要把处理器、管理内存、交换容量、端口速率和报文缓冲分别记录。
还要识别机器形态。固定端口交换机把主要端口与转发资源集成在较紧凑的机箱中；框式交换机通过线卡、交换结构和电源模块扩展。服务器也有机架式、刀片式和高密度节点等形态。共享机箱背板、共享电源与共享上行会改变故障影响范围。外观同样是 2 个网络接口，可能属于同 1 张网卡，也可能来自不同插槽，可靠性含义并不相同。
学习目标是把“这台设备很快”改写成可以核对的判断：哪些接口以什么速率连接，资源由谁共享，在哪种流量下达到上限，故障后还能保留多少容量。后面所有计算都从这个边界出发，复杂的芯片内部调度、拥塞控制协议和 CPU 微架构留到后续课程。
2 交换机芯片、缓冲区与转发管线
交换机收到以太网帧后，需要识别报文头、查询转发表、确定出口，并按相应规则排队和发送。可以把转发管线理解为若干连续的硬件处理阶段。不同型号的阶段划分与处理方式不同，入门时只需要抓住 3 个问题：报文去哪个端口，能否被接收，什么时候能够发出。管理界面显示链路正常，只回答物理连接的一部分问题，无法证明报文在每个阶段都没有丢失。
交换芯片的容量有不同口径。假设设备有 32 个 100 Gb/s 端口，全部端口单方向速率之和是 3.2 Tb/s。若规格按收发双向相加，可能标为 6.4 Tb/s。二者可能描述同 1 套端口，不能直接当成性能相差 2 倍。做比较时，要写明方向、端口组合和是否同时工作；端口拆分或速率模式互斥，也会改变实际可用组合。
另一个指标是包转发率，常用每秒多少百万个包表示。相同的比特率下，小包数量更多，每秒需要做的查表、排队等工作也更多。大块文件传输达到高吞吐，不代表大量短消息也能达到相同链路利用率。估算小包压力时，还要考虑前导码、帧间隙等在线路上占用的时间，不能只用应用负载字节数除以端口速率。具体最小帧转发能力应以设备公开测试条件为准。
缓冲区负责暂存暂时发不出去的报文。假设 2 个输入各以 100 Gb/s 向同 1 个 100 Gb/s 输出发送，输入合计为 200 Gb/s，输出只能消化 100 Gb/s，差额就会积累。只要持续足够久，任何有限缓冲都会装满。缓冲能吸收短时间的不均匀，不能把长期超载变成可持续运行。理解这一点，才能避免把“深缓冲”理解成无限吞吐。
标称总缓冲也不是每个端口随时可用的空间。设备可能有共享池、队列保留、端口限制和动态分配规则。某个出口队列达到限制时，其他区域仍有空闲也可能出现丢包。缓存使用的内部计量单位还可能带来额外开销。因此容量规划要同时看总量、分配规则和队列级计数器，不能只在规格表里抄下 1 个 MB 数字。
转发方式也影响等待时间。有的路径需要收到完整帧再处理，有的能够在识别必要信息后较早开始发送。这里不展开内部实现，只需知道：标称最低时延通常有特定报文长度与负载条件，排队时延可能远大于基础转发时延。100 Gb/s 出口前若已有 1 MB 数据等待，按十进制单位粗算就需要约 80 μs 才能发完，还没有计算其他处理时间。
3 光模块、线缆与速率演进
端口速率只是连接成立的条件之一。交换机端口、模块、线缆和对端必须共同支持相应的速率与工作模式。面板上的可插拔笼子提供机械与电气接口，模块负责把设备侧电信号转换成适合线路传输的信号。模块封装名称描述外形和接口家族，不能单凭外形判断距离、光纤类型或是否能与某个对端互通。
机架内短距离连接可以采用直连铜缆，常简称 DAC。它把两端连接器与铜缆做成整体，通常适合较短距离，具体长度取决于速率和产品规格。有源光缆常简称 AOC，两端光电转换部分与光缆集成。分离式光模块加光纤则便于按现场距离、布线路径和维护方式组合。选择时要考虑长度、弯曲半径、重量、功耗以及更换的便利程度。
使用光纤时，必须核对单模或多模、连接器、纤芯数量、发送与接收波长及距离预算。同样写着 100 Gb/s 的 2 个模块，可能面向不同光纤与传输方式，不能直接配对。接收光功率过低可能来自距离、脏污、连接损耗或错误配线；过高也可能超出接收范围。看到端口反复起落时，要先检查这些具体条件，再考虑更换整台交换机。
速率从 25、100 到 400 Gb/s 演进，并不意味着所有链路都应立即升级。高速端口可能由多个通道组成，也可能支持拆分成多个低速端口，但拆分需要设备、软件、线缆与端口模式共同支持。1 个 400 Gb/s 端口能否拆成 4 个 100 Gb/s，必须查对应端口的能力表。拆分后还要计算面板端口数量、线缆管理与故障影响范围。
高速连接常用前向纠错，也称 FEC，帮助接收端纠正一定范围的传输错误。能被纠正的错误与无法纠正的错误含义不同：前者可以提示链路质量变化，后者可能造成报文损失。双方 FEC 模式不匹配也可能影响链路建立。规划时应记录推荐模式与兼容条件，排查时则比较同类端口的错误趋势，不把所有非零计数都直接判成业务中断。
模块功耗、设备风道和供电同样是网络能力的一部分。较高端口密度带来更集中的热量，模块温度过高可能导致告警、异常甚至链路掉线。机架冷热通道方向与设备进出风方向需要一致，线缆不能堵住风口。带宽升级除了计算交换机价格，也要核对电源预算、散热能力、备件类型和现场可维护性。这些约束会直接影响设备能否长期稳定地保持额定速率。
4 动手：对照一台 ToR 的端口与上行预算
现在为 1 个机架建立端口账本。假设固定端口 ToR 提供 32 个 100 Gb/s 端口，连接 24 台服务器，每台先使用 1 个 100 Gb/s 接口。另有 4 个端口作为上行，剩余 4 个留给扩展或替换。下行名义容量为 24 × 100 = 2400 Gb/s，上行名义容量为 4 × 100 = 400 Gb/s，下行与上行的容量比是 6∶1。这通常被称为超售比，但方案中应明确采用的是下行除以上行的口径。
这并不表示每台服务器始终只能使用约 16.7 Gb/s。少量服务器发送时，可以获得更多带宽；24 台同时向机架外持续满速发送时，上行才成为明确瓶颈。机架内部交换的流量不一定经过上行，所以还要区分机架内与跨机架流量。不能先把所有服务器网卡速率相加，再认定它们会在任何时刻同时压到上行链路上。
给这个机架设定 1 个可检查的业务假设：每台服务器需要向机架外持续发送 12 Gb/s，24 台合计为 288 Gb/s，占正常上行容量的 72%。若失去 1 条上行，剩余 300 Gb/s，利用率升至 96%，只剩 12 Gb/s 名义余量。平均值虽然仍低于总容量，短时突发和流量分布已经很难容纳。因此“正常能跑”与“故障后仍有余量”必须分别计算。
若改用 8 个端口上行，就恰好占满 32 个端口，容量比变成 3∶1，但不再保留空闲端口。若改用带有独立高速上行的设备，则要重新核对交换芯片容量、模块与线缆，以及对端可提供的端口。上行数并非可以无限增加的独立选项；每次改变，都要回到面板和芯片资源的实际组合。
动手时可以制作表格，列出端口编号、用途、配置速率、实际协商状态、连接对象和故障归属。只看管理界面上的“启用”不够，还要确认是否已经建立链路，以及错误计数是否持续增长。实验环境中可读取接口统计，比较观测窗口起止的字节数与丢包数。不同设备的命令不同，本课要求掌握记录字段，不假定某种命令在所有设备都存在。
多条上行也不能简单理解成任意流量都能平均分配。常见等价路径选择会按流的特征把流量分到不同路径，单条流通常受所选成员链路限制，多个大流也可能分布不均。因此计算 400 Gb/s 聚合容量时，要另列单路径 100 Gb/s 的约束。正式压测应使用能覆盖真实流数量、报文大小和收发方向的负载，避免用单个大文件传输替代全部验证。
5 CLOS 与叶脊的硬件含义
CLOS 是一种多级互连思路，叶脊网络是数据中心中常见的实现形式。叶交换机连接服务器，脊交换机负责连接各个叶交换机。在典型的 2 级结构中，每台叶交换机都连接每台脊交换机，服务器之间的跨叶通信经过叶、脊、叶。这里的层级描述连接关系，与设备外观大小或安装高度无关。
硬件上首先要核对端口数量。设有 8 台叶交换机、4 台脊交换机，每台叶向每台脊连接 1 条 100 Gb/s 链路，那么每台叶需要 4 个上行端口，每台脊需要至少 8 个对应端口，整个结构需要 32 条叶脊链路。机房扩展到更多叶时，脊的端口会逐渐用完；扩展更多脊时，每台叶也需要额外上行端口。能否扩容取决于两端资源。
若每台叶下接 24 个 100 Gb/s 服务器端口，该叶的下行总量为 2.4 Tb/s，上行仍为 400 Gb/s。增加叶的数量可以连接更多机架，却不会自动降低已有叶的 6∶1 超售比。只有为该叶增加可用上行带宽，或者减少对上行的需求，才会改变这个比值。网络图画得对称，不代表每个位置都有相同的可用容量。
再看故障。失去 1 台脊时，每台叶都少了 1 条上行，剩余上行从 400 降到 300 Gb/s；失去 1 条单独线缆时，主要影响相应叶的可用路径。若多条链路经过同 1 个线缆槽、配线架或电源故障域，它们可能同时失效。方案里要区分链路冗余与设备、供电、布线的独立性，不能只数图中的平行线。
服务器双网卡接入 2 台叶，也需要端到端设计。2 个端口若都在同 1 张网卡上，网卡本身仍是共享故障点；2 台交换机若共用会同时失效的供电路径，也不能覆盖相应故障。主机如何使用多条链路、故障后如何切换，还需要配套配置和验证。本课不展开多机协同协议，只要求在硬件表里把这些共享点标出来。
框式核心、固定端口叶脊和不同级数的网络各有适用范围，没有仅凭名称就能保证的无阻塞能力。所谓无阻塞必须附带流量条件、端口配置与故障状态。入门阶段可以先画出服务器到服务器的完整路径，标注每一段速率和共享资源，再用最窄的一段限制持续吞吐。复杂路由算法留到网络专题继续学习。
6 常见坑：用接入交换机思维估核心容量
办公接入网络常见大量终端接入、少量终端持续高负载的情况。数据中心里的存储复制、分布式计算和批量同步，可能让大量服务器在相近时间发送数据。若直接沿用“端口多、平均利用率低、上行够用”的判断，容易低估核心与汇聚路径的压力。关键差异是流量形态，而不是设备被叫作接入还是核心。
第 1 个坑是用端口速率代替全路径能力。服务器有 100 Gb/s 网卡，链路也显示 100 Gb/s，但网卡所在插槽可能只协商到较窄的 PCIe 链路，CPU 可能忙于处理小包，或者接收端存储写入跟不上。应该把发送主机、网络路径与接收主机分开观察。如果交换机没有拥塞证据，就不能仅凭应用变慢认定交换机缓冲不足。
第 2 个坑是混用单位和统计口径。100 Gb/s 的比特率按十进制除以 8，得到 12.5 GB/s 的理论字节率，还未扣除协议开销。文件工具显示的有效吞吐通常更低，若工具使用 GiB/s 还会出现单位差别。同样，按双向加总的交换容量不能直接除以单方向业务需求。方案应在每个数字旁保留单位和方向，让读者能复算。
第 3 个坑是把长窗口平均值当作瞬时峰值。某端口 1 分钟平均只有 20 Gb/s，也可能在其中很短的时段达到 100 Gb/s 并发生排队。监控采样周期越长，越容易把短峰值摊平。实际排查可结合队列峰值、丢弃计数、应用事件时间与更细粒度的遥测，明确数据能证明的时间尺度；缺少高频证据时，应保留假设而非断言。
第 4 个坑是把“有冗余”当成“故障时性能不变”。2 台设备、2 个电源或多条上行首先提供的是某种故障下继续工作的机会。少了资源以后，剩余容量可能只够维持关键任务。容量方案应该为正常、单链路故障、单设备故障分别列出需求与余量，写明是否允许降低后台任务速率，而不是只勾选冗余选项。
第 5 个坑是认为更大缓冲总能改善体验。对于短突发，更多可用缓冲可能减少丢包；对于长期拥塞，更多缓冲也可能让报文等待更久。存储读写、交互请求和后台备份对时延的容忍度不同，不能用同 1 个队列长度指标替代全部目标。硬件选型必须同时看吞吐、时延、丢包与故障容量，避免让某项漂亮参数掩盖其他限制。
7 案例：缓冲不足导致的微突发丢包
某机架中的 8 台服务器同时向另 1 台服务器发送结果。每个发送端在短窗口内达到 25 Gb/s，接收服务器所在出口为 100 Gb/s。交换机端口大多时间空闲，分钟平均利用率不高，但任务集中完成时出现重传和尾部等待。此处把“很多输入在很短时间汇向同 1 个输出”的突发叫作微突发，重点在时间短和汇聚强，而不是某个固定时长定义。
先做理想化估算。8 × 25 = 200 Gb/s 输入汇向 100 Gb/s 输出，超出部分为 100 Gb/s。若突发持续 200 μs，新增排队数据约为 100 × 10⁹ × 200 × 10⁻⁶ ÷ 8，即 2.5 MB。这里使用十进制 MB，假设起初队列为空、速率稳定且忽略内部存储开销。它是解释压力的模型，实际队列占用可能因报文大小和调度方式而不同。
假设该出口队列当时只可使用 1 MB 缓冲，在超额速率保持 100 Gb/s 的条件下，大约 80 μs 就会填满。后续报文可能被丢弃。若发送停止后队列里还有 1 MB 数据，在 100 Gb/s 出口上仍需约 80 μs 才能排空。这说明观察“任务结束”的时刻也要区分发送结束、队列排空和应用处理完成。
不能仅凭这个模型就下结论。先对齐应用异常与交换机计数器的时间：入口是否收到预期流量，目标出口队列是否出现峰值与丢弃，物理端口是否有不可纠正错误，接收网卡是否出现接收丢弃。若链路频繁起落或错误增长，应先排查模块和线缆；若交换机没有丢包而主机接收环节丢弃，就需要转向主机 CPU、内存与网卡处理能力。
在这次案例中，目标出口队列丢弃增加，其他出口较平稳，物理错误没有同步增长，应用重传时间与集中发送窗口相符。这些证据支持出口拥塞的判断。仍应确认计数器含义，区分队列拥塞丢弃、策略丢弃与其他异常，避免把名称接近的指标合并。若没有队列细粒度遥测，可在隔离实验中改变发送端数量和突发时长，观察故障是否随预测变化。
改进可以从减少同时发送量、分批启动后台任务、提高接收出口速率或调整经过验证的缓冲分配入手。增加其他方向的上行不会缓解这个接收出口的瓶颈；增加发送端网卡速率甚至可能使突发更尖锐。每次只改变可解释的条件，再对比队列峰值、丢弃与任务完成时间。本课不展开复杂的无损网络与拥塞控制机制，先把资源不足的地点找准。
8 把硬件规格写进网络容量方案
容量方案应把需求、硬件和验收连成可追溯的关系。需求可以写为“24 台服务器每台向机架外持续发送 12 Gb/s，允许后台任务分批执行”，同时注明统计窗口、并发条件与预计增长。不要只写“支持高性能计算”或“满足未来扩容”，因为这些表述无法决定端口数，也无法据此验收。
硬件清单需要覆盖服务器网卡型号类别、接口数量、端口速率、PCIe 接口要求、交换机端口模式、上行数量、线缆距离及模块类型。对于 100 Gb/s 端口，要说明使用何种连接介质与配套模式；对于双口网卡，要说明是否期望双口同时满速，以及主机侧总线是否具备相应能力。具体选型仍需依据设备公开规格与兼容性资料。
容量表至少包含正常状态和选定故障状态。前面的 400 Gb/s 上行承载 288 Gb/s 需求，在失去 1 条 100 Gb/s 链路后只余 300 Gb/s，故障余量明显不足。可以增加上行、降低允许并发或调整业务放置，但必须写明采用哪种措施。余量比例应由增长、突发与故障目标决定，不能凭空给所有机架套用同 1 个百分比。
再写可观察的验收条件：指定并发下的有效吞吐、应用完成时间、出口丢弃、链路错误与故障切换后的容量。测试流量要覆盖大包持续传输和短时汇聚等代表性场景，记录报文大小与测试时长。若某项指标来自估算而非实测，应保留这个标签；把模型结果写成实测结果，会让后续排查失去可信的起点。
最后补齐运维信息，包括端口标签、线缆两端标识、备用模块、供电与风道、计数器采集周期。端口资源与功耗资源都应留有可说明的扩展路径。这样设备到货后，实施人员能按表接线，测试人员能按条件验收，维护人员也能知道故障会影响哪些服务器，而不必重新猜测设计者的想法。
9 从网络硬件走向 PCIe 总线（H31）
沿着数据回到服务器内部，会遇到网卡与主机之间的连接。网卡装在物理插槽里，但插槽外形长度不保证实际可用通道数。较长插槽可能只接出较少的电气通道，也可能与其他设备共享资源。安装位置、主板配置和设备协商结果，都可能影响最终链路宽度与速率。这正是后续 PCIe 总线课程需要解释的内容。
先用带宽边界形成直觉。100 Gb/s 单方向对应 12.5 GB/s 的理论网络字节率。PCIe 4.0 每通道为 16 GT/s，采用 128b/130b 编码，x8 单方向编码后的理论上限约为 15.75 GB/s，尚未扣除事务等开销。GT/s 表示传输次数，不能直接当作 GB/s。这个比较只用于识别量级，不能保证某张网卡在该接口上一定达到线速。
如果 1 张双口 100 Gb/s 网卡的 2 个端口都要同方向满速，网络侧理论合计达到 25 GB/s，就更需要核对总线能力与实际工作负载。即使总线足够，CPU 处理小包、内存访问与软件配置仍可能限制吞吐。网络容量方案应把主机边界作为待核对项，把实际协商状态与目标负载下的测量作为证据。
到这里应形成跨设备的观察顺序：应用产生数据，主机准备数据，网卡通过总线取送数据，链路传输，交换机按出口容量排队，对端再接收处理。任意阶段都可能限制速度，但每种限制都有不同证据。H31 将继续解释 PCIe 的通道、代际和连接关系，帮助把“网卡很快但机器跑不满”缩小到可检查的硬件条件。
放进方案里
为 1 个包含 24 台服务器的机架编写网络容量条目，先写业务边界：每台服务器需要 1 个 100 Gb/s 接口，跨机架持续发送目标为每台 12 Gb/s，后台同步可能集中启动。将持续需求合计为 288 Gb/s，并单列微突发风险，不用分钟平均值代替瞬时输入。机架内流量另行统计，避免把不经过上行的数据重复计入。
设备条目写明 ToR 提供 32 个 100 Gb/s 端口，其中 24 个下联、4 个上联、4 个预留。正常上行容量为 400 Gb/s，下上行容量比为 6∶1；失去 1 条上行后容量为 300 Gb/s，持续目标占用达到 96%。据此记录待解决项：增加可用上行或限制后台并发，并在确定措施后重新给出故障余量，不能直接把当前配置判为故障容量充足。
连接条目注明线缆长度、模块与光纤类型、端口模式、FEC 配置依据，以及两端端口标签。服务器条目记录网卡安装位置、实际 PCIe 代际与宽度，核对双口同时工作时的主机带宽。供电和布线应标出共享故障点，说明哪些故障会同时影响多条路径。
验收条目安排持续发送、集中汇聚和断开 1 条上行的测试，记录有效吞吐、完成时间、出口队列峰值、丢弃与物理错误。估算缓冲需求时保留输入速率、出口速率和持续时间，注明共享缓冲并非全部可供该队列使用。最终交付端口表、容量表与测试记录，使后续扩容能够沿用相同口径复算。
持续负载验收可约定连续运行 10 分钟，每台服务器应用有效发送速率均达到 12 Gb/s，不能只凭合计值达标；同时要求链路无起落、不可纠正错误无新增。故障测试须预先写明允许的切换时间和后台限速值，并在切换后重复测量。保存测试前后的接口与队列计数器、模块收发光功率和温度，注明采样时间及计数器是否清零。模块更换后应复核兼容模式与错误增量，链路亮灯不能作为单独的交付依据。
10 小结：下一步 PCIe 总线（H31）
网络硬件能力来自完整路径：网卡、总线、链路、交换芯片、出口队列与对端共同决定结果。端口速率说明局部上限，聚合容量需要方向和流量条件，缓冲只吸收有限时长的输入输出差额。容量规划还要分别回答正常状态与故障状态能承受多少负载。
请尝试口头解释：为什么 4 条 100 Gb/s 上行不保证单流达到 400 Gb/s？为什么分钟平均利用率低仍可能丢包？为什么 16 GB 管理内存不等于 16 GB 报文缓冲？若能分别指出路径分配、突发时间尺度与资源用途，就已掌握本课主线。下一步进入 H31，把网卡背后的 PCIe 连接继续拆开看清。