Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 8304 T. Jones
Category: Informational University of Aberdeen
ISSN: 2070-1721 February 2018
Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 8304 T. Jones
Category: Informational University of Aberdeen
ISSN: 2070-1721 February 2018
Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)
用户数据报协议（UDP）和轻量级UDP（UDP Lite）的传输功能
Abstract
摘要
This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFC 8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols.
这是一个信息性文档，描述了用户数据报协议（UDP）和轻量级用户数据报协议（UDP Lite）传输协议提供的传输协议接口原语。它确定了向应用程序公开的数据报服务，以及应用程序如何配置和使用Internet数据报传输服务提供的功能。RFC 8303记录了IETF传输协议提供的传输功能的使用情况，描述了UDP、UDP Lite和其他传输协议向应用程序公开其服务的方式，以及应用程序如何配置和使用构成这些服务的功能。本文档提供了该文档的输入和上下文，并提供了可能帮助UDP和UDP Lite协议用户的文档路线图。
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/rfc8304.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8304.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. UDP and UDP-Lite Primitives . . . . . . . . . . . . . . . . . 4
3.1. Primitives Provided by UDP . . . . . . . . . . . . . . . 4
3.1.1. Excluded Primitives . . . . . . . . . . . . . . . . . 11
3.2. Primitives Provided by UDP-Lite . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Multicast Primitives . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. UDP and UDP-Lite Primitives . . . . . . . . . . . . . . . . . 4
3.1. Primitives Provided by UDP . . . . . . . . . . . . . . . 4
3.1.1. Excluded Primitives . . . . . . . . . . . . . . . . . 11
3.2. Primitives Provided by UDP-Lite . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Multicast Primitives . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
This document presents defined interactions between transport protocols and applications in the form of 'primitives' (function calls) for the User Datagram Protocol (UDP) [RFC0768] and the Lightweight User Datagram Protocol (UDP-Lite) [RFC3828]. In this usage, the word application refers to any program built on the datagram interface, including tunnels and other upper-layer protocols that use UDP and UDP-Lite.
本文档以用户数据报协议（UDP）[RFC0768]和轻量级用户数据报协议（UDP Lite）[RFC3828]的“原语”（函数调用）形式介绍传输协议和应用程序之间定义的交互。在这种用法中，“应用程序”一词指的是在数据报接口上构建的任何程序，包括使用UDP和UDP Lite的隧道和其他上层协议。
UDP is widely implemented and deployed. It is used for a wide range of applications. A special class of applications can derive benefit from having partially damaged payloads delivered, rather than discarded, when using paths that include error-prone links. Applications that can tolerate payload corruption can choose to use UDP-Lite instead of UDP and use the application programming interface
UDP被广泛地实现和部署。它的应用范围很广。当使用包含易出错链接的路径时，一类特殊的应用程序可以从交付而不是丢弃部分损坏的有效负载中获益。能够容忍负载损坏的应用程序可以选择使用UDP Lite而不是UDP，并使用应用程序编程接口
(API) to control checksum protection. Conversely, UDP applications could choose to use UDP-Lite, but this is currently less widely deployed, and users could encounter paths that do not support UDP-Lite. These topics are discussed more in Section 3.4 of "UDP Usage Guidelines" [RFC8085].
（API）控制校验和保护。相反，UDP应用程序可以选择使用UDP Lite，但目前部署的范围较小，用户可能会遇到不支持UDP Lite的路径。这些主题将在“UDP使用指南”[RFC8085]的第3.4节中详细讨论。
The IEEE standard API for TCP/IP applications is the "socket" interface [POSIX]. An application can use the recv() and send() POSIX functions as well as the recvfrom(), sendto(), recvmsg(), and sendmsg() functions. The UDP and UDP-Lite sockets API differs from that for TCP in several key ways. (Examples of usage of this API are provided in [STEVENS].) In UDP and UDP-Lite, each datagram is a self-contained message of a specified length, and options at the transport layer can be used to set properties for all subsequent datagrams sent using a socket or changed for each datagram. For datagrams, this can require the application to use the API to set IP-level information (IP Time To Live (TTL), Differentiated Services Code Point (DSCP), IP fragmentation, etc.) for the datagrams it sends and receives. In contrast, when using TCP and other connection-oriented transports, the IP-level information normally either remains the same for the duration of a connection or is controlled by the transport protocol rather than the application.
TCP/IP应用程序的IEEE标准API是“套接字”接口[POSIX]。应用程序可以使用recv（）和send（）POSIX函数以及recvfrom（）、sendto（）、recvmsg（）和sendmsg（）函数。UDP和UDP Lite套接字API在几个关键方面与TCP不同。（此API的使用示例在[STEVENS]中提供）在UDP和UDP Lite中，每个数据报都是指定长度的自包含消息，传输层的选项可用于为使用套接字发送的所有后续数据报设置属性，或为每个数据报更改属性。对于数据报，这可能需要应用程序使用API为其发送和接收的数据报设置IP级别信息（IP生存时间（TTL）、区分服务代码点（DSCP）、IP碎片等）。相反，当使用TCP和其他面向连接的传输时，IP级别的信息通常在连接期间保持不变，或者由传输协议而不是应用程序控制。
Socket options are used in the sockets API to provide additional functions. For example, the IP_RECVTTL socket option is used by some UDP multicast applications to return the IP TTL field from the IP header of a received datagram.
套接字API中使用套接字选项来提供附加功能。例如，一些UDP多播应用程序使用IP_RECVTTL套接字选项从接收到的数据报的IP报头返回IP TTL字段。
Some platforms also offer applications the ability to directly assemble and transmit IP packets through "raw sockets" or similar facilities. The raw sockets API is a second, more cumbersome, method to send UDP datagrams. The use of this API is discussed in the RFC series in the UDP Guidelines [RFC8085].
一些平台还为应用程序提供了通过“原始套接字”或类似设施直接组装和传输IP数据包的能力。原始套接字API是发送UDP数据报的第二种更麻烦的方法。UDP指南[RFC8085]中的RFC系列讨论了此API的使用。
The list of transport service features and primitives in this document is strictly based on the parts of protocol specifications in the RFC series that relate to what the transport protocol provides to an application that uses it and how the application interacts with the transport protocol. Primitives can be invoked by an application or a transport protocol; the latter type is called an "event".
本文档中的传输服务功能和原语列表严格基于RFC系列中协议规范的部分，这些部分与传输协议向使用它的应用程序提供的内容以及应用程序如何与传输协议交互有关。原语可以由应用程序或传输协议调用；后一种类型称为“事件”。
The description in Section 3 follows the methodology defined by the IETF TAPS Working Group in [RFC8303]. Specifically, this document provides the first pass of this process, which discusses the relevant RFC text describing primitives for each protocol. [RFC8303] uses this input to document the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other
第3节中的描述遵循了IETF TAPS工作组在[RFC8303]中定义的方法。具体来说，本文档提供了此过程的第一步，讨论了描述每个协议原语的相关RFC文本。[RFC8303]使用此输入记录IETF传输协议提供的传输功能的使用情况，描述UDP、UDP Lite和其他
transport protocols expose their services to applications and how an application can configure and use the features that make up these services.
传输协议向应用程序公开其服务，以及应用程序如何配置和使用构成这些服务的功能。
The presented road map to documentation of the transport interface may also help developers working with UDP and UDP-Lite.
所提供的传输接口文档路线图也可以帮助开发人员使用UDP和UDP Lite。
This document provides details for the pass 1 analysis of UDP and UDP-Lite that is used in "On the Usage of Transport Features Provided by IETF Transport Protocols" [RFC8303]. It uses common terminology defined in that document and also quotes RFCs that use the terminology of RFC 2119 [RFC2119].
本文档详细介绍了“关于IETF传输协议提供的传输功能的使用”[RFC8303]中使用的UDP和UDP Lite的pass 1分析。它使用该文件中定义的通用术语，并引用使用RFC 2119[RFC2119]术语的RFC。
UDP [RFC0768] [RFC8200] and UDP-Lite [RFC3828] are IETF Standards Track transport protocols. These protocols provide unidirectional, datagram services, supporting transmit and receive operations that preserve message boundaries.
UDP[RFC0768][RFC8200]和UDP Lite[RFC3828]是IETF标准的轨道传输协议。这些协议提供单向数据报服务，支持保留消息边界的发送和接收操作。
This section summarizes the relevant text parts of the RFCs describing the UDP and UDP-Lite protocols, focusing on what the transport protocols provide to the application and how the transport is used (based on abstract API descriptions, where they are available). It describes how UDP is used with IPv4 or IPv6 to send unicast or anycast datagrams and is used to send broadcast datagrams for IPv4. A set of network-layer primitives required to use UDP or UDP-Lite with IP multicast (for IPv4 and IPv6) have been specified in the RFC series. Appendix A describes where to find documentation for network-layer primitives required to use UDP or UDP-Lite with IP multicast (for IPv4 and IPv6).
本节总结RFC中描述UDP和UDP Lite协议的相关文本部分，重点介绍传输协议为应用程序提供的内容以及如何使用传输（基于抽象API描述，如果可用）。它描述了UDP如何与IPv4或IPv6一起用于发送单播或选播数据报，以及如何用于发送IPv4的广播数据报。RFC系列中指定了将UDP或UDP Lite与IP多播（用于IPv4和IPv6）一起使用所需的一组网络层原语。附录A描述了在何处查找将UDP或UDP Lite与IP多播（用于IPv4和IPv6）一起使用所需的网络层原语的文档。
"User Datagram Protocol" [RFC0768] states:
“用户数据报协议”[RFC0768]规定：
This User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks...This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism.
此用户数据报协议（UDP）定义为在一组互连的计算机网络环境中提供分组交换计算机通信的数据报模式。此协议为应用程序提供了一个程序，以最少的协议机制向其他程序发送消息。
The User Interface section of RFC 768 states that the user interface to an application should allow
RFC 768的用户界面部分指出，应用程序的用户界面应允许
the creation of new receive ports, receive operations on the receive ports that return the data octets and an indication of source port and source address, and an operation that allows a datagram to be sent, specifying the data, source and destination ports and addresses to be sent.
创建新的接收端口，在接收端口上执行接收操作，返回数据八位字节并指示源端口和源地址，以及允许发送数据报的操作，指定要发送的数据、源端口和目标端口以及地址。
UDP has been defined for IPv6 [RFC8200], together with API extensions for "Basic Socket Interface Extensions for IPv6" [RFC3493].
已经为IPv6[RFC8200]定义了UDP，并为“IPv6的基本套接字接口扩展”[RFC3493]定义了API扩展。
[RFC6935] and [RFC6936] define an update to the UDP transport originally specified in [RFC2460] (note that RFC 2460 has been obsoleted by RFC 8200). This enables use of a zero UDP checksum mode with a tunnel protocol, providing that the method satisfies the requirements in the corresponding applicability statement [RFC6936].
[RFC6935]和[RFC6936]定义了对[RFC2460]中最初指定的UDP传输的更新（注意，RFC 2460已被RFC 8200淘汰）。这允许在隧道协议中使用零UDP校验和模式，前提是该方法满足相应适用性声明[RFC6936]中的要求。
UDP offers only a basic transport interface. UDP datagrams may be directly sent and received, without exchanging messages between the endpoints to set up a connection (i.e., no handshake is performed by the transport protocol prior to communication). Using the sockets API, applications can receive packets from more than one IP source address on a single UDP socket. Common support allows specification of the local IP address, destination IP address, local port, and destination port values. Any or all of these can be indicated, with defaults supplied by the local system when these are not specified. The local endpoint address is set using the BIND call. At the remote end, the remote endpoint address is set using the CONNECT call. The CLOSE function has local significance only. It does not impact the status of the remote endpoint.
UDP只提供基本的传输接口。UDP数据报可以直接发送和接收，而无需在端点之间交换消息以建立连接（即，在通信之前传输协议不执行握手）。使用套接字API，应用程序可以在单个UDP套接字上从多个IP源地址接收数据包。公共支持允许指定本地IP地址、目标IP地址、本地端口和目标端口值。可以指示其中任何一个或全部，未指定时，由本地系统提供默认值。本地端点地址是使用BIND调用设置的。在远程端，使用CONNECT调用设置远程端点地址。关闭功能仅具有局部意义。它不会影响远程端点的状态。
Neither UDP nor UDP-Lite provide congestion control, retransmission, or mechanisms for application-level packetization that would avoid IP fragmentation and other transport functions. This means that applications using UDP need to provide additional functions on top of the UDP transport API [RFC8085]. Some transport functions require parameters to be passed through the API to control the network layer (IPv4 or IPv6). These additional primitives could be considered a part of the network layer (e.g., control of the setting of the Don't Fragment (DF) flag on a transmitted IPv4 datagram) but are nonetheless essential to allow a user of the UDP API to implement functions that are normally associated with the transport layer (such as probing for the path maximum transmission size). This document includes such primitives.
UDP和UDP Lite都不提供拥塞控制、重传或应用程序级分组机制，以避免IP碎片和其他传输功能。这意味着使用UDP的应用程序需要在UDP传输API[RFC8085]之上提供额外的功能。某些传输功能要求通过API传递参数以控制网络层（IPv4或IPv6）。这些附加原语可以被视为网络层的一部分（例如，控制传输的IPv4数据报上的不分段（DF）标志的设置），但对于允许UDP API的用户实现通常与传输层相关联的功能来说是必不可少的（例如探测路径最大传输大小）。本文档包括此类原语。
Guidance on the use of the services provided by UDP is provided in the UDP Guidelines [RFC8085]. This also states that
UDP指南[RFC8085]中提供了使用UDP提供的服务的指南。这也表明
many operating systems also allow a UDP socket to be connected, i.e., to bind a UDP socket to a specific pair of addresses and ports. This is similar to the corresponding TCP sockets API functionality. However, for UDP, this is only a local operation that serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports. Binding a UDP socket does not establish a connection -- UDP does not notify the remote end when a local UDP socket is bound. Binding a socket also allows configuring options that affect the UDP or IP layers, for example, use of the UDP checksum or the IP Timestamp option. On some stacks, a bound socket also allows an application to be notified when ICMP error messages are received for its transmissions [RFC1122].
许多操作系统还允许连接UDP套接字，即将UDP套接字绑定到特定的地址和端口对。这类似于相应的TCP套接字API功能。但是，对于UDP，这只是一个本地操作，用于简化本地发送/接收功能并过滤指定地址和端口的通信量。绑定UDP套接字不会建立连接——绑定本地UDP套接字时，UDP不会通知远程端。绑定套接字还允许配置影响UDP或IP层的选项，例如，使用UDP校验和或IP时间戳选项。在某些堆栈上，绑定套接字还允许在收到ICMP错误消息进行传输时通知应用程序[RFC1122]。
The POSIX Base Specifications [POSIX] define an API that offers mechanisms for an application to receive asynchronous data events at the socket layer. Calls such as "poll", "select", or "queue" allow an application to be notified when data has arrived at a socket or when a socket has flushed its buffers.
POSIX基本规范[POSIX]定义了一个API，该API为应用程序提供了在套接字层接收异步数据事件的机制。“poll”、“select”或“queue”等调用允许在数据到达套接字或套接字刷新其缓冲区时通知应用程序。
A callback-driven API to the network interface can be structured on top of these calls. Implicit connection setup allows an application to delegate connection life management to the transport API. The transport API uses protocol primitives to offer the automated service to the application via the sockets API. By combining UDP primitives (CONNECT.UDP and SEND.UDP), a higher-level API could offer a similar service.
可以在这些调用的基础上构造网络接口的回调驱动API。隐式连接设置允许应用程序将连接寿命管理委托给传输API。传输API使用协议原语通过套接字API向应用程序提供自动化服务。通过组合UDP原语（CONNECT.UDP和SEND.UDP），更高级别的API可以提供类似的服务。
The following datagram primitives are specified:
指定了以下数据报原语：
CONNECT: The CONNECT primitive allows the association of source and destination port sets to a socket to enable creation of a 'connection' for UDP traffic. This UDP connection allows an application to be notified of errors received from the network stack and provides a shorthand access to the SEND and RECEIVE primitives. Since UDP is itself connectionless, no datagrams are sent because this primitive is executed. A further connect call can be used to change the association.
CONNECT：CONNECT原语允许将源端口集和目标端口集关联到套接字，以便为UDP通信创建“连接”。此UDP连接允许应用程序收到来自网络堆栈的错误通知，并提供对发送和接收原语的速记访问。由于UDP本身是无连接的，因此不会发送数据报，因为此原语已执行。可以使用进一步的connect调用来更改关联。
The roles of a client and a server are often not appropriate for UDP, where connections can be peer-to-peer. The listening functions are performed using one of the forms of the CONNECT primitive:
客户端和服务器的角色通常不适用于UDP，因为UDP中的连接可以是对等的。侦听功能使用连接原语的一种形式执行：
1. bind(): A bind operation sets the local port either implicitly, triggered by a "sendto" operation on an unbound unconnected socket using an ephemeral port, or by an explicit "bind" to use a configured or well-known port.
1. bind（）：bind操作隐式设置本地端口，由使用临时端口的未绑定未连接套接字上的“sendto”操作触发，或由显式“bind”使用已配置或已知的端口触发。
2. bind(); connect(): A bind operation that is followed by a CONNECT primitive. The bind operation establishes the use of a known local port for datagrams rather than using an ephemeral port. The connect operation specifies a known address port combination to be used by default for future datagrams. This form either is used after receiving a datagram from an endpoint that causes the creation of a connection or can be triggered by a third-party configuration or a protocol trigger (such as reception of a UDP Service Description Protocol (SDP) [RFC4566] record).
2. bind（）；connect（）：后跟connect原语的绑定操作。bind操作为数据报使用已知的本地端口，而不是临时端口。connect操作指定默认情况下用于未来数据报的已知地址端口组合。此表单在从端点接收数据报后使用，该数据报导致连接的创建，或者可以由第三方配置或协议触发器触发（例如接收UDP服务描述协议（SDP）[RFC4566]记录）。
SEND: The SEND primitive hands over a provided number of bytes that UDP should send to the other side of a UDP connection in a UDP datagram. The primitive can be used by an application to directly send datagrams to an endpoint defined by an address/port pair. If a connection has been created, then the address/port pair is inferred from the current connection for the socket. Connecting a socket allows network errors to be returned to the application as a notification on the SEND primitive. Messages passed to the SEND primitive that cannot be sent atomically in an IP packet will not be sent by the network layer, generating an error.
SEND：SEND原语将UDP应发送到UDP数据报中UDP连接另一端的指定字节数传递给用户。应用程序可以使用原语将数据报直接发送到由地址/端口对定义的端点。如果已创建连接，则从套接字的当前连接推断地址/端口对。连接套接字允许将网络错误作为发送原语上的通知返回给应用程序。传递给发送原语的无法在IP数据包中自动发送的消息将不会由网络层发送，从而产生错误。
RECEIVE: The RECEIVE primitive allocates a receiving buffer to accommodate a received datagram. The primitive returns the number of bytes provided from a received UDP datagram. Section 4.1.3.5 of the requirements of Internet hosts [RFC1122] states "When a UDP datagram is received, its specific-destination address MUST be passed up to the application layer."
接收：接收原语分配接收缓冲区以容纳接收到的数据报。原语返回接收到的UDP数据报提供的字节数。互联网主机要求[RFC1122]第4.1.3.5节规定：“当接收到UDP数据报时，其特定目的地地址必须向上传递到应用层。”
CHECKSUM_ENABLED: The optional CHECKSUM_ENABLED primitive controls whether a sender enables the UDP checksum when sending datagrams [RFC0768] [RFC6935] [RFC6936] [RFC8085]. When unset, this overrides the default UDP behavior, disabling the checksum on sending. Section 4.1.3.4 of the requirements for Internet hosts [RFC1122] states that "An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on."
启用校验和：可选的启用校验和原语控制发送方在发送数据报[RFC0768][RFC6935][RFC6936][RFC8085]时是否启用UDP校验和。取消设置时，将覆盖默认UDP行为，禁用发送时的校验和。互联网主机要求[RFC1122]第4.1.3.4节规定，“应用程序可以选择控制是否生成UDP校验和，但必须默认为打开校验和。”
REQUIRE_CHECKSUM: The optional REQUIRE_CHECKSUM primitive determines whether UDP datagrams received with a zero checksum are permitted or discarded; UDP defaults to requiring checksums. Section 4.1.3.4 of the requirements for Internet hosts [RFC1122] states that "An application MAY optionally be able to control whether UDP datagrams without checksums should be discarded or passed to the application." Section 3.1 of the specification for UDP-Lite [RFC3828] requires that the checksum field be non-zero; hence, the UDP-Lite API must discard all datagrams received with a zero checksum.
REQUIRE_CHECKSUM：可选的REQUIRE_CHECKSUM原语确定是否允许或丢弃使用零校验和接收的UDP数据报；UDP默认要求校验和。互联网主机要求[RFC1122]第4.1.3.4节规定，“应用程序可以选择性地控制不带校验和的UDP数据报是否应丢弃或传递给应用程序。”UDP Lite规范[RFC3828]第3.1节要求校验和字段为非零；因此，UDP Lite API必须丢弃使用零校验和接收的所有数据报。
SET_IP_OPTIONS: The SET_IP_OPTIONS primitive requests the network layer to send a datagram with the specified IP options. Section 4.1.3.2 of the requirements for Internet hosts [RFC1122] states that an "application MUST be able to specify IP options to be sent in its UDP datagrams, and UDP MUST pass these options to the IP layer."
SET_IP_OPTIONS:SET_IP_OPTIONS原语请求网络层发送具有指定IP选项的数据报。互联网主机要求[RFC1122]第4.1.3.2节规定，“应用程序必须能够指定在其UDP数据报中发送的IP选项，并且UDP必须将这些选项传递给IP层。”
GET_IP_OPTIONS: The GET_IP_OPTIONS primitive retrieves the IP options of a datagram received at the network layer. Section 4.1.3.2 of the requirements for Internet hosts [RFC1122] states that a UDP receiver "MUST pass any IP option that it receives from the IP layer transparently to the application layer."
GET_IP_选项：GET_IP_选项原语检索在网络层接收的数据报的IP选项。互联网主机要求[RFC1122]第4.1.3.2节规定，UDP接收器“必须将其从IP层接收的任何IP选项透明地传递给应用层。”
SET_DF: The SET_DF primitive allows the network layer to fragment packets using the Fragment Offset in IPv4 [RFC6864] and a host to use Fragment Headers in IPv6 [RFC8200]. The SET_DF primitive sets the Don't Fragment (DF) flag in the IPv4 packet header that carries a UDP datagram, which allows routers to fragment IPv4 packets. Although some specific applications rely on fragmentation support, in general, a UDP application should implement a method that avoids IP fragmentation (Section 4 of [RFC8085]). NOTE: In many other IETF transports (e.g., TCP and the Stream Control Transmission Protocol (SCTP)), the transport provides the support needed to use DF. However, when using UDP, the application is responsible for the techniques needed to discover the effective Path MTU (PMTU) allowed on the network path, coordinating with the network layer. Classical Path MTU Discovery (PMTUD) [RFC1191] relies upon the network path returning ICMP Fragmentation Needed or ICMPv6 Packet Too Big messages to the sender. When these ICMP messages are not delivered (or filtered), a sender is unable to learn the actual PMTU, and UDP datagrams larger than the PMTU will be "black holed". To avoid this, an application can instead implement Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] that does not rely upon network
SET_DF:SET_DF原语允许网络层使用IPv4[RFC6864]中的片段偏移量对数据包进行分段，而主机使用IPv6[RFC8200]中的片段头。SET_DF原语在携带UDP数据报的IPv4数据包头中设置不分段（DF）标志，该标志允许路由器对IPv4数据包进行分段。尽管某些特定应用程序依赖于分段支持，但通常情况下，UDP应用程序应实现一种避免IP分段的方法（RFC8085第4节）。注：在许多其他IETF传输中（例如TCP和流控制传输协议（SCTP）），传输提供使用DF所需的支持。但是，当使用UDP时，应用程序负责发现网络路径上允许的有效路径MTU（PMTU）所需的技术，并与网络层协调。经典路径MTU发现（PMTUD）[RFC1191]依赖于向发送方返回所需ICMP碎片或ICMPv6数据包过大消息的网络路径。当这些ICMP消息未传递（或过滤）时，发送方无法了解实际的PMTU，并且大于PMTU的UDP数据报将被“黑洞”。为了避免这种情况，应用程序可以实现不依赖于网络的分组化层路径MTU发现（PLPMTUD）[RFC4821]
support for ICMPv6 messages and is therefore considered more robust than standard PMTUD, as recommended in [RFC8085] and [RFC8201].
支持ICMPv6消息，因此被认为比[RFC8085]和[RFC8201]中建议的标准PMTUD更健壮。
GET_MMS_S: The GET_MMS_S primitive retrieves a network-layer value that indicates the maximum message size (MMS) that may be sent at the transport layer using a non-fragmented IP packet from the configured interface. This value is specified in Section 6.1 of [RFC1191] and Section 5.1 of [RFC8201]. It is calculated from Effective MTU for Sending (EMTU_S) and the link MTU for the given source IP address. This takes into account the size of the IP header plus space reserved by the IP layer for additional headers (if any). UDP applications should use this value as part of a method to avoid sending UDP datagrams that would result in IP packets that exceed the effective PMTU allowed across the network path. The effective PMTU (specified in Section 1 of [RFC1191]) is equivalent to the EMTU_S (specified in [RFC1122]). The specification of PLPMTUD [RFC4821] states:
GET_MMS_S:GET_MMS_S原语检索网络层值，该值指示可在传输层使用来自配置接口的非分段IP数据包发送的最大消息大小（MMS）。[RFC1191]第6.1节和[RFC8201]第5.1节规定了该值。它是根据发送的有效MTU（EMTU_S）和给定源IP地址的链路MTU计算得出的。这将考虑IP头的大小加上IP层为其他头保留的空间（如果有）。UDP应用程序应使用此值作为方法的一部分，以避免发送UDP数据报，从而导致IP数据包超过网络路径上允许的有效PMTU。有效PMTU（在[RFC1191]第1节中规定）等同于EMTU（在[RFC1122]中规定）。PLPMTUD[RFC4821]的规范规定：
If PLPMTUD updates the MTU for a particular path, all Packetization Layer sessions that share the path representation (as described in Section 5.2) SHOULD be notified to make use of the new MTU and make the required congestion control adjustments.
如果PLPMTUD更新特定路径的MTU，则应通知共享路径表示（如第5.2节所述）的所有分组层会话使用新的MTU并进行所需的拥塞控制调整。
GET_MMS_R: The GET_MMS_R primitive retrieves a network-layer value that indicates the MMS that may be received at the transport layer from the configured interface. This value is specified in Section 3.1 of [RFC1191]. It is calculated from Effective MTU for Receiving (EMTU_R) and the link MTU for the given source IP address, and it takes into account the size of the IP header plus space reserved by the IP layer for additional headers (if any).
GET_MMS_R：GET_MMS_R原语检索网络层值，该值指示传输层可能从配置的接口接收的MMS。[RFC1191]第3.1节规定了该值。它是根据用于接收的有效MTU（EMTU_R）和给定源IP地址的链路MTU计算得出的，它考虑了IP报头的大小加上IP层为附加报头保留的空间（如果有）。
SET_TTL: The SET_TTL primitive sets the Hop Limit (TTL field) in the network layer that is used in the IPv4 header of a packet that carries a UDP datagram. This is used to limit the scope of unicast datagrams. Section 3.2.2.4 of the requirements for Internet hosts [RFC1122] states that "An incoming Time Exceeded message MUST be passed to the transport layer."
SET_TTL:SET_TTL原语设置网络层中的跃点限制（TTL字段），该限制用于承载UDP数据报的数据包的IPv4报头。这用于限制单播数据报的范围。互联网主机要求[RFC1122]第3.2.2.4节规定，“必须将传入的超时消息传递给传输层。”
GET_TTL: The GET_TTL primitive retrieves the value of the TTL field in an IP packet received at the network layer. An application using the Generalized TTL Security Mechanism (GTSM) [RFC5082] can use this information to trust datagrams with a TTL value within the expected range, as described in Section 3 of RFC 5082.
GET_TTL:GET_TTL原语检索在网络层接收的IP数据包中TTL字段的值。使用通用TTL安全机制（GTSM）[RFC5082]的应用程序可以使用此信息信任TTL值在预期范围内的数据报，如RFC 5082第3节所述。
SET_MIN_TTL: The SET_MIN_TTL primitive restricts datagrams delivered to the application to those received with an IP TTL value greater than or equal to the passed parameter. This primitive can be used to implement applications such as GTSM [RFC5082] too, as described in Section 3 of RFC 5082, but this RFC does not specify this method.
SET_MIN_TTL:SET_MIN_TTL原语将发送到应用程序的数据报限制为IP TTL值大于或等于传递参数的数据报。如RFC 5082第3节所述，此原语也可用于实现GTSM[RFC5082]等应用程序，但此RFC未指定此方法。
SET_IPV6_UNICAST_HOPS: The SET_IPV6_UNICAST_HOPS primitive sets the network-layer Hop Limit field in an IPv6 packet header [RFC8200] carrying a UDP datagram. For IPv6 unicast datagrams, this is functionally equivalent to the SET_TTL IPv4 function.
SET_IPV6_UNICAST_HOPS：SET_IPV6_UNICAST_HOPS原语在承载UDP数据报的IPV6数据包头[RFC8200]中设置网络层跃点限制字段。对于IPv6单播数据报，这在功能上等同于SET_TTL IPv4功能。
GET_IPV6_UNICAST_HOPS: The GET_IPV6_UNICAST_HOPS primitive is a network-layer function that reads the hop count in the IPv6 header [RFC8200] information of a received UDP datagram. This is specified in Section 6.3 of RFC 3542. For IPv6 unicast datagrams, this is functionally equivalent to the GET_TTL IPv4 function.
GET_IPV6_UNICAST_HOPS：GET_IPV6_UNICAST_HOPS原语是一个网络层函数，用于读取已接收UDP数据报的IPV6头[RFC8200]信息中的跳数。RFC 3542第6.3节对此进行了规定。对于IPv6单播数据报，这在功能上等同于GET_TTL IPv4函数。
SET_DSCP: The SET_DSCP primitive is a network-layer function that
sets the DSCP (or the legacy Type of Service (ToS)) value
[RFC2474] to be used in the field of an IP header of a packet that
carries a UDP datagram. Section 2.4 of the requirements for
Internet hosts [RFC1123] states that "Applications MUST select
appropriate ToS values when they invoke transport layer services,
and these values MUST be configurable." The application should be
able to change the ToS during the connection lifetime, and the ToS
value should be passed to the IP layer unchanged. Section 4.1.4
of [RFC1122] also states that on reception the "UDP MAY pass the
received ToS up to the application layer." The Diffserv model
[RFC2475] [RFC3260] replaces this field in the IP header assigning
the six most significant bits to carry the DSCP field [RFC2474].
Preserving the intention of the host requirements [RFC1122] to
allow the application to specify the "Type of Service" should be
interpreted to mean that an API should allow the application to
set the DSCP. Section 3.1.8 of the UDP Guidelines [RFC8085]
describes the way UDP applications should use this field.
Normally, a UDP socket will assign a single DSCP value to all
datagrams in a flow, but a sender is allowed to use different DSCP
values for datagrams within the same flow in certain cases
[RFC8085]. There are guidelines for WebRTC that illustrate this
use [RFC7657].
SET_DSCP: The SET_DSCP primitive is a network-layer function that
sets the DSCP (or the legacy Type of Service (ToS)) value
[RFC2474] to be used in the field of an IP header of a packet that
carries a UDP datagram. Section 2.4 of the requirements for
Internet hosts [RFC1123] states that "Applications MUST select
appropriate ToS values when they invoke transport layer services,
and these values MUST be configurable." The application should be
able to change the ToS during the connection lifetime, and the ToS
value should be passed to the IP layer unchanged. Section 4.1.4
of [RFC1122] also states that on reception the "UDP MAY pass the
received ToS up to the application layer." The Diffserv model
[RFC2475] [RFC3260] replaces this field in the IP header assigning
the six most significant bits to carry the DSCP field [RFC2474].
Preserving the intention of the host requirements [RFC1122] to
allow the application to specify the "Type of Service" should be
interpreted to mean that an API should allow the application to
set the DSCP. Section 3.1.8 of the UDP Guidelines [RFC8085]
describes the way UDP applications should use this field.
Normally, a UDP socket will assign a single DSCP value to all
datagrams in a flow, but a sender is allowed to use different DSCP
values for datagrams within the same flow in certain cases
[RFC8085]. There are guidelines for WebRTC that illustrate this
use [RFC7657].
SET_ECN: The SET_ECN primitive is a network-layer function that sets the Explicit Congestion Notification (ECN) field in the IP header of a UDP datagram. The ECN field defaults to a value of 00. When the use of the ToS field was redefined by Diffserv [RFC3260], 2 bits of the field were assigned to support ECN [RFC3168]. Section 3.1.5 of the UDP Guidelines [RFC8085] describes the way
SET_ECN:SET_ECN原语是一个网络层函数，用于在UDP数据报的IP报头中设置显式拥塞通知（ECN）字段。ECN字段的默认值为00。当ToS字段的使用由Diffserv[RFC3260]重新定义时，该字段的2位被分配用于支持ECN[RFC3168]。UDP指南[RFC8085]第3.1.5节描述了方法
UDP applications should use this field. NOTE: In many other IETF transports (e.g., TCP), the transport provides the support needed to use ECN; when using UDP, the application or higher-layer protocol is itself responsible for the techniques needed to use ECN.
UDP应用程序应使用此字段。注：在许多其他IETF传输（如TCP）中，传输提供使用ECN所需的支持；使用UDP时，应用程序或更高层协议本身负责使用ECN所需的技术。
GET_ECN: The GET_ECN primitive is a network-layer function that returns the value of the ECN field in the IP header of a received UDP datagram. Section 3.1.5 of [RFC8085] states that a UDP receiver "MUST check the ECN field at the receiver for each UDP datagram that it receives on this port", requiring the UDP receiver API to pass the received ECN field up to the application layer to enable appropriate congestion feedback.
GET_ECN:GET_ECN原语是一个网络层函数，返回接收到的UDP数据报的IP报头中的ECN字段值。[RFC8085]的第3.1.5节规定，UDP接收器“必须检查接收器处的ECN字段，以查看其在此端口上接收的每个UDP数据报”，要求UDP接收器API将接收到的ECN字段传递到应用层，以启用适当的拥塞反馈。
ERROR_REPORT: The ERROR_REPORT event informs an application of "soft errors", including the arrival of an ICMP or ICMPv6 error message. Section 4.1.4 of the requirements for Internet hosts [RFC1122] states that "UDP MUST pass to the application layer all ICMP error messages that it receives from the IP layer." For example, this event is required to implement ICMP-based Path MTU Discovery [RFC1191] [RFC8201]. UDP applications must perform a CONNECT to receive ICMP errors.
错误报告：错误报告事件通知应用程序“软错误”，包括ICMP或ICMPv6错误消息的到达。互联网主机要求[RFC1122]第4.1.4节规定“UDP必须将其从IP层接收到的所有ICMP错误消息传递给应用层”。例如，实施基于ICMP的路径MTU发现[RFC1191][RFC8201]需要此事件。UDP应用程序必须执行连接才能接收ICMP错误。
CLOSE: The CLOSE primitive closes a connection. No further datagrams can be sent or received. Since UDP is itself connectionless, no datagrams are sent when this primitive is executed.
CLOSE：CLOSE原语关闭连接。无法发送或接收更多数据报。由于UDP本身是无连接的，因此在执行此原语时不会发送数据报。
In the requirements for Internet hosts [RFC1122], Section 3.4 describes GET_MAXSIZES and ADVISE_DELIVPROB, and Section 3.3.4.4 describes GET_SRCADDR. These mechanisms are no longer used. It also specifies use of the Source Quench ICMP message, which has since been deprecated [RFC6633].
在互联网主机要求[RFC1122]中，第3.4节描述了GET_MAXSIZES和ADVISE_DeliverProb，第3.3.4.4节描述了GET_SRCADDR。这些机制不再使用。它还指定了源猝灭ICMP消息的使用，该消息已被弃用[RFC6633]。
The IPV6_V6ONLY function is a network-layer primitive that applies to all transport services, as defined in Section 5.3 of the basic socket interface for IPv6 [RFC3493]. This restricts the use of information from the name resolver to only allow communication of AF_INET6 sockets to use IPv6 only. This is not considered part of the transport service.
IPV6_V6ONLY函数是一个网络层原语，适用于所有传输服务，如IPV6基本套接字接口[RFC3493]第5.3节所定义。这限制了名称解析程序中信息的使用，仅允许AF_INET6套接字的通信仅使用IPv6。这不被视为运输服务的一部分。
UDP-Lite [RFC3828] provides similar services to UDP. It changed the semantics of the UDP "payload length" field to that of a "checksum coverage length" field. UDP-Lite requires the pseudo-header checksum to be computed at the sender and checked at a receiver. Apart from the length and coverage changes, UDP-Lite is semantically identical to UDP.
UDP Lite[RFC3828]提供与UDP类似的服务。它将UDP“有效负载长度”字段的语义更改为“校验和覆盖长度”字段的语义。UDP Lite要求在发送方计算伪报头校验和，在接收方检查伪报头校验和。除了长度和覆盖范围的变化外，UDP Lite在语义上与UDP相同。
The sending interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that communicates the checksum coverage length. This specifies the intended checksum coverage, with the remaining unprotected part of the payload called the "error-insensitive part".
UDP Lite的发送接口与UDP的不同之处在于添加了一个（套接字）选项，用于通信校验和覆盖长度。这指定了预期的校验和覆盖范围，有效负载的剩余未受保护部分称为“错误不敏感部分”。
The receiving interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that specifies the minimum acceptable checksum coverage. The UDP-Lite Management Information Base (MIB) [RFC5097] further defines the checksum coverage method. Guidance on the use of services provided by UDP-Lite is provided in the UDP Guidelines [RFC8085].
UDP Lite的接收接口与UDP的不同之处在于添加了一个（套接字）选项，该选项指定可接受的最小校验和覆盖率。UDP Lite管理信息库（MIB）[RFC5097]进一步定义了校验和覆盖率方法。UDP指南[RFC8085]中提供了有关使用UDP Lite提供的服务的指南。
UDP-Lite requires use of the UDP or UDP-Lite checksum; hence, it is not permitted to use the DISABLE_CHECKSUM function to disable use of a checksum, nor is it possible to disable receiver checksum processing using the REQUIRE_CHECKSUM function. All other primitives and functions for UDP are permitted.
UDP Lite需要使用UDP或UDP Lite校验和；因此，不允许使用DISABLE_CHECKSUM函数来禁用校验和的使用，也不可能使用REQUIRE_CHECKSUM函数来禁用接收器校验和处理。允许使用UDP的所有其他原语和函数。
In addition, the following are defined:
此外，定义了以下内容：
SET_CHECKSUM_COVERAGE: The SET_CHECKSUM_COVERAGE primitive sets the coverage area for a sent datagram. UDP-Lite traffic uses this primitive to set the coverage length provided by the UDP checksum. Section 3.3 of the UDP-Lite specification [RFC3828] states that "Applications that wish to define the payload as partially insensitive to bit errors...should do this by an explicit system call on the sender side." The default is to provide the same coverage as for UDP.
SET_CHECKSUM_COVERAGE:SET_CHECKSUM_COVERAGE原语为发送的数据报设置覆盖区域。UDP Lite通信使用此原语设置UDP校验和提供的覆盖长度。UDP Lite规范[RFC3828]第3.3节规定，“希望将有效负载定义为对位错误部分不敏感的应用程序……应通过发送方的显式系统调用来实现此目的。”默认情况下，提供与UDP相同的覆盖范围。
SET_MIN_COVERAGE: The SET_MIN_COVERAGE primitive sets the minimum acceptable coverage protection for received datagrams. UDP-Lite traffic uses this primitive to set the coverage length that is checked on receive. (Section 1.1 of [RFC5097] describes the corresponding MIB entry as udpliteEndpointMinCoverage.) Section 3.3 of the UDP-Lite specification [RFC3828] states that "Applications that wish to receive payloads that were only
SET_MIN_COVERAGE:SET_MIN_COVERAGE原语为接收到的数据报设置最小可接受覆盖保护。UDP Lite通信使用此原语设置接收时检查的覆盖范围长度。（RFC5097的第1.1节将相应的MIB条目描述为udpliteEndpointMinCoverage。）UDP Lite规范[RFC3828]的第3.3节指出，“希望接收有效负载的应用程序仅限于
partially covered by a checksum should inform the receiving system by an explicit system call." The default is to require only minimal coverage of the datagram payload.
部分由校验和覆盖的数据应通过显式系统调用通知接收系统。“默认情况下，只需要对数据报有效负载进行最小覆盖。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
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]中提供了应用程序使用的安全指南。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<https://www.rfc-editor.org/info/rfc768>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，DOI 10.17487/RFC1112，1989年8月<https://www.rfc-editor.org/info/rfc1112>.
[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>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，DOI 10.17487/RFC1123，1989年10月<https://www.rfc-editor.org/info/rfc1123>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC 1191，DOI 10.17487/RFC1191，1990年11月<https://www.rfc-editor.org/info/rfc1191>.
[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>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<https://www.rfc-editor.org/info/rfc3168>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003, <https://www.rfc-editor.org/info/rfc3493>.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，DOI 10.17487/RFC3493，2003年2月<https://www.rfc-editor.org/info/rfc3493>.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, <https://www.rfc-editor.org/info/rfc3828>.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，Ed.，和G.Fairhurst，Ed.，“轻量级用户数据报协议（UDP Lite）”，RFC 3828，DOI 10.17487/RFC3828，2004年7月<https://www.rfc-editor.org/info/rfc3828>.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, February 2013, <https://www.rfc-editor.org/info/rfc6864>.
[RFC6864]Touch，J.，“IPv4 ID字段的更新规范”，RFC 6864，DOI 10.17487/RFC6864，2013年2月<https://www.rfc-editor.org/info/rfc6864>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>.
[RFC6935]Eubanks，M.，Chimento，P.，和M.Westerlund，“隧道数据包的IPv6和UDP校验和”，RFC 6935，DOI 10.17487/RFC6935，2013年4月<https://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>.
[RFC6936]Fairhurst，G.和M.Westerlund，“使用具有零校验和的IPv6 UDP数据报的适用性声明”，RFC 6936，DOI 10.17487/RFC6936，2013年4月<https://www.rfc-editor.org/info/rfc6936>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，STD 86，RFC 8200，DOI 10.17487/RFC8200，2017年7月<https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201]McCann，J.，Deering，S.，Mogul，J.，和R.Hinden，编辑，“IP版本6的路径MTU发现”，STD 87，RFC 8201，DOI 10.17487/RFC8201，2017年7月<https://www.rfc-editor.org/info/rfc8201>.
[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of Transport Features Provided by IETF Transport Protocols", RFC 8303, DOI 10.17487/RFC8303, February 2018, <https://www.rfc-editor.org/info/rfc8303>.
[RFC8303]Welzl，M.，Tuexen，M.，和N.Khademi，“关于IETF传输协议提供的传输功能的使用”，RFC 8303，DOI 10.17487/RFC8303，2018年2月<https://www.rfc-editor.org/info/rfc8303>.
[POSIX] IEEE, "Standard for Information Technology - Portable Operating System Interface (POSIX(R)) Base Specifications", Issue 7, IEEE 1003.1, <http://ieeexplore.ieee.org/document/7582338/>.
[POSIX]IEEE，“信息技术标准-便携式操作系统接口（POSIX（R））基本规范”，第7期，IEEE 1003.1<http://ieeexplore.ieee.org/document/7582338/>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<https://www.rfc-editor.org/info/rfc2460>.
[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>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，版本3”，RFC 3376，DOI 10.17487/RFC3376，2002年10月<https://www.rfc-editor.org/info/rfc3376>.
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, DOI 10.17487/RFC3678, January 2004, <https://www.rfc-editor.org/info/rfc3678>.
[RFC3678]Thaler，D.，Fenner，B.，和B.Quinn，“多播源筛选器的套接字接口扩展”，RFC 3678，DOI 10.17487/RFC3678，2004年1月<https://www.rfc-editor.org/info/rfc3678>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.
[RFC3810]Vida，R.，Ed.和L.Costa，Ed.，“IPv6的多播侦听器发现版本2（MLDv2）”，RFC 3810，DOI 10.17487/RFC3810，2004年6月<https://www.rfc-editor.org/info/rfc3810>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<https://www.rfc-editor.org/info/rfc4566>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, August 2006, <https://www.rfc-editor.org/info/rfc4604>.
[RFC4604]Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，DOI 10.17487/RFC4604，2006年8月<https://www.rfc-editor.org/info/rfc4604>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 4821，DOI 10.17487/RFC4821，2007年3月<https://www.rfc-editor.org/info/rfc4821>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <https://www.rfc-editor.org/info/rfc5082>.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，Ed.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，DOI 10.17487/RFC5082，2007年10月<https://www.rfc-editor.org/info/rfc5082>.
[RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, <https://www.rfc-editor.org/info/rfc5097>.
[RFC5097]Renker，G.和G.Fairhurst，“UDP Lite协议的MIB”，RFC 5097，DOI 10.17487/RFC5097，2008年1月<https://www.rfc-editor.org/info/rfc5097>.
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, DOI 10.17487/RFC5790, February 2010, <https://www.rfc-editor.org/info/rfc5790>.
[RFC5790]Liu，H.，Cao，W.，和H.Asaeda，“轻量级Internet组管理协议版本3（IGMPv3）和多播侦听器发现版本2（MLDv2）协议”，RFC 5790，DOI 10.17487/RFC5790，2010年2月<https://www.rfc-editor.org/info/rfc5790>.
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, DOI 10.17487/RFC6633, May 2012, <https://www.rfc-editor.org/info/rfc6633>.
[RFC6633]Gont，F.，“ICMP源猝灭消息的弃用”，RFC 6633，DOI 10.17487/RFC6633，2012年5月<https://www.rfc-editor.org/info/rfc6633>.
[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>.
[STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network Programming, The sockets Networking API", Volume 1, ISBN-13: 9780131411555, October 2003.
[STEVENS]STEVENS，W.，Fenner，B.，和A.Rudoff，“UNIX网络编程，套接字网络API”，第1卷，ISBN-13:9780131411555，2003年10月。
This appendix describes primitives that are used when UDP and UDP-Lite support IPv4/IPv6 multicast. Multicast services are not considered by the IETF TAPS WG, but the currently specified primitives are included for completeness in this appendix. Guidance on the use of UDP and UDP-Lite for multicast services is provided in the UDP Guidelines [RFC8085].
本附录描述了UDP和UDP Lite支持IPv4/IPv6多播时使用的原语。IETF TAPS工作组不考虑多播服务，但为了完整起见，本附录中包含了当前指定的原语。UDP指南[RFC8085]中提供了有关在多播服务中使用UDP和UDP Lite的指导。
IP multicast may be supported by using the Any Source Multicast (ASM) model or the Source-Specific Multicast (SSM) model. The latter requires use of a Multicast Source Filter (MSF) when specifying an IP multicast group destination address.
可以使用任意源多播（ASM）模型或源特定多播（SSM）模型来支持IP多播。后者要求在指定IP多播组目标地址时使用多播源筛选器（MSF）。
Use of multicast requires additional primitives at the transport API that need to be called to coordinate operation of the IPv4 and IPv6 network-layer protocols. For example, to receive datagrams sent to a group, an endpoint must first become a member of a multicast group at the network layer. Local multicast reception is signaled for IPv4 by the Internet Group Management Protocol (IGMP) [RFC3376] [RFC4604]. IPv6 uses the equivalent Multicast Listener Discovery (MLD) protocol [RFC3810] [RFC5790], carried over ICMPv6. A lightweight version of these protocols has also been specified [RFC5790].
使用多播需要在传输API上调用其他原语，以协调IPv4和IPv6网络层协议的操作。例如，要接收发送到组的数据报，端点必须首先成为网络层多播组的成员。通过互联网组管理协议（IGMP）[RFC3376][RFC4604]为IPv4发送本地多播接收信号。IPv6使用通过ICMPv6传输的等效多播侦听器发现（MLD）协议[RFC3810][RFC5790]。还指定了这些协议的轻量级版本[RFC5790]。
The following are defined:
定义如下：
JoinHostGroup: Section 7.1 of "Host Extensions for IP Multicasting" [RFC1112] provides a function that allows receiving traffic from an IP multicast group.
JoinHostGroup:“IP多播的主机扩展”[RFC1112]的第7.1节提供了一个允许从IP多播组接收流量的功能。
JoinLocalGroup: Section 7.3 of "Host Extensions for IP Multicasting" [RFC1112] provides a function that allows receiving traffic from a local IP multicast group.
JoinLocalGroup:“IP多播的主机扩展”[RFC1112]的第7.3节提供了一个允许从本地IP多播组接收流量的功能。
LeaveHostGroup: Section 7.1 of "Host Extensions for IP Multicasting" [RFC1112] provides a function that allows leaving an IP multicast group.
LeaveHostGroup:“IP多播的主机扩展”[RFC1112]的第7.1节提供了允许离开IP多播组的功能。
LeaveLocalGroup: Section 7.3 of "Host Extensions for IP Multicasting" [RFC1112] provides a function that allows leaving a local IP multicast group.
LeaveLocalGroup:“IP多播的主机扩展”[RFC1112]的第7.3节提供了允许离开本地IP多播组的功能。
IPV6_MULTICAST_IF: Section 5.2 of the basic socket extensions for IPv6 [RFC3493] states that this sets the interface that will be used for outgoing multicast packets.
IPV6_MULTICAST_IF:IPV6的基本套接字扩展[RFC3493]的第5.2节指出，这将设置用于传出多播数据包的接口。
IP_MULTICAST_TTL: This sets the time-to-live field t to use for outgoing IPv4 multicast packets. This is used to limit the scope of multicast datagrams. Methods such as "The Generalized TTL Security Mechanism (GTSM)" [RFC5082] set this value to ensure link-local transmission. GTSM also requires the UDP receiver API to pass the received value of this field to the application.
IP_MULTICAST_TTL：设置用于传出IPv4多播数据包的生存时间字段t。这用于限制多播数据报的范围。“通用TTL安全机制（GTSM）”[RFC5082]等方法设置此值以确保链路本地传输。GTSM还要求UDP接收器API将此字段的接收值传递给应用程序。
IPV6_MULTICAST_HOPS: Section 5.2 of the basic socket extensions for IPv6 [RFC3493] states that this sets the hop count to use for outgoing multicast IPv6 packets. (This is equivalent to IP_MULTICAST_TTL used for IPv4 multicast.)
IPV6_多播_跃点：IPV6基本套接字扩展[RFC3493]的第5.2节指出，这将设置用于传出多播IPV6数据包的跃点计数。（这相当于用于IPv4多播的IP_多播\u TTL。）
IPV6_MULTICAST_LOOP: Section 5.2 of the basic socket extensions for IPv6 [RFC3493] states that this sets whether a copy of a datagram is looped back by the IP layer for local delivery when the datagram is sent to a group to which the sending host itself belongs).
IPV6_MULTICAST_LOOP:IPV6的基本套接字扩展[RFC3493]的第5.2节规定，当数据报发送到发送主机本身所属的组时，这将设置数据报的副本是否由IP层环回以进行本地传递。
IPV6_JOIN_GROUP: Section 5.2 of the basic socket extensions for IPv6 [RFC3493] provides a function that allows an endpoint to join an IPv6 multicast group.
IPV6_加入_组：IPV6基本套接字扩展[RFC3493]的第5.2节提供了允许端点加入IPV6多播组的功能。
SIOCGIPMSFILTER: Section 8.1 of the socket interface for MSF [RFC3678] provides a function that allows reading the multicast source filters.
SIOCGIMPSFILTER:MSF[RFC3678]套接字接口的第8.1节提供了一个允许读取多播源筛选器的函数。
SIOCSIPMSFILTER: Section 8.1 of the socket interface for MSF [RFC3678] provides a function that allows setting/modifying the multicast source filters.
SIOCSIPMSFILTER:MSF[RFC3678]套接字接口的第8.1节提供了允许设置/修改多播源筛选器的功能。
IPV6_LEAVE_GROUP: Section 5.2 of the basic socket extensions for IPv6 [RFC3493] provides a function that allows leaving an IPv6 multicast group.
IPV6_LEAVE_组：IPV6基本套接字扩展[RFC3493]的第5.2节提供了允许离开IPV6多播组的功能。
The socket interface extensions for MSF [RFC3678] updates the multicast interface to add support for MSF for IPv4 and IPv6 required by IGMPv3. Section 3 defines both basic and advanced APIs, and Section 5 describes protocol-independent versions of these APIs. Four sets of API functionality are therefore defined:
MSF的套接字接口扩展[RFC3678]更新了多播接口，以添加对IGMPv3所需的IPv4和IPv6的MSF支持。第3节定义了基本API和高级API，第5节描述了这些API的协议独立版本。因此定义了四套API功能：
1. IPv4 Basic (Delta-based) API. "Each function call specifies a single source address which should be added to or removed from the existing filter for a given multicast group address on which to listen."
1. IPv4基本（基于增量）API。“每个函数调用指定一个源地址，该地址应添加到要侦听的给定多播组地址的现有筛选器中或从中删除。”
2. IPv4 Advanced (Full-state) API. "This API allows an application to define a complete source-filter comprised of zero or more source addresses, and replace the previous filter with a new one."
2. IPv4高级（完整状态）API。此API允许应用程序定义由零个或多个源地址组成的完整源筛选器，并用新筛选器替换以前的筛选器
3. Protocol-Independent Basic MSF (Delta-based) API.
3. 独立于协议的基本MSF（基于增量）API。
4. Protocol-Independent Advanced MSF (Full-state) API.
4. 与协议无关的高级MSF（全状态）API。
It specifies the following primitives:
它指定以下基本体：
IP_ADD_MEMBERSHIP: This is used to join an ASM group.
IP_添加_成员身份：用于加入ASM组。
IP_BLOCK_SOURCE: This MSF can block data from a given multicast source to a given ASM or SSM group.
IP_BLOCK_SOURCE：此MSF可以阻止从给定多播源到给定ASM或SSM组的数据。
IP_UNBLOCK_SOURCE: This updates an MSF to undo a previous call to IP_UNBLOCK_SOURCE for an ASM or SSM group.
IP_UNBLOCK_SOURCE：这会更新MSF以撤消对ASM或SSM组的IP_UNBLOCK_SOURCE的先前调用。
IP_DROP_MEMBERSHIP: This is used to leave an ASM or SSM group. (In SSM, this drops all sources that have been joined for a particular group and interface. The operations are the same as if the socket had been closed.)
IP_DROP_成员身份：用于离开ASM或SSM组。（在SSM中，这会删除已为特定组和接口连接的所有源。操作与套接字已关闭的操作相同。）
Section 4.1.2 of the socket interface for MSF [RFC3678] updates the interface to add IPv4 MSF support to IGMPv3 using ASM:
MSF[RFC3678]套接字接口的第4.1.2节更新了接口，使用ASM将IPv4 MSF支持添加到IGMPv3：
IP_ADD_SOURCE_MEMBERSHIP: This is used to join an SSM group.
IP_添加_源_成员身份：用于加入SSM组。
IP_DROP_SOURCE_MEMBERSHIP: This is used to leave an SSM group.
IP_DROP_SOURCE_成员身份：用于离开SSM组。
Section 4.2 of the socket interface for MSF [RFC3678] defines the Advanced (Full-state) API:
MSF[RFC3678]套接字接口的第4.2节定义了高级（全状态）API：
setipv4sourcefilter: This is used to join an IPv4 multicast group or to enable multicast from a specified source.
setipv4sourcefilter：用于加入IPv4多播组或启用来自指定源的多播。
getipv4sourcefilter: This is used to leave an IPv4 multicast group or to filter multicast from a specified source.
getipv4sourcefilter：用于离开IPv4多播组或从指定源筛选多播。
Section 5.1 of the socket interface for MSF [RFC3678] specifies Protocol-Independent Multicast API functions:
MSF[RFC3678]套接字接口的第5.1节规定了与协议无关的多播API函数：
MCAST_JOIN_GROUP: This is used to join an ASM group.
MCAST_加入组：用于加入ASM组。
MCAST_JOIN_SOURCE_GROUP: This is used to join an SSM group.
MCAST\u加入\u源\u组：用于加入SSM组。
MCAST_BLOCK_SOURCE: This is used to block a source in an ASM group.
MCAST_BLOCK_SOURCE：用于阻止ASM组中的源。
MCAST_UNBLOCK_SOURCE: This removes a previous MSF set by MCAST_BLOCK_SOURCE.
MCAST_UNBLOCK_SOURCE：这将删除MCAST_BLOCK_SOURCE之前设置的MSF。
MCAST_LEAVE_GROUP: This leaves an ASM or SSM group.
MCAST_离开_组：这将离开ASM或SSM组。
MCAST_LEAVE_SOURCE_GROUP: This leaves an SSM group.
MCAST_LEAVE_SOURCE_组：这将留下一个SSM组。
Section 5.2 of the socket interface for MSF [RFC3678] specifies the Protocol-Independent Advanced MSF (Full-state) API applicable for both IPv4 and IPv6:
MSF套接字接口[RFC3678]的第5.2节规定了适用于IPv4和IPv6的与协议无关的高级MSF（完整状态）API：
setsourcefilter: This is used to join an IPv4 or IPv6 multicast group or to enable multicast from a specified source.
setsourcefilter：用于加入IPv4或IPv6多播组，或启用来自指定源的多播。
getsourcefilter: This is used to leave an IPv4 or IPv6 multicast group or to filter multicast from a specified source.
getsourcefilter：用于离开IPv4或IPv6多播组，或从指定源筛选多播。
The Lightweight IGMPv3 (LW_IGMPv3) and MLDv2 protocol [RFC5790] updates this interface (in Section 7.2 of RFC 5790).
轻型IGMPv3（LW_IGMPv3）和MLDv2协议[RFC5790]更新此接口（在RFC 5790的第7.2节中）。
Acknowledgements
致谢
This work was partially funded by the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). Thanks to all who have commented or contributed, including Joe Touch, Ted Hardie, Aaron Falk, Tommy Pauly, and Francis Dupont.
这项工作的部分资金来自欧盟地平线2020研究与创新计划（第644334号赠款协议，NEAT）。感谢所有发表评论或贡献的人，包括乔·图奇、特德·哈迪、亚伦·福尔克、汤米·保利和弗朗西斯·杜邦。
Authors' Addresses
作者地址
Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Fraser Noble Building Aberdeen AB24 3UE United Kingdom
GoRead FelHurt阿伯丁大学工程学院弗雷泽贵族大厦弗雷泽贵族大厦阿伯丁AB24 3UE英国
Email: gorry@erg.abdn.ac.uk
Email: gorry@erg.abdn.ac.uk
Tom Jones University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom
琼斯阿伯丁大学工程学院弗雷泽贵族大厦阿伯丁英国
Email: tom@erg.abdn.ac.uk
Email: tom@erg.abdn.ac.uk