摘要

  • RFC 3155 把“观察到损失”与“知道损失原因”分开。序列空洞、重复 ACK 和超时可以触发保守的拥塞响应，却不能单独证明拥塞、传输误码、乱序或反向路径丢失。
  • Fast Retransmit/Fast Recovery、SACK、D-SACK 与 NewReno 改善的是发现空洞后的修复过程。它们描述哪些字节到达、哪些需要重传，并不为缺失字节标注物理原因。
  • 完整证据必须连接链路误码、队列与 ECN、两个方向的报文、窗口变化、重传、接收端重组和应用结果。字节流恢复不等于业务按时恢复。

TCP 收到的是线索，不是现场结论

发送端能够记住已经发出的序列范围，也能看到接收端确认到哪里。当确认边界停止前进时，它知道有一个缺口妨碍了有序交付。至于缺口由谁造成，端到端反馈往往没有答案。

拥塞控制长期把丢包当作拥塞信号。这不是因为每个消失的数据包都必然遇到满队列，而是因为在缺乏显式反馈的互联网里，对拥塞作出减速反应可以保护所有共享路径的流量。这个近似在低误码网络里十分有效。

接入网络越来越多样以后，未被链路层纠正的传输错误开始进入 TCP 的视野。地面无线、卫星等链路可能损坏帧；链路层重传可能让包延迟或乱序；路由变化也会改变到达顺序；ACK 可能在返程丢失；当然，路由器队列同样可能溢出。

这些事件在发送端留下相互重叠的痕迹。RFC 3155 明确承认，当时研究过的端到端启发式方法无法可靠区分拥塞丢包与传输误码。协议必须先决定怎么做，证据却还没有说明为什么。

保守判断会浪费容量，反向误判可能伤害全网

如果真实原因只是链路误码，把它当作拥塞会降低利用率。发送端缩小拥塞窗口，再一点点试探增加，即使路径上的队列其实很空。误码持续发生时，连接可能长期用不满可用带宽。

但若把真正的拥塞误认为无害误码，代价会由其他流量一起承担。发送端拒绝减速，会进一步填满队列、制造更多丢包，甚至推动局部网络走向拥塞崩溃。因此，在没有可信原因反馈时，RFC 3155 仍让拥塞安全优先于最快修复。

这是一条控制原则，不是物理事实声明。“按拥塞处理”不等于“已经证明拥塞”。前者描述发送端的责任，后者需要队列、路径和时间证据。

回看历史时也应保持这条界线。一次 cwnd 减半只能证明算法执行了相应分支。附近的链路错误计数可以增强误码假设，却仍要对齐方向、流、序列号和时钟。单一计数器不能代表整条路径。

Reno 公式筛选问题，却不替任何数据包作证

RFC 3155 引用了一个近似的 TCP Reno 响应函数，用分段大小、端到端 RTT、重传超时和稳态丢包率估计发送速率。它帮助运营者判断：在当前丢包水平下，TCP 的反应是否已经把吞吐压到链路容量以下。

输入条件本身就是约束。RTT 是端到端往返时延，不是可疑链路的局部时延。文档允许用 Max(1.0, 4*RTT) 简化估算 RTO，但那仍然只是代入。长时间平均丢包率还可能掩盖短暂突发；同一窗口连续丢失多个分段，通常比稀疏独立丢失更难恢复。

若模型给出的速率高于物理链路速率，改进恢复也不能让链路超过自身上限。若预测值低于链路容量，并且进一步调查确认存在显著传输误码，端点机制才可能释放一部分闲置能力。

公式不告诉人哪个比特坏了、哪个队列满了，也不保证实际速率。它划出需要调查的区域，真正结论仍取决于测量、假设和运行中的实现。

三个重复 ACK 买到的是时间，不是因果标签

接收端若越过缺口收到后续分段，会立即重复报告仍在等待的下一个序列号。发送端收到三个重复 ACK 后，可以通过 Fast Retransmit 不等完整 RTO 就重传推定丢失的分段。

Fast Recovery 随后把拥塞窗口减半，并从拥塞避免继续恢复；超时则会把连接带回更严厉的 Slow Start。重复 ACK 说明后续包仍能通过，因此允许较轻的控制动作。

它们仍未解释空洞。IP 本来就允许乱序；链路层晚到的重传、路径切换和 ACK 路径异常都可能制造同样的模式。三个只是触发门槛，不是部署在队列旁边的传感器。

如果窗口尚未通过加性增长恢复，又发生一次丢包，新的减半会作用在已经缩小的值上。RFC 3155 把这种连续下压称为“向下螺旋”。高误码链路上，窗口可能很长时间保持低位。

窗口小于四个分段时，发送端甚至可能没有足够的后续数据去换来三个重复 ACK。但小窗口也未必来自误码：HTTP/1.0 常在对象结束时关闭连接，让下一个短连接从 Slow Start 重新训练。应用连接策略会在窗口图上制造类似症状。

SACK 画出收到的区间，却不认识缺口的制造者

累计 ACK 只给出连续收到的最远边界。如果一个窗口内有多个缺口，接收端已经缓存的后续数据无法被充分表达。SACK 可以报告这些区间，让发送端一次识别多个待补位置，而不是每修好一个才经过一个 RTT 发现下一个。

