预确认是唯一可能的，因为近加速器将段数据保持在队列中。因此，它可以 ACK 而不是远目的地，提示发送方提前发送窗口并发送比单独使用延迟带宽可能更多的段。

当然，近端加速器需要跟踪其内部较大的发送窗口，如果最终没有收到 ACK，它会使用该窗口自行重新发送数据。是的，如果您愿意，这实际上是一个额外的、隐藏的 TCP 连接，有点像代理。

大多数加速器使用某种黑匣子技术，供应商不会告诉您所有相关信息。但本质上，它与数据压缩、重复数据删除和扩大的发送窗口有关。如果您尝试对后者进行建模，您会发现它根本不是微不足道的。

简而言之：

恢复任何在 PEP [本地] 确认后丢失的数据的责任落在 TCP PEP 身上

见https://www.rfc-editor.org/rfc/rfc3135.html#section-3.1.2

使用标准机制增强卫星信道上的 TCP

见RFC2488

这是一个被称为“最佳当前实践”的 RFC。建议在卫星上使用的所有控件，来自第 [5] 节缓解摘要：

• 路径-MTU发现
• 前向纠错
• 慢启动 [必需]。不要尝试优化TCP的这部分，它不会与其他连接很好地平衡。
• 拥塞避免 [必需]
• 快速重传
• 快速恢复
• TCP 大窗口 - 缩放 - 见https://www.rfc-editor.org/rfc/rfc1323#page-8
• TCP 大窗口 - PAWS - “针对包装序列空间的保护”
• TCP 大窗口 - RTTM - “往返时间测量” - 调整窗口大小
• TCP SACK - 选择性确认。见https://www.rfc-editor.org/rfc/rfc2018

旨在缓解与链路相关的降级的性能增强代理

见RFC3135

这特别涉及如何实施“性能增强代理”[PEP] 的细节。此 RFC 中关于 PEP 的值得注意的摘录：

• M-TCP - 在无线网络断开期间保持连接活跃
• 传输层 PEP - “TCP PEP”。生成本地确认。有时会使用术语“TCP 欺骗”。
• 应用层 PEP - 例如。网络缓存代理
• 连接对称 - 有时连接是不对称的（不同的上传/下载速度），这需要特殊处理。
• 拆分连接：“拆分连接 TCP 实现会终止从一个端系统接收到的 TCP 连接，并与另一个端系统建立相应的 TCP 连接”。
• TCP 确认处理
• TCP 确认间隔
• 本地 TCP 确认 - 通常使用拆分连接。“恢复在 PEP [本地] 确认后丢弃的任何数据的责任落在 TCP PEP 上”。（又名本地 TCP 重传）
• 本地 TCP 重传
• TCP ACK 过滤和重建
• 隧道
• 压缩
• TCP断链处理周期
• 基于优先级的复用
• 协议增强方案

（这甚至不是 RFC 的一半——强烈建议使用 PEP 的网络工程师阅读）