RFC 3135：代理的 ACK 不等于应用已经收到

摘要

RFC 3135 调查了卫星、无线广域网和无线局域网中的性能增强代理：它们可以调整或过滤 ACK、本地确认与重传、拆分连接、压缩流量，也可以把链路中断暂时藏在端点之外。
代理发出的 ACK 最多证明代理接手了这些字节，不证明远端 TCP 已收到，更不证明应用已接受或完成处理。缩短反馈回路的同时，系统也改变了责任由谁承担。

ACK 回来了，数据还停在半路

地球同步卫星的传播时间无法靠算法消除。发送端若必须等到远端 ACK 完整往返，拥塞窗口就会受制于一条很长的反馈回路，即使链路本身还能承载更多数据，也可能无法被填满。

性能增强代理提供了一条捷径。它在困难链路之前接收 TCP 段，提前向发送端确认。发送端据此继续发送，看到的往返时间缩短，吞吐量可能上升。无线损失也可以由靠近无线侧的设备重传，不必让远端发送端把局部错误当成全路径拥塞。

然而，确认信号缩短了，事实距离没有缩短。那些字节可能仍在代理内存中，尚未经过卫星或无线链路，尚未到达另一侧代理、远端 TCP，更没有进入应用。如果本地 ACK 之后发生丢失，原始发送端已经把这部分数据视为被对端接收。恢复工作只能由中间代理接管。

RFC 3135 在 2001 年 6 月以 Informational RFC 发布，主题正是这种 Performance Enhancing Proxy，简称 PEP。它不是一项要求部署的标准，也没有宣布某种产品优胜。它调查不同代理如何缓解高时延、带宽不对称、误码、低带宽或间歇断连，并把这些改善带来的后果逐层列出来。

这份文档最重要的历史贡献，不是证明“代理能加速 TCP”，而是指出：一条更早返回的 ACK，可能只是换了证人。

PEP 不是一种固定设备

RFC 3135 没有把所有中间优化揉成一个架构。传输层 PEP 可以观察 TCP，只改变传输行为而让应用协议保持端到端。应用层 PEP 会理解乃至转换应用协议，也可能同时终止 TCP。集成式 PEP 是一个节点；分布式 PEP 则把两个或更多组件放在目标链路两端。

分布式设计常常按方向分工。卫星下行容量可能很大，上行 ACK 通道却很窄。一侧代理可以本地确认，让数据方向尽量填满；另一侧可以过滤冗余 ACK，节省返回方向的容量。同一条业务流因此被两个物理条件不同的控制面包围。

拆分连接走得更远。发送端建立的 TCP 连接在代理处终止，代理再向真正目的端建立另一条 TCP。两个代理之间还可能使用第三种为链路定制的连接，甚至是运行在 UDP 上的专有协议；多个用户连接也可能被复用到同一个中间通道。

但并非所有 PEP 都替换确认的作者。ACK spacing 只是重新安排既有 ACK 的时间；ACK filtering 删除冗余返回流量；Snoop 一类链路层机制缓存无线侧段并在局部重传；压缩减少需要传输的字节。这些机制对端到端语义的影响并不相同。

因此，RFC 3135 特别区分“透明”与“保持端到端语义”。代理可以对主机不可见，却悄悄终止连接；也可以被用户明确选择，同时让应用确认继续真正端到端。透明只说明谁知道代理存在，不能说明 ACK 属于谁，也不能说明关键状态存在哪里。

提前确认意味着提前接管责任

即使没有 PEP，TCP ACK 的证明力也有限。它表示对端系统的 TCP 实现收到了数据，并不保证上层应用已经读取、校验、持久化或执行。需要可靠完成语义的应用，必须建立适合自身事务的端到端检查或确认。

本地 ACK 又在这条证据链之前插入一层。RFC 3135 明确指出：代理一旦在本地确认，确认之后若有数据丢失，恢复负担就落到 PEP 身上。代理需要保留字节、序列状态、定时器和下游 ACK 视图，并决定何时局部重传。

