网卡、DMA、中断、协议栈、套接字、应用与对端共同构成网络路径；线速、单连接吞吐与业务成功率属于不同指标。
接收路径先进入设备，再交给应用
网卡接收流量并使用准备好的缓冲区，驱动处理相应完成状态，协议栈把内容交给匹配的套接字，应用获得调度机会后消费数据。不同驱动和加速模式存在差异，图仅描述常见内核网络路径。
线缆 -> NIC接收队列 -> DMA缓冲区 -> 驱动/NAPI
|
网络协议处理
|
套接字接收缓冲
|
应用读取
Linux NAPI 文档 描述网络处理中的轮询相关机制。中断提示与后续批处理不同，因此一个包并不必然对应一次独立中断。
描述符、数据缓冲区与协议对象的交接
接收之前，驱动需要让设备有可用的接收资源；收到数据之后，软件需要得到相应长度与状态，再把数据接入网络处理。描述符表达任务或缓冲区关系，缓冲区保存载荷，协议对象保存软件处理所需元数据，三者不能混为一个“包”。Linux 的 sk_buff 文档 说明这种软件对象与数据存储的区分。
原创推演：接收流量仍在到达，但应用消费速度下降。资源可能先积累在套接字或上游队列，最终影响后续工作；同时，某些接收资源不足可能在更早阶段表现为丢弃。仅看到“应用读得慢”不能确认丢弃发生在哪里，需要把接口、队列、协议与应用证据对应起来。
接收侧最后必须释放或重新提供资源，否则后续流量没有可用空间。发送侧同样需要确认设备何时不再使用载荷。释放时间是协议问题，不是“函数返回后随便复用”的普遍规则。
多队列处理的分工
硬件与软件可以把接收或发送工作分配到不同队列与 CPU。Linux 的 网络扩展文档 区分这些机制。它们不是四个同义的“加速开关”，也不能无条件同时打开就更好。
原创场景：多流吞吐高，单流吞吐低。单流可能受到某段串行处理或单队列路径约束，但还需排除窗口、丢包、对端、应用和调度因素。多队列数量多，不能证明一个连接会使用所有 CPU。
发送路径与缓冲区寿命
应用产生响应，协议栈组织发送，驱动和网卡执行任务。应用发送调用返回、主机缓冲区可复用、TCP 获得确认以及对端业务处理完成，发生在不同层。
应用生成字节 -> 套接字/协议栈 -> 驱动发送队列 -> NIC -> 网络
|
传输确认/业务确认（不同层）
“远端收到”的说法必须注明是哪层：远端网络栈、对端程序还是数据库提交。跨层结论不能由一个本地成功返回值证明。
背压沿路径传播
接收应用消费慢时，缓冲区和协议状态可能限制继续接收；发送对端或链路能力不足时，本地队列可能积累。业务超时因此既可能来自主机，也可能来自路径或对端。
把窗口限制、重传、丢弃、队列和业务处理时延放到共同时间轴上，才能缩小假设范围。任意单个计数都不能独自说明故障根因。
卸载改变观察位置
部分工作可由网卡或软件聚合机制处理，导致不同观察点看到不同粒度。主机抓包呈现的包形态不一定等于线缆上的帧形态；抓包丢包也可能是观察工具跟不上，而不是业务链路丢包。
原始流量中可能包含令牌、地址与用户内容。企业采集必须限定对象、时长和保留范围，不能将实际业务流量公开放入博客。
如何比较网络测试
吞吐结果需要说明方向、协议、流数、时长、双方 CPU 状态、MTU 与网络路径。工具测的是构造出来的工作，不是整个应用质量。有关 iperf3 参数的定义以 官方手册 为准，受控过程见 网络测试。
网络与硬件的交叉点
DMA 缓冲区、NUMA 位置和完成处理 CPU 使网络与内存系统紧密关联。某核心忙而网卡未达到预期吞吐，既可能是主机处理限制，也可能是其他路径因素。完整解释需要连接设备、协议栈、调度和应用四类证据。
服务器知识库 · 系统架构 · 数据路径 · 测试验收 · 工程参考
公开资料核对：2026-10-07。文档类型：Explanation。逻辑图、场景推演与报告模板为原创，不代表实测结果、厂商内部设计或公司制度；操作仅限获授权的目标和环境。