Internet Engineering Task Force (IETF) M. Welzl
Request for Comments: 8303 University of Oslo
Category: Informational M. Tuexen
ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
N. Khademi
University of Oslo
February 2018
Internet Engineering Task Force (IETF) M. Welzl
Request for Comments: 8303 University of Oslo
Category: Informational M. Tuexen
ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
N. Khademi
University of Oslo
February 2018
On the Usage of Transport Features Provided by IETF Transport Protocols
IETF传输协议提供的传输特性的使用
Abstract
摘要
This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a transport services (TAPS) API.
本文档描述了传输协议传输控制协议（TCP）、多路径TCP（MPTCP）、流控制传输协议（SCTP）、用户数据报协议（UDP）和轻量级用户数据报协议（UDP Lite）的工作原理向应用程序公开服务，以及应用程序如何配置和使用构成这些服务的功能。还讨论了低额外延迟背景传输（LEDBAT）拥塞控制机制提供的服务。该描述产生了一组传输抽象，这些抽象可以在传输服务（TAPS）API中导出。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8303.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8303.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Pass 1 ..........................................................6
3.1. Primitives Provided by TCP .................................6
3.1.1. Excluded Primitives or Parameters ...................9
3.2. Primitives Provided by MPTCP ..............................10
3.3. Primitives Provided by SCTP ...............................11
3.3.1. Excluded Primitives or Parameters ..................18
3.4. Primitives Provided by UDP and UDP-Lite ...................18
3.5. The Service of LEDBAT .....................................19
4. Pass 2 .........................................................20
4.1. CONNECTION-Related Primitives .............................21
4.2. DATA-Transfer-Related Primitives ..........................38
5. Pass 3 .........................................................41
5.1. CONNECTION-Related Transport Features .....................41
5.2. DATA-Transfer-Related Transport Features ..................47
5.2.1. Sending Data .......................................47
5.2.2. Receiving Data .....................................48
5.2.3. Errors .............................................49
6. IANA Considerations ............................................49
7. Security Considerations ........................................49
8. References .....................................................50
8.1. Normative References ......................................50
8.2. Informative References ....................................52
Appendix A. Overview of RFCs Used as Input for Pass 1 .............54
Appendix B. How This Document Was Developed .......................54
Acknowledgements ..................................................56
Authors' Addresses ................................................56
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Pass 1 ..........................................................6
3.1. Primitives Provided by TCP .................................6
3.1.1. Excluded Primitives or Parameters ...................9
3.2. Primitives Provided by MPTCP ..............................10
3.3. Primitives Provided by SCTP ...............................11
3.3.1. Excluded Primitives or Parameters ..................18
3.4. Primitives Provided by UDP and UDP-Lite ...................18
3.5. The Service of LEDBAT .....................................19
4. Pass 2 .........................................................20
4.1. CONNECTION-Related Primitives .............................21
4.2. DATA-Transfer-Related Primitives ..........................38
5. Pass 3 .........................................................41
5.1. CONNECTION-Related Transport Features .....................41
5.2. DATA-Transfer-Related Transport Features ..................47
5.2.1. Sending Data .......................................47
5.2.2. Receiving Data .....................................48
5.2.3. Errors .............................................49
6. IANA Considerations ............................................49
7. Security Considerations ........................................49
8. References .....................................................50
8.1. Normative References ......................................50
8.2. Informative References ....................................52
Appendix A. Overview of RFCs Used as Input for Pass 1 .............54
Appendix B. How This Document Was Developed .......................54
Acknowledgements ..................................................56
Authors' Addresses ................................................56
This specification describes how transport protocols offer transport services, such that applications using them are no longer directly tied to a specific protocol. Breaking this strict connection can reduce the effort for an application programmer, yet attain greater transport flexibility by pushing complexity into an underlying transport services (TAPS) system.
本规范描述了传输协议如何提供传输服务，以便使用它们的应用程序不再直接绑定到特定协议。打破这种严格的连接可以减少应用程序程序员的工作量，但通过将复杂性引入底层传输服务（TAPS）系统，可以获得更大的传输灵活性。
This design process has started with a survey of the services provided by IETF transport protocols and congestion control mechanisms [RFC8095]. The present document and [RFC8304] complement this survey with an in-depth look at the defined interactions between applications and the following unicast transport protocols: Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite). We also define a primitive to enable/disable and configure the Low Extra Delay Background Transport (LEDBAT) unicast congestion control mechanism. For UDP and UDP-Lite, the first step of the protocol analysis -- a discussion of relevant RFC text -- is documented in [RFC8304].
该设计过程始于对IETF传输协议和拥塞控制机制提供的服务的调查[RFC8095]。本文件和[RFC8304]通过深入研究应用程序和以下单播传输协议之间定义的交互来补充本调查：传输控制协议（TCP）、多路径TCP（MPTCP）、流控制传输协议（SCTP）、用户数据报协议（UDP），和轻量级用户数据报协议（UDP Lite）。我们还定义了一个原语来启用/禁用和配置低额外延迟后台传输（LEDBAT）单播拥塞控制机制。对于UDP和UDP Lite，协议分析的第一步——对相关RFC文本的讨论——记录在[RFC8304]中。
This snapshot in time of the IETF transport protocols is published as an RFC to document the analysis by the authors and the TAPS Working Group; this generates a set of transport abstractions that can be exported in a TAPS API. It provides the basis for the minimal set of transport services that end systems supporting TAPS should implement [TAPS-MINSET].
IETF传输协议的时间快照作为RFC发布，以记录作者和TAPS工作组的分析；这将生成一组传输抽象，这些抽象可以在TAPS API中导出。它为支持TAPS的终端系统应实现的最小传输服务集提供了基础[TAPS-MINSET]。
The list of primitives, events, and transport features in this document is strictly based on the parts of protocol specifications that describe what the protocol provides to an application using it and how the application interacts with it. Transport protocols provide communication between processes that operate on network endpoints, which means that they allow for multiplexing of communication between the same IP addresses, and this multiplexing is achieved using port numbers. Port multiplexing is therefore assumed to be always provided and not discussed in this document.
本文档中的原语、事件和传输特性列表严格基于协议规范的部分，这些部分描述了协议向使用它的应用程序提供的内容以及应用程序如何与之交互。传输协议提供在网络端点上运行的进程之间的通信，这意味着它们允许相同IP地址之间的通信多路复用，并且这种多路复用是使用端口号实现的。因此，假定始终提供端口多路复用，本文档中不讨论。
Parts of a protocol that are explicitly stated as optional to implement are not covered. Interactions between the application and a transport protocol that are not directly related to the operation of the protocol are also not covered. For example, there are various ways for an application to use socket options to indicate its interest in receiving certain notifications [RFC6458]. However, for the purpose of identifying primitives, events, and transport features, the ability to enable or disable the reception of notifications is irrelevant. Similarly, "one-to-many style sockets"
协议中明确声明为可选择实现的部分不包括在内。应用程序和传输协议之间与协议操作没有直接关系的交互也不包括在内。例如，应用程序可以通过多种方式使用套接字选项来表示其对接收某些通知的兴趣[RFC6458]。但是，为了识别原语、事件和传输特性，启用或禁用接收通知的功能是不相关的。类似地，“一对多样式套接字”
[RFC6458] just affect the application programming style, not how the underlying protocol operates, and they are therefore not discussed here. The same is true for the ability to obtain the unchanged value of a parameter that an application has previously set (e.g., via "get" in get/set operations [RFC6458]).
[RFC6458]只影响应用程序编程风格，而不影响底层协议的运行方式，因此这里不讨论它们。对于获取应用程序先前设置的参数的未更改值的能力（例如，通过get/set操作[RFC6458]中的“get”）也是如此。
The document presents a three-pass process to arrive at a list of transport features. In the first pass (pass 1), the relevant RFC text is discussed per protocol. In the second pass (pass 2), this discussion is used to derive a list of primitives and events that are uniformly categorized across protocols. Here, an attempt is made to present or -- where text describing primitives or events does not yet exist -- construct primitives or events in a slightly generalized form to highlight similarities. This is, for example, achieved by renaming primitives or events of protocols or by avoiding a strict 1:1 mapping between the primitives or events in the protocol specification and primitives or events in the list. Finally, the third pass (pass 3) presents transport features based on pass 2, identifying which protocols implement them.
本文件提供了一个三次通过的过程，以获得运输特征列表。在第一阶段（第1阶段），根据协议讨论相关RFC文本。在第二阶段（第2阶段），此讨论用于导出跨协议统一分类的原语和事件列表。在这里，试图以稍微广义的形式呈现或（在描述原语或事件的文本尚不存在的情况下）构造原语或事件，以突出相似性。例如，这是通过重命名协议的原语或事件或避免协议规范中的原语或事件与列表中的原语或事件之间严格的1:1映射来实现的。最后，第三个过程（过程3）基于过程2显示传输特性，确定实现它们的协议。
In the list resulting from the second pass, some transport features are missing because they are implicit in some protocols, and they only become explicit when we consider the superset of all transport features offered by all protocols. For example, TCP always carries out congestion control; we have to consider it together with a protocol like UDP (which does not have congestion control) before we can consider congestion control as a transport feature. The complete list of transport features across all protocols is therefore only available after pass 3.
在由第二遍产生的列表中，一些传输特性丢失，因为它们在某些协议中是隐式的，并且当我们考虑所有协议提供的所有传输特征的超集时，它们才变得显式。例如，TCP总是执行拥塞控制；在考虑拥塞控制作为传输特性之前，我们必须考虑与UDP（不具有拥塞控制）之类的协议一起考虑。因此，所有协议的传输功能的完整列表只有在通过3后才可用。
Some protocols are connection oriented. Connection-oriented protocols often use an initial call to a specific primitive to open a connection before communication can progress and require communication to be explicitly terminated by issuing another call to a primitive (usually called 'Close'). A "connection" is the common state that some transport primitives refer to, e.g., to adjust general configuration settings. Connection establishment, maintenance, and termination are therefore used to categorize transport primitives of connection-oriented transport protocols in pass 2 and pass 3. For this purpose, UDP is assumed to be used with "connected" sockets, i.e., sockets that are bound to a specific pair of addresses and ports [RFC8304].
有些协议是面向连接的。面向连接的协议通常使用对特定原语的初始调用来打开连接，然后才能进行通信，并要求通过对原语发出另一个调用（通常称为“关闭”）来显式终止通信。“连接”是一些传输原语所指的常见状态，例如，用于调整常规配置设置。因此，连接的建立、维护和终止被用于在第2阶段和第3阶段对面向连接的传输协议的传输原语进行分类。为此，假定UDP与“连接的”套接字一起使用，即绑定到特定地址和端口对的套接字[RFC8304]。
Transport Feature: a specific end-to-end feature that the transport layer provides to an application. Examples include confidentiality, reliable delivery, ordered delivery, message-versus-stream orientation, etc.
传输特性：传输层向应用程序提供的特定端到端特性。示例包括机密性、可靠交付、有序交付、消息与流定向等。
Transport Service: a set of transport features, without an association to any given framing protocol, which provides a complete service to an application.
传输服务：一组传输特性，不与任何给定的帧协议关联，为应用程序提供完整的服务。
Transport Protocol: an implementation that provides one or more transport services using a specific framing and header format on the wire.
传输协议：在线路上使用特定帧和报头格式提供一个或多个传输服务的实现。
Transport Protocol Component: an implementation of a transport feature within a protocol.
传输协议组件：协议中传输功能的实现。
Transport Service Instance: an arrangement of transport protocols with a selected set of features and configuration parameters that implement a single transport service, e.g., a protocol stack (RTP over UDP).
传输服务实例：传输协议的一种安排，具有一组选定的功能和配置参数，用于实现单个传输服务，例如协议栈（UDP上的RTP）。
Application: an entity that uses the transport layer for end-to-end delivery of data across the network (this may also be an upper-layer protocol or tunnel encapsulation).
应用：使用传输层在网络上进行端到端数据传输的实体（也可以是上层协议或隧道封装）。
Endpoint: an entity that communicates with one or more other endpoints using a transport protocol.
端点：使用传输协议与一个或多个其他端点通信的实体。
Connection: shared state of two or more endpoints that persists across messages that are transmitted between these endpoints.
连接：两个或多个端点的共享状态，在这些端点之间传输的消息中持续存在。
Primitive: a function call that is used to locally communicate between an application and a transport endpoint. A primitive is related to one or more transport features.
基元：用于在应用程序和传输端点之间进行本地通信的函数调用。基本体与一个或多个传输特征相关。
Event: a primitive that is invoked by a transport endpoint.
事件：由传输端点调用的原语。
Parameter: a value passed between an application and a transport protocol by a primitive.
参数：原语在应用程序和传输协议之间传递的值。
Socket: the combination of a destination IP address and a destination port number.
套接字：目标IP地址和目标端口号的组合。
Transport Address: the combination of an IP address, transport protocol, and the port number used by the transport protocol.
传输地址：IP地址、传输协议和传输协议使用的端口号的组合。
This first iteration summarizes the relevant text parts of the RFCs describing the protocols, focusing on what each transport protocol provides to the application and how it is used (abstract API descriptions, where they are available). When presenting primitives, events, and parameters, the use of lower- and upper-case characters is made uniform for the sake of readability.
第一次迭代总结了RFC中描述协议的相关文本部分，重点是每个传输协议为应用程序提供了什么以及如何使用（抽象API描述，如果可用）。在显示原语、事件和参数时，为了可读性，大小写字符的使用是统一的。
The initial TCP specification [RFC0793] states:
初始TCP规范[RFC0793]规定：
The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks.
传输控制协议（TCP）旨在用作分组交换计算机通信网络中主机之间以及此类网络的互连系统中的高度可靠的主机对主机协议。
Section 3.8 of [RFC0793] further specifies the interaction with the application by listing several transport primitives. It is also assumed that an Operating System provides a means for TCP to asynchronously signal the application; the primitives representing such signals are called 'events' in this section. This section describes the relevant primitives.
[RFC0793]的第3.8节通过列出几个传输原语进一步规定了与应用程序的交互。还假设操作系统为TCP提供了一种异步向应用程序发送信号的方法；在本节中，表示此类信号的原语称为“事件”。本节介绍相关的原语。
Open: This is either active or passive, to initiate a connection or listen for incoming connections. All other primitives are associated with a specific connection, which is assumed to first have been opened. An active open call contains a socket. A passive open call with a socket waits for a particular connection; alternatively, a passive open call can leave the socket unspecified to accept any incoming connection. A fully specified passive call can later be made active by calling 'Send'. Optionally, a timeout can be specified, after which TCP will abort the connection if data has not been successfully delivered to the destination (else a default timeout value is used). A procedure for aborting the connection is used to avoid excessive retransmissions, and an application is able to control the threshold used to determine the condition for aborting; this threshold may be measured in time units or as a count of retransmission [RFC1122]. This indicates that the timeout could also be specified as a count of retransmission.
打开：这是主动或被动的，用于启动连接或侦听传入连接。所有其他原语都与一个特定的连接相关联，假定该连接首先已打开。活动的打开调用包含一个套接字。带有套接字的被动打开调用等待特定连接；或者，被动式开放式呼叫可以不指定套接字以接受任何传入连接。完全指定的被动调用可以稍后通过调用“Send”激活。或者，可以指定一个超时，在此之后，如果数据未成功传递到目标，TCP将中止连接（否则使用默认超时值）。中止连接的过程用于避免过度的重新传输，并且应用程序能够控制用于确定中止条件的阈值；该阈值可以时间单位或作为重传计数来测量[RFC1122]。这表示超时也可以指定为重新传输的计数。
Also optional, for multihomed hosts, the local IP address can be provided [RFC1122]. If it is not provided, a default choice will be made in case of active open calls. A passive open call will await incoming connection requests to all local addresses and then maintain usage of the local IP address where the incoming
也可以选择，对于多主机主机，可以提供本地IP地址[RFC1122]。如果未提供该选项，则在活动的开放呼叫情况下将进行默认选择。被动式开放呼叫将等待所有本地地址的传入连接请求，然后保持使用传入连接所在的本地IP地址
connection request has arrived. Finally, the 'options' parameter allows the application to specify IP options such as Source Route, Record Route, or Timestamp [RFC1122]. It is not stated on which segments of a connection these options should be applied, but probably on all segments, as this is also stated in a specification given for the usage of the Source Route IP option (Section 4.2.3.8 of [RFC1122]). Source Route is the only non-optional IP option in this parameter, allowing an application to specify a source route when it actively opens a TCP connection.
连接请求已到达。最后，“options”参数允许应用程序指定IP选项，如源路由、记录路由或时间戳[RFC1122]。未说明这些选项应应用于连接的哪些段，但可能适用于所有段，因为在源路由IP选项的使用规范（RFC1122第4.2.3.8节）中也有说明。源路由是此参数中唯一的非可选IP选项，允许应用程序在主动打开TCP连接时指定源路由。
Master Key Tuples (MKTs) for authentication can optionally be configured when calling 'Open' (Section 7.1 of [RFC5925]). When authentication is in use, complete TCP segments are authenticated, including the TCP IPv4 pseudoheader, TCP header, and TCP data.
调用“Open”（RFC5925第7.1节）时，可以选择配置用于身份验证的主密钥元组（MKT）。使用身份验证时，将对完整的TCP段进行身份验证，包括TCP IPv4伪头、TCP头和TCP数据。
TCP Fast Open (TFO) [RFC7413] allows applications to immediately hand over a message from the active open to the passive open side of a TCP connection together with the first message establishment packet (the SYN). This can be useful for applications that are sensitive to TCP's connection setup delay. [RFC7413] states that "TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service-port basis." The size of the message sent with TFO cannot be more than TCP's maximum segment size (minus options used in the SYN). For the active open side, it is recommended to change or replace the connect() call in order to support a user data buffer argument [RFC7413]. For the passive open side, the application needs to enable the reception of Fast Open requests, e.g., via a new TCP_FASTOPEN setsockopt() socket option before listen(). The receiving application must be prepared to accept duplicates of the TFO message, as the first data written to a socket can be delivered more than once to the application on the remote host.
TCP快速开放（TFO）[RFC7413]允许应用程序立即将TCP连接的主动开放端的消息与第一个消息建立包（SYN）一起移交给被动开放端。这对于对TCP连接设置延迟敏感的应用程序非常有用。[RFC7413]声明“TCP实现在默认情况下不得使用TFO，但仅在应用程序基于每个服务端口明确请求时使用TFO。”使用TFO发送的消息的大小不能超过TCP的最大段大小（减去SYN中使用的选项）。对于活动的开放端，建议更改或替换connect（）调用，以支持用户数据缓冲区参数[RFC7413]。对于被动打开端，应用程序需要启用快速打开请求的接收，例如，在侦听（）之前通过新的TCP_FASTOPEN setsockopt（）套接字选项。接收应用程序必须准备好接受TFO消息的副本，因为写入套接字的第一个数据可以多次传递到远程主机上的应用程序。
Send: This is the primitive that an application uses to give the local TCP transport endpoint a number of bytes that TCP should reliably send to the other side of the connection. The 'urgent' flag, if set, states that the data handed over by this send call is urgent and this urgency should be indicated to the receiving process in case the receiving application has not yet consumed all non-urgent data preceding it. An optional timeout parameter can be provided that updates the connection's timeout (see 'Open'). Additionally, optional parameters allow the ability to indicate the preferred outgoing MKT (current_key) and/or the preferred incoming MKT (rnext_key) of a connection (Section 7.1 of [RFC5925]).
发送：这是应用程序用于为本地TCP传输端点提供TCP应可靠发送到连接另一端的字节数的原语。如果设置了“紧急”标志，则表明此发送呼叫移交的数据是紧急的，如果接收应用程序尚未使用其之前的所有非紧急数据，则应向接收进程指示此紧急性。可以提供一个可选的超时参数来更新连接的超时（请参阅“打开”）。此外，可选参数允许指示连接的首选传出MKT（当前_键）和/或首选传入MKT（rnext_键）（RFC5925）第7.1节）。
Receive: This primitive allocates a receiving buffer for a provided number of bytes. It returns the number of received bytes provided in the buffer when these bytes have been received and written into the buffer by TCP. The application is informed of urgent data via an 'urgent' flag: if it is on, there is urgent data; if it is off, there is no urgent data or this call to 'Receive' has returned all the urgent data. The application is also informed about the current_key and rnext_key information carried in a recently received segment via an optional parameter (Section 7.1 of [RFC5925]).
接收：此原语为提供的字节数分配接收缓冲区。当TCP接收并写入缓冲区时，它返回缓冲区中提供的接收字节数。通过“紧急”标志通知应用程序紧急数据：如果启用，则有紧急数据；如果关闭，则表示没有紧急数据，或者此“接收”呼叫已返回所有紧急数据。应用程序还通过可选参数（RFC5925第7.1节）获知最近接收段中携带的当前_键和rnext_键信息。
Close: This primitive closes one side of a connection. It is semantically equivalent to "I have no more data to send" but does not mean "I will not receive any more", as the other side may still have data to send. This call reliably delivers any data that has already been given to TCP (and if that fails, 'Close' becomes 'abort').
关闭：此原语关闭连接的一侧。它在语义上等同于“我没有更多的数据要发送”，但并不意味着“我将不再接收”，因为另一方可能仍然有数据要发送。此调用可靠地传递已提供给TCP的任何数据（如果失败，“关闭”变为“中止”）。
Abort: This primitive causes all pending 'Send' and 'Receive' calls to be aborted. A TCP "RESET" message is sent to the TCP endpoint on the other side of the connection [RFC0793].
中止：此原语导致所有挂起的“发送”和“接收”调用中止。TCP“重置”消息被发送到连接另一侧的TCP端点[RFC0793]。
Close Event: TCP uses this primitive to inform an application that the application on the other side has called the 'Close' primitive, so the local application can also issue a 'Close' and terminate the connection gracefully. See [RFC0793], Section 3.5.
Close事件：TCP使用此原语通知应用程序另一端的应用程序调用了“Close”原语，因此本地应用程序也可以发出“Close”并正常终止连接。参见[RFC0793]，第3.5节。
Abort Event: When TCP aborts a connection upon receiving a "RESET" from the peer, it "advises the user and goes to the CLOSED state." See [RFC0793], Section 3.4.
中止事件：当TCP在收到对等方的“重置”后中止连接时，它“通知用户并进入关闭状态”。请参阅[RFC0793]，第3.4节。
User Timeout Event: This event is executed when the user timeout (Section 3.9 of [RFC0793]) expires (see the definition of 'Open' in this section). All queues are flushed, and the application is informed that the connection had to be aborted due to user timeout.
用户超时事件：当用户超时（RFC0793的第3.9节）过期时执行此事件（请参阅本节中“打开”的定义）。将刷新所有队列，并通知应用程序由于用户超时而必须中止连接。
Error_Report event: This event informs the application of "soft errors" that can be safely ignored [RFC5461], including the arrival of an ICMP error message or excessive retransmissions (reaching a threshold below the threshold where the connection is aborted). See Section 4.2.4.1 of [RFC1122].
错误报告事件：此事件通知应用程序可以安全忽略的“软错误”[RFC5461]，包括ICMP错误消息的到达或过度重新传输（达到低于中断连接阈值的阈值）。见[RFC1122]第4.2.4.1节。
Type-of-Service: Section 4.2.4.2 of the requirements for Internet hosts [RFC1122] states that "The application layer MUST be able to specify the Type-of-Service (TOS) for segments that are sent on a connection." The application should be able to change the TOS during the connection lifetime, and the TOS value should be passed
服务类型：《互联网主机要求》[RFC1122]第4.2.4.2节规定“应用层必须能够为连接上发送的网段指定服务类型（TOS）”。应用程序应该能够在连接生存期内更改TOS，并且应该传递TOS值
to the IP layer unchanged. Since then, the TOS field has been redefined. The Differentiated Services (Diffserv) model [RFC2475] [RFC3260] replaces this field in the IP header, assigning the six most significant bits to carry the Differentiated Services Code Point (DSCP) field [RFC2474].
到IP层不变。此后，TOS字段被重新定义。区分服务（Diffserv）模型[RFC2475][RFC3260]替换IP报头中的此字段，分配六个最高有效位以携带区分服务代码点（DSCP）字段[RFC2474]。
Nagle: The Nagle algorithm delays sending data for some time to increase the likelihood of sending a full-sized segment (Section 4.2.3.4 of [RFC1122]). An application can disable the Nagle algorithm for an individual connection.
Nagle：Nagle算法将发送数据延迟一段时间，以增加发送全尺寸段的可能性（RFC1122第4.2.3.4节）。应用程序可以为单个连接禁用Nagle算法。
User Timeout Option: The User Timeout Option (UTO) [RFC5482] allows one end of a TCP connection to advertise its current user timeout value so that the other end of the TCP connection can adapt its own user timeout accordingly. In addition to the configurable value of the user timeout (see 'Send'), there are three per-connection state variables that an application can adjust to control the operation of the UTO: 'adv_uto' is the value of the UTO advertised to the remote TCP peer (default: system-wide default user timeout); 'enabled' (default false) is a boolean-type flag that controls whether the UTO option is enabled for a connection. This applies to both sending and receiving. 'changeable' is a boolean-type flag (default true) that controls whether the user timeout may be changed based on a UTO option received from the other end of the connection. 'changeable' becomes false when an application explicitly sets the user timeout (see 'Send').
用户超时选项：用户超时选项（UTO）[RFC5482]允许TCP连接的一端公布其当前用户超时值，以便TCP连接的另一端可以相应地调整其自己的用户超时。除了用户超时的可配置值（请参阅“发送”）外，应用程序还可以调整三个每个连接状态变量来控制UTO的操作：“adv_UTO”是向远程TCP对等方播发的UTO的值（默认：系统范围的默认用户超时）；'enabled”（默认为false）是一个布尔类型标志，用于控制是否为连接启用UTO选项。这适用于发送和接收。”“可更改”是一个布尔类型标志（默认为true），用于控制是否可以根据从连接另一端接收的UTO选项更改用户超时当应用程序显式设置用户超时时，“可更改”变为false（请参阅“发送”）。
Set/Get Authentication Parameters: The preferred outgoing MKT (current_key) and/or the preferred incoming MKT (rnext_key) of a connection can be configured. Information about current_key and rnext_key carried in a recently received segment can be retrieved (Section 7.1 of [RFC5925]).
设置/获取身份验证参数：可以配置连接的首选传出MKT（当前密钥）和/或首选传入MKT（rnext密钥）。可检索最近接收段中携带的当前_键和rnext_键的相关信息（RFC5925第7.1节）。
The 'Open' primitive can be handed optional precedence or security/ compartment information [RFC0793], but this was not included here because it is mostly irrelevant today [RFC7414].
“Open”原语可以被赋予可选的优先级或安全/隔间信息[RFC0793]，但这里不包括这一信息，因为它在今天基本上是不相关的[RFC7414]。
The 'Status' primitive was not included because the initial TCP specification describes this primitive as "implementation dependent" and states that it "could be excluded without adverse effect" [RFC0793]. Moreover, while a data block containing specific information is described, it is also stated that not all of this information may always be available. While [RFC5925] states that 'Status' "SHOULD be augmented to allow the MKTs of a current or pending connection to be read (for confirmation)", the same
未包括“状态”原语，因为初始TCP规范将此原语描述为“依赖于实现”，并声明它“可以排除而不会产生不利影响”[RFC0793]。此外，在描述包含特定信息的数据块的同时，还说明并非所有这些信息总是可用的。虽然[RFC5925]指出“应增加“状态”，以允许读取当前或挂起连接的MKT（用于确认）”，但相同
information is also available via 'Receive', which, following [RFC5925], "MUST be augmented" with that functionality. The 'Send' primitive includes an optional 'push' flag which, if set, requires data to be promptly transmitted to the receiver without delay [RFC0793]; the 'Receive' primitive described in can (under some conditions) yield the status of the 'push' flag. Because "push" functionality is optional to implement for both the 'Send' and 'Receive' primitives [RFC1122], this functionality is not included here. The requirements for Internet hosts [RFC1122] also introduce keep-alives to TCP, but these are optional to implement and hence not considered here. The same document also describes that "some TCP implementations have included a FLUSH call", indicating that this call is also optional to implement; therefore, it is not considered here.
信息也可通过“接收”获得，在[RFC5925]之后，“必须增加”该功能。“发送”原语包括一个可选的“推送”标志，如果设置了该标志，则要求立即将数据发送到接收器，而不延迟[RFC0793]；can中描述的“接收”原语（在某些情况下）产生“推送”标志的状态。因为“推送”功能对于“发送”和“接收”原语[RFC1122]都是可选的，所以这里不包括此功能。对Internet主机的要求[RFC1122]也为TCP引入了保持有效性，但这些是可选的，因此此处不考虑。同一文档还描述了“一些TCP实现中包含了一个刷新调用”，表明该调用也是可选的；因此，这里不考虑它。
MPTCP is an extension to TCP that allows the use of multiple paths for a single data stream. It achieves this by creating different so-called TCP subflows for each of the interfaces and scheduling the traffic across these TCP subflows. The service provided by MPTCP is described as follows in [RFC6182]:
MPTCP是TCP的扩展，允许对单个数据流使用多条路径。它通过为每个接口创建不同的所谓TCP子流并跨这些TCP子流调度流量来实现这一点。MPTCP提供的服务在[RFC6182]中描述如下：
Multipath TCP MUST follow the same service model as TCP [RFC0793]: in-order, reliable, and byte-oriented delivery. Furthermore, a Multipath TCP connection SHOULD provide the application with no worse throughput or resilience than it would expect from running a single TCP connection over any one of its available paths.
多路径TCP必须遵循与TCP相同的服务模型[RFC0793]：以便有序、可靠和面向字节的传输。此外，多路径TCP连接应该为应用程序提供的吞吐量或恢复能力不会比在其任何一条可用路径上运行单个TCP连接所期望的更差。
Further, there are some constraints on the API exposed by MPTCP, as stated in [RFC6182]:
此外，如[RFC6182]所述，MPTCP公开的API有一些限制：
A multipath-capable equivalent of TCP MUST retain some level of backward compatibility with existing TCP APIs, so that existing applications can use the newer transport merely by upgrading the operating systems of the end hosts.
具有多路径功能的等效TCP必须与现有TCP API保持一定程度的向后兼容性，以便现有应用程序只需升级终端主机的操作系统即可使用较新的传输。
As such, the primitives provided by MPTCP are equivalent to the ones provided by TCP. Nevertheless, the MPTCP RFCs [RFC6824] and [RFC6897] clarify some parts of TCP's primitives with respect to MPTCP and add some extensions for better control on MPTCP's subflows. Hereafter is a list of the clarifications and extensions the above-cited RFCs provide to TCP's primitives.
因此，MPTCP提供的原语与TCP提供的原语相同。然而，MPTCP RFC[RFC6824]和[RFC6897]澄清了TCP原语中与MPTCP相关的一些部分，并添加了一些扩展以更好地控制MPTCP的子流。以下是上述RFC向TCP原语提供的澄清和扩展列表。
Open: "An application should be able to request to turn on or turn off the usage of MPTCP" [RFC6897]. This functionality can be provided through a socket option called 'tcp_multipath_enable'. Further, MPTCP must be disabled in case the application is binding to a specific address [RFC6897].
打开：“应用程序应该能够请求打开或关闭MPTCP的使用”[RFC6897]。此功能可通过名为“tcp\u多路径\u启用”的套接字选项提供。此外，如果应用程序绑定到特定地址[RFC6897]，则必须禁用MPTCP。
Send/Receive: The sending and receiving of data does not require any changes to the application when MPTCP is being used [RFC6824]. The MPTCP-layer will take one input data stream from an application, and split it into one or more subflows, with sufficient control information to allow it to be reassembled and delivered reliably and in order to the recipient application.
发送/接收：在使用MPTCP时，数据的发送和接收不需要对应用程序进行任何更改[RFC6824]。MPTCP层将从一个应用程序中获取一个输入数据流，并将其拆分为一个或多个子流，具有足够的控制信息，以便能够可靠地重新组装并交付给接收方应用程序。
The use of the Urgent Pointer is special in MPTCP [RFC6824], which states: "a TCP subflow MUST NOT use the Urgent Pointer to interrupt an existing mapping."
在MPTCP[RFC6824]中，紧急指针的使用是特殊的，其中规定：“TCP子流不得使用紧急指针中断现有映射。”
Address and Subflow Management: MPTCP uses different addresses and allows a host to announce these addresses as part of the protocol. The MPTCP API Considerations RFC [RFC6897] says "An application should be able to restrict MPTCP to binding to a given set of addresses" and thus allows applications to limit the set of addresses that are being used by MPTCP. Further, "An application should be able to obtain information on the pairs of addresses used by the MPTCP subflows."
地址和子流管理：MPTCP使用不同的地址，并允许主机作为协议的一部分宣布这些地址。MPTCP API注意事项RFC[RFC6897]指出，“应用程序应该能够限制MPTCP绑定到给定的地址集”，因此允许应用程序限制MPTCP正在使用的地址集。此外，“应用程序应该能够获得MPTCP子流使用的地址对的信息。”
TCP has a number of limitations that SCTP removes (Section 1.1 of [RFC4960]). The following three removed limitations directly translate into transport features that are visible to an application using SCTP: 1) it allows for preservation of message delimiters; 2) it does not provide in-order or reliable delivery unless the application wants that; 3) multihoming is supported. In SCTP, connections are called "associations" and they can be between not only two (as in TCP) but multiple addresses at each endpoint.
TCP有许多SCTP消除的限制（RFC4960第1.1节）。以下三个已删除的限制直接转换为使用SCTP的应用程序可见的传输特性：1）它允许保留消息分隔符；2） 除非应用程序需要，否则它不会提供有序或可靠的交付；3） 支持多归宿。在SCTP中，连接被称为“关联”，它们不仅可以是两个地址之间的连接（如TCP中的连接），而且可以是每个端点的多个地址之间的连接。
Section 10 of the SCTP base protocol specification [RFC4960] specifies the interaction with the application (which SCTP calls the "Upper-Layer Protocol (ULP)"). It is assumed that the Operating System provides a means for SCTP to asynchronously signal the application; the primitives representing such signals are called 'events' in this section. Here, we describe the relevant primitives. In addition to the abstract API described in Section 10 of [RFC4960], an extension to the sockets API is described in [RFC6458]. This covers the functionality of the base protocol [RFC4960] and some of its extensions [RFC3758] [RFC4895] [RFC5061]. For other protocol extensions [RFC6525] [RFC6951] [RFC7053] [RFC7496] [RFC7829]
SCTP基本协议规范[RFC4960]第10节规定了与应用程序的交互（SCTP称之为“上层协议（ULP）”）。假设操作系统为SCTP提供了一种异步向应用程序发送信号的方法；在本节中，表示此类信号的原语称为“事件”。这里，我们描述相关的原语。除了[RFC4960]第10节中描述的抽象API外，[RFC6458]中还描述了套接字API的扩展。这包括基本协议[RFC4960]及其一些扩展[RFC3758][RFC4895][RFC5061]的功能。其他协议扩展[RFC6525][RFC6951][RFC7053][RFC7496][RFC7829]
[RFC8260], the corresponding extensions of the sockets API are specified in these protocol specifications. The functionality exposed to the ULP through all these APIs is considered here.
[RFC8260]，这些协议规范中指定了套接字API的相应扩展。这里考虑通过所有这些API向ULP公开的功能。
The abstract API contains a 'SetProtocolParameters' primitive that allows elements of a parameter list [RFC4960] to be adjusted; it is stated that SCTP implementations "may allow ULP to customize some of these protocol parameters", indicating that none of the elements of this parameter list are mandatory to make ULP configurable. Thus, we only consider the parameters in the abstract API that are also covered in one of the other RFCs listed above, which leads us to exclude the parameters 'RTO.Alpha', 'RTO.Beta', and 'HB.Max.Burst'. For clarity, we also replace 'SetProtocolParameters' itself with primitives that adjust parameters or groups of parameters that fit together.
抽象API包含一个“SetProtocolParameters”原语，允许调整参数列表[RFC4960]的元素；有人指出，SCTP实现“可能允许ULP自定义某些协议参数”，这表明此参数列表中的任何元素都不是使ULP可配置的必需元素。因此，我们只考虑抽象API中的参数，这些参数也包含在上面列出的其他RFC中，这导致我们排除参数“RTOα”、“RTOβ”和“Hb.Max突发”。为清楚起见，我们还将“SetProtocolParameters”本身替换为调整参数或组合在一起的参数组的原语。
Initialize: Initialize creates a local SCTP instance that it binds to a set of local addresses (and, if provided, a local port number) [RFC4960]. Initialize needs to be called only once per set of local addresses. A number of per-association initialization parameters can be used when an association is created, but before it is connected (via the primitive 'Associate' below): the maximum number of inbound streams the application is prepared to support, the maximum number of attempts to be made when sending the INIT (the first message of association establishment), and the maximum retransmission timeout (RTO) value to use when attempting an INIT [RFC6458]. At this point, before connecting, an application can also enable UDP encapsulation by configuring the remote UDP encapsulation port number [RFC6951].
初始化：Initialize创建一个本地SCTP实例，它绑定到一组本地地址（如果提供，还有一个本地端口号）[RFC4960]。每个本地地址集只需调用一次Initialize。在创建关联时，但在连接关联之前（通过下面的原语“Associate”），可以使用多个每个关联的初始化参数：应用程序准备支持的最大入站流数，发送INIT时尝试的最大次数（关联建立的第一条消息），以及尝试初始化[RFC6458]时要使用的最大重新传输超时（RTO）值。此时，在连接之前，应用程序还可以通过配置远程UDP封装端口号[RFC6951]来启用UDP封装。
Associate: This creates an association (the SCTP equivalent of a connection) that connects the local SCTP instance and a remote SCTP instance. To identify the remote endpoint, it can be given one or multiple (using "connectx") sockets (Section 9.9 of [RFC6458]). Most primitives are associated with a specific association, which is assumed to first have been created. Associate can return a list of destination transport addresses so that multiple paths can later be used. One of the returned sockets will be selected by the local endpoint as the default primary path for sending SCTP packets to this peer, but this choice can be changed by the application using the list of destination addresses. Associate is also given the number of outgoing streams to request and optionally returns the number of negotiated outgoing streams. An optional parameter of 32 bits, the adaptation layer indication, can be provided [RFC5061]. If authenticated chunks are used, the chunk types required to be sent authenticated by the peer can be provided [RFC4895]. An 'SCTP_Cant_Str_Assoc' notification is used to inform the
关联：这将创建连接本地SCTP实例和远程SCTP实例的关联（相当于连接的SCTP）。为了识别远程端点，可以为其提供一个或多个（使用“connectx”）套接字（RFC6458第9.9节）。大多数原语都与特定的关联相关联，假定该关联首先已创建。Associate可以返回目标传输地址列表，以便以后可以使用多个路径。本地端点将选择一个返回的套接字作为向该对等方发送SCTP数据包的默认主路径，但应用程序可以使用目标地址列表更改此选择。Associate还获得了要请求的传出流的数量，并可以选择返回协商传出流的数量。可提供32位的可选参数，即适配层指示[RFC5061]。如果使用经过身份验证的块，则可以提供需要由对等方进行身份验证发送的块类型[RFC4895]。“SCTP不能”Str Assoc通知用于通知
application of a failure to create an association [RFC6458]. An application could use sendto() or sendmsg() to implicitly set up an association, thereby handing over a message that SCTP might send during the association setup phase [RFC6458]. Note that this mechanism is different from TCP's TFO mechanism: the message would arrive only once, after at least one RTT, as it is sent together with the third message exchanged during association setup, the COOKIE-ECHO chunk).
未能创建关联的应用程序[RFC6458]。应用程序可以使用sendto（）或sendmsg（）隐式设置关联，从而传递SCTP在关联设置阶段可能发送的消息[RFC6458]。请注意，此机制不同于TCP的TFO机制：消息只会在至少一次RTT之后到达一次，因为它与在关联设置期间交换的第三条消息（COOKIE-ECHO块）一起发送。
Send: This sends a message of a certain length in bytes over an association. A number can be provided to later refer to the correct message when reporting an error, and a stream id is provided to specify the stream to be used inside an association (we consider this as a mandatory parameter here for simplicity: if not provided, the stream id defaults to 0). A condition to abandon the message can be specified (for example limiting the number of retransmissions or the lifetime of the user message). This allows control of the partial reliability extension [RFC3758] [RFC7496]. An optional maximum lifetime can specify the time after which the message should be discarded rather than sent. A choice (advisory, i.e., not guaranteed) of the preferred path can be made by providing a socket, and the message can be delivered out-of-order if the 'unordered' flag is set. An advisory flag indicates that the peer should not delay the acknowledgement of the user message provided [RFC7053]. Another advisory flag indicates whether the application prefers to avoid bundling user data with other outbound DATA chunks (i.e., in the same packet). A payload protocol-id can be provided to pass a value that indicates the type of payload protocol data to the peer. If authenticated chunks are used, the key identifier for authenticating DATA chunks can be provided [RFC4895].
发送：通过关联发送特定长度（字节）的消息。在报告错误时，可以提供一个数字，以便稍后参考正确的消息，并且提供流ID来指定要在关联中使用的流（在这里我们认为这是一个强制参数，如果不提供，流ID默认为0）。可以指定放弃消息的条件（例如限制重传次数或用户消息的生存期）。这允许控制部分可靠性扩展[RFC3758][RFC7496]。可选的最长生存期可以指定丢弃而不是发送消息的时间。可以通过提供套接字来选择（建议，即不保证）首选路径，如果设置了“无序”标志，则消息可以无序传递。建议标志指示对等方不应延迟对提供的用户消息的确认[RFC7053]。另一个建议标志指示应用程序是否倾向于避免将用户数据与其他出站数据块（即，在同一数据包中）捆绑。可以提供有效负载协议id以将指示有效负载协议数据类型的值传递给对等方。如果使用经过身份验证的数据块，则可以提供用于身份验证数据块的密钥标识符[RFC4895]。
Receive: Messages are received from an association, and optionally a stream within the association, with their size returned. The application is notified of the availability of data via a 'Data Arrive' notification. If the sender has included a payload protocol-id, this value is also returned. If the received message is only a partial delivery of a whole message, a 'partial' flag will indicate so, in which case the stream id and a stream sequence number are provided to the application.
接收：从关联接收消息，或者从关联内的流接收消息，并返回其大小。通过“数据到达”通知将数据可用性通知应用程序。如果发送方包含有效负载协议id，则也会返回此值。如果接收到的消息只是整个消息的部分传递，则“partial”标志将指示如此，在这种情况下，将向应用程序提供流id和流序列号。
Shutdown: This primitive gracefully closes an association, reliably delivering any data that has already been handed over to SCTP. A parameter lets the application control whether further receive or send operations or both are disabled when the call is issued. A return code informs about success or failure of this procedure.
Shutdown：此原语优雅地关闭关联，可靠地传递已移交给SCTP的任何数据。参数允许应用程序控制在发出调用时是否禁用进一步的接收或发送操作，或同时禁用这两种操作。返回代码通知此过程的成功或失败。
Abort: This ungracefully closes an association, by discarding any locally queued data and informing the peer that the association was aborted. Optionally, an abort reason to be passed to the peer may be provided by the application. A return code informs about success or failure of this procedure.
中止：通过丢弃任何本地排队的数据并通知对等方该关联已中止，此操作将不正常地关闭关联。可选地，应用程序可以提供要传递给对等方的中止原因。返回代码通知此过程的成功或失败。
Change Heartbeat / Request Heartbeat: This allows the application to enable/disable heartbeats and optionally specify a heartbeat frequency as well as requesting a single heartbeat to be carried out upon a function call, with a notification about success or failure of transmitting the HEARTBEAT chunk to the destination.
更改心跳/请求心跳：这允许应用程序启用/禁用心跳，并可选地指定心跳频率，以及在函数调用时请求执行单个心跳，并通知将心跳块传输到目标的成功或失败。
Configure Max. Retransmissions of an Association: The parameter 'Association.Max.Retrans' [RFC4960] (called "sasoc_maxrxt" in the SCTP sockets API extensions [RFC6458]) allows the configuration of the number of unsuccessful retransmissions after which an entire association is considered as failed; this should invoke a 'Communication Lost' notification.
配置关联的最大重传次数：参数'Association.Max.Retrans'[RFC4960]（在SCTP sockets API extensions[RFC6458]中称为“sasoc_maxrxt”）允许配置不成功的重传次数，在此之后，整个关联被视为失败；这将调用“通信丢失”通知。
Set Primary: This allows the ability to set a new primary default path for an association by providing a socket. Optionally, a default source address to be used in IP datagrams can be provided.
Set Primary：这允许通过提供套接字为关联设置新的主默认路径。可选地，可以提供IP数据报中使用的默认源地址。
Change Local Address / Set Peer Primary: This allows an endpoint to add/remove local addresses to/from an association. In addition, the peer can be given a hint for which address to use as the primary address [RFC5061].
更改本地地址/设置对等主地址：这允许端点在关联中添加/删除本地地址。此外，可以向对等方提示将哪个地址用作主地址[RFC5061]。
Configure Path Switchover: The abstract API contains a primitive called 'Set Failure Threshold' [RFC4960]. This configures the parameter 'Path.Max.Retrans', which determines after how many retransmissions a particular transport address is considered as unreachable. If there are more transport addresses available in an association, reaching this limit will invoke a path switchover. An extension called "SCTP-PF" adds a concept of "Potentially Failed (PF)" paths to this method [RFC7829]. When a path is in PF state, SCTP will not entirely give up sending on that path, but it will preferably send data on other active paths if such paths are available. Entering the PF state is done upon exceeding a configured maximum number of retransmissions. Thus, for all paths where this mechanism is used, there are two configurable error thresholds: one to decide that a path is in PF state, and one to decide that the transport address is unreachable.
配置路径切换：抽象API包含一个名为“设置故障阈值”的原语[RFC4960]。这将配置参数“Path.Max.Retrans”，该参数确定在多少次重新传输后，特定传输地址被视为无法访问。如果关联中有更多可用的传输地址，达到此限制将调用路径切换。一个名为“SCTP-PF”的扩展为该方法添加了“潜在故障（PF）”路径的概念[RFC7829]。当一条路径处于PF状态时，SCTP不会完全放弃在该路径上发送数据，但如果其他活动路径可用，它最好在其他活动路径上发送数据。当超过配置的最大重传次数时，进入PF状态。因此，对于使用此机制的所有路径，有两个可配置的错误阈值：一个用于确定路径处于PF状态，另一个用于确定传输地址不可访问。
Set/Get Authentication Parameters: This allows an endpoint to add/ remove key material to/from an association. In addition, the chunk types being authenticated can be queried [RFC4895].
设置/获取身份验证参数：这允许端点向关联添加/删除密钥材料。此外，可以查询正在验证的区块类型[RFC4895]。
Add/Reset Streams, Reset Association: This allows an endpoint to add streams to an existing association or to reset them individually. Additionally, the association can be reset [RFC6525].
添加/重置流，重置关联：这允许端点将流添加到现有关联或单独重置流。此外，可以重置关联[RFC6525]。
Status: The 'Status' primitive returns a data block with information about a specified association, containing: an association connection state; a destination transport address list; destination transport address reachability states; current local and peer receiver window sizes; current local congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; a primary path; the most recent Smoothed Round-Trip Time (SRTT) on a primary path; RTO on a primary path; SRTT and RTO on other destination addresses [RFC4960]; and an MTU per path [RFC6458].
状态：“Status”原语返回一个数据块，其中包含指定关联的信息，包括：关联连接状态；目的地传输地址列表；目的地传输地址可达状态；当前本地和对等接收器窗口大小；当前本地拥塞窗口大小；未确认数据块的数量；待接收的数据块数；主要路径；主路径上最近的平滑往返时间（SRTT）；主路径上的RTO；其他目标地址上的SRTT和RTO[RFC4960]；以及每个路径的MTU[RFC6458]。
Enable/Disable Interleaving: This allows the negotiation of user message interleaving support for future associations to be enabled or disabled. For existing associations, it is possible to query whether user message interleaving support was negotiated or not on a particular association [RFC8260].
启用/禁用交织：这允许为将来的关联启用或禁用用户消息交织支持的协商。对于现有关联，可以查询特定关联上是否协商了用户消息交错支持[RFC8260]。
Set Stream Scheduler: This allows the ability to select a stream scheduler per association, with a choice of: First-Come, First-Served; Round-Robin; Round-Robin per Packet; Priority-Based; Fair Bandwidth; and Weighted Fair Queuing [RFC8260].
Set Stream Scheduler：这允许为每个关联选择一个流调度器，可以选择：先到先得；循环赛；每包循环；基于优先级；公平带宽；和加权公平排队[RFC8260]。
Configure Stream Scheduler: This allows the ability to change a parameter per stream for the schedulers: a priority value for the Priority-Based scheduler and a weight for the Weighted Fair Queuing scheduler.
配置流调度器：这允许为调度器更改每个流的参数：基于优先级的调度器的优先级值和加权公平队列调度器的权重。
Enable/Disable NoDelay: This turns on/off any Nagle-like algorithm for an association [RFC6458].
启用/禁用节点延迟：这将打开/关闭关联的任何类似Nagle的算法[RFC6458]。
Configure Send Buffer Size: This controls the amount of data SCTP may have waiting in internal buffers to be sent or retransmitted [RFC6458].
配置发送缓冲区大小：这控制SCTP在内部缓冲区中等待发送或重新传输的数据量[RFC6458]。
Configure Receive Buffer Size: This sets the receive buffer size in octets, thereby controlling the receiver window for an association [RFC6458].
配置接收缓冲区大小：以八位字节为单位设置接收缓冲区大小，从而控制关联的接收器窗口[RFC6458]。
Configure Message Fragmentation: If a user message causes an SCTP packet to exceed the maximum fragmentation size (which can be provided by the application and is otherwise the Path MTU (PMTU) size), then the message will be fragmented by SCTP. Disabling message fragmentation will produce an error instead of fragmenting the message [RFC6458].
配置消息分段：如果用户消息导致SCTP数据包超过最大分段大小（可由应用程序提供，否则为路径MTU（PMTU）大小），则消息将由SCTP分段。禁用消息分段将产生错误，而不是对消息进行分段[RFC6458]。
Configure Path MTU Discovery: Path MTU Discovery (PMTUD) can be enabled or disabled per peer address of an association (Section 8.1.12 of [RFC6458]). When it is enabled, the current Path MTU value can be obtained. When it is disabled, the Path MTU to be used can be controlled by the application.
配置路径MTU发现：可以根据关联的每个对等地址启用或禁用路径MTU发现（PMTUD）（RFC6458的第8.1.12节）。启用时，可以获得当前路径MTU值。禁用时，应用程序可以控制要使用的路径MTU。
Configure Delayed SACK Timer: The time before sending a SACK can be adjusted; delaying SACKs can be disabled; and the number of packets that must be received before a SACK is sent without waiting for the delay timer to expire can be configured [RFC6458].
配置延迟SACK定时器：可调整发送SACK前的时间；可禁用延迟袋；并且可以配置在发送SACK之前必须接收的数据包数量，而无需等待延迟计时器过期[RFC6458]。
Set Cookie Life Value: The cookie life value can be adjusted (Section 8.1.2 of [RFC6458]). 'Valid.Cookie.Life' is also one of the parameters that is potentially adjustable with 'SetProtocolParameters' [RFC4960].
设置Cookie寿命值：可以调整Cookie寿命值（RFC6458的第8.1.2节）。'Valid.Cookie.Life”也是可以通过“SetProtocolParameters”[RFC4960]进行调整的参数之一。
Set Maximum Burst: The maximum burst of packets that can be emitted by a particular association (default 4, and values above 4 are optional to implement) can be adjusted (Section 8.1.2 of [RFC6458]). 'Max.Burst' is also one of the parameters that is potentially adjustable with 'SetProtocolParameters' [RFC4960].
Set Maximum Burst（设置最大突发）：可以调整特定关联可以发出的数据包的最大突发（默认值为4，并且4以上的值是可选的），如[RFC6458]第8.1.2节所述“Max.Burst”也是可通过“SetProtocolParameters”[RFC4960]进行调整的参数之一。
Configure RTO Calculation: The abstract API contains the following adjustable parameters: 'RTO.Initial'; 'RTO.Min'; 'RTO.Max'; 'RTO.Alpha'; and 'RTO.Beta'. Only the initial, minimum and maximum RTOs are also described as configurable in the SCTP sockets API extensions [RFC6458].
配置RTO计算：抽象API包含以下可调参数：“RTO.Initial”；”RTO.Min'；'RTO.Max'；'RTO.Alpha′；和“RTO.Beta”。SCTP sockets API扩展[RFC6458]中还描述了只有初始、最小和最大RTO是可配置的。
Set DSCP Value: The DSCP value can be set per peer address of an association (Section 8.1.12 of [RFC6458]).
设置DSCP值：可以根据关联的对等地址设置DSCP值（RFC6458第8.1.12节）。
Set IPv6 Flow Label: The flow label field can be set per peer address of an association (Section 8.1.12 of [RFC6458]).
设置IPv6流标签：可以根据关联的对等地址设置流标签字段（RFC6458的第8.1.12节）。
Set Partial Delivery Point: This allows the ability to specify the size of a message where partial delivery will be invoked. Setting this to a lower value will cause partial deliveries to happen more often [RFC6458].
设置部分传递点：这允许指定调用部分传递的消息的大小。将此值设置为较低值将导致更频繁地发生部分交付[RFC6458]。
Communication Up Notification: When a lost communication to an endpoint is restored or when SCTP becomes ready to send or receive user messages, this notification informs the application process about the affected association, the type of event that has occurred, the complete set of sockets of the peer, the maximum number of allowed streams, and the inbound stream count (the number of streams the peer endpoint has requested). If interleaving is supported by both endpoints, this information is also included in this notification.
通信启动通知：当恢复到端点的丢失通信或SCTP准备好发送或接收用户消息时，此通知通知通知应用程序进程受影响的关联、已发生的事件类型、对等方的完整套接字集、允许的最大流数，以及入站流计数（对等端点已请求的流数）。如果两个端点都支持交织，则此通知中也会包含此信息。
Restart Notification: When SCTP has detected that the peer has restarted, this notification is passed to the upper layer [RFC6458].
重新启动通知：当SCTP检测到对等机已重新启动时，此通知将传递给上层[RFC6458]。
Data Arrive Notification: When a message is ready to be retrieved via the 'Receive' primitive, the application is informed by this notification.
数据到达通知：当消息准备好通过“接收”原语检索时，应用程序将收到此通知。
Send Failure Notification / Receive Unsent Message / Receive Unacknowledged Message: When a message cannot be delivered via an association, the sender can be informed about it and learn whether the message has just not been acknowledged or (e.g., in case of lifetime expiry) if it has not even been sent. This can also inform the sender that a part of the message has been successfully delivered.
发送失败通知/接收未发送的消息/接收未确认的消息：当消息无法通过关联传递时，可以通知发送方消息，并了解消息是否尚未确认，或者（例如，在生命周期到期的情况下）消息是否甚至未发送。这还可以通知发件人消息的一部分已成功传递。
Network Status Change Notification: This informs the application about a socket becoming active/inactive [RFC4960] or "Potentially Failed" [RFC7829].
网络状态更改通知：通知应用程序套接字变为活动/非活动状态[RFC4960]或“可能失败”[RFC7829]。
Communication Lost Notification: When SCTP loses communication to an endpoint (e.g., via heartbeats or excessive retransmission) or detects an abort, this notification informs the application process of the affected association and the type of event (failure OR termination in response to a shutdown or abort request).
通信丢失通知：当SCTP失去与端点的通信（例如，通过心跳或过度重传）或检测到中止时，此通知通知通知受影响关联的应用程序进程和事件类型（响应关机或中止请求而失败或终止）。
Shutdown Complete Notification: When SCTP completes the shutdown procedures, this notification is passed to the upper layer, informing it about the affected association.
Shutdown Complete Notification（关闭完成通知）：当SCTP完成关闭过程时，此通知将传递给上层，通知其受影响的关联。
Authentication Notification: When SCTP wants to notify the upper layer regarding the key management related to authenticated chunks [RFC4895], this notification is passed to the upper layer.
身份验证通知：当SCTP想要通知上层与身份验证区块相关的密钥管理[RFC4895]时，此通知将传递给上层。
Adaptation Layer Indication Notification: When SCTP completes the association setup and the peer provided an adaptation layer indication, this is passed to the upper layer [RFC5061] [RFC6458].
适配层指示通知：当SCTP完成关联设置且对等方提供适配层指示时，该通知将传递给上层[RFC5061][RFC6458]。
Stream Reset Notification: When SCTP completes the procedure for resetting streams [RFC6525], this notification is passed to the upper layer, informing it about the result.
流重置通知：当SCTP完成重置流的过程[RFC6525]时，此通知将传递给上层，通知其结果。
Association Reset Notification: When SCTP completes the association reset procedure [RFC6525], this notification is passed to the upper layer, informing it about the result.
关联重置通知：当SCTP完成关联重置过程[RFC6525]时，该通知将传递给上层，通知其结果。
Stream Change Notification: When SCTP completes the procedure used to increase the number of streams [RFC6525], this notification is passed to the upper layer, informing it about the result.
流更改通知：当SCTP完成用于增加流数量的过程[RFC6525]时，此通知将传递给上层，通知其结果。
Sender Dry Notification: When SCTP has no more user data to send or retransmit on a particular association, this notification is passed to the upper layer [RFC6458].
Sender Dry通知：当SCTP在特定关联上没有更多的用户数据要发送或重新传输时，此通知将传递给上层[RFC6458]。
Partial Delivery Aborted Notification: When a receiver has begun to receive parts of a user message but the delivery of this message is then aborted, this notification is passed to the upper layer (Section 6.1.7 of [RFC6458]).
部分传递中止通知：当接收者开始接收部分用户消息，但该消息的传递随后中止时，该通知将传递给上层（RFC6458第6.1.7节）。
The 'Receive' primitive can return certain additional information, but this is optional to implement and therefore not considered. With a 'Communication Lost' notification, some more information may optionally be passed to the application (e.g., identification to retrieve unsent and unacknowledged data). SCTP "can invoke" a 'Communication Error' notification and "may send" a 'Restart' notification, making these two notifications optional to implement. The list provided under 'Status' includes "etc.", indicating that more information could be provided. The primitive 'Get SRTT Report' returns information that is included in the information that 'Status' provides and is therefore not discussed. The 'Destroy SCTP Instance' API function was excluded: it erases the SCTP instance that was created by 'Initialize' but is not a primitive as defined in this document because it does not relate to a transport feature. The 'Shutdown' event informs an application that the peer has sent a SHUTDOWN, and hence no further data should be sent on this socket (Section 6.1 of [RFC6458]). However, if an application would try to send data on the socket, it would get an error message anyway; thus, this event is classified as "just affecting the application programming style, not how the underlying protocol operates" and is not included here.
“Receive”原语可以返回某些附加信息，但这是可选的，因此不考虑。通过“通信丢失”通知，可以选择向应用程序传递更多信息（例如，检索未发送和未确认数据的标识）。SCTP“可以调用”一个“通信错误”通知，“可以发送”一个“重新启动”通知，使这两个通知可以选择执行。“状态”下提供的列表包括“等”，表明可以提供更多信息。原语“Get SRTT Report”返回的信息包含在“Status”提供的信息中，因此不进行讨论。“Destroy SCTP Instance”API函数已被排除：它将删除由“Initialize”创建的SCTP实例，但它不是本文档中定义的原语，因为它与传输功能无关。“Shutdown”事件通知应用程序对等方已发送关机，因此不应在此套接字上发送进一步的数据（RFC6458的第6.1节）。但是，如果应用程序试图在套接字上发送数据，它无论如何都会收到错误消息；因此，此事件被归类为“仅影响应用程序编程风格，而非底层协议的运行方式”，此处不包括此事件。
The set of pass 1 primitives for UDP and UDP-Lite is documented in [RFC8304].
UDP和UDP Lite的pass 1原语集记录在[RFC8304]中。
The service of the LEDBAT congestion control mechanism is described as follows:
LEDBAT拥塞控制机制的服务描述如下：
LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows [RFC6817].
LEDBAT设计用于后台批量传输应用程序，其攻击性不超过标准TCP拥塞控制（如RFC 5681中所规定），并在存在竞争流时产生，从而限制对竞争流网络性能的干扰[RFC6817]。
LEDBAT does not have any primitives, as LEDBAT is not a transport protocol. According to its specification [RFC6817]:
LEDBAT没有任何原语，因为LEDBAT不是传输协议。根据其规范[RFC6817]：
LEDBAT can be used as part of a transport protocol or as part of an application, as long as the data transmission mechanisms are capable of carrying timestamps and acknowledging data frequently. LEDBAT can be used with TCP, Stream Control Transmission Protocol (SCTP), and Datagram Congestion Control Protocol (DCCP), with appropriate extensions where necessary; and it can be used with proprietary application protocols, such as those built on top of UDP for peer-to-peer (P2P) applications.
LEDBAT可以用作传输协议的一部分或应用程序的一部分，只要数据传输机制能够频繁地携带时间戳和确认数据。LEDBAT可与TCP、流控制传输协议（SCTP）和数据报拥塞控制协议（DCCP）一起使用，必要时可进行适当的扩展；它还可以与专有的应用程序协议一起使用，例如构建在UDP之上的对等（P2P）应用程序协议。
At the time of writing, the appropriate extensions for TCP, SCTP, or DCCP do not exist.
在编写本文时，TCP、SCTP或DCCP的适当扩展不存在。
A number of configurable parameters exist in the LEDBAT specification: TARGET, which is the queuing delay target at which LEDBAT tries to operate, must be set to 100 ms or less. 'allowed_increase' (should be 1, must be greater than 0) limits the speed at which LEDBAT increases its rate. 'gain', which according to [RFC6817] "MUST be set to 1 or less" to avoid a faster ramp-up than TCP Reno, determines how quickly the sender responds to changes in queueing delay. Implementations may divide 'gain' into two parameters: one for increase and a possibly larger one for decrease. We call these parameters 'Gain_Inc' and 'Gain_Dec' here. 'Base_History' is the size of the list of measured base delays, and, according to [RFC6817], "SHOULD be 10". This list can be filtered using a 'Filter' function, which is not prescribed [RFC6817], that yields a list of size 'Current_Filter'. The initial and minimum congestion windows, 'Init_CWND' and 'Min_CWND', should both be 2.
LEDBAT规范中存在许多可配置参数：TARGET（LEDBAT尝试运行的排队延迟目标）必须设置为100 ms或更小允许的_增加’（应为1，必须大于0）限制LEDBAT增加其速率的速度增益'，根据[RFC6817]“必须设置为1或更小”，以避免比TCP Reno更快的爬升，确定发送方响应排队延迟变化的速度。实现可能将“增益”分为两个参数：一个用于增加，一个可能更大的用于减少。我们在这里称这些参数为“增益Inc”和“增益Dec”Base_History’是测量的基本延迟列表的大小，根据[RFC6817]，“应该是10”。可以使用[RFC6817]中未规定的“Filter”函数对该列表进行过滤，该函数生成大小为“Current_Filter”的列表。初始和最小拥塞窗口“Init_CWND”和“Min_CWND”都应为2。
Regarding which of these parameters should be under control of an application, the possible range goes from exposing nothing on the one hand to considering everything that is not prescribed with a "MUST" in the specification as a parameter on the other hand. Function implementations are not provided as a parameter to any of the transport protocols discussed here; hence, we do not regard the
关于这些参数中的哪一个应该在应用程序的控制下，可能的范围从一方面不公开任何内容到另一方面考虑规范中没有“必须”作为参数规定的所有内容。函数实现不作为此处讨论的任何传输协议的参数提供；因此，我们不认为
'Filter' function as a parameter. However, to avoid unnecessarily limiting future implementations, we consider all other parameters above as tunable parameters that should be exposed.
“Filter”函数作为参数。然而，为了避免不必要地限制未来的实现，我们考虑上面所有其他参数作为可被暴露的可调参数。
This pass categorizes the primitives from pass 1 based on whether they relate to a connection or to data transmission. Primitives are presented following the nomenclature "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL". The CATEGORY can be CONNECTION or DATA. Within the CONNECTION category, ESTABLISHMENT, AVAILABILITY, MAINTENANCE, and TERMINATION subcategories can be considered. The DATA category does not have any SUBCATEGORY. The PROTOCOL name "UDP(-Lite)" is used when primitives are equivalent for UDP and UDP-Lite; the PROTOCOL name "TCP" refers to both TCP and MPTCP. We present "connection" as a general protocol-independent concept and use it to refer to, e.g., TCP connections (identifiable by a unique pair of IP addresses and TCP port numbers), SCTP associations (identifiable by multiple IP address and port number pairs), as well UDP and UDP-Lite connections (identifiable by a unique socket pair).
此过程根据过程1中的原语是与连接相关还是与数据传输相关对其进行分类。原语按照术语“CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL”表示。类别可以是连接或数据。在连接类别中，可以考虑建立、可用性、维护和终止子类别。数据类别没有任何子类别。协议名“UDP（-Lite）”用于UDP和UDP Lite的原语等效时；协议名称“TCP”同时指TCP和MPTCP。我们将“连接”作为一个与协议无关的通用概念提出，并使用它来指代，例如TCP连接（通过一对唯一的IP地址和TCP端口号进行标识）、SCTP关联（通过多个IP地址和端口号对进行标识）以及UDP和UDP Lite连接（通过一对唯一的套接字进行标识）。
Some minor details are omitted for the sake of generalization -- e.g., SCTP's 'Close' [RFC4960] returns success or failure and lets the application control whether further receive or send operations, or both, are disabled [RFC6458]. This is not described in the same way for TCP [RFC0793], but these details play no significant role for the primitives provided by either TCP or SCTP (for the sake of being generic, it could be assumed that both receive and send operations are disabled in both cases).
为了一般化，省略了一些次要细节——例如，SCTP的“关闭”[RFC4960]返回成功或失败，并让应用程序控制是否禁用了进一步的接收或发送操作，或同时禁用了这两种操作[RFC6458]。这与TCP[RFC0793]的描述方式不同，但这些细节对于TCP或SCTP提供的原语没有重要作用（为了通用，可以假设在这两种情况下都禁用了接收和发送操作）。
The TCP 'Send' and 'Receive' primitives include usage of an 'urgent' parameter. This parameter controls a mechanism that is required to implement the "synch signal" used by telnet [RFC0854], but [RFC6093] states that "new applications SHOULD NOT employ the TCP urgent mechanism." Because pass 2 is meant as a basis for the creation of future systems, the "urgent" mechanism is excluded. This also concerns the notification 'Urgent Pointer Advance' in the 'Error_Report' (Section 4.2.4.1 of [RFC1122]).
TCP“发送”和“接收”原语包括使用“紧急”参数。此参数控制实现telnet[RFC0854]使用的“同步信号”所需的机制，但[RFC6093]指出“新应用程序不应使用TCP紧急机制”。由于pass 2是创建未来系统的基础，因此“紧急”机制被排除在外。这还涉及“错误报告”（RFC1122第4.2.4.1节）中的“紧急指针前进”通知。
Since LEDBAT is a congestion control mechanism and not a protocol, it is not currently defined when to enable/disable or configure the mechanism. For instance, it could be a one-time choice upon connection establishment or when listening for incoming connections, in which case it should be categorized under CONNECTION.ESTABLISHMENT or CONNECTION.AVAILABILITY, respectively. To avoid unnecessarily
由于LEDBAT是一种拥塞控制机制，而不是一种协议，因此当前未定义何时启用/禁用或配置该机制。例如，在建立连接或侦听传入连接时，它可能是一次性的选择，在这种情况下，它应该分别归入connection.building或connection.AVAILABILITY。不必要地避免
limiting future implementations, it was decided to place it under CONNECTION.MAINTENANCE, with all parameters that are described in the specification [RFC6817] made configurable.
由于限制了未来的实现，决定将其置于CONNECTION.MAINTENANCE下，并配置规范[RFC6817]中描述的所有参数。
ESTABLISHMENT:
编制：
Active creation of a connection from one transport endpoint to one or more transport endpoints. Interfaces to UDP and UDP-Lite allow both connection-oriented and connection-less usage of the API [RFC8085].
主动创建从一个传输端点到一个或多个传输端点的连接。UDP和UDP Lite的接口允许API的面向连接和无连接使用[RFC8085]。
o CONNECT.TCP:
o CONNECT.TCP：
Pass 1 primitive/event: 'Open' (active) or 'Open' (passive) with socket, followed by 'Send'
传递1个原语/事件：“打开”（主动）或“打开”（被动）带套接字，后跟“发送”
Parameters: 1 local IP address (optional); 1 destination transport
address (for active open; else the socket and the local IP address
of the succeeding incoming connection request will be maintained);
timeout (optional); options (optional); MKT configuration
(optional); and user message (optional)
Parameters: 1 local IP address (optional); 1 destination transport
address (for active open; else the socket and the local IP address
of the succeeding incoming connection request will be maintained);
timeout (optional); options (optional); MKT configuration
(optional); and user message (optional)
Comments: if the local IP address is not provided, a default choice will automatically be made. The timeout can also be a retransmission count. The options are IP options to be used on all segments of the connection. At least the Source Route option is mandatory for TCP to provide. 'MKT configuration' refers to the ability to configure MKTs for authentication. The user message may be transmitted to the peer application immediately upon reception of the TCP SYN packet. To benefit from the lower latency this provides as part of the experimental TFO mechanism, its length must be at most the TCP's maximum segment size (minus TCP options used in the SYN). The message may also be delivered more than once to the application on the remote host.
备注：如果未提供本地IP地址，将自动进行默认选择。超时也可以是重传计数。这些选项是要在连接的所有段上使用的IP选项。至少TCP必须提供源路由选项。”“MKT配置”指配置MKTs进行身份验证的能力。用户消息可以在接收到TCP SYN分组后立即发送到对等应用程序。为了从作为实验性TFO机制的一部分提供的较低延迟中获益，其长度必须最多为TCP的最大段大小（减去SYN中使用的TCP选项）。消息也可能多次传递到远程主机上的应用程序。
o CONNECT.SCTP:
o CONNECT.SCTP：
Pass 1 primitive/event: 'Initialize', followed by 'Enable/Disable Interleaving' (optional), followed by 'Associate'
传递1原语/事件：“初始化”，后跟“启用/禁用交错”（可选），后跟“关联”
Parameters: list of local SCTP port number / IP address pairs
('Initialize'); one or several sockets (identifying the peer);
outbound stream count; maximum allowed inbound stream count;
adaptation layer indication (optional); chunk types required to be
authenticated (optional); request interleaving on/off; maximum
Parameters: list of local SCTP port number / IP address pairs
('Initialize'); one or several sockets (identifying the peer);
outbound stream count; maximum allowed inbound stream count;
adaptation layer indication (optional); chunk types required to be
authenticated (optional); request interleaving on/off; maximum
number of INIT attempts (optional); maximum init. RTO for INIT
(optional); user message (optional); and remote UDP port number
(optional)
number of INIT attempts (optional); maximum init. RTO for INIT
(optional); user message (optional); and remote UDP port number
(optional)
Returns: socket list or failure
返回：套接字列表或失败
Comments: 'Initialize' needs to be called only once per list of local SCTP port number / IP address pairs. One socket will automatically be chosen; it can later be changed in MAINTENANCE. The user message may be transmitted to the peer application immediately upon reception of the packet containing the COOKIE-ECHO chunk. To benefit from the lower latency this provides, its length must be limited such that it fits into the packet containing the COOKIE-ECHO chunk. If a remote UDP port number is provided, SCTP packets will be encapsulated in UDP.
注释：每个本地SCTP端口号/IP地址对列表只需调用一次“初始化”。将自动选择一个插座；以后可以在维护中对其进行更改。用户消息可以在接收到包含COOKIE-ECHO块的分组后立即发送到对等应用程序。为了受益于它提供的较低延迟，必须限制其长度，使其适合包含COOKIE-ECHO块的数据包。如果提供了远程UDP端口号，则SCTP数据包将封装在UDP中。
o CONNECT.MPTCP:
o CONNECT.MPTCP：
This is similar to CONNECT.TCP except for one additional boolean parameter that allows the ability to enable or disable MPTCP for a particular connection or socket (default: enabled).
这与CONNECT.TCP类似，只是有一个额外的布尔参数允许启用或禁用特定连接或套接字的MPTCP（默认值：enabled）。
o CONNECT.UDP(-Lite):
o CONNECT.UDP（-Lite）：
Pass 1 primitive/event: 'Connect' followed by 'Send'
传递1原语/事件：“连接”后跟“发送”
Parameters: 1 local IP address (default (ANY) or specified); 1 destination transport address; 1 local port (default (OS chooses) or specified); and 1 destination port (default (OS chooses) or specified).
参数：1本地IP地址（默认（任意）或指定）；1目的地传输地址；1个本地端口（默认（OS选择）或指定）；和1个目标端口（默认（OS选择）或指定）。
Comments: associates a transport address creating a UDP(-Lite) socket connection. This can be called again with a new transport address to create a new connection. The CONNECT function allows an application to receive errors from messages sent to a transport address.
注释：关联创建UDP（-Lite）套接字连接的传输地址。可以使用新的传输地址再次调用它以创建新连接。连接功能允许应用程序从发送到传输地址的消息中接收错误。
AVAILABILITY:
可利用性：
Preparing to receive incoming connection requests.
正在准备接收传入的连接请求。
o LISTEN.TCP:
o LISTEN.TCP：
Pass 1 primitive/event: 'Open' (passive)
传递1原语/事件：“打开”（被动）
Parameters: 1 local IP address (optional); 1 socket (optional);
timeout (optional); buffer to receive a user message (optional);
and MKT configuration (optional)
Parameters: 1 local IP address (optional); 1 socket (optional);
timeout (optional); buffer to receive a user message (optional);
and MKT configuration (optional)
Comments: if the socket and/or local IP address is provided, this waits for incoming connections from only and/or to only the provided address. Else this waits for incoming connections without this/these constraint(s). ESTABLISHMENT can later be performed with 'Send'. If a buffer is provided to receive a user message, a user message can be received from a TFO-enabled sender before the TCP's connection handshake is completed. This message may arrive multiple times. 'MKT configuration' refers to the ability to configure MKTs for authentication.
备注：如果提供了套接字和/或本地IP地址，则只等待来自和/或到所提供地址的传入连接。否则将等待没有此/这些约束的传入连接。稍后可使用“发送”执行建立。如果提供了缓冲区来接收用户消息，则可以在TCP连接握手完成之前从启用TFO的发送方接收用户消息。此消息可能会多次到达。”“MKT配置”指配置MKTs进行身份验证的能力。
o LISTEN.SCTP:
o LISTEN.SCTP：
Pass 1 primitive/event: 'Initialize', followed by the 'Communication Up' or 'Restart' notification and possibly the 'Adaptation Layer' notification
传递1原语/事件：“初始化”，然后是“通信启动”或“重启”通知，可能还有“适配层”通知
Parameters: list of local SCTP port number / IP address pairs (initialize)
参数：本地SCTP端口号/IP地址对列表（初始化）
Returns: socket list; outbound stream count; inbound stream count;
adaptation layer indication; chunks required to be authenticated;
and interleaving supported on both sides yes/no
Returns: socket list; outbound stream count; inbound stream count;
adaptation layer indication; chunks required to be authenticated;
and interleaving supported on both sides yes/no
Comments: 'Initialize' needs to be called only once per list of local SCTP port number / IP address pairs. 'Communication Up' can also follow a 'Communication Lost' notification, indicating that the lost communication is restored. If the peer has provided an adaptation layer indication, an 'Adaptation Layer' notification is issued.
注释：每个本地SCTP端口号/IP地址对列表只需调用一次“初始化”“通信启动”也可以在“通信丢失”通知之后，指示已恢复丢失的通信。如果对等方提供了适配层指示，则发出“适配层”通知。
o LISTEN.MPTCP:
o LISTEN.MPTCP：
This is similar to LISTEN.TCP except for one additional boolean parameter that allows the ability to enable or disable MPTCP for a particular connection or socket (default: enabled).
这与LISTEN.TCP类似，只是有一个额外的布尔参数允许启用或禁用特定连接或套接字的MPTCP（默认值：enabled）。
o LISTEN.UDP(-Lite):
o LISTEN.UDP（-Lite）：
Pass 1 primitive/event: 'Receive'
传递1原语/事件：“接收”
Parameters: 1 local IP address (default (ANY) or specified); 1 destination transport address; local port (default (OS chooses) or specified); and destination port (default (OS chooses) or specified)
参数：1本地IP地址（默认（任意）或指定）；1目的地传输地址；本地端口（默认（OS选择）或指定）；和目标端口（默认（OS选择）或指定）
Comments: the 'Receive' function registers the application to listen for incoming UDP(-Lite) datagrams at an endpoint.
注释：“Receive”函数注册应用程序以侦听端点处传入的UDP（-Lite）数据报。
MAINTENANCE:
维护：
Adjustments made to an open connection, or notifications about it. These are out-of-band messages to the protocol that can be issued at any time, at least after a connection has been established and before it has been terminated (with one exception: CHANGE_TIMEOUT.TCP can only be issued for an open connection when DATA.SEND.TCP is called). In some cases, these primitives can also be immediately issued during ESTABLISHMENT or AVAILABILITY, without waiting for the connection to be opened (e.g., CHANGE_TIMEOUT.TCP can be done using TCP's 'Open' primitive). For UDP and UDP-Lite, these functions may establish a setting per connection but may also be changed per datagram message.
对打开的连接所做的调整或通知。这些是到协议的带外消息，可以在任何时候发出，至少在连接建立之后和终止之前发出（只有一个例外：只有在调用DATA.SEND.TCP时，才能为打开的连接发出CHANGE_TIMEOUT.TCP）。在某些情况下，这些原语也可以在建立或可用期间立即发出，而无需等待连接打开（例如，更改超时。TCP可以使用TCP的“打开”原语完成）。对于UDP和UDP Lite，这些函数可以建立每个连接的设置，但也可以根据数据报消息进行更改。
o CHANGE_TIMEOUT.TCP:
o 更改\u TIMEOUT.TCP：
Pass 1 primitive/event: 'Open' or 'Send' combined with unspecified control of per-connection state variables
Pass 1原语/事件：“打开”或“发送”与每个连接状态变量的未指定控件组合
Parameters: timeout value (optional); adv_uto (optional); boolean
uto_enabled (optional, default false); and boolean changeable
(optional, default true)
Parameters: timeout value (optional); adv_uto (optional); boolean
uto_enabled (optional, default false); and boolean changeable
(optional, default true)
Comments: when sending data, an application can adjust the connection's timeout value (the time after which the connection will be aborted if data could not be delivered). If 'uto_enabled' is true, the 'timeout value' (or, if provided, the value 'adv_uto') will be advertised for the TCP on the other side of the connection to adapt its own user timeout accordingly. 'uto_enabled' controls whether the UTO option is enabled for a connection. This applies to both sending and receiving. 'changeable' controls whether the user timeout may be changed based on a UTO option received from the other end of the connection; it becomes false when the 'timeout value' is used.
Comments: when sending data, an application can adjust the connection's timeout value (the time after which the connection will be aborted if data could not be delivered). If 'uto_enabled' is true, the 'timeout value' (or, if provided, the value 'adv_uto') will be advertised for the TCP on the other side of the connection to adapt its own user timeout accordingly. 'uto_enabled' controls whether the UTO option is enabled for a connection. This applies to both sending and receiving. 'changeable' controls whether the user timeout may be changed based on a UTO option received from the other end of the connection; it becomes false when the 'timeout value' is used.translate error, please retry
o CHANGE_TIMEOUT.SCTP:
o 更改\u TIMEOUT.SCTP：
Pass 1 primitive/event: 'Change Heartbeat' combined with 'Configure Max. Retransmissions of an Association'
Pass 1原语/事件：“更改心跳”与“配置关联的最大重传”组合
Parameters: 'Change Heartbeat': heartbeat frequency and 'Configure Max. Retransmissions of an Association': Association.Max.Retrans
参数：“更改心跳”：心跳频率和“配置关联的最大重传”：Association.Max.Retrans
Comments: 'Change Heartbeat' can enable/disable heartbeats in SCTP as well as change their frequency. The parameter 'Association.Max.Retrans' defines after how many unsuccessful transmissions of any packets (including heartbeats) the
注释：“更改心跳”可以在SCTP中启用/禁用心跳，并更改其频率。参数“Association.Max.Retrans”定义了任何数据包（包括心跳）传输失败的次数
association will be terminated; thus, these two primitives/ parameters together can yield a similar behavior for SCTP associations as CHANGE_TIMEOUT.TCP does for TCP connections.
协会将被终止；因此，这两个原语/参数一起可以产生SCTP关联的类似行为，就像CHANGE_TIMEOUT.TCP对TCP连接的行为一样。
o DISABLE_NAGLE.TCP:
o 禁用_NAGLE.TCP：
Pass 1 primitive/event: not specified
传递1原语/事件：未指定
Parameters: one boolean value
参数：一个布尔值
Comments: the Nagle algorithm delays data transmission to increase the chance of sending a full-sized segment. An application must be able to disable this algorithm for a connection.
注释：Nagle算法延迟数据传输，以增加发送全尺寸段的机会。应用程序必须能够为连接禁用此算法。
o DISABLE_NAGLE.SCTP:
o 禁用_NAGLE.SCTP：
Pass 1 primitive/event: 'Enable/Disable NoDelay'
Pass 1 primitive/event: 'Enable/Disable NoDelay'
Parameters: one boolean value
参数：一个布尔值
Comments: Nagle-like algorithms delay data transmission to increase the chance of sending a full-sized packet.
注释：类似Nagle的算法延迟数据传输，以增加发送全尺寸数据包的机会。
o REQUEST_HEARTBEAT.SCTP:
o 请求\u HEARTBEAT.SCTP：
Pass 1 primitive/event: 'Request Heartbeat'
传递1原语/事件：“请求心跳”
Parameters: socket
参数：套接字
Returns: success or failure
回报：成功还是失败
Comments: requests an immediate heartbeat on a path, returning success or failure.
注释：请求路径上的即时心跳，返回成功或失败。
o ADD_PATH.MPTCP:
o 添加_PATH.MPTCP：
Pass 1 primitive/event: not specified
传递1原语/事件：未指定
Parameters: local IP address and optionally the local port number
参数：本地IP地址和可选的本地端口号
Comments: the application specifies the local IP address and port number that must be used for a new subflow.
注释：应用程序指定新子流必须使用的本地IP地址和端口号。
o ADD_PATH.SCTP:
o 添加_PATH.SCTP：
Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
Parameters: local IP address
参数：本地IP地址
o REM_PATH.MPTCP:
o REM_PATH.MPTCP：
Pass 1 primitive/event: not specified
传递1原语/事件：未指定
Parameters: local IP address; local port number; remote IP
address; and remote port number
Parameters: local IP address; local port number; remote IP
address; and remote port number
Comments: the application removes the subflow specified by the IP/ port-pair. The MPTCP implementation must trigger a removal of the subflow that belongs to this IP/port-pair.
注释：应用程序删除IP/端口对指定的子流。MPTCP实现必须触发删除属于此IP/端口对的子流。
o REM_PATH.SCTP:
o REM_PATH.SCTP：
Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
Parameters: local IP address
参数：本地IP地址
o SET_PRIMARY.SCTP:
o SET_PRIMARY.SCTP：
Pass 1 primitive/event: 'Set Primary'
传递1原语/事件：“设置主”
Parameters: socket
参数：套接字
Returns: result of attempting this operation
返回：尝试此操作的结果
Comments: update the current primary address to be used, based on the set of available sockets of the association.
注释：根据关联的可用套接字集更新要使用的当前主地址。
o SET_PEER_PRIMARY.SCTP:
o 设置\u PEER\u PRIMARY.SCTP：
Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
Parameters: local IP address
参数：本地IP地址
Comments: this is only advisory for the peer.
备注：这只是对同行的建议。
o CONFIG_SWITCHOVER.SCTP:
o CONFIG_SWITCHOVER.SCTP：
Pass 1 primitive/event: 'Configure Path Switchover'
传递1原语/事件：“配置路径切换”
Parameters: primary max retrans (number of retransmissions after which a path is considered inactive) and PF max retrans (number of retransmissions after which a path is considered to be "Potentially Failed", and others will be preferably used) (optional)
参数：主最大重传次数（重传次数，在此之后路径被视为不活动）和PF最大重传次数（重传次数，在此之后路径被视为“潜在失败”，其他次数将优先使用）（可选）
o STATUS.SCTP:
o STATUS.SCTP：
Pass 1 primitive/event: 'Status', 'Enable/Disable Interleaving', and 'Network Status Change' notification
传递1原语/事件：“状态”、“启用/禁用交织”和“网络状态更改”通知
Returns: data block with information about a specified
association, containing: association connection state; destination
transport address list; destination transport address reachability
states; current local and peer receiver window sizes; current
local congestion window sizes; number of unacknowledged DATA
chunks; number of DATA chunks pending receipt; primary path; most
recent SRTT on primary path; RTO on primary path; SRTT and RTO on
other destination addresses; MTU per path; and interleaving
supported yes/no
Returns: data block with information about a specified
association, containing: association connection state; destination
transport address list; destination transport address reachability
states; current local and peer receiver window sizes; current
local congestion window sizes; number of unacknowledged DATA
chunks; number of DATA chunks pending receipt; primary path; most
recent SRTT on primary path; RTO on primary path; SRTT and RTO on
other destination addresses; MTU per path; and interleaving
supported yes/no
Comments: the 'Network Status Change' notification informs the application about a socket becoming active/inactive; this only affects the programming style, as the same information is also available via 'Status'.
备注：“网络状态更改”通知通知应用程序套接字变为活动/非活动状态；这只会影响编程风格，因为同样的信息也可以通过“状态”获得。
o STATUS.MPTCP:
o STATUS.MPTCP：
Pass 1 primitive/event: not specified
传递1原语/事件：未指定
Returns: list of pairs of tuples of IP address and TCP port number of each subflow. The first of the pair is the local IP and port number, while the second is the remote IP and port number.
返回：每个子流的IP地址和TCP端口号的元组对列表。第一对是本地IP和端口号，第二对是远程IP和端口号。
o SET_DSCP.TCP:
o SET_DSCP.TCP：
Pass 1 primitive/event: not specified
传递1原语/事件：未指定
Parameters: DSCP value
参数：DSCP值
Comments: this allows an application to change the DSCP value for outgoing segments.
注释：这允许应用程序更改传出段的DSCP值。
o SET_DSCP.SCTP:
o SET_DSCP.SCTP：
Pass 1 primitive/event: 'Set DSCP value'
传递1原语/事件：“设置DSCP值”
Parameters: DSCP value
参数：DSCP值
Comments: this allows an application to change the DSCP value for outgoing packets on a path.
注释：这允许应用程序更改路径上传出数据包的DSCP值。
o SET_DSCP.UDP(-Lite):
o SET_DSCP.UDP（-Lite）：
Pass 1 primitive/event: 'Set_DSCP'
传递1原语/事件：“设置\u DSCP”
Parameter: DSCP value
参数：DSCP值
Comments: this allows an application to change the DSCP value for outgoing UDP(-Lite) datagrams. [RFC7657] and [RFC8085] provide current guidance on using this value with UDP.
注释：这允许应用程序更改传出UDP（-Lite）数据报的DSCP值。[RFC7657]和[RFC8085]提供了有关在UDP中使用此值的当前指导。
o ERROR.TCP:
o ERROR.TCP：
Pass 1 primitive/event: 'Error_Report'
传递1原语/事件：“错误报告”
Returns: reason (encoding not specified) and subreason (encoding not specified)
返回：原因（未指定编码）和子原因（未指定编码）
Comments: soft errors that can be ignored without harm by many applications; an application should be able to disable these notifications. The reported conditions include at least: ICMP error message arrived and excessive retransmissions.
注释：许多应用程序可以忽略而不造成伤害的软错误；应用程序应该能够禁用这些通知。报告的情况至少包括：ICMP错误消息到达和过度重传。
o ERROR.UDP(-Lite):
o 错误。UDP（-Lite）：
Pass 1 primitive/event: 'Error_Report'
传递1原语/事件：“错误报告”
Returns: Error report
返回：错误报告
Comments: this returns soft errors that may be ignored without harm by many applications; an application must connect to be able receive these notifications.
注释：这会返回软错误，许多应用程序可能会忽略这些错误而不造成损害；应用程序必须连接才能接收这些通知。
o SET_AUTH.TCP:
o SET_AUTH.TCP：
Pass 1 primitive/event: not specified
传递1原语/事件：未指定
Parameters: current_key and rnext_key
参数：当前_键和rnext_键
Comments: current_key and rnext_key are the preferred outgoing MKT and the preferred incoming MKT, respectively, for a segment that is sent on the connection.
注释：对于在连接上发送的段，当前_键和rnext_键分别是首选的传出MKT和首选的传入MKT。
o SET_AUTH.SCTP:
o SET_AUTH.SCTP：
Pass 1 primitive/event: 'Set/Get Authentication Parameters'
Pass 1 primitive/event: 'Set/Get Authentication Parameters'
Parameters: key_id; key; and hmac_id
Parameters: key_id; key; and hmac_id
o GET_AUTH.TCP:
o 获取\u AUTH.TCP：
Pass 1 primitive/event: not specified
传递1原语/事件：未指定
Parameters: current_key and rnext_key
参数：当前_键和rnext_键
Comments: current_key and rnext_key are the preferred outgoing MKT and the preferred incoming MKT, respectively, that were carried on a recently received segment.
备注：当前_键和rnext_键分别是首选的传出MKT和首选的传入MKT，它们是在最近接收到的段上进行的。
o GET_AUTH.SCTP:
o 获取_AUTH.SCTP：
Pass 1 primitive/event: 'Set/Get Authentication Parameters'
Pass 1 primitive/event: 'Set/Get Authentication Parameters'
Parameters: key_id and chunk_list
参数：key\u id和chunk\u list
o RESET_STREAM.SCTP:
o 重置\u STREAM.SCTP：
Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
Parameters: sid and direction
参数：sid和方向
o RESET_STREAM-EVENT.SCTP:
o 重置\u STREAM-EVENT.SCTP：
Pass 1 primitive/event: 'Stream Reset' notification
传递1原语/事件：“流重置”通知
Parameters: information about the result of RESET_STREAM.SCTP
参数：关于RESET_STREAM.SCTP结果的信息
Comments: this is issued when the procedure for resetting streams has completed.
备注：当重置流的程序完成时，会发出此消息。
o RESET_ASSOC.SCTP:
o 重置关联SCTP：
Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
Parameters: information related to the extension, as defined in [RFC3260]
参数：与[RFC3260]中定义的扩展相关的信息
o RESET_ASSOC-EVENT.SCTP:
o 重置\u ASSOC-EVENT.SCTP：
Pass 1 primitive/event: 'Association Reset' notification
传递1原语/事件：“关联重置”通知
Parameters: information about the result of RESET_ASSOC.SCTP
参数：关于RESET_ASSOC.SCTP结果的信息
Comments: this is issued when the procedure for resetting an association has completed.
备注：当重置关联的过程完成时发出此消息。
o ADD_STREAM.SCTP:
o 添加_STREAM.SCTP：
Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
Parameters: number of outgoing and incoming streams to be added
参数：要添加的传出流和传入流的数量
o ADD_STREAM-EVENT.SCTP:
o 添加\u STREAM-EVENT.SCTP：
Pass 1 primitive/event: 'Stream Change' notification
传递1原语/事件：“流更改”通知
Parameters: information about the result of ADD_STREAM.SCTP
参数：关于ADD_STREAM.SCTP结果的信息
Comments: this is issued when the procedure for adding a stream has completed.
备注：当添加流的过程完成时发出此消息。
o SET_STREAM_SCHEDULER.SCTP:
o SET_STREAM_SCHEDULER.SCTP：
Pass 1 primitive/event: 'Set Stream Scheduler'
传递1原语/事件：“设置流计划程序”
Parameters: scheduler identifier
参数：调度程序标识符
Comments: choice of First-Come, First-Served; Round-Robin; Round-Robin per Packet; Priority-Based; Fair Bandwidth; and Weighted Fair Queuing.
备注：选择先到先得；循环赛；每包循环；基于优先级；公平带宽；加权公平排队。
o CONFIGURE_STREAM_SCHEDULER.SCTP:
o 配置\u STREAM\u SCHEDULER.SCTP：
Pass 1 primitive/event: 'Configure Stream Scheduler'
传递1原语/事件：“配置流计划程序”
Parameters: priority
参数：优先级
Comments: the priority value only applies when Priority-Based or Weighted Fair Queuing scheduling is chosen with SET_STREAM_SCHEDULER.SCTP. The meaning of the parameter differs between these two schedulers, but in both cases, it realizes some form of prioritization regarding how bandwidth is divided among streams.
备注：仅当使用SET_STREAM_SCHEDULER.SCTP选择基于优先级或加权公平队列调度时，优先级值才适用。参数的含义在这两个调度器之间有所不同，但在这两种情况下，它都实现了某种形式的优先级划分，即如何在流之间分配带宽。
o SET_FLOWLABEL.SCTP:
o SET_FLOWLABEL.SCTP：
Pass 1 primitive/event: 'Set IPv6 Flow Label'
传递1原语/事件：“设置IPv6流标签”
Parameters: flow label
参数：流标签
Comments: this allows an application to change the IPv6 header's flow label field for outgoing packets on a path.
备注：这允许应用程序为路径上的传出数据包更改IPv6标头的流标签字段。
o AUTHENTICATION_NOTIFICATION-EVENT.SCTP:
o 身份验证通知-EVENT.SCTP：
Pass 1 primitive/event: 'Authentication' notification
传递1原语/事件：“身份验证”通知
Returns: information regarding key management
返回：有关密钥管理的信息
o CONFIG_SEND_BUFFER.SCTP:
o CONFIG_SEND_BUFFER.SCTP：
Pass 1 primitive/event: 'Configure Send Buffer Size'
传递1原语/事件：“配置发送缓冲区大小”
Parameters: size value in octets
参数：大小值（以八位字节为单位）
o CONFIG_RECEIVE_BUFFER.SCTP:
o CONFIG_RECEIVE_BUFFER.SCTP：
Pass 1 primitive/event: 'Configure Receive Buffer Size'
传递1原语/事件：“配置接收缓冲区大小”
Parameters: size value in octets
参数：大小值（以八位字节为单位）
Comments: this controls the receiver window.
注释：这控制接收器窗口。
o CONFIG_FRAGMENTATION.SCTP:
o CONFIG_FRAGMENTATION.SCTP：
Pass 1 primitive/event: 'Configure Message Fragmentation'
传递1原语/事件：“配置消息碎片”
Parameters: one boolean value (enable/disable) and maximum
fragmentation size (optional; default: PMTU)
Parameters: one boolean value (enable/disable) and maximum
fragmentation size (optional; default: PMTU)
Comments: if fragmentation is enabled, messages exceeding the maximum fragmentation size will be fragmented. If fragmentation is disabled, trying to send a message that exceeds the maximum fragmentation size will produce an error.
备注：如果启用了分段，则超过最大分段大小的邮件将被分段。如果禁用碎片，尝试发送超过最大碎片大小的消息将产生错误。
o CONFIG_PMTUD.SCTP:
o CONFIG_PMTUD.SCTP：
Pass 1 primitive/event: 'Configure Path MTU Discovery'
传递1原语/事件：“配置路径MTU发现”
Parameters: one boolean value (PMTUD on/off) and PMTU value (optional)
参数：一个布尔值（PMTUD开/关）和PMTU值（可选）
Returns: PMTU value
返回：PMTU值
Comments: this returns a meaningful PMTU value when PMTUD is enabled (the boolean is true), and the PMTU value can be set if PMTUD is disabled (the boolean is false).
备注：启用PMTUD（布尔值为true）时，返回有意义的PMTU值；禁用PMTUD（布尔值为false）时，可以设置PMTU值。
o CONFIG_DELAYED_SACK.SCTP:
o CONFIG_DELAYED_SACK.SCTP：
Pass 1 primitive/event: 'Configure Delayed SACK Timer'
传递1原语/事件：“配置延迟SACK计时器”
Parameters: one boolean value (delayed SACK on/off); timer value
(optional); and number of packets to wait for (default 2)
Parameters: one boolean value (delayed SACK on/off); timer value
(optional); and number of packets to wait for (default 2)
Comments: if delayed SACK is enabled, SCTP will send a SACK either upon receiving the provided number of packets or when the timer expires, whatever occurs first.
备注：如果启用了延迟SACK，SCTP将在收到提供的数据包数或计时器过期时发送SACK，无论先发生什么。
o CONFIG_RTO.SCTP:
o CONFIG_RTO.SCTP：
Pass 1 primitive/event: 'Configure RTO Calculation'
传递1原语/事件：“配置RTO计算”
Parameters: init (optional); min (optional); and max (optional)
Parameters: init (optional); min (optional); and max (optional)
Comments: this adjusts the initial, minimum, and maximum RTO values.
备注：这将调整初始、最小和最大RTO值。
o SET_COOKIE_LIFE.SCTP:
o 设置\u COOKIE\u LIFE.SCTP：
Pass 1 primitive/event: 'Set Cookie Life Value'
传递1原语/事件：“设置Cookie寿命值”
Parameters: cookie life value
参数：cookie寿命值
o SET_MAX_BURST.SCTP:
o 设置\u MAX\u BURST.SCTP：
Pass 1 primitive/event: 'Set Maximum Burst'
传递1原语/事件：“设置最大突发”
Parameters: max burst value
参数：最大突发值
Comments: not all implementations allow values above the default of 4.
注释：并非所有实现都允许值高于默认值4。
o SET_PARTIAL_DELIVERY_POINT.SCTP:
o 设置部分交付点。SCTP：
Pass 1 primitive/event: 'Set Partial Delivery Point'
传递1原语/事件：“设置部分传递点”
Parameters: partial delivery point (integer)
参数：部分交货点（整数）
Comments: this parameter must be smaller or equal to the socket receive buffer size.
注释：此参数必须小于或等于套接字接收缓冲区大小。
o SET_CHECKSUM_ENABLED.UDP:
o SET_CHECKSUM_ENABLED.UDP:
Pass 1 primitive/event: 'Checksum_Enabled'
传递1原语/事件：“已启用校验和”
Parameters: 0 when zero checksum is used at sender, 1 for checksum at sender (default)
参数：发送方使用零校验和时为0，发送方使用校验和时为1（默认值）
o SET_CHECKSUM_REQUIRED.UDP:
o SET_CHECKSUM_REQUIRED.UDP:
Pass 1 primitive/event: 'Require_Checksum'
传递1原语/事件：“需要校验和”
Parameter: 0 to allow zero checksum, 1 when a non-zero checksum is required (default) at the receiver
参数：0允许零校验和，当接收器需要非零校验和（默认）时为1
o SET_CHECKSUM_COVERAGE.UDP-Lite:
o 设置校验和覆盖率。UDP-Lite：
Pass 1 primitive/event: 'Set_Checksum_Coverage'
传递1原语/事件：“设置校验和覆盖”
Parameters: coverage length at sender (default maximum coverage)
参数：发件人的覆盖范围长度（默认最大覆盖范围）
o SET_MIN_CHECKSUM_COVERAGE.UDP-Lite:
o 设置\u最小\u校验和\u覆盖率。UDP-Lite：
Pass 1 primitive/event: 'Set_Min_Coverage'
传递1原语/事件：“设置最小覆盖率”
Parameter: coverage length at receiver (default minimum coverage)
参数：接收器的覆盖长度（默认最小覆盖）
o SET_DF.UDP(-Lite):
o SET_DF.UDP（-Lite）：
Pass 1 primitive event: 'Set_DF'
Pass 1基本事件：“Set_DF”
Parameter: 0 when DF is not set (default) in the IPv4 header, 1 when DF is set
参数：IPv4标头中未设置DF时为0（默认值），设置DF时为1
o GET_MMS_S.UDP(-Lite):
o 获取MMS.UDP（-Lite）：
Pass 1 primitive event: 'Get_MM_S'
Pass 1基本事件：“Get_MM_S”
Comments: this retrieves the maximum transport-message size that may be sent using a non-fragmented IP packet from the configured interface.
注释：这将从配置的接口检索可能使用非分段IP数据包发送的最大传输消息大小。
o GET_MMS_R.UDP(-Lite):
o 获取\u MMS\u R.UDP（-Lite）：
Pass 1 primitive event: 'Get_MMS_R'
传递1个基本事件：“获取彩信”
Comments: this retrieves the maximum transport-message size that may be received from the configured interface.
注释：这将检索可能从配置的接口接收的最大传输消息大小。
o SET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):
o 设置TTL.UDP（-Lite）（IPV6单播跳数）：
Pass 1 primitive/event: 'Set_TTL' and 'Set_IPV6_Unicast_Hops'
传递1原语/事件：“设置TTL”和“设置IPV6单播跃点”
Parameters: IPv4 TTL value or IPv6 Hop Count value
参数：IPv4 TTL值或IPv6跃点计数值
Comments: this allows an application to change the IPv4 TTL of IPv6 Hop Count value for outgoing UDP(-Lite) datagrams.
备注：这允许应用程序更改传出UDP（-Lite）数据报的IPv6跃点的IPv4 TTL计数值。
o GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):
o 获取TTL.UDP（-Lite）（IPV6单播跳数）：
Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'
传递1原语/事件：“获取TTL”和“获取IPV6单播跃点”
Returns: IPv4 TTL value or IPv6 Hop Count value
返回：IPv4 TTL值或IPv6跃点计数值
Comments: this allows an application to read the IPv4 TTL of the IPv6 Hop Count value from a received UDP(-Lite) datagram.
注释：这允许应用程序从接收的UDP（-Lite）数据报读取IPv6跃点计数值的IPv4 TTL。
o SET_ECN.UDP(-Lite):
o SET_ECN.UDP（-Lite）：
Pass 1 primitive/event: 'Set_ECN'
传递1原语/事件：“Set\u ECN”
Parameters: ECN value
参数：ECN值
Comments: this allows a UDP(-Lite) application to set the Explicit Congestion Notification (ECN) code point field for outgoing UDP(-Lite) datagrams. It defaults to sending '00'.
注释：这允许UDP（-Lite）应用程序为传出UDP（-Lite）数据报设置显式拥塞通知（ECN）代码点字段。它默认为发送“00”。
o GET_ECN.UDP(-Lite):
o 获取\u ECN.UDP（-Lite）：
Pass 1 primitive/event: 'Get_ECN'
传递1原语/事件：“Get_ECN”
Parameters: ECN value
参数：ECN值
Comments: this allows a UDP(-Lite) application to read the ECN code point field from a received UDP(-Lite) datagram.
注释：这允许UDP（-Lite）应用程序从收到的UDP（-Lite）数据报读取ECN代码点字段。
o SET_IP_OPTIONS.UDP(-Lite):
o 设置IP选项。UDP（-Lite）：
Pass 1 primitive/event: 'Set_IP_Options'
传递1原语/事件：“设置IP选项”
Parameters: options
参数：选项
Comments: this allows a UDP(-Lite) application to set IP options for outgoing UDP(-Lite) datagrams. These options can at least be the Source Route, Record Route, and Timestamp option.
注释：这允许UDP（-Lite）应用程序为传出UDP（-Lite）数据报设置IP选项。这些选项至少可以是源路由、记录路由和时间戳选项。
o GET_IP_OPTIONS.UDP(-Lite):
o 获取IP选项。UDP（-Lite）：
Pass 1 primitive/event: 'Get_IP_Options'
传递1原语/事件：“获取IP选项”
Returns: options
返回：选项
Comments: this allows a UDP(-Lite) application to receive any IP options that are contained in a received UDP(-Lite) datagram.
注释：这允许UDP（-Lite）应用程序接收接收到的UDP（-Lite）数据报中包含的任何IP选项。
o CONFIGURE.LEDBAT:
o CONFIGURE.LEDBAT：
Pass 1 primitive/event: N/A
Pass 1 primitive/event: N/A
Parameters: enable (boolean); target; allowed_increase; gain_inc;
gain_dec; base_history; current_filter; init_cwnd; and min_cwnd
Parameters: enable (boolean); target; allowed_increase; gain_inc;
gain_dec; base_history; current_filter; init_cwnd; and min_cwnd
Comments: 'enable' is a newly invented parameter that enables or disables the whole LEDBAT service.
注释：“enable”是一个新发明的参数，用于启用或禁用整个LEDBAT服务。
TERMINATION:
终止：
Gracefully or forcefully closing a connection or being informed about this event happening.
优雅地或有力地关闭一个连接或被告知此事件的发生。
o CLOSE.TCP:
o CLOSE.TCP：
Pass 1 primitive/event: 'Close'
传递1原语/事件：“关闭”
Comments: this terminates the sending side of a connection after reliably delivering all remaining data.
备注：这将在可靠地传递所有剩余数据后终止连接的发送端。
o CLOSE.SCTP:
o CLOSE.SCTP：
Pass 1 primitive/event: 'Shutdown'
传递1原语/事件：“关机”
Comments: this terminates a connection after reliably delivering all remaining data.
备注：这将在可靠地传递所有剩余数据后终止连接。
o ABORT.TCP:
o ABORT.TCP：
Pass 1 primitive/event: 'Abort'
传递1原语/事件：“中止”
Comments: this terminates a connection without delivering remaining data and sends an error message to the other side.
注释：这会终止连接而不传递剩余数据，并向另一端发送错误消息。
o ABORT.SCTP:
o ABORT.SCTP：
Pass 1 primitive/event: 'Abort'
传递1原语/事件：“中止”
Parameters: abort reason to be given to the peer (optional)
参数：给对等方的中止原因（可选）
Comments: this terminates a connection without delivering remaining data and sends an error message to the other side.
注释：这会终止连接而不传递剩余数据，并向另一端发送错误消息。
o ABORT.UDP(-Lite):
o 中止.UDP（-Lite）：
Pass 1 primitive event: 'Close'
传递1基本事件：“关闭”
Comments: this terminates a connection without delivering remaining data. No further UDP(-Lite) datagrams are sent/received for this transport service instance.
注释：这将终止连接，而不传递剩余数据。此传输服务实例不再发送/接收其他UDP（-Lite）数据报。
o TIMEOUT.TCP:
o TIMEOUT.TCP：
Pass 1 primitive/event: 'User Timeout' event
传递1原语/事件：“用户超时”事件
Comments: the application is informed that the connection is aborted. This event is executed on expiration of the timeout set in CONNECTION.ESTABLISHMENT.CONNECT.TCP (possibly adjusted in CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP).
注释：通知应用程序连接已中止。此事件在CONNECTION.Establish.CONNECT.TCP中设置的超时过期时执行（可能在CONNECTION.MAINTENANCE.CHANGE\u timeout.TCP中进行了调整）。
o TIMEOUT.SCTP:
o TIMEOUT.SCTP：
Pass 1 primitive/event: 'Communication Lost' event
传递1原语/事件：“通信丢失”事件
Comments: the application is informed that the connection is aborted. This event is executed on expiration of the timeout that should be enabled by default (see the beginning of Section 8.3 in [RFC4960]) and was possibly adjusted in CONNECTION.MAINTENANCE.CHANGE_TIMEOOUT.SCTP.
注释：通知应用程序连接已中止。此事件在默认情况下应启用的超时过期时执行（请参阅[RFC4960]中第8.3节的开头），并可能在CONNECTION.MAINTENANCE.CHANGE\u TIMEOOUT.SCTP中进行了调整。
o ABORT-EVENT.TCP:
o ABORT-EVENT.TCP：
Pass 1 primitive/event: not specified
传递1原语/事件：未指定
o ABORT-EVENT.SCTP:
o ABORT-EVENT.SCTP：
Pass 1 primitive/event: 'Communication Lost' event
传递1原语/事件：“通信丢失”事件
Returns: abort reason from the peer (if available)
返回：来自对等方的中止原因（如果可用）
Comments: the application is informed that the other side has aborted the connection using CONNECTION.TERMINATION.ABORT.SCTP.
注释：应用程序被告知另一方已使用connection.TERMINATION.ABORT.SCTP中止连接。
o CLOSE-EVENT.TCP:
o CLOSE-EVENT.TCP：
Pass 1 primitive/event: not specified
传递1原语/事件：未指定
o CLOSE-EVENT.SCTP:
o CLOSE-EVENT.SCTP：
Pass 1 primitive/event: 'Shutdown Complete' event
传递1原语/事件：“关机完成”事件
Comments: the application is informed that CONNECTION.TERMINATION.CLOSE.SCTP was successfully completed.
备注：通知应用程序CONNECTION.TERMINATION.CLOSE.SCTP已成功完成。
All primitives in this section refer to an existing connection, i.e., a connection that was either established or made available for receiving data (although this is optional for the primitives of UDP(-Lite)). In addition to the listed parameters, all sending primitives contain a reference to a data block, and all receiving primitives contain a reference to available buffer space for the data. Note that CONNECT.TCP and LISTEN.TCP in the ESTABLISHMENT and AVAILABILITY categories also allow to transfer data (an optional user message) before the connection is fully established.
本节中的所有原语均指现有连接，即已建立或可用于接收数据的连接（尽管这对于UDP（-Lite）原语是可选的）。除了列出的参数外，所有发送原语都包含对数据块的引用，所有接收原语都包含对数据可用缓冲区空间的引用。请注意，“建立”和“可用性”类别中的CONNECT.TCP和LISTEN.TCP还允许在完全建立连接之前传输数据（可选用户消息）。
o SEND.TCP:
o SEND.TCP：
Pass 1 primitive/event: 'Send'
传递1原语/事件：“发送”
Parameters: timeout (optional); current_key (optional); and rnext_key (optional)
参数：超时（可选）；当前_键（可选）；和rnext_键（可选）
Comments: this gives TCP a data block for reliable transmission to the TCP on the other side of the connection. The timeout can be configured with this call (see also CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP). 'current_key' and 'rnext_key' are authentication parameters that can be configured with this call (see also CONNECTION.MAINTENANCE.SET_AUTH.TCP).
注释：这为TCP提供了一个数据块，用于可靠地传输到连接另一端的TCP。可以通过此调用配置超时（另请参阅CONNECTION.MAINTENANCE.CHANGE\u timeout.TCP）“当前_密钥”和“rnext_密钥”是可通过此调用配置的身份验证参数（另请参阅CONNECTION.MAINTENANCE.SET_AUTH.TCP）。
o SEND.SCTP:
o SEND.SCTP：
Pass 1 primitive/event: 'Send'
传递1原语/事件：“发送”
Parameters: stream number; context (optional); socket (optional);
unordered flag (optional); no-bundle flag (optional); payload
protocol-id (optional); pr-policy (optional) pr-value (optional);
sack-immediately flag (optional); and key-id (optional)
Parameters: stream number; context (optional); socket (optional);
unordered flag (optional); no-bundle flag (optional); payload
protocol-id (optional); pr-policy (optional) pr-value (optional);
sack-immediately flag (optional); and key-id (optional)
Comments: this gives SCTP a data block for transmission to the SCTP on the other side of the connection (SCTP association). The 'stream number' denotes the stream to be used. The 'context' number can later be used to refer to the correct message when an error is reported. The 'socket' can be used to state which path should be preferred, if there are multiple paths available (see also CONNECTION.MAINTENANCE.SETPRIMARY.SCTP). The data block can be delivered out of order if the 'unordered' flag is set. The 'no-bundle flag' can be set to indicate a preference to avoid bundling. The 'payload protocol-id' is a number that will, if provided, be handed over to the receiving application. Using pr-policy and pr-value, the level of reliability can be controlled. The 'sack-immediately' flag can be used to indicate
注释：这为SCTP提供了一个数据块，用于传输到连接另一侧的SCTP（SCTP关联）。“流编号”表示要使用的流。“上下文”编号可在以后报告错误时用于引用正确的消息。如果有多条路径可用，“套接字”可用于说明首选路径（另请参见CONNECTION.MAINTENANCE.SETPRIMARY.SCTP）。如果设置了“无序”标志，则数据块可能会无序交付。可以设置“无捆绑标志”以指示避免捆绑的首选项。“有效负载协议id”是一个数字，如果提供，将移交给接收应用程序。使用pr策略和pr值，可以控制可靠性水平。“立即解雇”标志可用于指示
that the peer should not delay the sending of a SACK corresponding to the provided user message. If specified, the provided key-id is used for authenticating the user message.
对等方不应延迟发送与所提供的用户消息相对应的SACK。如果指定，则提供的密钥id用于验证用户消息。
o SEND.UDP(-Lite):
o SEND.UDP（-Lite）：
Pass 1 primitive/event: 'Send'
传递1原语/事件：“发送”
Parameters: IP address and port number of the destination endpoint (optional if connected)
参数：目标端点的IP地址和端口号（如果已连接，则可选）
Comments: this provides a message for unreliable transmission using UDP(-Lite) to the specified transport address. The IP address and port number may be omitted for connected UDP(-Lite) sockets. All CONNECTION.MAINTENANCE.SET_*.UDP(-Lite) primitives apply per message sent.
注释：这提供了一条使用UDP（-Lite）到指定传输地址的不可靠传输消息。对于已连接的UDP（-Lite）套接字，可以省略IP地址和端口号。所有CONNECTION.MAINTENANCE.SET.*.UDP（-Lite）原语适用于发送的每条消息。
o RECEIVE.TCP:
o RECEIVE.TCP：
Pass 1 primitive/event: 'Receive'
传递1原语/事件：“接收”
Parameters: current_key (optional) and rnext_key (optional)
参数：当前_键（可选）和rnext_键（可选）
Comments: 'current_key' and 'rnext_key' are authentication parameters that can be read with this call (see also CONNECTION.MAINTENANCE.GET_AUTH.TCP).
注释：“current_key”和“rnext_key”是可通过此调用读取的身份验证参数（另请参阅CONNECTION.MAINTENANCE.GET_AUTH.TCP）。
o RECEIVE.SCTP:
o RECEIVE.SCTP：
Pass 1 primitive/event: 'Data Arrive' notification, followed by 'Receive'
传递1原语/事件：“数据到达”通知，后跟“接收”
Parameters: stream number (optional)
参数：流编号（可选）
Returns: stream sequence number (optional) and partial flag (optional)
返回：流序列号（可选）和部分标志（可选）
Comments: if the 'stream number' is provided, the call to receive only receives data on one particular stream. If a partial message arrives, this is indicated by the 'partial flag', and then the 'stream sequence number' must be provided such that an application can restore the correct order of data blocks that comprise an entire message.
备注：如果提供了“流编号”，则receive调用只接收一个特定流上的数据。如果部分消息到达，则由“部分标志”指示，然后必须提供“流序列号”，以便应用程序可以恢复组成整个消息的数据块的正确顺序。
o RECEIVE.UDP(-Lite):
o RECEIVE.UDP（-Lite）：
Pass 1 primitive/event: 'Receive'
传递1原语/事件：“接收”
Parameters: buffer for received datagram
参数：接收数据报的缓冲区
Comments: all CONNECTION.MAINTENANCE.GET_*.UDP(-Lite) primitives apply per message received.
注释：所有CONNECTION.MAINTENANCE.GET.*.UDP（-Lite）原语适用于收到的每条消息。
o SENDFAILURE-EVENT.SCTP:
o SENDFAILURE-EVENT.SCTP：
Pass 1 primitive/event: 'Send Failure' notification, optionally followed by 'Receive Unsent Message' or 'Receive Unacknowledged Message'
传递1原语/事件：“发送失败”通知，可选后跟“接收未发送消息”或“接收未确认消息”
Returns: cause code; context; and unsent or unacknowledged message
(optional)
Returns: cause code; context; and unsent or unacknowledged message
(optional)
Comments: 'cause code' indicates the reason of the failure, and 'context' is the context number if such a number has been provided in DATA.SEND.SCTP, for later use with 'Receive Unsent Message' or 'Receive Unacknowledged Message', respectively. These primitives can be used to retrieve the unsent or unacknowledged message (or part of the message, in case a part was delivered) if desired.
注释：“原因代码”表示故障原因，“上下文”是上下文编号（如果DATA.SEND.SCTP中提供了此编号），以供以后分别与“接收未发送消息”或“接收未确认消息”一起使用。如果需要，这些原语可用于检索未发送或未确认的消息（或消息的一部分，如果部分已交付）。
o SEND_FAILURE.UDP(-Lite):
o 发送失败。UDP（-Lite）：
Pass 1 primitive/event: 'Send'
传递1原语/事件：“发送”
Comments: this may be used to probe for the effective PMTU when using in combination with the 'MAINTENANCE.SET_DF' primitive.
备注：当与“MAINTENANCE.SET_DF”原语结合使用时，这可用于探测有效的PMTU。
o SENDER_DRY-EVENT.SCTP:
o 发送方\u DRY-EVENT.SCTP：
Pass 1 primitive/event: 'Sender Dry' notification
传递1原语/事件：“发件人干燥”通知
Comments: this informs the application that the stack has no more user data to send.
注释：这会通知应用程序堆栈没有更多的用户数据要发送。
o PARTIAL_DELIVERY_ABORTED-EVENT.SCTP:
o 部分交付\u中止-EVENT.SCTP：
Pass 1 primitive/event: 'Partial Delivery Aborted' notification
传递1原语/事件：“部分传递已中止”通知
Comments: this informs the receiver of a partial message that the further delivery of the message has been aborted.
注释：这会通知部分消息的接收者消息的进一步传递已中止。
This section presents the superset of all transport features in all protocols that were discussed in the preceding sections, based on the list of primitives in pass 2 but also on text in pass 1 to include transport features that can be configured in one protocol and are static properties in another (congestion control, for example). Again, some minor details are omitted for the sake of generalization -- e.g., TCP may provide various different IP options, but only source route is mandatory to implement, and this detail is not visible in the pass 3 transport feature "Specify IP options". As before, "UDP(-Lite)" represents both UDP and UDP-Lite, and "TCP" refers to both TCP and MPTCP.
本节根据第2阶段中的原语列表以及第1阶段中的文本，展示了前面章节讨论的所有协议中所有传输功能的超集，以包括可以在一个协议中配置且在另一个协议中是静态属性的传输功能（例如，拥塞控制）。同样，为了一般化，省略了一些次要细节——例如，TCP可能提供各种不同的IP选项，但只有源路由是必须实现的，并且在pass 3传输功能“Specify IP options”（指定IP选项）中看不到该细节。如前所述，“UDP（-Lite）”表示UDP和UDP Lite，“TCP”表示TCP和MPTCP。
ESTABLISHMENT: Active creation of a connection from one transport endpoint to one or more transport endpoints.
建立：主动创建从一个传输端点到一个或多个传输端点的连接。
o Connect Protocols: TCP, SCTP, and UDP(-Lite)
o 连接协议：TCP、SCTP和UDP（-Lite）
o Specify which IP options must always be used Protocols: TCP and UDP(-Lite)
o 指定必须始终使用的IP选项协议：TCP和UDP（-Lite）
o Request multiple streams Protocols: SCTP
o 请求多流协议：SCTP
o Limit the number of inbound streams Protocols: SCTP
o 限制入站流协议的数量：SCTP
o Specify number of attempts and/or timeout for the first establishment message Protocols: TCP and SCTP
o 指定首次建立消息协议TCP和SCTP的尝试次数和/或超时
o Obtain multiple sockets Protocols: SCTP
o 获取多个套接字协议：SCTP
o Disable MPTCP Protocols: MPTCP
o 禁用MPTCP协议：MPTCP
o Configure authentication Protocols: TCP and SCTP Comments: with TCP, this allows the configuration of MKTs. In SCTP, this allows the specification of which chunk types must always be authenticated. DATA, ACK, etc., are different 'chunks' in SCTP; one or more chunks may be included in a single packet.
o 配置身份验证协议：TCP和SCTP注释：使用TCP，这允许配置MKTs。在SCTP中，这允许指定必须始终对哪些块类型进行身份验证。数据、确认等在SCTP中是不同的“块”；一个或多个块可以包括在单个分组中。
o Indicate an Adaptation Layer (via an adaptation code point) Protocols: SCTP
o 指示适配层（通过适配代码点）协议：SCTP
o Request to negotiate interleaving of user messages Protocols: SCTP
o 协商用户消息交织协议的请求：SCTP
o Hand over a message to reliably transfer (possibly multiple times) before connection establishment Protocols: TCP
o 在建立连接协议（TCP）之前，移交消息以可靠地传输（可能多次）
o Hand over a message to reliably transfer during connection establishment Protocols: SCTP
o 在连接建立协议（SCTP）期间移交消息以可靠传输
o Enable UDP encapsulation with a specified remote UDP port number Protocols: SCTP
o 使用指定的远程UDP端口号启用UDP封装协议：SCTP
AVAILABILITY:
可利用性：
Preparing to receive incoming connection requests.
正在准备接收传入的连接请求。
o Listen, 1 specified local interface Protocols: TCP, SCTP, and UDP(-Lite)
o 侦听，1个指定的本地接口协议：TCP、SCTP和UDP（-Lite）
o Listen, N specified local interfaces Protocols: SCTP
o 侦听，N个指定的本地接口协议：SCTP
o Listen, all local interfaces Protocols: TCP, SCTP, and UDP(-Lite)
o 侦听，所有本地接口协议：TCP、SCTP和UDP（-Lite）
o Obtain requested number of streams Protocols: SCTP
o 获取请求的流数协议：SCTP
o Limit the number of inbound streams Protocols: SCTP
o 限制入站流协议的数量：SCTP
o Specify which IP options must always be used Protocols: TCP and UDP(-Lite)
o 指定必须始终使用的IP选项协议：TCP和UDP（-Lite）
o Disable MPTCP Protocols: MPTCP
o 禁用MPTCP协议：MPTCP
o Configure authentication Protocols: TCP and SCTP Comments: with TCP, this allows the configuration of MKTs. In SCTP, this allows the specification of which chunk types must always be authenticated. DATA, ACK, etc., are different 'chunks' in SCTP; one or more chunks may be included in a single packet.
o 配置身份验证协议：TCP和SCTP注释：使用TCP，这允许配置MKTs。在SCTP中，这允许指定必须始终对哪些块类型进行身份验证。数据、确认等在SCTP中是不同的“块”；一个或多个块可以包括在单个分组中。
o Indicate an Adaptation Layer (via an adaptation code point) Protocols: SCTP
o 指示适配层（通过适配代码点）协议：SCTP
MAINTENANCE:
维护：
Adjustments made to an open connection, or notifications about it.
对打开的连接所做的调整或通知。
o Change timeout for aborting connection (using retransmit limit or time value) Protocols: TCP and SCTP
o 更改中止连接的超时（使用重传限制或时间值）协议：TCP和SCTP
o Suggest timeout to the peer Protocols: TCP
o 建议对等协议超时：TCP
o Disable Nagle algorithm Protocols: TCP and SCTP
o 禁用Nagle算法协议：TCP和SCTP
o Request an immediate heartbeat, returning success/failure Protocols: SCTP
o 请求立即心跳，返回成功/失败协议：SCTP
o Notification of excessive retransmissions (early warning below abortion threshold) Protocols: TCP
o 过度重传通知（低于堕胎阈值的早期警告）协议：TCP
o Add path Protocols: MPTCP and SCTP MPTCP Parameters: source-IP; source-Port; destination-IP; and destination-Port SCTP Parameters: local IP address
o 添加路径协议：MPTCP和SCTP MPTCP参数：源IP；源端口；目的IP；和目标端口SCTP参数：本地IP地址
o Remove path Protocols: MPTCP and SCTP MPTCP Parameters: source-IP; source-Port; destination-IP; and destination-Port SCTP Parameters: local IP address
o 移除路径协议：MPTCP和SCTP MPTCP参数：源IP；源端口；目的IP；和目标端口SCTP参数：本地IP地址
o Set primary path Protocols: SCTP
o 设置主路径协议：SCTP
o Suggest primary path to the peer Protocols: SCTP
o 建议对等协议的主要路径：SCTP
o Configure Path Switchover Protocols: SCTP
o 配置路径切换协议：SCTP
o Obtain status (query or notification) Protocols: SCTP and MPTCP SCTP parameters: association connection state; destination transport address list; destination transport address reachability states; current local and peer receiver window sizes; current local congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; primary path; most recent SRTT on primary path; RTO on primary path; SRTT and RTO on other destination addresses; MTU per path; and interleaving supported yes/no MPTCP parameters: subflow-list (identified by source-IP; source-Port; destination-IP; and destination-Port)
o 获取状态（查询或通知）协议：SCTP和MPTCP SCTP参数：关联连接状态；目的地传输地址列表；目的地传输地址可达状态；当前本地和对等接收器窗口大小；当前本地拥塞窗口大小；未确认数据块的数量；待接收的数据块数；主要路径；主路径上最近的SRTT；主路径上的RTO；其他目的地址上的SRTT和RTO；每条路径的MTU；和交错支持的是/否MPTCP参数：子流列表（由源IP、源端口、目标IP和目标端口标识）
o Specify DSCP field Protocols: TCP, SCTP, and UDP(-Lite)
o 指定DSCP字段协议：TCP、SCTP和UDP（-Lite）
o Notification of ICMP error message arrival Protocols: TCP and UDP(-Lite)
o ICMP错误消息到达协议通知：TCP和UDP（-Lite）
o Change authentication parameters Protocols: TCP and SCTP
o 更改身份验证参数协议：TCP和SCTP
o Obtain authentication information Protocols: TCP and SCTP
o 获取身份验证信息协议：TCP和SCTP
o Reset Stream Protocols: SCTP
o 重置流协议：SCTP
o Notification of Stream Reset Protocols: STCP
o 流重置协议通知：STCP
o Reset Association Protocols: SCTP
o 重置关联协议：SCTP
o Notification of Association Reset Protocols: STCP
o 关联重置协议通知：STCP
o Add Streams Protocols: SCTP
o 添加流协议：SCTP
o Notification of Added Stream Protocols: STCP
o 添加流协议的通知：STCP
o Choose a scheduler to operate between streams of an association Protocols: SCTP
o 选择要在关联协议流之间操作的计划程序：SCTP
o Configure priority or weight for a scheduler Protocols: SCTP
o 为调度程序协议配置优先级或权重：SCTP
o Specify IPv6 flow label field Protocols: SCTP
o 指定IPv6流标签字段协议：SCTP
o Configure send buffer size Protocols: SCTP
o 配置发送缓冲区大小协议：SCTP
o Configure receive buffer (and rwnd) size Protocols: SCTP
o 配置接收缓冲区（和rwnd）大小协议：SCTP
o Configure message fragmentation Protocols: SCTP
o 配置消息分段协议：SCTP
o Configure PMTUD Protocols: SCTP
o 配置PMTUD协议：SCTP
o Configure delayed SACK timer Protocols: SCTP
o 配置延迟SACK定时器协议：SCTP
o Set Cookie life value Protocols: SCTP
o 设置Cookie生命值协议：SCTP
o Set maximum burst Protocols: SCTP
o 设置最大突发协议：SCTP
o Configure size where messages are broken up for partial delivery Protocols: SCTP
o 为部分传递协议配置拆分邮件的大小：SCTP
o Disable checksum when sending Protocols: UDP
o 发送协议时禁用校验和：UDP
o Disable checksum requirement when receiving Protocols: UDP
o 接收协议时禁用校验和要求：UDP
o Specify checksum coverage used by the sender Protocols: UDP-Lite
o 指定发送方协议使用的校验和覆盖率：UDP Lite
o Specify minimum checksum coverage required by receiver Protocols: UDP-Lite
o 指定接收器协议所需的最小校验和覆盖率：UDP Lite
o Specify DF field Protocols: UDP(-Lite)
o 指定DF字段协议：UDP（-Lite）
o Get max. transport-message size that may be sent using a non-fragmented IP packet from the configured interface Protocols: UDP(-Lite)
o 从配置的接口协议：UDP（-Lite）获取可使用非分段IP数据包发送的最大传输消息大小
o Get max. transport-message size that may be received from the configured interface Protocols: UDP(-Lite)
o 获取可从配置的接口协议接收的最大传输消息大小：UDP（-Lite）
o Specify TTL/Hop Count field Protocols: UDP(-Lite)
o 指定TTL/跃点计数字段协议：UDP（-Lite）
o Obtain TTL/Hop Count field Protocols: UDP(-Lite)
o 获取TTL/跃点计数字段协议：UDP（-Lite）
o Specify ECN field Protocols: UDP(-Lite)
o 指定ECN字段协议：UDP（-Lite）
o Obtain ECN field Protocols: UDP(-Lite)
o 获取ECN字段协议：UDP（-Lite）
o Specify IP options Protocols: UDP(-Lite)
o 指定IP选项协议：UDP（-Lite）
o Obtain IP options Protocols: UDP(-Lite)
o 获取IP选项协议：UDP（-Lite）
o Enable and configure "Low Extra Delay Background Transfer" Protocols: A protocol implementing the LEDBAT congestion control mechanism
o 启用和配置“低额外延迟后台传输”协议：实现LEDBAT拥塞控制机制的协议
TERMINATION:
终止：
Gracefully or forcefully closing a connection, or being informed about this event happening.
优雅地或有力地关闭连接，或被告知此事件正在发生。
o Close after reliably delivering all remaining data, causing an event informing the application on the other side Protocols: TCP and SCTP Comments: a TCP endpoint locally only closes the connection for sending; it may still receive data afterwards.
o 可靠地传递所有剩余数据后关闭，导致事件通知另一端的应用程序协议：TCP和SCTP注释：TCP端点仅在本地关闭用于发送的连接；之后它仍可能接收数据。
o Abort without delivering remaining data, causing an event that informs the application on the other side Protocols: TCP and SCTP
o 在不传递剩余数据的情况下中止，导致在另一端协议（TCP和SCTP）上通知应用程序的事件
Comments: in SCTP, a reason can optionally be given by the application on the aborting side, which can then be received by the application on the other side.
备注：在SCTP中，可以选择由中止端的应用程序给出原因，然后由另一端的应用程序接收。
o Abort without delivering remaining data, not causing an event that informs the application on the other side Protocols: UDP(-Lite)
o 在不传递剩余数据的情况下中止，不会导致事件通知另一端的应用程序协议：UDP（-Lite）
o Timeout event when data could not be delivered for too long Protocols: TCP and SCTP Comments: the timeout is configured with CONNECTION.MAINTENANCE "Change timeout for aborting connection (using retransmit limit or time value)".
o 数据传输时间过长时发生超时事件协议：TCP和SCTP注释：超时配置为CONNECTION.MAINTENANCE“更改中止连接的超时（使用重新传输限制或时间值）”。
All transport features in this section refer to an existing connection, i.e., a connection that was either established or made available for receiving data. Note that TCP allows the transfer of data (a single optional user message, possibly arriving multiple times) before the connection is fully established. Reliable data transfer entails delay -- e.g., for the sender to wait until it can transmit data or due to retransmission in case of packet loss.
本节中的所有传输功能均指现有连接，即已建立或可用于接收数据的连接。请注意，TCP允许在连接完全建立之前传输数据（单个可选用户消息，可能多次到达）。可靠的数据传输需要延迟——例如，发送方等待，直到它可以传输数据，或者在数据包丢失的情况下由于重新传输。
All transport features in this section are provided by DATA.SEND from pass 2. DATA.SEND is given a data block from the application, which here we call a "message" if the beginning and end of the data block can be identified at the receiver, and "data" otherwise.
本节中的所有传输功能均由DATA.SEND from pass 2提供。DATA.SEND从应用程序中获得一个数据块，如果数据块的开始和结束可以在接收方识别，则在这里我们称之为“消息”，否则称之为“数据”。
o Reliably transfer data, with congestion control Protocols: TCP
o 使用拥塞控制协议（TCP）可靠地传输数据
o Reliably transfer a message, with congestion control Protocols: SCTP
o 使用拥塞控制协议（SCTP）可靠地传输消息
o Unreliably transfer a message, with congestion control Protocols: SCTP
o 使用拥塞控制协议（SCTP）不可靠地传输消息
o Unreliably transfer a message, without congestion control Protocols: UDP(-Lite)
o 不可靠地传输消息，没有拥塞控制协议：UDP（-Lite）
o Configurable Message Reliability Protocols: SCTP
o 可配置消息可靠性协议：SCTP
o Choice of stream Protocols: SCTP
o 流协议的选择：SCTP
o Choice of path (destination address) Protocols: SCTP
o 路径（目标地址）协议的选择：SCTP
o Ordered message delivery (potentially slower than unordered) Protocols: SCTP
o 有序消息传递（可能比无序消息传递慢）协议：SCTP
o Unordered message delivery (potentially faster than ordered) Protocols: SCTP and UDP(-Lite)
o 无序消息传递（可能快于有序）协议：SCTP和UDP（-Lite）
o Request not to bundle messages Protocols: SCTP
o 请求不捆绑消息协议：SCTP
o Specifying a 'payload protocol-id' (handed over as such by the receiver) Protocols: SCTP
o 指定“有效负载协议id”（由接收方移交）协议：SCTP
o Specifying a key identifier to be used to authenticate a message Protocols: SCTP
o 指定用于验证消息的密钥标识符协议：SCTP
o Request not to delay the acknowledgement (SACK) of a message Protocols: SCTP
o 请求不延迟消息协议的确认（SACK）：SCTP
All transport features in this section are provided by DATA.RECEIVE from pass 2. DATA.RECEIVE fills a buffer provided by the application, with what here we call a "message" if the beginning and end of the data block can be identified at the receiver, and "data" otherwise.
本节中的所有传输功能均由DATA.RECEIVE from pass 2提供。DATA.RECEIVE填充由应用程序提供的缓冲区，如果数据块的开始和结束可以在接收方识别，则在这里我们称之为“消息”，否则称为“数据”。
o Receive data (with no message delimiting) Protocols: TCP
o 接收数据（无消息分隔）协议：TCP
o Receive a message Protocols: SCTP and UDP(-Lite)
o 接收消息协议：SCTP和UDP（-Lite）
o Choice of stream to receive from Protocols: SCTP
o 选择从协议接收的流：SCTP
o Information about partial message arrival Protocols: SCTP Comments: in SCTP, partial messages are combined with a stream sequence number so that the application can restore the correct order of data blocks an entire message consists of.
o 有关部分消息到达协议的信息：SCTP注释：在SCTP中，部分消息与流序列号组合，以便应用程序可以恢复整个消息所包含的数据块的正确顺序。
This section describes sending failures that are associated with a specific call to DATA.SEND from pass 2.
本节介绍与特定DATA.SEND from pass 2调用关联的发送失败。
o Notification of an unsent (part of a) message Protocols: SCTP and UDP(-Lite)
o 未发送（a部分）消息的通知协议：SCTP和UDP（-Lite）
o Notification of an unacknowledged (part of a) message Protocols: SCTP
o 未确认（a部分）消息协议的通知：SCTP
o Notification that the stack has no more user data to send Protocols: SCTP
o 堆栈没有更多用户数据可发送的通知协议：SCTP
o Notification to a receiver that a partial message delivery has been aborted Protocols: SCTP
o 通知接收方部分消息传递已中止协议：SCTP
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
Authentication, confidentiality protection, and integrity protection are identified as transport features [RFC8095]. These transport features are generally provided by a protocol or layer on top of the transport protocol; none of the transport protocols considered in this document provides these transport features on its own. Therefore, these transport features are not considered in this document, with the exception of native authentication capabilities of TCP and SCTP for which the security considerations in [RFC5925] and [RFC4895] apply.
身份验证、机密性保护和完整性保护被标识为传输功能[RFC8095]。这些传输特性通常由传输协议之上的协议或层提供；本文档中考虑的传输协议均未单独提供这些传输功能。因此，除了[RFC5925]和[RFC4895]中的安全注意事项适用的TCP和SCTP的本机身份验证功能外，本文档不考虑这些传输功能。
Security considerations for the use of UDP and UDP-Lite are provided in the referenced RFCs. Security guidance for application usage is provided in the UDP Guidelines [RFC8085].
参考的RFC中提供了使用UDP和UDP Lite的安全注意事项。UDP指南[RFC8085]中提供了应用程序使用的安全指南。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<https://www.rfc-editor.org/info/rfc1122>.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <https://www.rfc-editor.org/info/rfc3758>.
[RFC3758]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，DOI 10.17487/RFC3758，2004年5月<https://www.rfc-editor.org/info/rfc3758>.
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007, <https://www.rfc-editor.org/info/rfc4895>.
[RFC4895]Tuexen，M.，Stewart，R.，Lei，P.，和E.Rescorla，“流控制传输协议（SCTP）的认证块”，RFC 4895，DOI 10.17487/RFC4895，2007年8月<https://www.rfc-editor.org/info/rfc4895>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 4960，DOI 10.17487/RFC4960，2007年9月<https://www.rfc-editor.org/info/rfc4960>.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, <https://www.rfc-editor.org/info/rfc5061>.
[RFC5061]Stewart，R.，Xie，Q.，Tuexen，M.，Maruyama，S.，和M.Kozuka，“流控制传输协议（SCTP）动态地址重新配置”，RFC 5061，DOI 10.17487/RFC5061，2007年9月<https://www.rfc-editor.org/info/rfc5061>.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, DOI 10.17487/RFC5482, March 2009, <https://www.rfc-editor.org/info/rfc5482>.
[RFC5482]Eggert，L.和F.Gont，“TCP用户超时选项”，RFC 5482，DOI 10.17487/RFC5482，2009年3月<https://www.rfc-editor.org/info/rfc5482>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 5925，DOI 10.17487/RFC5925，2010年6月<https://www.rfc-editor.org/info/rfc5925>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, <https://www.rfc-editor.org/info/rfc6182>.
[RFC6182]福特，A.，雷丘，C.，汉德利，M.，巴尔，S.，和J.艾扬格，“多路径TCP开发的体系结构指南”，RFC 6182，DOI 10.17487/RFC6182，2011年3月<https://www.rfc-editor.org/info/rfc6182>.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, <https://www.rfc-editor.org/info/rfc6458>.
[RFC6458]Stewart，R.，Tuexen，M.，Poon，K.，Lei，P.，和V.Yasevich，“流控制传输协议（SCTP）的套接字API扩展”，RFC 6458，DOI 10.17487/RFC6458，2011年12月<https://www.rfc-editor.org/info/rfc6458>.
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, <https://www.rfc-editor.org/info/rfc6525>.
[RFC6525]Stewart，R.，Tuexen，M.，和P.Lei，“流控制传输协议（SCTP）流重新配置”，RFC 6525，DOI 10.17487/RFC6525，2012年2月<https://www.rfc-editor.org/info/rfc6525>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.
[RFC6817]Shalunov，S.，Hazel，G.，Iyengar，J.，和M.Kuehlewind，“低额外延迟背景传输（LEDBAT）”，RFC 6817，DOI 10.17487/RFC6817，2012年12月<https://www.rfc-editor.org/info/rfc6817>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <https://www.rfc-editor.org/info/rfc6824>.
[RFC6824]Ford，A.，Raiciu，C.，Handley，M.，和O.Bonaventure，“多地址多路径操作的TCP扩展”，RFC 6824DOI 10.17487/RFC68242013年1月<https://www.rfc-editor.org/info/rfc6824>.
[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, <https://www.rfc-editor.org/info/rfc6897>.
[RFC6897]Scharf，M.和A.Ford，“多路径TCP（MPTCP）应用程序接口注意事项”，RFC 6897，DOI 10.17487/RFC6897，2013年3月<https://www.rfc-editor.org/info/rfc6897>.
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <https://www.rfc-editor.org/info/rfc6951>.
[RFC6951]Tuexen，M.和R.Stewart，“用于端主机到端主机通信的流控制传输协议（SCTP）数据包的UDP封装”，RFC 6951，DOI 10.17487/RFC6951，2013年5月<https://www.rfc-editor.org/info/rfc6951>.
[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, <https://www.rfc-editor.org/info/rfc7053>.
[RFC7053]Tuexen，M.，Ruengeler，I.，和R.Stewart，“流控制传输协议的SACK-立即扩展”，RFC 7053，DOI 10.17487/RFC7053，2013年11月<https://www.rfc-editor.org/info/rfc7053>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413]Cheng，Y.，Chu，J.，Radhakrishnan，S.，和A.Jain，“TCP快速开放”，RFC 7413，DOI 10.17487/RFC74132014年12月<https://www.rfc-editor.org/info/rfc7413>.
[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension", RFC 7496, DOI 10.17487/RFC7496, April 2015, <https://www.rfc-editor.org/info/rfc7496>.
[RFC7496]Tuexen，M.，Seggelmann，R.，Stewart，R.，和S.Loreto，“部分可靠流控制传输协议扩展的附加策略”，RFC 7496，DOI 10.17487/RFC7496，2015年4月<https://www.rfc-editor.org/info/rfc7496>.
[RFC7829] Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K. Nielsen, "SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol", RFC 7829, DOI 10.17487/RFC7829, April 2016, <https://www.rfc-editor.org/info/rfc7829>.
[RFC7829]Nishida，Y.，Natarajan，P.，Caro，A.，Amer，P.，和K.Nielsen，“SCTP-PF：流控制传输协议的快速故障转移算法”，RFC 7829，DOI 10.17487/RFC7829，2016年4月<https://www.rfc-editor.org/info/rfc7829>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085]Eggert，L.，Fairhurst，G.和G.Shepherd，“UDP使用指南”，BCP 145，RFC 8085，DOI 10.17487/RFC8085，2017年3月<https://www.rfc-editor.org/info/rfc8085>.
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", RFC 8260, DOI 10.17487/RFC8260, November 2017, <https://www.rfc-editor.org/info/rfc8260>.
[RFC8260]Stewart，R.，Tuexen，M.，Loreto，S.，和R.Seggelmann，“流控制传输协议的流调度器和用户消息交错”，RFC 8260，DOI 10.17487/RFC8260，2017年11月<https://www.rfc-editor.org/info/rfc8260>.
[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, <https://www.rfc-editor.org/info/rfc8304>.
[RFC8304]Fairhurst，G.和T.Jones，“用户数据报协议（UDP）和轻量级UDP（UDP Lite）的传输特性”，RFC 8304，DOI 10.17487/RFC8304，2018年2月<https://www.rfc-editor.org/info/rfc8304>.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, <https://www.rfc-editor.org/info/rfc854>.
[RFC0854]Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，DOI 10.17487/RFC0854，1983年5月<https://www.rfc-editor.org/info/rfc854>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 2475，DOI 10.17487/RFC2475，1998年12月<https://www.rfc-editor.org/info/rfc2475>.
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, <https://www.rfc-editor.org/info/rfc3260>.
[RFC3260]Grossman，D.，“区分服务的新术语和澄清”，RFC 3260，DOI 10.17487/RFC3260，2002年4月<https://www.rfc-editor.org/info/rfc3260>.
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI 10.17487/RFC5461, February 2009, <https://www.rfc-editor.org/info/rfc5461>.
[RFC5461]Gont，F.，“TCP对软错误的反应”，RFC 5461，DOI 10.17487/RFC5461，2009年2月<https://www.rfc-editor.org/info/rfc5461>.
[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, <https://www.rfc-editor.org/info/rfc6093>.
[RFC6093]Gont，F.和A.Yourtchenko，“关于TCP紧急机制的实施”，RFC 6093，DOI 10.17487/RFC6093，2011年1月<https://www.rfc-editor.org/info/rfc6093>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, <https://www.rfc-editor.org/info/rfc7414>.
[RFC7414]杜克，M.，布拉登，R.，艾迪，W.，布兰顿，E.，和A.齐默尔曼，“传输控制协议（TCP）规范文件路线图”，RFC 7414，DOI 10.17487/RFC7414，2015年2月<https://www.rfc-editor.org/info/rfc7414>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.
[RFC7657]Black，D.，Ed.和P.Jones，“区分服务（Diffserv）和实时通信”，RFC 7657，DOI 10.17487/RFC7657，2015年11月<https://www.rfc-editor.org/info/rfc7657>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.
[RFC8095]Fairhurst，G.，Ed.，Trammell，B.，Ed.，和M.Kuehlewind，Ed.，“IETF传输协议和拥塞控制机制提供的服务”，RFC 8095，DOI 10.17487/RFC8095，2017年3月<https://www.rfc-editor.org/info/rfc8095>.
[TAPS-MINSET] Welzl, M. and S. Gjessing, "A Minimal Set of Transport Services for TAPS Systems", Work in Progress, draft-ietf-taps-minset-01, February 2018.
[TAPS-MINSET]Welzl，M.和S.Gjessing，“TAPS系统的最小运输服务集”，正在进行的工作，草稿-ietf-TAPS-MINSET-01，2018年2月。
TCP: [RFC0793], [RFC1122], [RFC5482], [RFC5925], and [RFC7413].
TCP:[RFC0793]、[RFC1122]、[RFC5482]、[RFC5925]和[RFC7413]。
MPTCP: [RFC6182], [RFC6824], and [RFC6897].
MPTCP:[RFC6182]、[RFC6824]和[RFC6897]。
SCTP: RFCs without a sockets API specification: [RFC3758], [RFC4895], [RFC4960], and [RFC5061].
SCTP:RFC不带套接字API规范：[RFC3758]、[RFC4895]、[RFC4960]和[RFC5061]。
RFCs that include a sockets API specification: [RFC6458], [RFC6525], [RFC6951], [RFC7053], [RFC7496], and [RFC7829].
包含套接字API规范的RFC：[RFC6458]、[RFC6525]、[RFC6951]、[RFC7053]、[RFC7496]和[RFC7829]。
UDP(-Lite): See [RFC8304].
UDP（-Lite）：请参阅[RFC8304]。
LEDBAT: [RFC6817].
莱德巴特：[RFC6817]。
This section gives an overview of the method that was used to develop this document. It was given to contributors for guidance, and it can be helpful for future updates or extensions.
本节概述了用于编制本文档的方法。它被提供给贡献者以供指导，并且它可以对将来的更新或扩展有所帮助。
This document is only concerned with transport features that are explicitly exposed to applications via primitives. It also strictly follows RFC text: if a transport feature is truly relevant for an application, the RFCs should say so, and they should describe how to use and configure it. Thus, the approach followed for developing this document was to identify the right RFCs, then analyze and process their text.
本文档仅涉及通过原语显式公开给应用程序的传输特性。它还严格遵循RFC文本：如果传输特性确实与应用程序相关，RFC应该这样说，并且应该描述如何使用和配置它。因此，制定本文件所采用的方法是确定正确的RFC，然后分析和处理其文本。
Primitives that "MAY" be implemented by a transport protocol were excluded. To be included, the minimum requirement level for a primitive to be implemented by a protocol was "SHOULD". Where style requirement levels as described in [RFC2119] are not used, primitives were excluded when they are described in conjunction with statements like, e.g., "some implementations also provide" or "an implementation may also". Excluded primitives or parameters were briefly described in a dedicated subsection.
排除了“可能”由传输协议实现的原语。要包括在内，协议要实现的原语的最低要求级别是“应该”。如果未使用[RFC2119]中所述的样式需求级别，则当原语与诸如“某些实现还提供”或“某个实现也可以”之类的语句一起描述时，它们被排除在外。排除的原语或参数在专用小节中进行了简要描述。
Pass 1: This began by identifying text that talks about primitives. An API specification, abstract or not, obviously describes primitives -- but we are not *only* interested in API specifications. The text describing the 'Send' primitive in the API specified in [RFC0793],
第1步：首先确定谈论原语的文本。API规范，不管是抽象的还是非抽象的，显然描述了原语——但我们不仅仅对API规范感兴趣。[RFC0793]中指定的API中描述“发送”原语的文本，
for instance, does not say that data transfer is reliable. TCP's reliability is clear, however, from this text in Section 1 of [RFC0793]:
例如，并不是说数据传输是可靠的。然而，从[RFC0793]第1节中的文本可以清楚地看出TCP的可靠性：
The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks.
传输控制协议（TCP）旨在用作分组交换计算机通信网络中主机之间以及此类网络的互连系统中的高度可靠的主机对主机协议。
Some text for the pass 1 subsections was developed by copying and pasting all the relevant text parts from the relevant RFCs then adjusting the terminology to match that in Section 2 and shortening phrasing to match the general style of the document. An effort was made to formulate everything as a primitive description such that the primitive descriptions became as complete as possible (e.g., the 'SEND.TCP' primitive in pass 2 is explicitly described as reliably transferring data); text that is relevant for the primitives presented in this pass but still does not fit directly under any primitive was used in a subsection's introduction.
通过复制和粘贴相关RFC中的所有相关文本部分，然后调整术语，使其与第2节中的术语相匹配，并缩短措辞，使其与文件的一般风格相匹配，从而形成了pass 1小节的一些文本。努力将所有内容表述为基本描述，以使基本描述尽可能完整（例如，第2阶段中的“SEND.TCP”基本描述明确描述为可靠传输数据）；在一小节的引言中使用了与本节中介绍的原语相关但仍不直接适用于任何原语的文本。
Pass 2: The main goal of this pass is unification of primitives. As input, only text from pass 1 was used (no exterior sources). The list in pass 2 is not arranged by protocol (i.e., "first protocol X, here are all the primitives; then protocol Y, here are all the primitives, ...") but by primitive (i.e., "primitive A, implemented this way in protocol X, this way in protocol Y, ..."). It was a goal to obtain as many similar pass 2 primitives as possible. For instance, this was sometimes achieved by not always maintaining a 1:1 mapping between pass 1 and pass 2 primitives, renaming primitives, etc. For every new primitive, the already-existing primitives were considered to try to make them as coherent as possible.
过程2：这个过程的主要目标是原语的统一。作为输入，仅使用过程1中的文本（无外部源）。过程2中的列表不是按协议排列的（即，“第一个协议X，这里是所有的原语；然后协议Y，这里是所有的原语，…”），而是按原语排列的（即，“原语A，在协议X中以这种方式实现，在协议Y中以这种方式实现，…”）。目标是获得尽可能多的类似pass 2原语。例如，有时通过不总是在过程1和过程2基本体之间保持1:1映射、重命名基本体等来实现。对于每个新的基本体，都会考虑现有的基本体，以使它们尽可能一致。
For each primitive, the following style was used:
对于每个基本体，使用了以下样式：
o PRIMITIVENAME.PROTOCOL: Pass 1 primitive/event: Parameters: Returns: Comments:
o PRIMITIVENAME.PROTOCOL:传递1原语/事件：参数：返回：注释：
The entries "Parameters", "Returns", and "Comments" were skipped when a primitive had no parameters, no described return value, or no comments seemed necessary, respectively. Optional parameters are followed by "(optional)". When known, default values were provided.
当原语分别没有参数、没有描述的返回值或似乎没有必要注释时，将跳过条目“Parameters”、“Returns”和“Comments”。可选参数后跟“（可选）”。已知时，会提供默认值。
Pass 3: The main point of this pass is to identify transport features that are the result of static properties of protocols, for which all protocols have to be listed together; this is then the final list of
过程3：此过程的要点是识别协议静态属性的结果传输特性，所有协议必须一起列出；这是最后一张名单
all available transport features. This list was primarily based on text from pass 2, with additional input from pass 1 (but no external sources).
所有可用的传输功能。该列表主要基于pass2中的文本，以及pass1中的额外输入（但没有外部源）。
Acknowledgements
致谢
The authors would like to thank (in alphabetical order) Bob Briscoe, Spencer Dawkins, Aaron Falk, David Hayes, Karen Nielsen, Tommy Pauly, Joe Touch, and Brian Trammell for providing valuable feedback on this document. We especially thank Christoph Paasch for providing input related to Multipath TCP and Gorry Fairhurst and Tom Jones for providing input related to UDP(-Lite). This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT).
作者要感谢（按字母顺序排列）鲍勃·布里斯科、斯宾塞·道金斯、亚伦·福克、大卫·海斯、凯伦·尼尔森、汤米·保利、乔·图奇和布赖恩·特拉梅尔为本文件提供了宝贵的反馈。我们特别感谢Christoph Paasch提供了与多路径TCP相关的输入，感谢Gorry Fairhurst和Tom Jones提供了与UDP（-Lite）相关的输入。这项工作得到了欧盟地平线2020研究和创新计划的资助，资助协议号为644334（NEAT）。
Authors' Addresses
作者地址
Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
米迦勒WelZl奥斯陆大学邮政信箱1080盲人奥斯陆N-0316挪威
Email: michawe@ifi.uio.no
Email: michawe@ifi.uio.no
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 Steinfurt 48565 Germany
米迦勒TuxEN明斯特应用科学大学StugWaldStasSE 39 Stin Furt 48565德国
Email: tuexen@fh-muenster.de
Email: tuexen@fh-muenster.de
Naeem Khademi University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
Neim-KHADMi奥斯陆大学邮政信箱1080盲人奥斯陆N-0316挪威
Email: naeemk@ifi.uio.no
Email: naeemk@ifi.uio.no