这种责任转移可以带来真实收益。无线链路丢一个段，不必等待远端完整 RTT 后再修复。链路断开时，代理可以停止继续接收，用零窗口或普通流控冻结发送端，保存未确认数据，等链路恢复后继续。拆分连接还可以为交互流设置高优先级，让后台传输长期暂停，而不让原始发送端因全路径沉默不断超时。

可一旦代理承担保管责任，系统就需要保管证据。缓存是易失内存还是持久介质？代理重启会发生什么？它是否在发出 ACK 之前真正存好了全部字节？缓冲区压力如何处理？恢复完成由哪个远端事件证明？

本地 ACK 并不虚假。它可以准确表示“代理收到了”。错误发生在监控、运营或合同把它升级成“远端已经收到”。

同一批字节至少有五张收据

若要还原责任，应把一次传输拆成独立事件。

第一，发送应用把字节交给本地 TCP。第二，中间 PEP 接收、缓存并可能发出本地 ACK。第三，字节跨过受损子路径。第四，远端 TCP 实现发出自己的确认。第五，远端应用根据协议语义确认：消息已解析、任务已入队、记录已持久化、事务已提交，或工作已经完成。

这些收据不能互相补写。进入代理缓存不等于离开缓存；远端 TCP ACK 不等于应用完成；应用 ACK 也没有统一含义，它可能只表示排队，而不是持久化。

RFC 3135 用邮件中继说明一种公开的责任转交。中继 MTA 可以把邮件写入非易失存储，在应用层确认，然后承担之后多次尝试投递的责任。它不是百分之百保证最终投达，却公开了谁接管、保存在哪里、失败后由谁重试。

传输层 PEP 通常不会伪造应用 ACK，应用协议仍可端到端运行。这一点限制了风险，也必须如实保留。但它不意味着发送端最先看到的 TCP ACK 就具有应用层收据的权威。那只是更近的一张收据。

优化器成为连接命运的一部分

端到端设计中的 fate sharing 有一个朴素目标：关键连接状态保存在端点。路径中的路由器故障时，只要还有替代路线，端点可以保留状态并继续通信。

当代理持有已被确认的数据与拆分连接状态，它就不再是一台可以任意绕过的普通路由器。代理崩溃可能让连接终止，即便 IP 层仍有另一条可用路径。丢失的不是连通性，而是代理独占的记忆。

RFC 3135 没有把这种风险判定为永远不可接受。PEP 常部署在没有现实备份路径的最后一跳或私有网络。无线链路若持续中断，本来就可能使连接失效。用户可能愿意用额外故障点换取多数时间更好的体验。

关键是知情与选择。用户或负责任的管理员应知道代理如何工作、故障意味着什么，并在可能时保留不用 PEP、坚持端到端 IP 的选项。

如果 PEP 由接入网络透明强制，这种选择很容易消失。运营者获得总吞吐量提升，厂商控制缓存与恢复逻辑，应用承担遗漏的结果，而用户甚至不知道 ACK 来自中间。性能改善与责任承担可能落在不同主体身上。

加密让代理失去视力

许多 PEP 功能依赖可见性。识别 ACK 需要读取 TCP 头；本地重传需要理解序列与窗口；拆分连接需要终止传输状态；应用压缩和变换还要看到负载。

端到端 IPsec ESP 会把 TCP 头和内容对中间节点隐藏。RFC 3135 因而指出，许多代理在这种情况下不能正常工作，甚至完全无法工作。即使某种机制不破坏语义，例如 ACK spacing，它也必须先识别哪些包是相关 ACK。

一种替代方案是让安全关联在代理处终止，再从代理建立另一段保护。这可以保护每一段链路，却不是端到端安全。数据为了处理会在代理中暴露，端点必须信任它。两段还可能采用不同保护等级，让一端误以为整个路径都具有自己协商的强度。

在两台 PEP 之间建立 IPsec、让部分流量绕过代理、或在应用层加密，都可以缓解部分问题。但这些安排只是重新划定信任边界，并没有抹去代理内部的明文处理或配置复杂度。

后来的 RFC 显示这并非短暂争论。RFC 3449 说明多种不对称路径优化依赖未加密的 IP/TCP 头与流识别。RFC 8404、RFC 8517 记录传输加密与网络功能之间的长期张力。RFC 8684 在多路径 TCP 的重传规则中仍要考虑 PEP 主动确认数据的情况。这些后续资料不是 2001 年部署统计，只证明当年的边界持续影响协议设计。

