RFC 6824, TCP Extensions for Multipath Operation with Multiple Addresses清楚地解释了您的问题的答案：

2.6. 关闭 MPTCP 连接

当主机 A 想要通知主机 B 它没有更多数据要发送时，它会将此“数据 FIN”作为数据序列信号的一部分发出信号（见上文）。它具有与常规 TCP FIN 相同的语义和行为，但在连接级别。一旦成功接收到 MPTCP 连接上的所有数据，则在连接级别使用 DATA_ACK 确认此消息。更多详细信息在第 3.3.3 节中。

  Host A                                 Host B
  ------                                 ------
  DATA_SEQUENCE_SIGNAL      ->
  [Data FIN]

                            <-           (MPTCP DATA_ACK)

-和-

3.3.3. 关闭连接

在常规 TCP 中，FIN 通知接收方，发送方没有更多数据要发送。为了允许子流独立运行并保持 TCP 在线路上的外观，MPTCP 中的 FIN 仅影响发送它的子流。这允许节点在任何时候对哪些路径正在使用中行使相当大的自由。FIN 的语义与常规 TCP 保持一致；即，直到双方都确认了对方的 FIN，子流才完全关闭。

当应用程序在套接字上调用 close() 时，这表明它没有更多数据要发送；对于常规 TCP，这将导致连接出现 FIN。对于 MPTCP，需要一个等效的机制，这被称为 DATA_FIN。

DATA_FIN 表示发送方没有更多数据要发送，因此可用于验证是否已成功接收所有数据。与常规 TCP 连接上的 FIN 一样，DATA_FIN 是单向信号。

DATA_FIN 通过将数据序列信号选项（图 9）中的“F”标志设置为 1 来发出信号。DATA_FIN 占用连接级序列空间的 1 个八位字节（最后一个八位字节）。请注意，DATA_FIN 包含在数据级别长度中，但不在子流级别：例如，DSN 为 80 且数据级别长度为 11 且设置了 DATA_FIN 的段会将子流中的 10 个八位字节映射到数据序列中空间 80-89，DATA_FIN 为 DSN 90；因此，包含 DATA_FIN 的该段将使用 91 的 DATA_ACK 进行确认。

请注意，当 DATA_FIN 未附加到包含数据的 TCP 段时，数据序列信号必须具有 0 的子流序列号，1 的数据级长度，以及与 DATA_FIN 本身对应的数据序列号。在这种情况下，校验和将仅覆盖伪标头。

DATA_FIN 具有与常规 TCP FIN 相同的语义和行为，但在连接级别。值得注意的是，只有在连接级别成功接收到所有数据后才进行 DATA_ACKed。因此，请注意，DATA_FIN 与子流 FIN 分离。只有在其他子流上没有未处理的数据时，才允许在一个子流上组合这些信号。否则，可能需要在不同的子流上重新传输数据。本质上，主机不得关闭所有正常工作的子流，除非这样做是安全的，即，直到所有未完成的数据都已被 DATA_ACKed，或者直到设置了 DATA_FIN 标志的段是唯一未完成的段。

一旦 DATA_FIN 被确认，所有剩余的子流必须用标准的 FIN 交换关闭。两个主机都应该在所有子流上发送 FIN，作为一种礼貌，即使单个子流失败，中间盒也可以清理状态。还鼓励减少终端主机上子流的超时（最大段寿命）。特别是，仍然有未完成数据排队的任何子流（已在其他子流上重新传输以确认 DATA_FIN）可以用 RST 关闭。

一旦两个主机的 DATA_FIN 都已被 DATA_ACK 确认，则认为连接已关闭。

如上所述，单个子流上的标准 TCP FIN 只会关闭发送它的子流。如果所有子流都已通过 FIN 交换关闭，但没有收到并确认任何 DATA_FIN，则 MPTCP 连接仅在超时后才被视为关闭。这意味着实现将在子流和连接级别具有 TIME_WAIT 状态（请参阅附录 C）。这允许在重新建立新子流之前所有子流上的连接都丢失的“先断后续”场景。