1 为什么应用同学也要懂设备角色
订单 API 的调用超时，应用日志只留下“上游响应超时”。这句话描述了调用方的感受，却没有指出请求停在哪里：可能尚未离开服务器，也可能在某个交换端口排队，可能被安全规则丢弃，还可能已经到达后端，只是返回方向出现故障。把所有现象统称为“网络问题”，很难确定接下来该查看哪类证据。理解设备角色，是为了把模糊报错拆成可以验证的链路假设。
H14 已经讨论过 ENI 与主机路由：主机根据目的地址选择出口，必要时把报文交给网关。本课从主机出口继续向外走。交换机主要帮助同一二层网络中的设备交付以太网帧；路由器根据目的 IP 与路由表把分组送往其他网段；负载均衡器按照配置把流量分配给后端；防火墙按照安全策略决定流量是否允许通过。这里的名称表示功能角色，不能仅凭机箱外观判断职责。
现实中，1 台设备可能同时承担交换、路由和过滤功能，负载均衡也可能由软件实现。云中的虚拟交换、虚拟路由与安全策略同样具有这些角色，但实现位置和可见接口可能不同。我们先使用清楚的逻辑边界建立直觉，再把观察结果对应到实际部署。这样在讨论“网关是否异常”时，团队能继续问清楚：涉及哪条路由、哪个接口，还是这个节点上的过滤规则？
设想订单服务分布在应用网段，库存服务位于另一个网段，入口还有负载均衡与防火墙。应用同学至少应知道自己的请求经过哪些功能、每段链路的速率，以及应该找谁提供证据。设备知识不要求你独立配置整张网络，而是帮助你提出准确的问题：连接建立是否成功，报文是否进入正确的 VLAN，某个出口是否出现丢弃，健康检查与真实请求是否走了相同路径。
还有1个重要习惯：同时画请求方向与响应方向。请求成功经过的节点，不保证响应按相反顺序返回；路由、策略与负载均衡的地址转换都可能影响回程。后面每次分析订单 API，都要记录观察点、流量方向与时间窗口。没有这些限定，“端口正常”“带宽不高”“ping 能通”都只能支持很有限的结论。
2 交换机：二层转发直觉
以太网在本地链路上传送帧，帧中包含源 MAC 地址与目的 MAC 地址。交换机收到帧后，通常先根据源 MAC 学习“这个地址可以从哪个端口到达”，再根据目的 MAC 查找转发表。学习与查找需要结合所属 VLAN 理解：同样的 MAC 值处于不同 VLAN 时，不能直接当作同一个转发范围。交换机也不会通过阅读订单号来决定出口。
例如，订单服务器 A 与日志服务器 B 接在同一 VLAN 的不同端口。A 向 B 发送帧，交换机从入端口学习 A 的位置。如果已知 B 的位置，便把帧送到 B 对应的端口；如果尚未知晓目的 MAC，通常会在该 VLAN 允许的其他端口泛洪。B 发出响应后，交换机又能学习 B 的位置。这里的泛洪是对未知目的位置的处理，并不表示所有后续流量都要遍历整个网络。
广播帧也会在所属广播域内传播。IPv4 的 ARP 请求就是常见例子：主机需要知道本地目标或下一跳网关的 MAC 地址时，会发起地址解析。对于跨网段的订单请求，主机通常解析的是网关 MAC，而不是远端服务器 MAC。因此，同一个以太网帧的目的 MAC 可以指向网关，帧内 IP 分组的目的 IP 仍然是远端服务器。这是理解交换与路由衔接的关键。
VLAN 用于划分逻辑上的二层广播域。接入端口通常把终端接入某个 VLAN；需要在设备间承载多个 VLAN 时，链路可以使用 802.1Q 标签区分流量。具体的无标签处理与端口模式由配置决定，不能看到“有网线连接”就认定两端属于同一网络。端口 VLAN 配错，可能让主机解析不到网关，也可能把流量放进错误的广播域。
VLAN 隔离了二层传播范围，但 VLAN 编号本身不是完整的安全策略。不同 VLAN 之间可以通过路由互通，允许哪些业务仍需结合过滤规则决定。VLAN 与 IP 子网也属于不同层面的概念；工程中经常让1个 VLAN 对应1个子网，便于管理，但不能把这种惯例误认为协议强制要求。排查时应分别核对 VLAN 归属、IP 地址与网关配置。
交换网络还必须避免失控的二层环路。广播帧不像 IP 分组那样依靠 TTL 限制逐跳寿命，环路可能导致帧反复复制，迅速消耗带宽并使 MAC 学习不稳定。网络会使用环路防护机制或受控的拓扑设计，但应用侧不能默认任何新增连线都无害。看到广播突增、MAC 地址在端口间频繁变化，应考虑环路或异常发送者，并由网络人员结合拓扑验证。
3 路由器：跨网段怎么走
当目的 IP 不在主机认定的直连网段内时，主机根据路由表选择下一跳。分组到达路由节点后，节点继续查询目的 IP，通常按照最长前缀匹配选择最具体的路由。例如，去往某个 /24 网段的路由，比覆盖它的 /16 路由更具体；没有更具体匹配时，才可能使用默认路由。路由器首先解决的是“交给谁继续走”，并不保证最终服务一定可用。
路由转发会跨越链路边界。路由节点移除入链路的二层封装，在下一段以太网链路上重新封装，源与目的 MAC 随链路变化。普通转发通常保留源与目的 IP，同时递减 IPv4 的 TTL 或 IPv6 的 Hop Limit；若路径还执行地址转换，IP 或端口也可能改变。不要拿起点看到的 MAC 地址去要求所有中间链路保持一致。
以订单应用访问库存服务为例：应用发现库存 IP 位于远端网段，把帧交给本地网关；网关查到库存网段的路由，再把分组转发给下一跳或直接交付目标所在链路。库存服务响应时，也要按照自己的路由配置寻找订单应用。去程路由正确、回程缺失，仍会表现为应用超时。只检查发起端的默认网关，不能证明整个会话可达。
物理路由器并不是跨网段转发的唯一载体，具有路由能力的交换设备也能承担网关角色。图上的“路由”应先当作逻辑功能理解，再确认它落在哪个设备、虚拟网络或主机上。同样，配置了路由不等于允许通过：接口状态、下一跳解析、访问控制和回程都可能改变结果。排查时把“有路由”“能转发”“策略允许”“业务正常”分开验证。
路由路径中还有 MTU 约束，即链路能够承载的分组大小上限。小探测包可以通过，并不代表较大的业务报文也能顺利交付。封装可能减少可用空间，路径 MTU 发现又依赖相关反馈能返回发送端。初学阶段不必记住所有分片细节，但要记住：如果小请求正常、大响应或特定报文尺寸异常，应把 MTU 与反馈报文处理加入候选原因。
4 负载均衡与防火墙在链路上的位置
负载均衡器给调用方提供服务入口，再根据后端池、健康状态与分配规则处理流量。面向传输层的实现可以围绕 IP、端口与连接分配后端；面向应用层的实现还可以依据 HTTP 主机名、路径等信息选择服务。某些实现会代理连接，形成客户端到入口、入口到后端的不同连接；另一些实现采用不同转发方式。因此，看到“负载均衡”这个名字，还要继续确认它的具体工作模式。
健康检查是负载均衡器对后端可用性的抽样判断。检查某个端口能建立连接，只证明该条件下的连接测试通过；检查健康路径返回成功，也未必覆盖订单写入、数据库访问或库存锁定。后端过载、检查过于简单、摘除延迟，都可能使“健康”的节点仍然让真实订单超时。应用应提供有意义且成本可控的健康信号，并明确检查源地址、协议与路径。
防火墙的核心工作是执行安全策略，规则可能涉及源地址、目的地址、协议、端口以及连接状态。具备状态跟踪的防火墙会维护会话信息，允许既有连接的合法返回流量，但其行为受具体配置和实现影响。连接数量、状态表容量与超时设置也可能成为约束。端口速率仍有余量时，新连接也可能因为状态资源耗尽而失败。
防火墙可以采用路由模式，也可以采用透明模式，还可能同时执行地址转换。负载均衡也可能位于防火墙之前、之后，或与多段安全策略组合。不存在适用于所有系统的唯一设备顺序。本课示例采用“入口防火墙—负载均衡—路由功能—应用网段”的逻辑路径，目的在于标出检查责任；真实项目必须依据部署证据画图，并补上回程和旁路流量。
订单 API 的 HTTPS 请求尤其适合用来检查边界。若 TLS 在负载均衡处终止，入口能够看到解密后的 HTTP 信息，随后到后端的协议需要另行确认；若 TLS 透传，入口可见的信息和分配能力会受到工作方式限制。排查时记录 TLS 终止点、地址转换点与日志中的客户端地址来源，否则容易把代理地址误认成真实客户端，或者在错误的链路寻找加密会话。
定位时按观察点串联证据：防火墙是否记录到命中或拒绝，负载均衡是否接受连接并选出后端，后端是否收到请求。时间、连接地址与端口要能对应，必要时结合请求标识关联应用日志。单独看到防火墙“放行”日志，只能证明相应策略判断，不能证明后端处理成功；单独看到后端响应，也还需要确认响应是否到达调用方。
5 网线、光口与带宽标称
链路最终需要物理介质承载信号。常见网线传输电信号，光纤传输光信号；可用距离、支持速率与误码表现受介质规格、收发器、连接器和布线质量共同影响。光口还要匹配光纤类型、波长、传输距离与收发方向等条件。接口形状相同不代表可以任意互换，接头插上也不等于链路质量合格。
“10 Gbit/s”表示比特率，不能直接当作“每秒 10 GB”。按十进制单位换算，10 Gbit/s 对应理论上的 1.25 GB/s；应用有效数据还要扣除各层开销，并受到报文大小、确认机制、重传与处理能力影响。全双工端口通常可以在两个方向各自按协商速率传输，观察利用率时应分别看收与发，不能把双向流量相加后随意除以单向速率。
端口标称速率也不等于整条业务路径的可用带宽。多个服务器可能共享同一个上联，交换设备内部的资源也可能存在限制。假设 8 台服务器各接入 10 Gbit/s 端口，却共同经过 20 Gbit/s 上联；它们同时向上联方向发送时，需求可能超过出口能力。是否发生拥塞取决于流量方向、同时性和目的位置，不能仅把所有接入口速率相加就判定系统必然故障。
平均利用率还会隐藏短时突发。监控以 60 秒为周期展示的 30%，可能包含数毫秒内多个发送者同时打满出口的时刻。队列能够暂存部分流量，但排队会增加延迟，空间耗尽后会发生丢弃。增加缓存只能改变突发的容纳能力，不能持续解决输入速率超过输出速率的问题。订单 API 对尾延迟敏感，往往会先感受到排队，再看到明显的平均吞吐异常。
链路聚合也要谨慎理解。多条物理链路可以共同提供容量与冗余，但常见分配方法按流的特征做哈希，同一个连接通常仍落在某条成员链路上。于是聚合总利用率不高，某个成员却可能拥塞；增加成员也不保证单连接吞吐按比例提高。排查时应同时看聚合口和成员口，理解分配粒度，再判断扩容是否能改善当前订单流量。
6 观测：接口计数、错包、光功率入门
接口计数器提供了设备实际经历的流量证据。初次查看时，先确认接口连接谁、统计方向是什么、速率是多少，再关注收发字节数、报文数、错误、丢弃与链路状态变化。很多计数是累计值，设备重启或计数清零会影响解释。不能仅凭“错误累计 200”判断当前故障，必须比较故障窗口内的增量与流量规模。
例如，记录间隔为 10 秒，接口发送字节计数增加 500000000，则平均发送速率约为 400000000 bit/s，即 400 Mbit/s。计算使用“字节增量 × 8 ÷ 秒数”，再与该方向的实际链路速率比较。如果采样跨越设备重启、计数回绕或接口重新创建，应先处理时间序列断点。采样越粗，对短时队列峰值的解释能力越有限。
错误与丢弃不能混为一谈。CRC 或 FCS 错误常提示接收端发现帧校验异常，可进一步检查介质、连接器、收发器或相关端口；输出丢弃与队列丢弃可能指向拥塞、队列策略或其他资源限制。不同平台对计数项目的定义不完全一致，需查看对应说明。看见 drops 并不能立即归因于线缆，看见 errors 也不能跳过接口方向和具体子项。
光功率可以帮助判断光链路的物理状态。支持数字诊断的收发器可能报告发送功率、接收功率、温度与告警。功率常用 dBm 表示，是对数单位；负值本身很常见，不能简单当作故障。接收功率过低可能缺少接收裕量，过高也可能超出接收范围。判断时要对照对应器件的工作范围和告警阈值，同时比较两端与历史变化。
如果某侧接收功率下降，又伴随接收错误或链路反复切换，应检查连接器污染、弯折、插接和器件状态等候选原因。诊断读数正常也不能排除所有瞬态物理问题，反过来，单次读数接近阈值也不足以证明它造成了订单超时。让物理指标、接口计数和应用失败时间对齐，证据才会形成约束，而不是各说各话。
应用同学可以先收集业务请求数、请求大小分布、连接建立耗时、错误比例与延迟分位数，再请网络侧提供相同时间窗口的接口增量、队列丢弃与状态变化。双方需要统一时区并确认时钟偏差。临时采集宜先采用只读查询，保留原始证据；清零计数、切换端口或替换器件会改变现场，应纳入受控处置，并记录操作时刻与影响范围。
7 常见坑：把防火墙当路由器、忽略广播域
第 1 个坑是看到安全设备就把所有可达性责任交给它。路由回答下一跳在哪里，安全策略回答该流量是否允许，两者都可能配置在同一台设备上。增加允许规则不能修复缺失路由，增加静态路由也不能绕过拒绝策略。讨论“防火墙不通”时，应拆成入接口是否收到、路由是否匹配、策略是否允许、出接口是否发出，以及返回连接是否符合状态要求。
第 2 个坑是用 VLAN 数量代替广播域影响分析。某 VLAN 中接入的主机越多，异常广播或未知单播泛洪可能影响的对象也越多；真正需要关注的还包括广播速率、拓扑范围、端口能力与终端承受能力。把多个服务随意放进同一个 VLAN，可能让备份任务或错误接线影响订单业务。拆分 VLAN 也不是自动修复，应同时设计跨网段通信、地址规划与安全边界。
第 3 个坑是把不同失败原因都叫“丢包”。策略明确拒绝、队列溢出、校验错误和主机接收处理不及时，都可能导致调用方没有等到数据，但对应的证据与改进方式不同。还要区分网络报文丢失与应用主动关闭连接。先给现象确定范围：哪些源和目的、哪个协议、哪个方向、何时开始、是否只影响大包或新连接，再决定查看哪种计数。
第 4 个坑是只看设备在线和端口灯亮。管理地址可访问，说明特定管理路径可用；端口处于 up 状态，说明链路在相应层面建立，仍可能存在错包、拥塞或策略问题。一次 ping 成功也只说明该次 ICMP 探测得到了响应。设备角色图必须配合业务路径与负载证据，才能从“设备看起来活着”推进到“订单请求经过的这段路径满足要求”。
8 案例：大促时某 VLAN 打满
大促开始后，订单 API 的延迟突然升高，部分请求重试。应用 CPU 和数据库负载没有同步升高，监控面板却显示“应用 VLAN 接近打满”。这仍然只是线索：VLAN 是逻辑范围，没有脱离物理路径的统一线速。团队先明确面板汇总了哪些接口，最终发现受影响的应用实例与一个备份任务共用某条上联，拥塞集中在通往应用区域的出口方向。
故障窗口内，该出口的发送速率接近链路能力，输出队列丢弃持续增加；相关端口的 CRC 错误没有明显增长。业务日志显示大响应和高并发阶段更容易超时，备份任务恰在活动开始时执行全量传输。进一步查看流量组成，广播并未异常增加，主要是已知目的的单播。证据指向共享出口拥塞，而非仅凭“同一 VLAN”就认定发生广播风暴。
团队先对备份流量实施已有预案中的限速和错峰，保留订单业务容量，并观察队列丢弃与请求延迟是否共同下降。若只能暂停任务，也应记录暂停时刻，比较前后业务指标。盲目重启交换设备会中断更多连接，还可能清除重要计数；直接提高客户端重试次数则可能增加流量，使拥塞进一步恶化。缓解动作需要对应已经发现的资源竞争。
后续方案包含为共享上联扩容、调整备份路径，并为非关键传输设置带宽约束。是否拆分 VLAN，要根据广播域边界与业务隔离需求决定：如果拆分后仍经过同一个拥塞出口，总带宽竞争依然存在。若证据实际显示广播异常，则应定位广播来源、核查环路和防护配置，处理路径又会不同。相同的“VLAN 打满”口头描述，可以对应完全不同的原因。
复盘还补充了更细的出口监控与容量预算。预算包含正常订单流量、活动峰值、批处理和故障切换后的集中流量，预留空间依据测量和服务目标确定。不能只按平日平均值采购带宽，也不能假设备用路径在切换后天然有足够容量。这个案例的可迁移经验，是把逻辑隔离范围、物理瓶颈和流量竞争者分别标出来，再选择对应措施。
9 排查案例：偶发丢包却 ping 正常
另一次故障中，订单接口每隔一段时间出现少量超时，运维从办公机连续 ping 服务入口却未发现异常。团队没有据此关闭网络调查，而是先对齐探测条件：办公机到入口的路径，并不等于应用实例到库存服务的路径；小尺寸、低频 ICMP 探测，也不等于并发 TCP 请求。探测成功仍有价值，但只能说明它覆盖的源、目的、协议、大小与时间条件。
团队从受影响应用实例发起受控业务探测，记录连接建立耗时、实际请求耗时与失败时刻。结果显示连接建立大多正常，超时集中在返回数据较多的调用。负载均衡日志确认请求已分配到后端，后端日志也记录了处理完成。于是排查重点移向返回方向，同时核对地址转换后的连接信息，避免在错误接口上寻找原始地址。
对应时间窗口中，返回路径某个出口出现短时队列丢弃，60 秒平均利用率却不高，CRC 错误与光功率趋势没有同步异常。更细的采样和受控复现显示，多个后端同时完成批量读取时，会向同一个出口集中返回数据。TCP 重传吸收了部分损失，少数请求则超过调用方超时阈值。因此应用看到的是偶发超时，低频 ping 没有稳定捕捉到同样的拥塞窗口。
团队通过限制批量调用并发、分散集中返回时刻来缓解突发，同时评估出口容量与队列策略。调整后，使用相同探测条件比较重传、队列丢弃和高分位延迟，确认它们随之改善。仅把超时阈值调大可能减少报错，却会让用户等待更久；是否调整需要结合服务目标，而不能替代对拥塞来源的处理。
这个案例也有明确的推断边界：若没有队列丢弃与时间关联，就不能因为“大响应更容易失败”直接认定拥塞。还应检查路径 MTU、策略差异、主机接收丢弃或物理错误等候选项。有效排查是逐步缩小范围：先复现业务条件，再定位失败阶段，最后用对应观察点的增量证据验证假设。ping 是工具箱中的1项工具，不能独自承担业务验收。
放进方案里
为订单 API 编写方案时，先给出包含请求与响应的逻辑路径：客户端经过入口安全策略和负载均衡，到达应用网段，再经路由访问库存服务。标明交换范围、网关、VLAN 与子网的对应关系，并注明这些角色实际部署在哪里。另行标出 TLS 终止点、地址转换点和健康检查来源，使应用日志中的地址能够与设备侧记录对应。
容量部分列出关键接口的实际速率、共享上联、链路聚合成员及故障切换后的承载关系。根据订单峰值、报文大小、并发与批处理流量估算需求，说明采用何种测量窗口和预留依据。对于备份等可调度任务，写清限速与错峰规则；若多个 VLAN 共用出口，应在图中保留这条共享依赖，避免把逻辑隔离误当成独享带宽。
观测部分约定应用请求成功率、连接耗时与高分位延迟，同时采集关键接口收发速率、错误增量、队列丢弃和链路变化。光链路记录功率趋势与对应阈值，不给所有器件套用同一个数值。监控需注明方向、采样周期和时间基准，并约定异常时由谁提供安全策略日志、负载均衡日志及接口证据。
验收使用接近真实订单的请求大小、连接方式和并发，覆盖正常运行、批处理重叠与单路径故障场景。检查业务指标与链路指标是否同时满足目标，保留测试时间和拓扑版本。处置预案优先规定如何定位拥塞出口、如何限流和隔离异常来源，以及何时恢复；每项调整都有负责人、影响范围、回退条件和复测方式，让设备角色最终落实为可执行的保障措施。
10 小结：设备角色清单
- 交换机：依据 MAC 与 VLAN 等信息进行二层转发，关注广播域、学习状态、端口与环路。
- 路由器：依据目的 IP 和路由选择下一跳，关注去程、回程、邻居解析与 MTU。
- 负载均衡：按照工作模式和后端状态分配流量，关注健康检查、连接边界与 TLS 终止点。
- 防火墙：执行安全策略，关注匹配条件、会话状态、拒绝记录与状态资源。
- 物理链路：提供实际传输能力，关注速率、介质匹配、接口错误与光功率趋势。
自测时尝试解释3件事：为什么跨网段帧的目的 MAC 可以是网关，目的 IP 却是库存服务？为什么拆分 VLAN 后仍可能争抢同一条上联？为什么 ping 正常不能证明订单 API 的返回路径满足要求？能沿着设备角色、链路方向与证据回答这些问题，就能把“网络不稳定”转化为可协作处理的具体问题。
下一课转向 H18 数据中心入门：把本章验收过的结论带进后续主题，写成可检查的方案约束。