1. 新技术宣称
单端口带宽迈向 1.6Tbps 时，一个被搁置多年的问题回到了网络研究的中心：端点还消化得了吗？
算一笔物理账（Presto 论文的口径）：8K MTU（最大传输单元）下饱和 1.6Tbps 需要 25Mpps 的处理速率；维持 1500B MTU 则要翻数倍。而内核 TCP 栈的每包处理成本是固定的。Presto 引用的测量显示，即使最先进的 kernel-bypass 栈，应用程序仍把每包 CPU 周期的 48% 花在协议栈里（FlexTOE 数据）。阿里的生产数据更直接：内核 TCP 的 socket 操作吃掉应用 50%-90% 的 CPU 时间（SMC-R 论文）。带宽每翻一代，这份"协议栈 CPU 税"就翻一倍。
SIGCOMM 2026 对这个问题的回应是一个完整的路线图：七篇论文分布在四条不同的路线上：可编程化（Presto 把 TCP 状态机搬进交换机流水线）、绕过内核（SMC-R 的四年生产教训）、压缩（Flow.ZIP 的包头瘦身）、换语义（PacketExpress 的大 MTU 与 Capybara 的微秒级连接迁移），外加一张测量底图（Host Stack Latency）和 Google 在信号层的渐进补丁（CSIG）。把这个阵容与 RS15（Programmable Switches，Presto 所在 session）合起来看，端侧协议栈是本届"被 AI 负载重新提问"的经典方向里回应最系统的一个（四条路线+测量底图+信号层的完整覆盖度）。
2. 逐篇深读：四条路线与一张底图
2.1 Presto：把 TCP 状态机搬进交换机流水线
Presto（华盛顿大学 + MPI-SWS，Best Student Paper）要解的矛盾长期被判为不可解：TCP 的状态更新复杂且相互依赖——重组需要先读后写同一份状态，而 RMT（可重构 match-action 架构）交换机流水线是单向、逐级 lock-step、无回写的。状态机进流水线，等于让单向、无回写的硬件去执行相互依赖的状态更新。所以此前的共识一直是：RMT 只适合无状态或轻状态转发，有状态传输协议放不进去。
Presto 用三个机制把"回头路"拆掉了：乐观并发——先推测性更新，下游阶段验证，错了再补偿；伪段注入——用注入的哑包解决循环写依赖，全程不停摆；bump-in-the-wire——单遍处理，不重循环。整个 TCP 栈（重传、重组、流控、拥塞控制）落在 Tofino 2 的流水线上。
数字（Tofino 2 测试床）：25Mpps/core、8K MTU 饱和 1.6Tbps；规模测试近 1Bpps，99.99p 尾延迟 ~20μs；比 kernel-bypass 的 TAS 少用 16 个 CPU 核，仍超过其峰值吞吐；KV store 吞吐每瓦 2×；FPGA 移植版在同时序约束下包率 3× 于 Tonic。
这篇的意义在能力边界而不在数字：RMT 的可编程性边界被大幅外推——有状态传输协议也能进流水线。此前"RMT 只做转发"是设计原则，现在是历史结论。可落地性属长期档：等 Tofino 后继或国产 RMT 芯片的量产存量。
2.2 SMC-R：透明替换的四年生产教训
SMC-R 是透明 TCP 替换（RDMA 加速共享内存通信）在阿里云的四年生产实践：生产默认配置下 point_select 吞吐 1.52×、read_write 1.28× 于 TCP。但这篇论文的价值在教训而非数字。
四年里 SMC-R 最大的工程成本不在协议栈，在与每一个应用配置组合的缠斗。论文的结论是：应用与系统配置（而非协议栈优化本身）主导或放大性能问题——线程数、缓冲策略、fallback 触发的配置组合在跨组件协同层面失效，而"常规测试套件验证孤立规格合规，验证不了跨组件协同行为"。论文设想 LLM 辅助的兼容性测试作为出路。
这为"透明替换"路线画出了真实边界：协议可以透明，生态不能透明。任何 RDMA 替换项目开工前，都应该把这篇当配置审计清单来读。
2.3 Flow.ZIP：给 1.6T 时代的包头开销重新记账
包头开销是分组网络最古老的低效：隧道叠加（VXLAN/NVGRE）后聚合开销可超 100B/包。这笔账在小端口时代可以忽略，在 1.6T 端口上每包都在交税。Flow.ZIP（宾大 + MSR + 米兰理工 + UCL + Broadcom）做逐跳无关的头压缩，把"每包开销的边际影响"重新量化进 1.6T 时代的账本。署名阵容值得记：UPenn 出品、Vincent Liu 在列，Broadcom 的 Ben Basat 参与，头压缩是交换芯片厂的直接利益线。
（Flow.ZIP 的具体压缩率与 FCT 改善数字在已读部分未提取到头条值，正文以定性引用为主，终稿前补核原文 §6。）
2.4 PacketExpress：MTU 语义在域边界重写
私网和企业网里一个被默认的参数：1500B 的 MTU。它决定了每 9000 字节的数据要交六次逐包处理的税。首尔国立大学牵头的 PacketExpress（PXGW 网关，SNU + KAIST + UT Austin）在域边界把私网内 90% 以上的 1500B 包聚合为 9000B jumbo 帧转发，出域再拆回。
效果：未修改的 middlebox 性能 4.3-5.1×，端主机 2.5×，包处理次数至多降为 1/6（9000/1500）。聪明之处在部署路径：middlebox 不用动、端主机不用动，改造收敛在一个网关设备上——这是"换语义"路线里工程侵入性最小的做法。
2.5 Capybara：微秒级的 TCP 连接迁移
L4 负载均衡器的经典困境：已建立的连接无法重均衡，因为 TCP 状态绑定四元组。连接不平衡就只能在原地扛到断。此前业界共识是 TCP 连接迁移必然引入可感知中断。
NUS 牵头的 Capybara（+ ETH + Red Hat/Harvard + UPenn + MSR）把共识改写了：快速 L4 LB + 主机-交换机协同迁移协议 + 应用状态迁移接口，三层架构实现不中断的连接搬家。数字：尾延迟最高降 149×，8 核支撑 1.47Tbps（真实负载三应用，含 TLS）。对超大规模 LB 厂商，这是中期可复刻的架构。
2.6 Host Stack Latency：四条路线共用的验尸报告
在四条出路之外，这篇（UVA + SKKU + Cornell）回答了那个被搁置的基本问题："为什么 Linux 网络栈有毫秒级尾延迟？"对尾延迟来源做系统分解，是一张所有路线都引用的测量底图。它与 Presto 构成证据链：Presto 引用的 48% 协议栈 CPU 占比来自 kernel-bypass 栈的测量（FlexTOE），而这篇把内核栈的病灶拆开。四条出路都在治症，这篇在验尸——先知道病在哪，才好选疗法。
2.7 CSIG：Google 的渐进答案
Cardwell（BBR 作者）、Dukkipati、Karp、Vahdat 全明星阵容的 CSIG 走的是与 Presto 相反的渐进路线：不改栈、不卸载，只在定长以太网头里携带多比特的瓶颈拥塞信号（μs 粒度的交换机可用带宽）。精度介于 ECN/RTT（粗）与 P4-INT（需全网硬件）之间——零硬件依赖的高精度。生产收益：未认领带宽 -60%。
3. 路线分析：四条路线的经济学
把四条路线放进"改动成本 × 收益半径"的矩阵：
（SMC-R 未放进矩阵：它的改动成本四年起伏：协议替换是补丁级，但生态配置缠斗是年份级，位置取决于把"改动"定义在哪一层。）
三个结构性观察：
观察一：Google 与学术界在同一个问题上选择了相反的答案。 Presto 代表"彻底解决"（CPU 税归零），CSIG 代表"持续止血"（信号更准）。Google 拥有全网硬件与协议演进权（BBR 的部署史），却仍选渐进路线，因为生产系统的协议栈替换成本（SMC-R 的四年教训恰好是证据）远高于算法收益。这个分歧本身就是预测：未来五年数据中心主力流量会继续跑在"内核/旁路栈 + 更好的信号"上，全卸载是 DPU/交换机厂商的增量故事而不是存量替换。
观察二：CPU 税的量变正在引起质变。 48%（FlexTOE 引）与 50-90%（SMC-R 生产）这两个数字意味着：在 1.6T 端口上，协议栈 CPU 成本已与网络带宽成本同量级。MaaS 推理服务的单位成本模型里，"每 Gbps 的 CPU 开销"会成为一个独立计价项。我们在 MaaS 系列里写的"一张 H100 卖给 1000 人"的账本需要加一行。
观察三：四条路线不互斥，且正在分层组合。 PacketExpress（域边界 MTU）+ Flow.ZIP（逐跳头压缩）+ CSIG（信号）可以叠加；Presto 与 SMC-R 是替代关系但目标负载不同（超低延迟 RPC vs 通用云负载）。终局形态大概率是：域内大包 + 压缩头 + 精确信号 + 关键路径的专用栈（Presto 类硬件卸载或 kernel-bypass）。
4. 证据核对
| 主张 | 数字 | 出处 |
|---|---|---|
| 8K MTU 饱和 1.6Tbps 需 25Mpps | Presto §1 | Presto 摘要+§1 |
| kernel-bypass 栈每包 CPU 48% 在协议栈 | 引 FlexTOE [91] | Presto §1 |
| 内核 TCP socket 操作吃 50%-90% CPU | 阿里云生产 | SMC-R §1 |
| SMC-R 1.52×/1.28× | point_select 32 线程 / read_write 16 线程，生产默认配置 | SMC-R §5 |
| PacketExpress 90%+ 1500B→9000B；middlebox 4.3-5.1×；主机 2.5× | PXGW 网关 | PacketExpress 摘要+§5 |
| Capybara 尾延迟 -149×；8 核 1.47Tbps | 真实负载三应用（含 TLS） | Capybara 摘要 |
| CSIG 未认领带宽 -60% | 生产部署口径 | CSIG 摘要 |
| 头开销可超 100B（VXLAN/NVGRE 叠加） | 表 1 聚合 | Flow.ZIP §1 |
| Presto 25Mpps/core、1Bpps、-16 核、2× 每瓦、20μs 99.99p | Tofino 2 测试床 | Presto 摘要+§5（卡04） |
口径说明：Flow.ZIP 的具体压缩率/FCT 改善数字在已读部分未提取到头条值，正文以定性引用为主，终稿前补核原文 §6。Presto 的所有数字已在卡04 完成原文锚定。
5. 技术评估与预测
一、"协议栈 CPU 税"会成为 2027-2028 年的显性成本科目。 七篇论文从四个方向围攻同一笔税，说明生产界已经痛了。云厂商的下一步可预测：把协议栈开销写进实例规格（vCPU 与网络带宽的联动计价），以及 DPU 卸载从"高级功能"变成"默认配置"。Azure 已经在这条路上（ROE 论文是证据），AWS/Meta 跟进。
二、TCP 不会死，但会分层。 Presto 证明 TCP 语义可以搬进硬件流水线，这反而延长了 TCP 的寿命（比换协议便宜）。Capybara 的连接迁移与 SMC-R 的透明替换共同指向一个中间态：TCP 的外部语义保留、内部实现多元化（内核/旁路/交换机/DPU 各占一段）。QUIC 在数据中心内部的机会窗口被这个中间态进一步压缩。
三、CSIG 是 BBR 团队的下一步棋，值得单独跟踪。 从 BBRv1（2016）到 CSIG（2026），Google 的拥塞控制十年走的是"端点可部署性优先"路线。CSIG 把信号精度提升到多比特/μs 粒度且零硬件要求。如果进入 Linux 内核主线（BBR 的老路），五年内部署量可能超过绝大多数 SIGCOMM 拥塞控制论文。学术影响小、产业影响大，这类论文的价值常被顶会低估。
四、可落地性四档。 立即可用：CSIG 思路（内核/驱动补丁级）、Flow.ZIP 类头压缩（网卡固件级）；中期：PacketExpress 的域内大包（网络运维改造）、SMC-R 教训（任何 RDMA 替换项目的配置审计清单）；长期：Presto 全卸载（等 Tofino 后继/国产 RMT 芯片的量产存量）；Capybara 的连接迁移对超大规模 LB 厂商是中期可复刻的架构。
五、与 locsic 前文对账。 broadcom-th6（5/21）判断"51.2T→102.4T 时代内核栈必然出局"。本届四条路线是对"出局之后去哪"的完整回答；maas-inference-tech-stack（6/13）的成本账本需要加上协议栈 CPU 税一行（观察二）。Presto 获 Best Student Paper 与 λλ 获 Best Paper 合读：两个奖项共同指向"抽象层与实现层的重新分工"是本届 SIGCOMM 的元主题：光域分工给类型系统，传输域分工给 match-action 流水线。
声明： 本文基于 Presto 全文深读 + Host Stack Latency/Flow.ZIP/PacketExpress/Capybara/SMC-R/CSIG 六篇全文或摘要（组卡 18）。Flow.ZIP 的压缩率与 FCT 头条数字未在已读部分检出，正文以定性引用为主；SMC-R 的 50-90% 与 1.52×/1.28× 均为阿里云生产口径。文中数据截至 2026 年 8 月 22 日。
本篇为 SIGCOMM 2026 深读系列第五篇（终篇）。系列全六篇：总览（篇0）、KV Cache 网络公民（篇1）、Collectives 运行时（篇2）、Scale-Up 主战场（篇3）、光子软件栈（篇4）、Terabit 协议栈（篇5）。