摘要

  • sctp_peeloff 拆出的是已经建立的 SCTP 关联，不是重新建立一条关联；此后的数据和控制操作转由新的套接字承接。
  • 关闭原来的一对多套接字，不会终止已经拆出的关联。资源隔离的收益，必须连同独立的生命周期管理一起验收。

一次关停可能执行正确，却没有关掉管理者以为它会关掉的全部工作。对于 SCTP，这不一定意味着远端失联、命令丢失，或者协议实现出了问题。另一种更安静的原因是：应用此前已经把某个关联拆到了别的套接字上，关停流程却仍按旧的范围记账。

RFC 6458 描述的 sctp_peeloff 就有这样一条边界。它把一对多套接字上的某个已建立关联，交给单独的一对一套接字。关联还在继续，但今后操作它的本地入口变了。规范同时明确，关闭原套接字，不会终止已经分支出去的关联。

因此，这不是一个“多开一个描述符”就说完的细节。一次为减轻共享压力而作出的技术选择，也重新划定了谁能从哪个入口结束工作。性能说明若只记录前半句，关停责任就容易留在旧的系统图里。

非阻塞并没有回答资源是否共享

一对多接口用一个套接字管理多个关联，应用在必要时以关联标识区分它们。这可以节省接口层面的管理，但并不意味着背后的每份资源都彼此独立。

RFC 6458 第 3.3 节讨论了一种有条件的情形：实现若在多个关联之间共享出站缓冲分配，一个停止推进的关联就可能占满这份空间，使其他关联也无法继续发送。把套接字设为非阻塞，并不能消除这层资源耦合。调用可以不在原地等待，却仍然没有可用的共享缓冲。

文档给出的办法不止拆分一种。实现可以为每个关联保留缓冲资源；应用协议可以限制未读数据的规模；应用也可以一开始就使用一对一套接字，或者在可能大量积压的数据交换前拆出特定关联。这些办法分别把约束放在资源分配、业务交互和接口边界上，并不是同一个方案的不同名称。

这里不应偷换成某种操作系统的性能承诺。该段讨论依赖实现的分配方式，不能据此宣称某个平台一定复制队列、一定零拷贝，或者拆出以后吞吐必然上升。它支持的是一个更具体的选择：应用可以不再让选定关联继续属于原来的套接字操作范围。

已有工作换了控制入口

调用 sctp_peeloff 时，应用提供原套接字以及要拆出的关联标识。成功返回新的非负描述符，失败返回负一并给出错误信息。它不是普通意义上等待新连接到来再接受连接；应用选择的是已经存在的关联。

第 9.2 节随后要求，该关联此后的所有数据和控制操作都使用新套接字。这里的“控制”不能省略。拆出的不只是数据量，还有今后操作这个关联的入口。

可以设想一种服务：多数关联由共享入口处理，某次大交换单独拆出。这只是说明机制的假设，不是实际部署记录。服务随后关闭共享套接字时，关掉的范围不再包括那次已拆出的交换。要把它纳入完整关停，应用就必须知道新描述符在哪里，并把它列入需要管理的对象。

由此产生的不是自动失控，而是管理范围的分叉。分叉本身可能完全合理；问题在于应用真实的控制结构已经变了，值班表、资源报表或维护流程是否也跟着变。

空闲策略不能靠名字继承

套接字选项也有适用范围。RFC 6458 对套接字层及 IP 层选项的说明，以套接字为作用范围；一对多情形涉及属于该套接字的关联，一对一则涉及它所代表的那个关联。接收和发送缓冲相关章节还明确，一对多的具体处理存在实现差异。

空闲关闭尤其值得单独检查。第 8.1.8 节将 SCTP_AUTOCLOSE 限定为一对多套接字使用的选项。这里的空闲指用户数据的收发活动；默认值零表示关闭该功能，非零值按秒计。应用若需要获知这种关联关闭，还应启用关联状态变化通知。

但这并不等于文档已经说明：拆出关联时，原本启动的定时器会被取消、重置还是继承。不能从选项的适用范围，凭空推导出一个具体的定时器迁移行为。稳妥的结论是，新套接字所需的生命周期策略必须与实际实现一起核对，不能只引用原套接字上曾经设过的参数。

“关闭”本身也有分支。一般情况下，关闭一对一套接字会发起 SCTP 的有序关闭，并使描述符不能再用于后续操作。但启用 SO_LINGER 且等待时间为零时，close 会中止关联。正的等待时间限制的是 close 调用等待多久；调用返回后，协议关闭仍可能继续，不能把等待到期直接写成中止。

若应用希望在终止过程中保留描述符以接收通知，可以考察文档描述的 shutdown 接口。不过 SHUT_WR 对 SCTP 发起的是完整的协议关闭，不是照搬 TCP 的半关闭语义。这些都是接口层面的行为，不是业务交易已经结清的证据。

把责任写回真实的边界

RFC Editor 的记录 将该文档标为 2011 年 12 月发布的 Informational 文件。它不是今天各操作系统实现情况的普查。本次读取的勘误列表 含有文档其他位置的已验证修正，但没有直接针对第 9.2 节的修正；保留待更新和被拒绝的条目，也不能混作已经接受的规范变更。

治理层面的判断应与这些事实分开。Lu Heng 在关于互联网治理代理问题的文章中讨论决策权与后果承担的关系。放到这里，问题很具体：认可拆分收益的人，是否同时确认了谁负责结束被拆出的工作？这并不是指责工程师的动机，而是检查责任有没有跟随控制入口一起移动。

他在阐述 BTW Media 存在理由的文章中强调现实而非倡导。对应到一次关停，就是查看实际还有哪些描述符控制着关联，而不是用“主套接字已关闭”的叙述代替全量状态。

拆分没有破坏原来的关闭规则。它改变了规则能覆盖的集合。真正需要修正的，往往是那张仍把全部工作画在原套接字下面的管理清单。