Skip to main content

1. 简介 (Introduction)

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

本文档废弃了 [RFC2960] 和 [RFC3309].

1.1. 动机 (Motivation)​

TCP [RFC0793] 作为IP网络中可靠数据传输的主要手段,已经提供了巨大的服务. 然而,越来越多的最新应用发现TCP过于受限,并在UDP [RFC0768] 之上整合了它们自己的可靠数据传输协议. 用户希望绕过的限制包括以下几点:

  • TCP提供可靠的数据传输和严格的传输顺序交付. 一些应用需要可靠的传输而不需要序列维护,而其他应用则对数据的部分排序感到满意. 在这两种情况下,TCP提供的队头阻塞 (head-of-line blocking) 会导致不必要的延迟.

  • TCP的面向流特性通常是一种不便. 应用必须添加它们自己的记录标记来划分消息,并且必须显式使用推送设施来确保完整消息在合理时间内传输.

  • TCP套接字的有限范围使得使用多宿主主机提供高可用数据传输能力的任务变得复杂.

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

跨IP网络传输PSTN信令是一个应用,其中TCP的所有这些限制都是相关的. 虽然此应用直接推动了SCTP的开发,但其他应用可能会发现SCTP很好地匹配了它们的需求.

1.2. SCTP架构视图 (Architectural View of SCTP)​

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

