跳到主要内容

1. 引言

本节说明开发流控制传输协议 (Stream Control Transmission Protocol, SCTP) 的动机,SCTP 提供的服务, 以及理解本协议详细描述所需的基本概念.

本文档废止 [RFC2960] 和 [RFC3309].

1.1. 动机​

TCP [RFC0793] 作为 IP 网络中可靠数据传输的主要手段, 已经发挥了巨大作用. 然而, 越来越多的近期应用发现 TCP 过于受限, 因而在 UDP [RFC0768] 之上实现自己的可靠数据传输协议. 用户希望绕过的限制包括:

  • TCP 同时提供可靠数据传输和严格的按传输顺序交付. 某些应用需要可靠传输但不需要保持顺序, 另一些应用只需要部分有序的数据. 在这两种情况下, TCP 的队头阻塞会造成不必要的延迟.

  • TCP 面向字节流的性质常常带来不便. 应用必须自行添加记录标记来界定消息, 并且必须显式使用 push 功能, 以确保完整消息能在合理时间内传输.

  • TCP socket 的作用范围有限, 使得使用多宿主主机提供高可用数据传输能力变得复杂.

  • TCP 相对容易受到拒绝服务攻击, 例如 SYN 攻击.

在 IP 网络上传输 PSTN 信令是一类与 TCP 所有这些限制都相关的应用. 虽然该应用直接推动了 SCTP 的开发, 其他应用也可能发现 SCTP 很适合其需求.

1.2. SCTP 的体系结构视图​

SCTP 可视为位于 SCTP 用户应用 ("SCTP user" 的简称) 与无连接分组网络服务 (如 IP) 之间的一层. 本文档其余部分假定 SCTP 运行在 IP 之上. SCTP 提供的基本服务是在对等 SCTP 用户之间可靠传输用户消息. 它在两个 SCTP 端点之间的关联上下文中执行此服务. 本文档 Section 10 概述了 SCTP 层与 SCTP 用户层边界处应存在的 API.

SCTP 本质上是面向连接的, 但 SCTP 关联是比 TCP 连接更宽泛的概念. SCTP 为每个 SCTP 端点 (Section 1.3) 提供一种方式, 使其能在关联启动期间向另一个端点提供传输地址列表 (即多个 IP 地址与 SCTP 端口的组合). 通过这些地址, 该端点可以被访问, 也将从这些地址发出 SCTP 分组. 该关联覆盖可由各端点列表生成的所有可能源/目的组合上的传输.

     _____________                                      _____________
    |  SCTP User  |                                    |  SCTP User  |
    | Application |                                    | Application |
    |-------------|                                    |-------------|
    |    SCTP     |                                    |    SCTP     |
    |  Transport  |                                    |  Transport  |
    |   Service   |                                    |   Service   |
    |-------------|                                    |-------------|
    |             |One or more    ----      One or more|             |
    | IP Network  |IP address      \/        IP address| IP Network  |
    |   Service   |appearances     /\       appearances|   Service   |
    |_____________|               ----                 |_____________|

      SCTP Node A |`<-------- Network transport ------->`| SCTP Node B

                       Figure 1: SCTP 关联

1.3. 关键术语​

