一台主机能够运行程序，并不意味着它已经能够与其他主机交换数据。程序产生的数据需要经过操作系统、驱动和网卡，再沿着具体链路到达下一台设备。网卡把主机内部的数据搬运与外部通信连接起来，端口提供连接位置，链路则描述两端之间可用的通信通道。本课沿用 H6 中 CPU、内存与外设协作的视角，结合 H12 中吞吐与延迟的区分，建立阅读网络规格和选择网络配置所需的基础。
学完本课，应能指出网卡、端口、链路各自负责什么，辨认以太网帧中的主要字段，说明交换机与路由器处理范围的区别，并用带宽和 PPS 两个维度判断云实例的网络能力。这里关注数据如何离开主机、经过哪些边界以及哪里可能成为瓶颈，不展开传输层连接建立、拥塞控制与路由协议。
1 网卡角色
网卡是主机参与网络通信的接口设备，常写作 NIC。发送时，它接收主机安排的数据，按照链路规则形成可发送的信号；接收时，它识别进入端口的帧，并把符合条件的数据交给主机。这里的“网卡”既可能是一块独立扩展卡，也可能集成在主板上。在虚拟机里，操作系统看到的还可能是虚拟网卡，背后由宿主机和云平台共同提供实际传输能力。
端口是连接的落点，链路是两个落点之间形成的通信关系。一块网卡可以有多个物理端口，每个端口又可能连接不同网络。操作系统中的网络接口名称是软件管理对象，不能简单等同于机箱上的插口数量。例如，虚拟接口没有独立插口；具有多个端口的网卡也可能呈现多个接口。阅读规格时，应分别确认网卡数量、端口数量、单端口能力与软件接口布局。
主机发送数据时，CPU 通常负责执行协议处理和提交发送任务，内存保存等待发送的内容，驱动负责与网卡交换描述信息。网卡可以通过 DMA 访问被安排好的内存区域，减少由 CPU 逐字搬运数据的工作。DMA 并不意味着 CPU 完全退出通信过程，队列管理、接收处理以及应用读写仍会消耗计算资源。H6 中“外设与 CPU、内存协作”的关系，在网络路径上同样成立。
因此，网络慢不能直接归因于网线或网卡。应用产出速度、CPU 处理能力、内存访问、驱动队列以及外部链路都可能限制结果。定位问题首先要把路径画清楚，确定观察的是应用完成速度、接口发送速度，还是链路能够承载的上限。只有指标指向同一段路径，比较才有意义。
2 链路与速率
以太网链路的速率常以 bit/s 表示，例如 1 Gbit/s、10 Gbit/s、25 Gbit/s。这里的 bit 是比特，而文件大小和程序读写量常以 Byte 表示。按照 1 Byte = 8 bit 换算，10 Gbit/s 对应的理论字节速率是 1.25 GB/s。这个换算只是单位转换，尚未扣除帧头、帧间开销以及上层协议消耗，因此应用实际传输文件的速度通常达不到该数值。
一条链路能以什么速率工作，需要两端端口和中间介质共同支持。端口标称支持 25 Gbit/s，不代表接上任意线缆或模块都能建立该速率的链路。另一端交换机端口、光模块或铜缆类型、兼容性和距离都需要匹配。有些设备可以协商到较低速率，有些组合则无法正常建立链路。选型应同时列出两端端口与介质，不能只购买一块高速网卡便认为升级完成。
常见现代以太网链路以全双工方式工作，发送和接收可以同时进行。一个标称 10 Gbit/s 的全双工端口，通常可以在两个方向分别达到该链路速率，但不能因此把单向任务的上限写成 20 Gbit/s。云规格中的“总带宽”“入方向”“出方向”还可能采用不同计量口径，应以对应规格定义为准。比较两个产品之前，先确认数字描述的是单方向还是双向合计。
链路速率也不等于整条业务路径的速度。主机到交换机可以是 25 Gbit/s，而后续出口只有 5 Gbit/s；同一交换机上的多台主机还可能竞争共享上联。此时，提高本地主机端口速率不一定改善跨出口传输。它与 H12 中存储吞吐的判断相似：某个接口的标称上限，只描述路径中的一个环节，实际结果还取决于其他环节和同时发生的负载。
还要区分速率与延迟。较高链路速率能够缩短相同大小帧占用线路的时间，却不能保证应用响应时间按比例下降。排队、主机处理和传播时间仍然存在。一项需要快速响应的小请求，即使只消耗少量带宽，也可能受到队列等待影响。因此，链路升级的理由应落到业务需求上，是要搬运更多字节、处理更多帧，还是降低某段排队时间。
在自有物理测试机上，可以先确认链路实际建立的速率。以下假设接口名为 eth0，生产环境应替换成真实名称；命令只读取状态，不修改配置。
ethtool eth0典型输出中的关键行如下：
Speed: 1000Mb/s
Duplex: Full
Link detected: yes如果采购目标是万兆，这组输出说明当前只建立了千兆链路。此时应检查对端端口、模块和线缆，而不是先调整应用并发。若输出为 Speed: Unknown!，还要结合驱动类型判断，不能据此认定链路断开。云虚拟网卡可能不公开物理协商速率，需要另查实例配额。
再看一次实际传输：两次接口发送字节计数相隔10秒，相差十亿字节，换算得到平均八百兆比特每秒。若链路实际为千兆，这已经是较高利用率；若误把单位看成每秒八百兆字节，就会把负载高估八倍。测量应记录字节来自接口还是应用：文件复制工具显示的是文件有效内容，接口还可能统计同机其他程序的通信。用共享接口计数评价单个任务时，应先确认背景流量，或者同时记录任务开始前后的空闲基线。
还需避免把多条连接的合计速度当作单条连接能力。例如多任务同时复制可以消耗整台实例的总带宽，但一个任务仍可能受远端磁盘、单个处理线程或中间出口限制。测试结果应写明发送端、接收端、方向、并发数和持续时间，才能判断升级哪段链路有帮助。
3 MAC 与帧
以太网链路上传输的基本组织单位是帧。常见以太网帧包含目的 MAC 地址、源 MAC 地址、以太类型、载荷以及用于差错检测的 FCS。目的地址说明这一帧在当前以太网范围内交给谁，源地址说明由哪个接口发出，以太类型帮助接收方判断载荷应交给哪类处理逻辑。载荷可以装入 IP 数据包，但帧与 IP 数据包属于不同层次，不能混用名称。
MAC 地址通常写成 6 组十六进制字节，例如 02:1a:2b:3c:4d:5e。它是以太网接口使用的链路层地址，适合说明当前链路范围内的交付对象。不要把 MAC 当成业务身份、用户身份或永不改变的硬件身份证。虚拟接口可以拥有由平台分配的 MAC，部分场景也允许软件配置地址；地址能否变更、如何保持唯一，需要服从所在网络的管理规则。
发送端不会把应用中的任意长内容一次性塞进一个普通帧。接口的 MTU 规定该接口通常允许承载的最大网络层包大小，常见以太网 IP MTU 是 1500 Byte。这个数字不包含完整以太网帧的所有字段，也不是应用每次写入的长度。更大的应用数据需要由协议栈按规则组织；一次应用写入与线路上的帧数量通常没有固定的一一对应关系。
帧到达接收端后，网卡和操作系统逐步检查并处理它，载荷最终交给相应程序。若经过路由器，原来的以太网帧会在这一跳终止，路由器根据网络层信息选择下一跳，再为新的链路构造新的帧。因此，远端服务器的 MAC 通常不是发送主机在本地链路上直接使用的目的 MAC；跨网段发送时，本地帧往往先交给网关对应的链路层接口。
更大的 MTU 有时能降低处理相同字节量所需的包数，但前提是路径和设备配置支持。仅把一端 MTU 调大，不能保证整条路径支持，也可能造成通信异常。初次规划时，保持平台推荐的 MTU 并核对路径要求，通常比盲目追求更大帧更可靠。本课只要求理解帧大小影响开销和包数，不继续展开分片与路径发现机制。
可以用接口输出把这些字段对应起来：
ip link show dev eth0输出节选可能是：
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
link/ether 02:1a:2b:3c:4d:5e brd ff:ff:ff:ff:ff:ff这里的 link/ether 后面是本接口的 MAC，brd 后面是以太网广播地址，mtu 1500 是接口的网络层包大小约束。3个字段分别回答身份、广播目的地址和大小限制，不能把广播地址抄成网关地址。接口支持广播也不表示当前业务正在广播；是否存在大量广播，需要观察实际流量和相关计数。
在允许探测的测试网络内，可用下面的命令验证一条 IPv4 路径能否传送相应大小的包。这里要求发送端禁止分片，载荷大小再加上通常的二十字节 IPv4 头和八字节 ICMP 头，正好对应一千五百字节。
ping -4 -c 3 -M do -s 1472 10.0.1.20若出现 3 packets transmitted, 3 received, 0% packet loss，说明这次探测成功；若出现 message too long, mtu=1400，说明本机已知的出口约束更小，应核查接口与路径。单纯超时则不能直接证明 MTU 不匹配，也可能是目标不回应或规则过滤。不要为了让测试通过直接修改生产 MTU，尤其要核对隧道封装和云平台推荐值。小包能通而大包异常是线索，仍需结合路径证据确认原因。
4 交换与路由边界
交换机主要在同一个第 2 层网络内转发以太网帧。它可以根据收到帧的源 MAC 与入口端口建立学习记录，再根据目的 MAC 查找合适的出口。这里的关键关系是“某个 MAC 可以从哪个端口到达”。交换机不是每次都把帧送给所有端口：已知目的地址时通常可以定向转发，未知目的以及广播等情况则可能在所属第 2 层范围内扩散。
路由器主要连接不同的 IP 网络。它读取 IP 数据包中的目的地址，根据已有转发信息决定下一跳或出口。数据从一个网络进入另一个网络时，需要跨越这样的第 3 层边界。可以把交换理解为同一片本地网络中的交付，把路由理解为选择通往其他网络的下一段路径。真实设备可能同时提供这两类功能，设备外壳上的名称并不能完全说明某次转发使用的处理方式。
例如，主机 A 与主机 B 位于同一第 2 层网络且 IP 配置允许直接通信时，A 可以取得 B 的链路层地址，并通过交换机向 B 发送帧。如果主机 C 位于另一个 IP 网络，A 通常先把承载目标 IP 数据包的帧交给网关。此时帧的目的 MAC 指向本地网关，IP 数据包的目的地址仍指向 C。把这两个目的地址分开，便能避免“发往远端就必须知道远端 MAC”的误解。
第 2 层广播的传播范围需要控制，否则许多主机会被迫处理与自己无关的流量。网络划分和第 3 层边界可以限制这类传播。云上的 VPC、子网与虚拟网络通过平台实现相应的地址和转发规则，但不应直接把它们想象成完全可见的机房线缆。使用者通常根据平台公开的子网、路由和安全规则配置连接，而不管理底层交换机如何学习每个地址。
安全组与路由也承担不同职责。路由描述数据应往哪里走，安全规则描述哪些通信被允许。存在路由不代表一定能够通过安全检查，安全组放行也不能补齐缺失的转发路径。分析“能不能通”时，应分别核对地址归属、出口路径和允许规则，再结合接口状态判断问题发生在哪个边界。
用一个具体地址例子检查转发选择。假设主机地址为 10.0.1.10/24，本地网关为 10.0.1.1，在普通 Linux 以太网测试环境执行：
ip route get 10.0.1.20
ip route get 10.0.2.20
ip neigh show dev eth0对应输出可简化为：
10.0.1.20 dev eth0 src 10.0.1.10
10.0.2.20 via 10.0.1.1 dev eth0 src 10.0.1.10
10.0.1.1 lladdr 02:aa:bb:cc:dd:01 REACHABLE第一行没有 via，表示本机按现有路由把目标视为直接可达；第二行明确选择网关。第3行是网关 IP 到本地链路 MAC 的邻居记录，因此可以解释跨网段帧的目的地址从哪里来。邻居表按需建立，尚未发起通信时没有目标记录很正常；STALE 也不等于断网，它表示记录需要在后续使用时确认。持续出现 INCOMPLETE 或 FAILED 才值得检查邻居解析、地址配置与本地连接。
如果第二条命令反而显示直接从接口发往目标，应先查子网掩码和更具体路由，不能立即归咎于交换机。掩码错误可能使主机对远端地址尝试本地解析，从而始终交不到正确网关。云网络可能通过代理或虚拟化提供邻居响应，不能根据看到的 MAC 反推真实机房拓扑。路由命令验证的是本机选择，后续仍要核对云路由表、对端返回路径和安全规则；单方向有路由，并不足以完成一次请求与响应。
5 云 ENI、带宽与 PPS
弹性网卡常写作 ENI，是云平台提供的网络接口资源。它通常关联某个 VPC 和子网，并按平台规则配置私有 IP、MAC 以及安全组等属性。ENI 挂载到云实例后，实例中的操作系统才能通过对应接口使用这部分网络连接。它不是一块由用户直接插拔的实体扩展卡，而是平台网络能力在实例侧的资源表达。
“弹性”也不意味着可以任意迁移或无限叠加能力。ENI 可挂载的实例类型、数量、所在 AZ、子网约束、辅助地址数量以及卸载条件，都需要阅读平台说明。主网卡和辅助网卡的生命周期规则可能不同。业务如果依赖迁移地址或多网卡隔离，应先确认支持范围，再设计切换步骤，不能仅凭接口资源的名称推断故障恢复能力。
带宽描述单位时间允许传输多少比特，PPS 表示每秒处理的数据包数量。它们约束的是不同维度：大包更容易消耗带宽，小包更容易消耗包处理能力。云实例可能同时受到实例总带宽、实例 PPS、公网带宽以及具体出口资源限制。增加 ENI 数量通常不代表实例总带宽与 PPS 随之线性增长，多个接口也可能共享同一实例上限。
规格还可能区分基准能力与突发能力。基准能力用于判断持续负载，突发能力则可能受持续时间、资源配额或平台条件约束。如果业务持续发送大量数据，仅根据“最高可达”的数字选型，很容易在运行一段时间后碰到限制。应核对所选实例规格、通信方向、内外网范围以及统计窗口，确保两个数字可以放在一起比较。
网络性能还会消耗主机资源。接收大量小包时，即使链路利用率不高，CPU 也可能忙于中断、队列处理和协议工作。多队列、合适的驱动以及平台支持的加速机制有助于分配处理压力，但最终效果需要在目标实例上测量。不能把平台标称 PPS 直接当作应用每秒能完成的请求数量，一个请求可能涉及多个包，应用自身也有处理成本。
6 观察 ethtool 与 ip
在 Linux 主机上，ip link 可以查看网络接口名称、管理状态、链路状态、MAC 和 MTU 等信息。接口处于 UP 通常说明管理上已启用，但还应结合 LOWER_UP、载波状态及运行环境判断是否存在可用链路。虚拟接口的状态含义可能受到平台实现影响。看到接口名或 MAC，只证明对象存在，不能单独证明远端业务可达。
ip addr 用于观察接口地址，ip route 用于观察本机已有的路由信息。例如，运行 ip route get 目标IP，可以查看内核针对该目的地址选择的出口、下一跳和源地址。它帮助解释“数据准备从哪里离开”，但不是一次端到端通信成功测试。应把输出与实例子网、目标地址和云上路由配置对应起来，避免仅凭默认路由存在就认定网络正常。
ethtool 接口名常用于查看接口报告的速率、双工和链路检测结果，ethtool -i 接口名可以观察驱动信息。实体网卡上，这些字段有助于确认链路是否按预期建立；云虚拟网卡上，某些字段可能不支持、显示未知，或报告虚拟设备能力。此时应以实例规格和平台文档作为配额依据，不能把虚拟接口报告的速率直接解释为承诺可用带宽。
ip -s link 可以查看收发字节、包数、错误和丢弃等累计计数，部分网卡还支持通过 ethtool -S 接口名读取更详细的统计。不同驱动的字段名称与含义并不完全相同，计数所在层次也可能不同。丢弃既可能与资源压力有关，也可能来自过滤或其他处理条件，需要结合对应字段说明分析，不能看到一个 dropped 数字就断言线路损坏。
累计计数最有用的读法是间隔取样。若 10 s 内发送字节增加 500000000 Byte，则这段时间平均发送速率约为 400 Mbit/s；若发送包数增加 2000000，则平均为 200000 PPS。两次取样应针对同一接口、同一方向和同一时间区间，并留意重启或计数重置。主机计数可能受卸载机制影响，与线路帧数并不总是完全一致，应结合云监控核对。
一次可复核的取样应保留原始输出和时间，而不是只截取异常数字。例如，在同一接口上连续读两次，间隔10秒：
date -Is
ip -s link show dev eth0
sleep 10
date -Is
ip -s link show dev eth0接收方向的示例节选为：
RX: bytes packets errors dropped missed mcast
1000000000 10000000 0 12 0 0
# 十秒后，同一接口
RX: bytes packets errors dropped missed mcast
1100000000 11000000 0 112 0 0这段时间接收了一亿字节、一百万个包，平均约八十兆比特每秒、十万 PPS，并新增一百次丢弃。已有的12次丢弃可能来自过去，只有新增量与当前故障时间对应。字节增量除以包数增量得到约一百字节的平均统计包长，但不能据此断言所有包都一样大。若第二次数字反而变小，应检查接口重建、计数复位或采集对象变化，不能继续套用相减公式。
随后读取 ethtool -i eth0 确认驱动，再读取 ethtool -S eth0 寻找相关队列或配额计数。先保存完整输出，再根据驱动文档解释字段；同样带有 drop 的名字，可能分别指接收缓冲耗尽、平台限流或其他丢弃。部分读取需要权限，若提示不支持，就明确记录缺少这层证据，并转向云监控，不能把没有字段当作没有丢包。主机和云平台若使用不同统计周期，应统一到同一时间段比较增量，避免把一分钟峰值与10秒平均值直接相减。
7 坑：带宽不等于 PPS
只用“占了多少 Gbit/s”描述网络负载，会漏掉包处理压力。假设暂时把每个包的平均计费或统计大小记为 L Byte，忽略额外线路开销，则所需 PPS 约等于每秒比特数除以 8L。在相同比特率下，平均包越小，需要处理的包越多。计算时必须说明 L 取自哪一层，不能把应用载荷大小与完整线路占用混在一起。
例如，同样传输 1 Gbit/s，按每包 1000 Byte 粗算，需要约 125000 PPS；按每包 100 Byte 粗算，则需要约 1250000 PPS。字节速率相同，包处理次数相差 10 倍。真实以太网还存在帧头、最小帧长度、前导码和帧间间隔等开销，因此这只是帮助理解数量关系的估算，不是精确线路容量公式。
如果某实例允许的带宽较高，却只能处理较少的包，那么小包业务可能先触及 PPS 上限。反过来，大包业务可能在 PPS 尚有余量时先耗尽带宽。这里与 H12 中 IOPS 和吞吐的关系相似：每次操作大小决定两类上限如何共同作用。网络包与存储操作并不相同，但同时查看“次数”和“字节量”的分析习惯可以直接迁移。
平均值还可能掩盖短时间突发。1 min 平均带宽很低，不代表每个 1 s 内都没有拥挤；多个发送者在同一时刻到达，可能使队列迅速积累。实际评估应同时记录业务高峰、包长分布、PPS、带宽和丢弃变化。对延迟敏感的业务，还应观察响应时间分位值，判断少数请求是否因为排队明显变慢。
8 案例：小包压垮网络路径
某内部服务原本主要传输较大的数据块，迁移到新实例后带宽监控一直较低。随后业务增加了大量短消息，应用响应时间上升，并出现间歇性超时。运维最初认为网络仍有大量带宽余量，继续增加并发，希望提高利用率，结果请求积压更明显。这个现象说明“链路没有跑满”不能作为网络路径没有瓶颈的充分证据。
团队把同一时间段的请求速率、接口包数、字节数和 CPU 负载放到一起观察。按监控采用的统一统计口径，流量约为 2000000 PPS，平均每包约 100 Byte，对应约 1.6 Gbit/s。实例带宽上限为 10 Gbit/s，但公开规格中的 PPS 上限为 2000000。这个估算表明包处理配额已经值得重点核查，尽管带宽只用了较小一部分。
进一步检查还发现，接收处理相关 CPU 工作增加，部分队列出现丢弃。PPS 到达规格上限与主机处理压力可能同时存在，不能只凭数字接近就认定唯一原因。团队在保持请求内容和包长分布一致的条件下，降低并发并观察恢复情况，再用 PPS 更高的规格进行对照。业务恢复与这些变化一致，才支持把问题定位到包处理能力不足。
解决方案包括选择更适合高 PPS 的实例、减少不必要的短消息，以及在业务允许的范围内合并发送。合并可能降低包数，却也可能增加等待时间，必须同时检查响应目标。提高并发则可能增加排队，应通过测量确定合理范围。最终验收使用相同业务模型，对比持续 PPS、有效业务吞吐、CPU、丢弃和响应时间，避免只展示一个更高的带宽峰值。
9 排查案例：带宽够却丢包
某消息接收服务使用带宽上限十吉比特每秒的云实例，晚高峰接收流量约一点六吉比特每秒，业务却出现超时，接收方报告消息缺失。降低发送速率后恢复，增加并发后恶化。排查先固定发送端、包长分布与测试时段，记录业务发送量、接收量和响应时间，确认缺失发生在哪个方向。带宽余量只说明字节维度尚有空间，不能排除包数配额或接收队列压力。
第一步，在故障发生前后对同一个接收接口采样，下面列出间隔10秒的关键输出：
ip -s link show dev eth0
ethtool -S eth0# ip -s link：第一次
RX: bytes packets errors dropped missed mcast
5000000000 50000000 0 200 0 0
# ip -s link：十秒后
RX: bytes packets errors dropped missed mcast
7000000000 70000000 0 1200 0 0
# ethtool -S：两次输出中同一字段
pps_allowance_exceeded: 300
pps_allowance_exceeded: 18300接口增量对应平均一点六吉比特每秒、二百万 PPS，接收丢弃新增一千。这里假设使用会公开 pps_allowance_exceeded 的云网卡驱动，且已按该平台说明确认它表示超过包速率配额的累计次数；该字段不是所有网卡都有。其增量为一万八千，但不能与接口丢弃的一千简单相加：两者观察位置和覆盖范围不同，也不能由此推出业务恰好丢了一万九千条消息。业务消息、网络包和底层丢弃计数需要各自保留口径。
第二步，在云监控选择同一实例、同一高峰窗口，查看接收带宽、包速率以及平台提供的配额超限指标。示例读数如下，名称是便于说明的标签，实际应使用平台对应指标：
接收带宽（十秒平均）: 1.6 Gbit/s
接收包速率（十秒平均）: 2.0 Mpps
实例公开 PPS 上限: 2.0 Mpps
包速率配额超限计数增量: 18000字节流量较低、包速率贴近规格且超限计数增长，3项证据共同指向包处理配额。接口错误仍为零，并不能否定这种丢弃；它也不支持直接换线。若平台没有超限指标，只有包速率接近上限，还需要控制负载的对照实验，不能据此确诊。与此同时查看 CPU 各核与接收队列统计：若单个核心繁忙、队列缓冲不足计数持续增加，主机接收处理也可能是共同瓶颈，应继续核查驱动和队列配置。
修复先在可控测试中把发送包速率降到规格以内，观察超限增量和业务超时是否同步下降，再选择持续 PPS 更高的实例进行同负载对照。若业务允许合并短消息，可以减少包数，但必须验证合并等待是否损害响应时间。单纯追加 ENI 不能保证增加实例总 PPS，扩大接收缓冲也无法消除平台配额。
验收保持原来的发送量、包长分布和方向，覆盖完整高峰及突发时段。示例中，更换规格后仍承接二百万 PPS，超限计数不再增长，接口丢弃增量归零，业务接收量与发送记录吻合，响应时间恢复目标范围，才支持修复有效。如果只看到低负载下丢弃停止，说明暂时绕开了触发条件，尚不能证明原有容量需求已经满足。
放进方案里
编写网络方案时，先写清通信双方、所在 Region 与 AZ、是否跨子网以及是否经过公网出口。把主机、ENI、虚拟网络和出口资源依次画出，并标注每段由谁管理。路径中凡是存在共享带宽或独立配额的地方，都应单独列出。这样可以把需求对应到具体资源，避免只给出一个无法解释的总带宽数字。
随后描述业务负载，至少给出持续与峰值字节速率、平均包大小、PPS、通信方向和响应时间目标。文件传输更需要关注持续带宽，短消息和大量小请求则必须核对 PPS。若缺少实测数据，应写明估算口径与假设，再安排具有代表性的测量。应用请求数不能直接替代 PPS，应用载荷也不能直接当成完整线路流量。
选择实例与 ENI 配置时，同时核对持续带宽、PPS、网卡数量、地址数量及挂载约束，并说明公网出口是否另有上限。多网卡应服务于地址配置、网络分工或平台支持的特定能力；若目的是提高总吞吐，必须找到明确的规格依据。对于需要持续运行的任务，应以可持续能力为基础，并为业务增长和短时波动保留有依据的余量。
验收应覆盖正常负载、预期峰值和持续运行场景，在相同统计窗口内记录有效吞吐、PPS、CPU、丢弃和响应时间。方案还要写明观察接口、云监控位置及触发扩容的条件。例如，当高峰 PPS 接近预定阈值且响应时间恶化时启动复核，而不是等待带宽跑满。交付结果应让后来者能够读懂选型理由，并重复验证这些判断。
10 小结：走向 Linux 入门（S6）
网卡连接主机内部处理与外部链路，端口提供连接位置，链路速率描述特定连接的容量。以太网帧用 MAC 地址完成当前链路范围内的交付，IP 数据包则可以跨越多个网络；经过路由边界后，承载它的帧会随下一段链路重新构造。交换与路由的区别应从处理的地址和边界理解，而不是仅靠设备名称判断。
云 ENI 提供可管理的网络接口资源，但实际性能还受到实例、出口及平台规则约束。带宽限制字节搬运速度，PPS 限制包处理数量，两者必须结合包长和负载方向一起阅读。使用 ip、ethtool 和云监控时，应分清设备状态、累计计数、统计窗口与规格口径，再把观察结果对应到真实业务路径。
面对一份网络规格，可以依次回答：连接到哪里，经过哪些边界，每秒搬运多少字节，处理多少个包，哪些资源共享上限，以及如何验证。能够回答这些问题，就具备了把网卡与网络基础放进系统方案的能力。后续网络课程将在这条路径之上继续解释传输机制与更复杂的网络行为。本课建立的是读规格与对路径的习惯，而不是背诵某一厂商的参数表。
下一课转向 S6 Linux 入门。
把本课的网卡路径、带宽/PPS 与计数口径带走：下一课在 Linux 里用 ip/ethtool/ss 把这些接口变成可操作的命令与日志，并检查「规格写得对」是否等于「主机上能核对到相同计数」。
作业：保留本课 1 条业务路径的带宽与 PPS 估算，作为 S6 对照实机计数的输入。