RFC 3155 还推荐 RFC 2883 的 D-SACK 扩展。重复数据的信息有助于理解乱序、ACK 丢失、报文复制或过早重传。在长 RTT、大窗口和突发误码组合下，更丰富的回执能够减少等待和无用重传。

但 SACK 记分板仍是到达记录。它能证明前后两段已经在接收端，也能证明中间尚未补齐；它不会说明中间那段是被噪声破坏，还是被队列删除。

当双方无法启用 SACK 时，NewReno 利用部分 ACK 改善同一窗口多个丢失的恢复。Limited Transmit 则试图让小窗口再发送少量数据，从而产生足够的重复 ACK。RFC 3155 把后者列为应评估的标准化机制，并未把它写成普遍成功证明。

这些机制缩短修复路径，却不取消拥塞控制。恢复更聪明，不代表诊断更确定。

小 MTU 会影响窗口训练，却不会自动修好链路

误码较高的链路常使用较小 MTU。由于 TCP 按分段增加窗口，小分段会让窗口按字节计算时增长得更慢。但仅仅缩小 MTU 不会减少未纠正错误。

Path MTU Discovery 可以避免分片，并让端点采用路径允许的最大报文。它有助于避免不必要的小分段，不过窗口达到时延带宽积仍可能需要多个 RTT。

这里必须与 RFC 3150 分开。RFC 3150 的中心问题是：一个大包在低速共享链路上占用多久，会让其他流量等多久。RFC 3155 的中心问题是：残余错误造成的损失如何被 TCP 解读和修复。前者是轮到谁以及占用时间，后者是反馈含义和恢复成本。

报文大小同时改变串行化、头部比例、每窗口分段数、分片与误码暴露。把两个 RFC 合并成“小包总是更好”会抹掉各自的条件。

端到端方案保住加密，也接受局部不可见

RFC 3155 选择不要求中间节点理解 TCP 的机制。这样做保留了端到端命运共享，并能穿过端到端 IPsec。代价是端点对路径内部的本地事件没有完整视野。

Performance Enhancing Proxy 可以部署在网络特性突变的边界，利用局部知识。它同时可能引入第三个故障点、移动时的状态转移、对双向对称路径的依赖、扩展性与诊断问题，以及与 IPsec 的冲突。不是每类 PEP 都具备全部缺点，但每一项都需要明确核对。

RFC 3135 的既有文章已经拥有代理状态与命运共享的完整论点。RFC 3155 在这里仅用于说明取舍：中间设备若要增加局部认知，就必须取得连接状态和执行权；端点方案保留兼容性，也保留认知边界。

ECN 命名的是拥塞，不能用沉默命名误码

ECN 让路由器在丢包以前显式标记拥塞。路径和两端都支持时，发送端可以少依赖“丢失等于拥塞”的推断。

RFC 3155 特别拒绝把 ECN 反过来解释。ECN 不能冒充显式传输错误通知；一个没有 ECN 标记的丢包，并不因此被证明是误码。如果报文头本身损坏，网络甚至可能无法确定该向哪个端点报告错误。

文档认为未来的传输错误通知很有价值，也提到第一跳 PEP 环境可能更容易提供局部信息，但并没有定义这种机制。一个信号的缺席，不会自动生成另一个信号的内容。

“建议采用”与“值得研究”不是同一状态

RFC 3155 的即时建议很克制：保留 Slow Start 与 Congestion Avoidance；实现 Fast Retransmit/Fast Recovery；使用 SACK 与 D-SACK；双方不能使用 SACK 时，用 NewReno 改善多个丢失的恢复。

其他设想仍在研究栏。延迟重复 ACK 也许能让链路层先完成重传，但任意拓扑下都安全的等待值尚不可得。发送端 pacing 和 ACK 速率控制可能减少突发。Appropriate Byte Counting 让窗口按确认字节增长，却可能在 ACK 丢失后制造更大突发。

应用行为也决定效果。持久 HTTP 连接可以保留已经训练的窗口；RFC 2140 与 Congestion Manager 探索跨连接共享拥塞知识，避免每个新请求都从完全无知开始。

被列入未来工作不等于已经部署。后来的标准化也不证明 2001 年的主机使用了它。即便选项在两端出现，也要看运行代码是否在具体事件里正确执行。

补齐字节流，只完成了证据链的一段

TCP 要向应用交付有序字节流。缺口存在时，接收端可以缓存后续字节，却不能越过空洞交付。重传填补缺口，重组继续前进，这是明确的传输层成功。

它没有反向证明原始原因，也没有自动挽回业务时间。交易可能在截止时间后完成，用户可能在恢复前离开，大文件也可能最终完成但长期运行在远低于可用容量的速度。

因此，审计应保留连接与应用阶段，RTT、RTO、MSS、MTU 和窗口，序列空洞、ACK、SACK 与超时，队列与 ECN，CRC、链路重试和乱序，发送端算法与重传，窗口轨迹，接收端重组，最后才是应用完成时间与结果。

RFC 3155 留下的不是“TCP 不该减速”，而是更严格的认识论：安全动作可以正确，原因判断仍然未知。发送端替共享互联网承担保守责任；只有跨层证据才能解释损失，也只有应用才能说明修复是否有价值。

来源