前几节已经引入了一些用于描述 SCTP 的语言. 本节汇总关键术语及其定义.

  • Active destination transport address: 对等端点上的一个传输地址, 发送端点认为该地址可用于接收用户消息.

  • Bundling: 一种可选的复用操作, 可在同一个 SCTP 分组中携带多个用户消息. 每个用户消息占用自己的 DATA chunk.

  • Chunk: SCTP 分组中的信息单元, 由 chunk 头部和 chunk 特定内容组成.

  • Congestion window (cwnd): SCTP 变量, 用字节数限制发送方在收到确认前可向某个特定目的传输地址发送的数据量.

  • Cumulative TSN Ack Point: 通过 SACK 的 Cumulative TSN Ack 字段确认的最后一个 DATA chunk 的 TSN.

  • Idle destination address: 在一段时间内未向其发送用户消息的地址, 通常为 HEARTBEAT 间隔或更长.

  • Inactive destination transport address: 因错误而被视为非活动,不可用于传输用户消息的地址.

  • Message = user message: Upper Layer Protocol (ULP) 提交给 SCTP 的数据.

  • Message Authentication Code (MAC): 基于使用密钥的密码散列函数的完整性检查机制. 通常, 消息认证码用于共享密钥的两方之间, 以验证双方之间传输的信息. 在 SCTP 中, 端点使用它验证对端在 COOKIE ECHO chunk 中返回的 State Cookie 信息. "MAC" 一词在不同上下文中含义不同. SCTP 使用的含义与 [RFC2104] 中相同.

  • Network Byte Order: 最高有效字节在前, 又称大端序.

  • Ordered Message: 相对于同一流上先前发送的所有用户消息按顺序交付的用户消息.

  • Outstanding TSN (at an SCTP endpoint): 端点已经发送,但尚未收到确认的 TSN (以及关联的 DATA chunk).

  • Path: 一个 SCTP 端点向其对等 SCTP 端点的特定目的传输地址发送 SCTP 分组所采用的路由. 发送到不同目的传输地址并不一定保证获得不同路径.

  • Primary Path: 主路径是默认放入发往对等端点的出站分组中的目的地址和源地址. 该定义包含源地址, 因为实现可以希望同时指定目的地址和源地址, 以便在数据发送方为多宿主时, 更好地控制回复 chunk 采用的返回路径以及分组通过哪个接口发送.

  • Receiver Window (rwnd): 数据发送方使用的 SCTP 变量, 用字节数保存最近计算出的对端接收窗口. 它向发送方指示接收方入站缓冲区中的可用空间.

  • SCTP association: SCTP 端点之间的协议关系, 由两个 SCTP 端点和协议状态信息组成, 其中包括 Verification Tag,当前活动的 Transmission Sequence Number (TSN) 集合等. 关联可由关联中端点使用的传输地址唯一标识. 任意时刻两个 SCTP 端点之间不得存在多于一个 SCTP 关联.

  • SCTP endpoint: SCTP 分组的逻辑发送方/接收方. 在多宿主主机上, SCTP 端点对其对端表现为一组可用于发送 SCTP 分组的合格目的传输地址, 以及一组可用于接收 SCTP 分组的合格源传输地址的组合. SCTP 端点使用的所有传输地址必须使用相同端口号, 但可以使用多个 IP 地址. SCTP 端点使用的传输地址不得被另一个 SCTP 端点使用. 换言之, 传输地址对 SCTP 端点是唯一的.

  • SCTP packet (or packet): SCTP 与无连接分组网络 (例如 IP) 之间接口上的数据交付单元. SCTP 分组包括公共 SCTP 头部,可能的 SCTP 控制 chunk, 以及封装在 SCTP DATA chunk 中的用户数据.

  • SCTP user application (SCTP user): 使用 SCTP 服务的逻辑高层应用实体, 也称为 Upper-Layer Protocol (ULP).

  • Slow-Start Threshold (ssthresh): SCTP 变量. 这是端点用于决定是否在特定目的传输地址上执行慢启动或拥塞避免的阈值. Ssthresh 以字节数表示.

  • Stream: 在一个已关联的 SCTP 端点到另一个端点之间建立的单向逻辑信道. 在该信道内, 除提交给无序交付服务的消息外, 所有用户消息都按序交付.

注: 相反方向上的流编号之间的关系完全取决于应用如何使用它们. 如果需要这种关联, SCTP 用户负责创建和管理这些对应关系.

  • Stream Sequence Number: SCTP 内部使用的 16 位序列号, 用于确保给定流内用户消息的顺序交付. 每个用户消息附带一个 Stream Sequence Number.

  • Tie-Tags: 两个 32 位随机数, 合在一起形成 64 位 nonce. 这些 tag 用于 State Cookie 和 TCB 中, 使新重启的关联可在未重启的端点内关联到原关联, 同时不暴露现有关联的真实 Verification Tag.

  • Transmission Control Block (TCB): SCTP 端点为其与其他 SCTP 端点之间每个现有 SCTP 关联创建的内部数据结构. TCB 包含端点维护和管理对应关联所需的全部状态和运行信息.

  • Transmission Sequence Number (TSN): SCTP 内部使用的 32 位序列号. 每个包含用户数据的 chunk 附带一个 TSN, 以便接收 SCTP 端点确认接收并检测重复交付.

  • Transport address: 传输地址传统上由网络层地址,传输层协议和传输层端口号定义. 当 SCTP 运行在 IP 之上时, 传输地址由 IP 地址和 SCTP 端口号的组合定义 (其中 SCTP 是传输协议).

  • Unacknowledged TSN (at an SCTP endpoint): 端点已经收到,但尚未发送确认的 TSN (以及关联的 DATA chunk). 或者相反情形中, 已发送分组但尚未收到确认.

  • Unordered Message: 无序消息相对于任何其他消息都是 "unordered"; 这包括其他无序消息以及有序消息. 无序消息可能早于或晚于同一流上发送的有序消息交付.

  • User message: SCTP 与其用户之间接口上的数据交付单元.

  • Verification Tag: 随机生成的 32 位无符号整数. Verification Tag 提供一个键, 使接收方能够验证 SCTP 分组属于当前关联, 而不是来自先前关联的旧分组或陈旧分组.