SCTP在本质上是面向连接的,但SCTP关联是一个比TCP连接更广泛的概念. SCTP为每个SCTP端点(第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

                       图1: 一个SCTP关联

1.3. 关键术语 (Key Terms)​

前面章节中已经介绍了一些用于描述SCTP的语言. 本节提供了关键术语及其定义的综合列表.

  • 活动目标传输地址 (Active destination transport address): 发送端点认为可用于接收用户消息的对等端点上的传输地址.

  • 打包 (Bundling): 一种可选的多路复用操作,其中多个用户消息可以在同一个SCTP数据包中携带. 每个用户消息占用其自己的DATA块.

  • 块 (Chunk): SCTP数据包内的一个信息单元,由块头部和块特定内容组成.

  • 拥塞窗口 (Congestion window, cwnd): 一个SCTP变量,限制发送方在收到确认之前可以发送到特定目标传输地址的数据(以字节数计).

  • 累积TSN确认点 (Cumulative TSN Ack Point): 通过SACK的累积TSN确认字段确认的最后一个DATA块的TSN.

  • 空闲目标地址 (Idle destination address): 在一段时间内(通常是HEARTBEAT间隔或更长时间)没有发送用户消息的地址.

  • 非活动目标传输地址 (Inactive destination transport address): 由于错误而被认为非活动且不可用于传输用户消息的地址.

  • 消息 = 用户消息 (Message = user message): 上层协议 (ULP) 提交给SCTP的数据.

  • 消息认证码 (Message Authentication Code, MAC): 一种基于使用密钥的加密哈希函数的完整性检查机制. 通常,消息认证码用于两个共享密钥的方在这些方之间传输的信息之间进行验证. 在SCTP中,它由端点用于验证从对等方在COOKIE ECHO块中返回的状态Cookie信息. 术语"MAC"在不同的上下文中有不同的含义. SCTP使用此术语的含义与 [RFC2104] 中的含义相同.

  • 网络字节序 (Network Byte Order): 最高有效字节在前,也称为大端序.

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

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

  • 路径 (Path): 一个SCTP端点发送到其对等SCTP端点的特定目标传输地址的SCTP数据包所采取的路由. 发送到不同的目标传输地址不一定保证获得单独的路径.

  • 主路径 (Primary Path): 默认情况下将被放入到对等端点的出站数据包中的目标和源地址. 该定义包括源地址,因为实现可能希望指定目标和源地址,以更好地控制回复块采取的返回路径,以及当数据发送方是多宿主时在哪个接口上传输数据包.

  • 接收器窗口 (Receiver Window, rwnd): 数据发送方使用的SCTP变量,用于存储其对等方最近计算的接收器窗口(以字节数计). 这为发送方提供了接收方入站缓冲区中可用空间的指示.

  • SCTP关联 (SCTP association): SCTP端点之间的协议关系,由两个SCTP端点和协议状态信息组成,包括验证标签 (Verification Tags) 和当前活动的传输序列号 (TSN) 集等. 关联可以通过关联中端点使用的传输地址唯一标识. 两个SCTP端点在任何给定时间之间不能有多于一个SCTP关联.

  • SCTP端点 (SCTP endpoint): SCTP数据包的逻辑发送方/接收方. 在多宿主主机上,SCTP端点向其对等方表示为一组可以发送SCTP数据包的合格目标传输地址和一组可以接收SCTP数据包的合格源传输地址的组合. SCTP端点使用的所有传输地址必须使用相同的端口号,但可以使用多个IP地址. SCTP端点使用的传输地址不能被另一个SCTP端点使用. 换句话说,传输地址对于SCTP端点是唯一的.

  • SCTP数据包(或数据包) (SCTP packet or packet): SCTP和无连接数据包网络(例如IP)之间接口上的数据传递单元. SCTP数据包包括公共SCTP头部、可能的SCTP控制块以及封装在SCTP DATA块内的用户数据.

  • SCTP用户应用程序(SCTP用户) (SCTP user application, SCTP user): 使用SCTP服务的逻辑高层应用实体,也称为上层协议 (ULP).

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

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

注意: 相反方向上的流编号之间的关系严格取决于应用程序如何使用它们. SCTP用户有责任在需要时创建和管理这些相关性.

  • 流序列号 (Stream Sequence Number): SCTP内部使用的16位序列号,用于确保在给定流内对用户消息进行有序传递. 每个用户消息附加一个流序列号.

  • 关联标签 (Tie-Tags): 两个32位随机数,它们一起构成64位随机数. 这些标签在状态Cookie和TCB中使用,以便新重新启动的关联可以链接到未重新启动的端点内的原始关联,同时不透露现有关联的真实验证标签.

  • 传输控制块 (Transmission Control Block, TCB): SCTP端点为其与其他SCTP端点的每个现有SCTP关联创建的内部数据结构. TCB包含端点维护和管理相应关联的所有状态和操作信息.

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

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

  • 未确认TSN (Unacknowledged TSN, at an SCTP endpoint): 端点已接收但尚未发送确认的TSN(及其关联的DATA块). 或者在相反的情况下,已发送但尚未收到确认的数据包.

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

  • 用户消息 (User message): SCTP与其用户之间接口上的数据传递单元.

  • 验证标签 (Verification Tag): 随机生成的32位无符号整数. 验证标签提供了一个密钥,允许接收方验证SCTP数据包属于当前关联,而不是来自先前关联的旧数据包或陈旧数据包.

1.4. 缩写 (Abbreviations)​

  • MAC - 消息认证码 (Message Authentication Code) [RFC2104]
  • RTO - 重传超时 (Retransmission Timeout)
  • RTT - 往返时间 (Round-Trip Time)
  • RTTVAR - 往返时间变化 (Round-Trip Time Variation)
  • SCTP - 流控制传输协议 (Stream Control Transmission Protocol)
  • SRTT - 平滑RTT (Smoothed RTT)
  • TCB - 传输控制块 (Transmission Control Block)
  • TLV - 类型-长度-值编码格式 (Type-Length-Value coding format)
  • TSN - 传输序列号 (Transmission Sequence Number)
  • ULP - 上层协议 (Upper-Layer Protocol)

1.5. SCTP功能视图 (Functional View of SCTP)​

SCTP传输服务可以分解为多个功能. 这些功能在图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            |
         |_____________|    |________________________________|

           图2: SCTP传输服务的功能视图

1.5.1. 关联启动和终止 (Association Startup and Takedown)​

关联由来自SCTP用户的请求启动(参见第10节中ASSOCIATE(或SEND)原语的描述).

在初始化期间采用了类似于Karn和Simpson在 [RFC2522] 中描述的cookie机制,以提供针对同步攻击的保护. cookie机制使用四次握手,最后两次允许携带用户数据以实现快速设置. 启动序列在本文档的第5节中描述.

SCTP根据SCTP用户的请求提供活动关联的优雅关闭(即shutdown). 参见第10节中SHUTDOWN原语的描述. SCTP还允许非优雅关闭(即abort),无论是根据用户的请求(ABORT原语)还是作为SCTP层内检测到的错误条件的结果. 第9节描述了优雅和非优雅关闭过程.

SCTP不支持半开状态(如TCP),其中一方可能继续发送数据而另一端已关闭. 当任一端点执行shutdown时,每个对等方上的关联将停止接受来自其用户的新数据,并仅传递在优雅关闭时排队的数据(参见第9节).

1.5.2. 流内有序传递 (Sequenced Delivery within Streams)​

术语"流"在SCTP中用于指代相对于同一流内的其他消息按顺序交付给上层协议的用户消息序列. 这与其在TCP中的用法形成对比,在TCP中它指的是字节序列(在本文档中,假设一个字节为8位).

SCTP用户可以在关联启动时指定关联要支持的流数. 此数字与远端协商(参见第5.1.1节). 用户消息与流编号相关联(SEND, RECEIVE原语,第10节). 在内部,SCTP为SCTP用户传递给它的每条消息分配一个流序列号. 在接收端,SCTP确保消息在给定流内按顺序交付给SCTP用户. 但是,当一个流可能被阻塞等待下一个顺序用户消息时,来自其他流的传递可能会继续.

SCTP提供了一种绕过有序传递服务的机制. 使用此机制发送的用户消息一旦收到就立即交付给SCTP用户.

1.5.3. 用户数据分片 (User Data Fragmentation)​

当需要时,SCTP对用户消息进行分片,以确保传递给下层的SCTP数据包符合路径MTU. 在接收时,片段在传递给SCTP用户之前被重新组装成完整的消息.

1.5.4. 确认和拥塞避免 (Acknowledgement and Congestion Avoidance)​

SCTP为每个用户数据片段或未分片的消息分配一个传输序列号 (TSN). TSN独立于在流级别分配的任何流序列号. 接收端确认所有收到的TSN,即使序列中存在间隙. 通过这种方式,可靠交付在功能上与有序流交付分开.

确认和拥塞避免功能负责在未及时收到确认时进行数据包重传. 数据包重传受到类似于TCP使用的拥塞避免过程的制约. 有关与此功能相关的协议过程的详细描述,请参见第6节和第7节.

1.5.5. 块打包 (Chunk Bundling)​

如第3节所述,传递给下层的SCTP数据包由公共头部后跟一个或多个块组成. 每个块可能包含用户数据或SCTP控制信息. SCTP用户可以选择请求将多个用户消息打包到单个SCTP数据包中. SCTP的块打包功能负责完整SCTP数据包的组装及其在接收端的拆卸.

在拥塞期间,即使用户请求SCTP不打包,SCTP实现仍可执行打包. 用户禁用打包仅影响可能在传输之前延迟一小段时间(以尝试鼓励打包)的SCTP实现. 当用户层禁用打包时,此小延迟被禁止,但在拥塞或重传期间执行的打包不被禁止.

1.5.6. 数据包验证 (Packet Validation)​

SCTP公共头部中包含强制性的验证标签字段和32位校验和字段(有关CRC32c校验和的描述,请参见附录B). 验证标签值在关联启动期间由关联的每一端选择. 丢弃未带有预期验证标签值的接收数据包,作为针对盲伪装攻击和来自先前关联的陈旧SCTP数据包的保护. 每个SCTP数据包的发送方应设置CRC32c校验和,以提供针对网络中数据损坏的额外保护. 具有无效CRC32c校验和的SCTP数据包的接收方将静默丢弃该数据包.

1.5.7. 路径管理 (Path Management)​

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

在关联启动时,为每个SCTP端点定义主路径,并用于正常发送SCTP数据包.

在接收端,路径管理负责在将入站SCTP数据包传递以进行进一步处理之前验证其所属的有效SCTP关联的存在.

注意: 路径管理和数据包验证同时进行,因此尽管上面单独描述,但实际上它们不能作为单独的项目执行.

1.6. 序列号运算 (Serial Number Arithmetic)​

必须记住,实际的传输序列号空间是有限的,尽管非常大. 此空间的范围从0到232 - 1. 由于空间是有限的,所有处理传输序列号的算术都必须以模232执行. 这种无符号算术保留了序列号从232 - 1再次循环到0时的关系. 计算机模运算有一些微妙之处,因此在编程此类值的比较时应格外小心. 当引用TSN时,符号 "=<" 表示"小于或等于"(模232).

本文档中对TSN的比较和算术应使用 [RFC1982] 中定义的序列号算术,其中SERIAL_BITS = 32.

端点不应传输TSN大于其当前发送窗口起始TSN 2**31 - 1 以上的DATA块. 这样做会导致比较TSN时出现问题.

传输序列号在达到232 - 1时回绕. 也就是说,在传输TSN = 232 - 1之后DATA块必须使用的下一个TSN是TSN = 0.

对流序列号执行的任何算术应使用 [RFC1982] 中定义的序列号算术,其中SERIAL_BITS = 16. 本文档中的所有其他算术和比较使用正常算术.

1.7. 与RFC 2960的变更 (Changes from RFC 2960)​

SCTP最初在 [RFC2960] 中定义,本文档废弃了该文档. 对本文档包含的各种变更的详细信息感兴趣的读者,请参阅 [RFC4460].

Last updated on