隐藏链路故障，也可能隐藏诊断线索

短暂无线断连不一定应立即杀死应用。代理可以保存状态、冻结发送端、等链路回来后恢复。对移动用户而言，这可能正是服务可用性的来源。

但同一机制也会推迟端点发现长时间故障。发送端仍处于看似合理的传输状态，下游却已经无法前进。有备用通信路径的应用可能因为代理持续掩盖中断而延迟切换。

Ping 与 traceroute 未必能解释这种差异。ICMP 可能绕开 PEP；也可能穿过同一设备，却不接受 TCP 的拆分和缓存处理；代理甚至可能代表远端回应。绿色 ping 也许只证明到代理可达。traceroute 可以列出路由节点，却看不见连接在哪里终止、多少字节卡在缓存里。

非对称路由会让分布式 PEP 的某个方向绕开另一组件。移动主机切换接入点时，代理状态可能需要迅速迁移，迁移不及就会断开连接。扩展性又引入新的上限：查看高层字段、保存每流状态比普通 IP 转发消耗更多 CPU 与内存；多台代理并行后，还需要额外系统保证同一流命中正确状态。

为了让差链路在用户眼中“消失”，网络增加了一处可能从监控中消失的复杂状态机。

这是一份调查，不是普遍裁决

RFC 3135 的文档地位决定了它能证明什么。它是 Informational survey，不是一项 Internet Standard，也不是部署指南、产品评测或采用率调查。VSAT、无线 WAN、WAP、Snoop 等例子说明设计动机和机制，不证明每一种实现都正确，也不证明所有 PEP 都产生同样结果。

作者仍把端到端原则作为主导方法，认为只有在特定环境、端到端方案无法提供相同改进时才应考虑 PEP；设计新链路技术时，应尽量让这类代理不再必要。同时，他们也承认物理时延与昂贵链路不能靠原则口号消失。

RFC 3234 后来把 PEP 放进更广的 middlebox 分类。RFC 3426 则把 RFC 3135 当作架构权衡案例：一边是性能收益，另一边是端到端 IP 安全受限、新故障点、诊断困难、非对称路由与移动性复杂度。完整决策必须同时记录两边。

为性能测量补上保管链

可信测试首先要写清原问题：链路方向、拓扑、原生 RTT、误码、断连、带宽不对称、工作负载和应用成功标准。随后记录 PEP 的版本、所有者、位置、机制、集成或分布模式、是否拆分连接、是否透明，以及用户能否绕过。

每次关键操作都应分开记录发送时间、本地 ACK、代理接收字节、缓存是否持久、下游发送、本地重传、远端 TCP ACK、应用 ACK 与最终持久完成。还要记录由谁重传、哪一个计时器触发、窗口如何改变、重启是否丢状态、两方向实际路径和切换结果。

安全记录需要列出加密端点、每段可见的头与负载、代理内部是否出现明文、绕过规则与不同安全段的保护差异。结果评估应同时比较吞吐量、表观 RTT、端到端时延、应用完成时间和最终正确性。

应触发复核的不是某个单独低值，而是证据冲突：本地 ACK 早于可靠保管；代理重启丢失已确认数据；ping 正常而 TCP 停滞；加密悄悄关闭优化；返回路径绕开代理状态；移动切换丢状态；传输吞吐量提高而应用完成率下降。

RFC 3135 试图缩短的是控制回路，不是事实本身。代理可以诚实地说“这些字节到我这里了”。在远端应用给出自己的证据之前，它没有权力替远端说“已经收到”。

代理已经确认字节，应用却还没有收到：RFC 3135

为何重要

摘要

ACK 回来了，数据还停在半路

PEP 不是一种固定设备

提前确认意味着提前接管责任

同一批字节至少有五张收据

优化器成为连接命运的一部分

加密让代理失去视力

隐藏链路故障，也可能隐藏诊断线索

这是一份调查，不是普遍裁决

为性能测量补上保管链

Sources

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报