1.4. 缩略语​

  • MAC - Message Authentication Code [RFC2104]
  • RTO - Retransmission Timeout
  • RTT - Round-Trip Time
  • RTTVAR - Round-Trip Time Variation
  • SCTP - Stream Control Transmission Protocol
  • SRTT - Smoothed RTT
  • TCB - Transmission Control Block
  • TLV - Type-Length-Value coding format
  • TSN - Transmission Sequence Number
  • ULP - Upper-Layer Protocol

1.5. SCTP 的功能视图​

SCTP 传输服务可分解为若干功能. 这些功能如 Figure 2 所示, 并在本节其余部分说明.

                        SCTP User Application

         -----------------------------------------------------
          _____________                  ____________________
         |             |                | Sequenced Delivery |
         | Association |                |   within Streams   |
         |             |                |____________________|
         |   Startup   |
         |             |         ____________________________
         |     and     |        |    User Data Fragmentation |
         |             |        |____________________________|
         |   Takedown  |
         |             |         ____________________________
         |             |        |     Acknowledgement        |
         |             |        |          and               |
         |             |        |    Congestion Avoidance    |
         |             |        |____________________________|
         |             |
         |             |         ____________________________
         |             |        |       Chunk Bundling       |
         |             |        |____________________________|
         |             |
         |             |     ________________________________
         |             |    |      Packet Validation         |
         |             |    |________________________________|
         |             |
         |             |     ________________________________
         |             |    |     Path Management            |
         |_____________|    |________________________________|

           Figure 2: Functional View of the SCTP Transport Service

1.5.1. 关联启动和拆除​

关联由 SCTP 用户的请求发起 (见 Section 10 中 ASSOCIATE (或 SEND) 原语的说明).

初始化期间采用一种 cookie 机制, 类似 Karn 和 Simpson 在 [RFC2522] 中描述的机制, 以防御同步攻击. 该 cookie 机制使用四次握手, 其中后两段允许携带用户数据以实现快速建立. 启动序列见本文档 Section 5.

SCTP 支持在 SCTP 用户请求下对活动关联进行优雅关闭 (即 shutdown). 见 Section 10 中 SHUTDOWN 原语的说明. SCTP 还允许非优雅关闭 (即 abort), 可由用户请求 (ABORT 原语) 触发, 也可由 SCTP 层内检测到的错误条件触发. Section 9 同时说明优雅关闭和非优雅关闭过程.

SCTP 不支持半开状态 (类似 TCP 中一端可继续发送数据而另一端已关闭的状态). 当任一端点执行 shutdown 时, 每个对端上的关联都将停止接受来自其用户的新数据, 并且只交付优雅关闭时已在队列中的数据 (见 Section 9).

1.5.2. 流内顺序交付​

在 SCTP 中, "stream" 指一系列用户消息, 这些消息要相对于同一流内其他消息按顺序交付给上层协议. 这与 TCP 中的用法不同; 在 TCP 中, stream 指字节序列 (本文档假定一个 byte 为 8 bit).

SCTP 用户可在关联启动时指定该关联要支持的流数量. 该数量与远端协商 (见 Section 5.1.1). 用户消息与流编号关联 (SEND,RECEIVE 原语, Section 10). 在内部, SCTP 为 SCTP 用户传给它的每条消息分配一个 Stream Sequence Number. 在接收侧, SCTP 确保给定流内的消息按序交付给 SCTP 用户. 然而, 当一个流可能因等待下一条按序用户消息而阻塞时, 其他流仍可继续交付.

