摘要

  • 重传超时决定何时再次发送；用户超时决定何时中止连接。
  • RFC 5482 传递对端的持久化建议，但本地边界和 CHANGEABLE 仍决定是否采用。

两只时钟回答不同问题

当数据在途却没有得到有效确认时，重传计时器可能到期，TCP 会再次发送队首数据段并重新启动重传计时器。这次重传只说明还可以再试一次，并不说明应用愿意无限期保留连接。

用户超时处理的是另一件事：已发送数据在成功交付前最多可以停留多久？RFC 793 已经把它定义为 TCP 的本地期限。RFC 9293 对两个事件作了明确区分：重传超时事件重新发送队首数据段并重置重传计时器；USER TIMEOUT 事件清空队列，报告连接已中止，删除传输控制块，并进入 CLOSED 状态。

因此两只时钟出现不同结果并不矛盾。即使还可以安排下一次重传，用户为持续等待设定的预算也可能已经耗尽。RTO 根据往返时间和丢失情况调整重试节奏；USER TIMEOUT 则表达继续占用连接状态、内存并承受应用不确定性的最长时间。

它也不是应用请求超时的替代物。应用可以放弃某个操作而保留连接，也可以要求在未确认数据无法交付时直接结束传输连接。

用秒或分钟表达的建议

最初的用户超时是本地参数。一个端点无法知道另一个端点希望为受扰连接保留多久。RFC 5482 定义 TCP User Timeout 选项，使这种偏好能够被对端看见。

该选项的 Kind 为 28，Length 为 4。一个粒度位选择秒或分钟，其余 15 位携带建议的时间间隔。它可以表示从 1 秒到超过 9 小时，或从 1 分钟到超过 22 天的范围。

这个值是给对端的建议，不是远程中止命令。RFC 5482 的抽象状态包括 USER_TIMEOUT、ADV_UTO、ENABLED 和 CHANGEABLE。ENABLED 默认关闭，控制是否发送和处理该选项。CHANGEABLE 控制收到的建议是否可以改变本地 USER_TIMEOUT。

如果应用已经指定本地期限且 CHANGEABLE 为假，收到的值不能覆盖它；TCP 仍应把对端的建议通知应用。信息可以跨越连接，权力却不会随之转移。

边界保护资源

实现必须设置本地上下限。过短的值可能在高延迟或暂时受损的路径上过早中止连接；过长的值会长期保留缓冲区和连接状态，并放大资源耗尽风险。身份验证和按对端设置资源限制可以作为缓解手段。

没有看到 UTO 也不能证明没有用户超时。不支持该选项的实现会按普通选项规则静默忽略它，TCP 有限的选项空间也可能已经被其他选项占满。防火墙还可能在端点期限之前丢弃自己的连接状态。抓包只能证明某个观察点出现过建议，不能证明接收方采用了它，也不能证明中间设备会保持同样长的状态。

如果同时启用 keepalive，其计时器必须大于采用的 USER_TIMEOUT。keepalive 检查空闲连接的活性；USER TIMEOUT 限制未交付数据的持续时间。二者相邻，却不是同一个机制。

RFC 5482 的历史意义在于：它把本地策略作为有边界的建议公开，同时没有把最终的中止权交给对端。

来源