摘要

  • RFC 2012 把 tcpConnState 定义为可读写对象；管理站唯一可以设置的值是 deleteTCB(12)，其效果是删除对应连接的 TCB，并立即终止本地连接。
  • 连接行由本地与远端 IPv4 地址、端口组成的四元组定位；连接数、重置与报文计数器只能描述各自口径，不能独自证明是谁发起了删除、为何获权，以及应用和用户经历了什么。
  • RFC 4022 保留断线动作，同时增加地址类型、独立监听表和进程关联，明确写能力并非合规必需，并首次警告未授权写入能够任意终止连接、造成拒绝服务。

消失的表项不会留下完整原因

RFC 2012 提供了一套看似连续的观察面。管理端可以读取重传算法与超时上下界，看到主动和被动打开次数、失败尝试、从已建立状态进入关闭的次数、当前已建立连接数，以及收发、重传、错误和 RST 报文计数。tcpConnTable 又把视线推进到一条具体连接：本地地址与端口、远端地址与端口、当前状态。

问题在于，状态列不只用于观察。tcpConnState 的 MAX-ACCESS 是 read-write。管理站不能把它随意写成 established 或 timeWait，唯一合法写值是 deleteTCB(12)。一旦代理接受该值，规范要求删除受管节点上的对应 TCB，本地连接随即终止。实现可以向另一端发送 RST，也可以不发；即使发送，RFC 也提醒 RST 并非可靠交付。

所以“删除成功”至少要拆成四件事：代理接受了写请求；本地主机删除了状态；远端是否收到复位；两端应用如何解释和恢复。状态表只直接规定其中的本地协议动作。

TCB 不是一个可随手改写的标签

RFC 793 把 Transmission Control Block 描述为 TCP 记住连接的地方。里面包括本地与远端 socket、连接的安全与优先级、发送和接收缓冲区指针、重传队列与当前报文段，以及收发序列变量。它甚至把 CLOSED 称为“虚构状态”，因为没有 TCB 就没有连接。

因此，deleteTCB 删除的不是仪表盘上的一行颜色，而是让该连接在本地主机继续存在所需的协议记忆。管理表提供四元组，却没有动作 ID、工单、原因、操作者、应用负责人或持久的前后状态收据。连接一旦关闭，临时表项很快消失；地址、端口乃至后继规范里的进程号还可能再次被使用。

这项能力也不是 1996 年突然出现的。RFC 1213 在 1991 年就把 tcpConnState 改成可读写，并在变更清单中明确说是为了支持删除连接的 TCB。RFC 2012 的历史作用，是把同一组 TCP 管理对象带入 SNMPv2/SMIv2。它在开头把认证、授权、访问控制和隐私交给管理框架，却在安全章节只写了一句：本文不讨论安全问题。

计数可见，不等于动作可归因

删除后，tcpCurrEstab 可能下降，tcpEstabResets 或 tcpOutRsts 可能变化。但这些对象各有严格而有限的分母。前者是当前处于 ESTABLISHED 或 CLOSE-WAIT 的连接数量；tcpEstabResets 统计特定状态到 CLOSED 的直接转换；tcpOutRsts 统计带 RST 标志的发出报文段。

它们都没有写入“由某次 SNMP 管理操作造成”。重置可能来自对端、应用、超时、协议处理或管理动作；一枚计数器也不会保存目标四元组、请求主体、授权上下文和服务影响。观察到数值一致，只能说明一种解释可能成立，不能把相关性变成因果。

完整证据链应当连接：写前读取的精确表项、经过认证的请求、当时有效的安全角色、针对该实例的写权限、已记录的操作意图、代理响应、本地 TCB 消失、应用感知、对端感知、重试与中断时长。RFC 2012 的单行对象没有承担这整条链。

后继 MIB 扩大了问责面，也收窄了承诺

RFC 4022 在 2005 年替代 RFC 2012 时，没有删除 deleteTCB(12)。新的 tcpConnectionState 仍可触发立即的本地终止，RST 仍是可选且不可靠的后续动作。但它重新组织了“这条连接是谁”的答案。

旧表被弃用有两个理由：只支持 IPv4，而且把监听端点与连接混在一起。新表把本地、远端的 InetAddressType、地址与端口纳入索引；RFC 4001 还让带 zone index 的地址可以在作用域不唯一时区分接口。监听者进入独立的 tcpListenerTable，可表示双栈通配、单地址族通配或绑定到具体地址。连接和监听行又增加进程 ID，允许与主机资源或应用 MIB 对照。

这些字段能帮助回答“哪一个 socket、哪一个本地进程”，却不会自动回答“哪一位人、依据哪一条业务授权、造成了何种客户结果”。进程号可以是零，可以复用，也只在本机上下文中有意义。

更关键的是，RFC 4022 的合规声明明确允许 tcpConnectionState 只有只读访问；写入和 deleteTCB(12) 支持都不是必需项。实现了同一个模块，不代表实现了同一种干预能力。模式存在、功能存在、主体获权、动作执行与结果被证明，必须分别验证。

RFC 4022 的安全章节也终于把后果写明：未授权访问这些可写状态对象，可以任意终止连接并造成拒绝服务；连接、监听与进程的可读信息本身也可能敏感。

SNMPv3 只能补齐请求路径的一部分

RFC 3414 的 USM 能把消息绑定到一个用户/安全名，提供完整性、时效性和可选的保密性。RFC 3415 的 VACM 则依据安全模型、安全名、安全级别、context、读写视图与对象实例决定是否允许访问。读权限与写权限因此可以被明确拆开。

但认证的仍是“消息代表的用户”，不一定是键盘前的具体人。访问控制也不会自动保存工单、紧急理由、应用确认、对端收据、客户影响或恢复时长。它们能证明请求是怎样进入代理的，却不能替代运行结果的收据。

历史教训不是所有远程断线能力都不应存在。故障处置有时确实需要执行器。真正的边界是：看见一条连接、获准删除它、实际删除它，以及证明删除后的网络和服务结果，是四种不同证据。规范可以定义开关；运行中的系统承担开关后面的现实。

来源

证据边界

来源可以证明文档沿革、对象语法、合规选项和安全模型语义；它们不能证明某厂商实现过可写状态、某操作者使用过该功能、现实事故或 SLA 违约曾经发生，也不能证明今天的部署率或默认配置。