SCTP 提供一种绕过顺序交付服务的机制. 使用该机制发送的用户消息在收到后会尽快交付给 SCTP 用户.

1.5.3. 用户数据分片​

必要时, SCTP 会对用户消息进行分片, 以确保传给下层的 SCTP 分组符合路径 MTU. 接收时, 分片会在传给 SCTP 用户之前重组为完整消息.

1.5.4. 确认和拥塞避免​

SCTP 为每个用户数据分片或未分片消息分配 Transmission Sequence Number (TSN). TSN 独立于流层分配的任何 Stream Sequence Number. 接收端确认收到的所有 TSN, 即使序列中存在缺口也是如此. 通过这种方式, 可靠交付在功能上与流的顺序交付保持分离.

确认和拥塞避免功能负责在未及时收到确认时重传分组. 分组重传受类似 TCP 所用过程的拥塞避免机制约束. 与此功能相关的协议过程详见 Section 6 和 Section 7.

1.5.5. Chunk 捆绑​

如 Section 3 所述, 交付给下层的 SCTP 分组由公共头部后跟一个或多个 chunk 组成. 每个 chunk 可包含用户数据或 SCTP 控制信息. SCTP 用户可选择请求将多个用户消息捆绑到单个 SCTP 分组中. SCTP 的 chunk 捆绑功能负责组装完整 SCTP 分组, 并在接收端对其拆解.

在拥塞期间, 即使用户已请求 SCTP 不进行捆绑, SCTP 实现可以仍执行捆绑. 用户禁用捆绑只影响那些可能在传输前短暂延迟 (试图促进捆绑) 的 SCTP 实现. 当用户层禁用捆绑时, 被禁止的是这种短暂延迟, 而不是拥塞或重传期间执行的捆绑.

1.5.6. 分组验证​

SCTP 公共头部包含一个强制的 Verification Tag 字段和一个 32 位校验和字段 (CRC32c 校验和说明见 Appendix B). Verification Tag 值由关联两端在关联启动期间选择. 收到的分组如果没有预期的 Verification Tag 值, 将被丢弃, 以防御盲伪装攻击以及先前关联产生的陈旧 SCTP 分组. 每个 SCTP 分组的发送方应设置 CRC32c 校验和, 以针对网络中的数据损坏提供额外保护. 接收方会静默丢弃 CRC32c 校验和无效的 SCTP 分组.

1.5.7. 路径管理​

发送 SCTP 用户能够通过 Section 10 中描述的原语, 操控用作 SCTP 分组目的地的传输地址集合. SCTP 路径管理功能会根据 SCTP 用户的指令以及当前感知的合格目的集合可达状态, 为每个出站 SCTP 分组选择目的传输地址. 当其他分组流量不足以提供可达性信息时, 路径管理功能通过 heartbeat 监测可达性, 并在任何远端传输地址的可达性变化时通知 SCTP 用户. 路径管理功能还负责在关联启动期间向远端报告本地合格传输地址集合, 并向 SCTP 用户报告远端返回的传输地址.

在关联启动时, 每个 SCTP 端点都会定义一个主路径, 并将其用于 SCTP 分组的正常发送.

在接收端, 路径管理负责在将入站 SCTP 分组交给后续处理前, 验证该分组所属的有效 SCTP 关联存在.

注: Path Management 和 Packet Validation 同时完成, 因此虽然上文分开描述, 实际上它们不能作为独立项执行.

1.6. 序列号算术​

必须记住, 实际的 Transmission Sequence Number 空间虽然非常大, 但仍是有限的. 该空间范围为 0 到 232 - 1. 由于空间有限, 所有涉及 Transmission Sequence Number 的算术都必须按模 232 执行. 这种无符号算术在序列号从 232 - 1 回绕到 0 时保持序列号之间的关系. 计算机模运算存在一些细微之处, 因此在编写此类值的比较逻辑时应格外谨慎. 引用 TSN 时, 符号 "=<" 表示 "小于或等于" (模 232).

最后于 更新