[要約] RFC 8095は、IETFの輸送プロトコルと輻輳制御メカニズムによって提供されるサービスに関する情報を提供するものです。このRFCの目的は、IETFの輸送プロトコルと輻輳制御メカニズムの機能と特性を理解し、ネットワークのパフォーマンスを向上させるためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) G. Fairhurst, Ed.
Request for Comments: 8095 University of Aberdeen
Category: Informational B. Trammell, Ed.
ISSN: 2070-1721 M. Kuehlewind, Ed.
ETH Zurich
March 2017
Services Provided by IETF Transport Protocols and Congestion Control Mechanisms
IETFトランスポートプロトコルおよび輻輳制御メカニズムによって提供されるサービス
Abstract
概要
This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK-Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group.
このドキュメントでは、既存のIETFプロトコルによって提供されるプロトコルメカニズムについて、共通のトランスポートサービスセットを決定するための背景として説明、調査、および分類しています。 Transmission Control Protocol（TCP）、Multipath TCP、Stream Control Transmission Protocol（SCTP）、User Datagram Protocol（UDP）、UDP-Lite、Datagram Congestion Control Protocol（DCCP）、Internet Control Message Protocol（ICMP ）、リアルタイムトランスポートプロトコル（RTP）、一方向トランスポートを介したファイル配信/信頼性のあるマルチキャストのための非同期レイヤードコーディング（FLUTE / ALC）、NACK指向の信頼性のあるマルチキャスト（NORM）、トランスポートレイヤーセキュリティ（TLS）、データグラムTLS（DTLS ）、およびハイパーテキスト転送プロトコル（HTTP）（HTTPが疑似トランスポートとして使用される場合）。この調査は、TAPSワーキンググループ内の輸送サービスの定義の背景を提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc8095.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8095で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Overview of Transport Features .............................4
2. Terminology .....................................................5
3. Existing Transport Protocols ....................................6
3.1. Transport Control Protocol (TCP) ...........................6
3.1.1. Protocol Description ................................6
3.1.2. Interface Description ...............................8
3.1.3. Transport Features ..................................9
3.2. Multipath TCP (MPTCP) .....................................10
3.2.1. Protocol Description ...............................10
3.2.2. Interface Description ..............................10
3.2.3. Transport Features .................................11
3.3. User Datagram Protocol (UDP) ..............................11
3.3.1. Protocol Description ...............................11
3.3.2. Interface Description ..............................12
3.3.3. Transport Features .................................13
3.4. Lightweight User Datagram Protocol (UDP-Lite) .............13
3.4.1. Protocol Description ...............................13
3.4.2. Interface Description ..............................14
3.4.3. Transport Features .................................14
3.5. Stream Control Transmission Protocol (SCTP) ...............14
3.5.1. Protocol Description ...............................15
3.5.2. Interface Description ..............................17
3.5.3. Transport Features .................................19
3.6. Datagram Congestion Control Protocol (DCCP) ...............20
3.6.1. Protocol Description ...............................21
3.6.2. Interface Description ..............................22
3.6.3. Transport Features .................................22
3.7. Transport Layer Security (TLS) and Datagram TLS
(DTLS) as a Pseudotransport ...............................23
3.7.1. Protocol Description ...............................23
3.7.2. Interface Description ..............................24
3.7.3. Transport Features .................................25
3.8. Real-Time Transport Protocol (RTP) ........................26
3.8.1. Protocol Description ...............................26
3.8.2. Interface Description ..............................27
3.8.3. Transport Features .................................27
3.9. Hypertext Transport Protocol (HTTP) over TCP as a
Pseudotransport ...........................................28
3.9.1. Protocol Description ...............................28
3.9.2. Interface Description ..............................29
3.9.3. Transport Features .................................30
3.10. File Delivery over Unidirectional Transport /
Asynchronous Layered Coding (FLUTE/ALC) for
Reliable Multicast .......................................31
3.10.1. Protocol Description ..............................31
3.10.2. Interface Description .............................33
3.10.3. Transport Features ................................33
3.11. NACK-Oriented Reliable Multicast (NORM) ..................34
3.11.1. Protocol Description ..............................34
3.11.2. Interface Description .............................35
3.11.3. Transport Features ................................36
3.12. Internet Control Message Protocol (ICMP) .................36
3.12.1. Protocol Description ..............................37
3.12.2. Interface Description .............................37
3.12.3. Transport Features ................................38
4. Congestion Control .............................................38
5. Transport Features .............................................39
6. IANA Considerations ............................................42
7. Security Considerations ........................................42
8. Informative References .........................................42
Acknowledgments ...................................................53
Contributors ......................................................53
Authors' Addresses ................................................54
Internet applications make use of the services provided by a transport protocol, such as TCP (a reliable, in-order stream protocol) or UDP (an unreliable datagram protocol). We use the term "transport service" to mean the end-to-end service provided to an application by the transport layer. That service can only be provided correctly if information about the intended usage is supplied from the application. The application may determine this information at design time, compile time, or run time, and may include guidance on whether a feature is required, a preference by the application, or something in between. Examples of features of transport services are reliable delivery, ordered delivery, content privacy to in-path devices, and integrity protection.
インターネットアプリケーションは、TCP（信頼性の高い順序付けられたストリームプロトコル）またはUDP（信頼性の低いデータグラムプロトコル）などのトランスポートプロトコルによって提供されるサービスを利用します。 「トランスポートサービス」という用語は、トランスポート層によってアプリケーションに提供されるエンドツーエンドサービスを意味するために使用します。そのサービスは、使用目的に関する情報がアプリケーションから提供された場合にのみ正しく提供されます。アプリケーションは、設計時、コンパイル時、または実行時にこの情報を決定し、機能が必要かどうか、アプリケーションによる設定、またはその間の何かに関するガイダンスを含めることができます。トランスポートサービスの機能の例としては、信頼性の高い配信、順序付き配信、パス内デバイスへのコンテンツのプライバシー、および整合性保護があります。
The IETF has defined a wide variety of transport protocols beyond TCP and UDP, including SCTP, DCCP, MPTCP, and UDP-Lite. Transport services may be provided directly by these transport protocols or layered on top of them using protocols such as WebSockets (which runs over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run over SCTP over DTLS over UDP or TCP). Services built on top of UDP or UDP-Lite typically also need to specify additional mechanisms, including a congestion control mechanism (such as NewReno [RFC6582], TCP-Friendly Rate Control (TFRC) [RFC5348], or Low Extra Delay Background Transport (LEDBAT) [RFC6817]). This extends the set of available transport services beyond those provided to applications by TCP and UDP.
IETFは、SCTP、DCCP、MPTCP、UDP-Liteなど、TCPやUDP以外のさまざまなトランスポートプロトコルを定義しています。トランスポートサービスは、これらのトランスポートプロトコルによって直接提供されるか、WebSocket（TCP上で実行）、RTP（TCPまたはUDP上）、またはWebRTCデータチャネル（SCTP over DTLSまたはUDPまたはTCP上で実行）などのプロトコルを使用して、その上に階層化されます。 ）。 UDPまたはUDP-Liteの上に構築されたサービスは、通常、輻輳制御メカニズム（NewReno [RFC6582]、TCP-Friendly Rate Control（TFRC）[RFC5348]、低追加遅延バックグラウンド転送など）を含む追加のメカニズムも指定する必要がありますLEDBAT）[RFC6817]）。これにより、TCPおよびUDPによってアプリケーションに提供されるものを超えて、利用可能なトランスポートサービスのセットが拡張されます。
The transport protocols described in this document provide a basis for the definition of transport services provided by common protocols, as background for the TAPS working group. The protocols listed here were chosen to help expose as many potential transport services as possible and are not meant to be a comprehensive survey or classification of all transport protocols.
このドキュメントで説明されているトランスポートプロトコルは、TAPSワーキンググループの背景として、一般的なプロトコルによって提供されるトランスポートサービスの定義の基礎を提供します。ここにリストされているプロトコルは、可能な限り多くの潜在的なトランスポートサービスを公開するために選択されたものであり、すべてのトランスポートプロトコルを包括的に調査または分類するものではありません。
Transport protocols can be differentiated by the features of the services they provide.
トランスポートプロトコルは、提供するサービスの機能によって区別できます。
Some of these provided features are closely related to basic control function that a protocol needs to work over a network path, such as addressing. The number of participants in a given association also determines its applicability: a connection can be between endpoints (unicast), to one of multiple endpoints (anycast), or simultaneously to multiple endpoints (multicast). Unicast protocols usually support bidirectional communication, while multicast is generally unidirectional. Another feature is whether a transport requires a control exchange across the network at setup (e.g., TCP) or whether it is connectionless (e.g., UDP).
これらの提供される機能のいくつかは、プロトコルがアドレス指定などのネットワークパスを介して動作する必要がある基本的な制御機能に密接に関連しています。特定のアソシエーションの参加者の数もその適用範囲を決定します。接続は、エンドポイント間（ユニキャスト）、複数のエンドポイントの1つ（エニーキャスト）、または同時に複数のエンドポイント（マルチキャスト）にすることができます。ユニキャストプロトコルは通常双方向通信をサポートしていますが、マルチキャストは一般的に単方向です。もう1つの機能は、セットアップ時にトランスポートがネットワーク全体で制御交換を必要とするか（TCPなど）、またはコネクションレス型であるか（UDPなど）です。
For packet delivery itself, reliability and integrity protection, ordering, and framing are basic features. However, these features are implemented with different levels of assurance in different protocols. As an example, a transport service may provide full reliability, with detection of loss and retransmission (e.g., TCP). SCTP offers a message-based service that can provide full or partial reliability and allows the protocol to minimize the head-of-line blocking due to the support of ordered and unordered message delivery within multiple streams. UDP-Lite and DCCP can provide partial integrity protection to enable corruption tolerance.
パケット配信自体については、信頼性と完全性の保護、順序付け、およびフレーミングが基本機能です。ただし、これらの機能は、さまざまなプロトコルでさまざまなレベルの保証で実装されます。例として、トランスポートサービスは、損失と再送信（TCPなど）を検出して、完全な信頼性を提供します。 SCTPは、完全または部分的な信頼性を提供できるメッセージベースのサービスを提供し、複数のストリーム内での順序付きおよび順序なしのメッセージ配信のサポートにより、プロトコルが行頭ブロッキングを最小限に抑えることを可能にします。 UDP-LiteとDCCPは、部分的な整合性保護を提供して、破損への耐性を実現できます。
Usually, a protocol has been designed to support one specific type of delivery/framing: either data needs to be divided into transmission units based on network packets (datagram service) or a data stream is segmented and re-combined across multiple packets (stream service). Whole objects such as files are handled accordingly. This decision strongly influences the interface that is provided to the upper layer.
通常、プロトコルは1つの特定のタイプの配信/フレーミングをサポートするように設計されています。データはネットワークパケットに基づいて送信ユニットに分割する必要があります（データグラムサービス）、またはデータストリームをセグメント化して複数のパケットに再結合する（ストリームサービス） ）。ファイルなどのオブジェクト全体がそれに応じて処理されます。この決定は、上位層に提供されるインターフェースに強く影響します。
In addition, transport protocols offer a certain support for transmission control. For example, a transport service can provide flow control to allow a receiver to regulate the transmission rate of a sender. Further, a transport service can provide congestion control (see Section 4). As an example, TCP and SCTP provide congestion control for use in the Internet, whereas UDP leaves this function to the upper-layer protocol that uses UDP.
さらに、トランスポートプロトコルは、伝送制御に対して特定のサポートを提供します。たとえば、トランスポートサービスは、フロー制御を提供して、受信者が送信者の送信レートを調整できるようにすることができます。さらに、トランスポートサービスは輻輳制御を提供できます（セクション4を参照）。例として、TCPおよびSCTPはインターネットで使用するための輻輳制御を提供しますが、UDPはこの機能をUDPを使用する上位層プロトコルに任せます。
Security features are often provided independently of the transport protocol, via Transport Layer Security (TLS) (see Section 3.7) or by the application-layer protocol itself. The security properties TLS provides to the application (such as confidentiality, integrity, and authenticity) are also features of the transport layer, even though they are often presently implemented in a separate protocol.
多くの場合、セキュリティ機能は、トランスポートプロトコルとは無関係に、トランスポート層セキュリティ（TLS）（セクション3.7を参照）またはアプリケーション層プロトコル自体によって提供されます。 TLSがアプリケーションに提供するセキュリティプロパティ（機密性、整合性、信頼性など）も、現在別々のプロトコルで実装されていることが多いにもかかわらず、トランスポート層の機能でもあります。
The following terms are used throughout this document and in subsequent documents produced by the TAPS working group that describe the composition and decomposition of transport services.
次の用語は、このドキュメント全体、および輸送サービスの構成と分解を説明するTAPSワーキンググループによって作成された後続のドキュメントで使用されます。
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, that provides a complete service to an application.
トランスポートサービス：特定のフレーミングプロトコルに関連付けられていない一連のトランスポート機能で、アプリケーションに完全なサービスを提供します。
Transport Protocol: an implementation that provides one or more different transport services using a specific framing and header format on the wire.
トランスポートプロトコル：ワイヤー上で特定のフレーミングとヘッダー形式を使用して1つ以上の異なるトランスポートサービスを提供する実装。
Application: an entity that uses the transport layer for end-to-end delivery data across the network (this may also be an upper-layer protocol or tunnel encapsulation).
アプリケーション：ネットワーク全体のエンドツーエンド配信データにトランスポート層を使用するエンティティ（これは、上位層プロトコルまたはトンネルカプセル化の場合もあります）。
This section provides a list of known IETF transport protocols and transport protocol frameworks. It does not make an assessment about whether specific implementations of protocols are fully compliant to current IETF specifications.
このセクションでは、既知のIETFトランスポートプロトコルとトランスポートプロトコルフレームワークのリストを示します。プロトコルの特定の実装が現在のIETF仕様に完全に準拠しているかどうかについての評価は行いません。
TCP is an IETF Standards Track transport protocol. [RFC793] introduces TCP as follows:
TCPはIETF Standards Trackトランスポートプロトコルです。 [RFC793]は次のように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）は、パケット交換コンピュータ通信ネットワーク内のホスト間、およびそのようなネットワークの相互接続されたシステム内のホスト間の信頼性の高いホスト間プロトコルとして使用することを目的としています。
Since its introduction, TCP has become the default connection-oriented, stream-based transport protocol in the Internet. It is widely implemented by endpoints and widely used by common applications.
導入以来、TCPはインターネットにおけるデフォルトのコネクション型のストリームベースのトランスポートプロトコルになりました。エンドポイントによって広く実装され、一般的なアプリケーションによって広く使用されています。
TCP is a connection-oriented protocol that provides a three-way handshake to allow a client and server to set up a connection and negotiate features and provides mechanisms for orderly completion and immediate teardown of a connection [RFC793] [TCP-SPEC]. TCP is defined by a family of RFCs (see [RFC7414]).
TCPは、クライアントとサーバーが接続をセットアップして機能をネゴシエートできるようにする3ウェイハンドシェイクを提供する接続指向のプロトコルであり、接続の正常な完了と即時の破棄のためのメカニズムを提供します[RFC793] [TCP-SPEC]。 TCPはRFCファミリによって定義されます（[RFC7414]を参照）。
TCP provides multiplexing to multiple sockets on each host using port numbers. A similar approach is adopted by other IETF-defined transports. An active TCP session is identified by its four-tuple of local and remote IP addresses and local and remote port numbers. The destination port during connection setup is often used to indicate the requested service.
TCPは、ポート番号を使用して、各ホスト上の複数のソケットへの多重化を提供します。他のIETF定義のトランスポートでも同様のアプローチが採用されています。アクティブなTCPセッションは、ローカルおよびリモートのIPアドレスの4つのタプルと、ローカルおよびリモートのポート番号によって識別されます。接続セットアップ中の宛先ポートは、要求されたサービスを示すためによく使用されます。
TCP partitions a continuous stream of bytes into segments, sized to fit in IP packets based on a negotiated maximum segment size and further constrained by the effective Maximum Transmission Unit (MTU) from Path MTU Discovery (PMTUD). ICMP-based PMTUD [RFC1191] [RFC1981] as well as Packetization Layer PMTUD (PLPMTUD) [RFC4821] have been defined by the IETF.
TCPは、バイトの連続ストリームをセグメントに分割し、ネゴシエートされた最大セグメントサイズに基づいてIPパケットに収まるサイズであり、さらにパスMTUディスカバリ（PMTUD）からの有効な最大伝送ユニット（MTU）によって制約されます。 ICMPベースのPMTUD [RFC1191] [RFC1981]およびパケット化レイヤーPMTUD（PLPMTUD）[RFC4821]は、IETFによって定義されています。
Each byte in the stream is identified by a sequence number. The sequence number is used to order segments on receipt, to identify segments in acknowledgments, and to detect unacknowledged segments for retransmission. This is the basis of the reliable, ordered delivery of data in a TCP stream. TCP Selective Acknowledgment (SACK) [RFC2018] extends this mechanism by making it possible to provide earlier identification of which segments are missing, allowing faster retransmission. SACK-based methods (e.g., Duplicate Selective ACK) can also result in less spurious retransmission.
ストリームの各バイトはシーケンス番号で識別されます。シーケンス番号は、受信時のセグメントの順序付け、確認応答のセグメントの識別、および再送信のための未確認のセグメントの検出に使用されます。これは、TCPストリームでのデータの信頼性の高い、順序付けられた配信の基礎です。 TCP選択的確認応答（SACK）[RFC2018]は、欠落しているセグメントをより早く識別できるようにすることでこのメカニズムを拡張し、より高速な再送信を可能にします。 SACKベースの方法（例：Duplicate Selective ACK）を使用すると、偽の再送信が少なくなります。
Receiver flow control is provided by a sliding window, which limits the amount of unacknowledged data that can be outstanding at a given time. The window scale option [RFC7323] allows a receiver to use windows greater than 64 KB.
レシーバーフロー制御はスライディングウィンドウによって提供されます。これにより、所定の時間に未処理になる可能性がある未確認データの量が制限されます。ウィンドウスケールオプション[RFC7323]では、レシーバーは64 KBを超えるウィンドウを使用できます。
All TCP senders provide congestion control, such as that described in [RFC5681]. TCP uses a sequence number with a sliding receiver window for flow control. The TCP congestion control mechanism also utilizes this TCP sequence number to manage a separate congestion window [RFC5681]. The sending window at a given point in time is the minimum of the receiver window and the congestion window. The congestion window is increased in the absence of congestion and decreased if congestion is detected. Often, loss is implicitly handled as a congestion indication, which is detected in TCP (also as input for retransmission handling) based on two mechanisms: a retransmission timer with exponential back-off or the reception of three acknowledgments for the same segment, so called "duplicated ACKs" (fast retransmit). In addition, Explicit Congestion Notification (ECN) [RFC3168] can be used in TCP and, if supported by both endpoints, allows a network node to signal congestion without inducing loss. Alternatively, a delay-based congestion control scheme that reacts to changes in delay as an early indication of congestion can be used in TCP. This is further described in Section 4. Examples of different kinds of congestion control schemes are provided in Section 4.
すべてのTCP送信側は、[RFC5681]で説明されているような輻輳制御を提供します。 TCPは、フロー制御にスライディングレシーバーウィンドウのシーケンス番号を使用します。 TCP輻輳制御メカニズムもこのTCPシーケンス番号を利用して、別の輻輳ウィンドウを管理します[RFC5681]。特定の時点での送信ウィンドウは、受信ウィンドウと輻輳ウィンドウの最小値です。輻輳ウィンドウは、輻輳がない場合は増加し、輻輳が検出された場合は減少します。多くの場合、損失は、2つのメカニズムに基づいてTCPで検出される（再送信処理の入力としても）輻輳表示として暗黙的に処理されます：指数バックオフ付きの再送信タイマーまたは同じセグメントに対する3つの確認応答の受信、いわゆる「重複ACK」（高速再送信）。さらに、明示的輻輳通知（ECN）[RFC3168]はTCPで使用でき、両方のエンドポイントでサポートされている場合、ネットワークノードが損失を引き起こすことなく輻輳を通知できます。あるいは、輻輳の早期兆候として遅延の変化に反応する遅延ベースの輻輳制御方式をTCPで使用できます。これについては、セクション4で詳しく説明します。さまざまな種類の輻輳制御方式の例をセクション4に示します。
TCP protocol instances can be extended (see [RFC7414]). Some protocol features may also be tuned to optimize for a specific deployment scenario. Some features are sender-side only, requiring no negotiation with the receiver; some are receiver-side only; and some are explicitly negotiated during connection setup.
TCPプロトコルインスタンスは拡張できます（[RFC7414]を参照）。一部のプロトコル機能は、特定の展開シナリオに最適化するように調整される場合もあります。一部の機能は送信側のみであり、受信側とのネゴシエーションを必要としません。一部は受信側のみです。また、一部は接続のセットアップ中に明示的にネゴシエートされます。
TCP may buffer data, e.g., to optimize processing or capacity usage. TCP therefore provides mechanisms to control this, including an optional "PUSH" function [RFC793] that explicitly requests the transport service not to delay data. By default, TCP segment partitioning uses Nagle's algorithm [TCP-SPEC] to buffer data at the sender into large segments, potentially incurring sender-side buffering delay; this algorithm can be disabled by the sender to transmit more immediately, e.g., to reduce latency for interactive sessions.
TCPは、たとえば処理や容量の使用を最適化するために、データをバッファリングする場合があります。したがって、TCPは、これを制御するメカニズムを提供します。これには、データを遅延させないようにトランスポートサービスに明示的に要求するオプションの「PUSH」機能[RFC793]が含まれます。デフォルトでは、TCPセグメントパーティショニングはNagleのアルゴリズム[TCP-SPEC]を使用して送信側のデータを大きなセグメントにバッファリングし、送信側のバッファリング遅延が発生する可能性があります。送信者はこのアルゴリズムを無効にして、より迅速に送信することができます。たとえば、インタラクティブセッションの遅延を減らすことができます。
TCP provides an "urgent data" function for limited out-of-order delivery of the data. This function is deprecated [RFC6093].
TCPは、データの順序どおりでない配信を制限するための「緊急データ」機能を提供します。この関数は非推奨です[RFC6093]。
A TCP Reset (RST) control message may be used to force a TCP endpoint to close a session [RFC793], aborting the connection.
TCPリセット（RST）制御メッセージを使用して、TCPエンドポイントに強制的にセッションを閉じさせ[RFC793]、接続を中止します。
A mandatory checksum provides a basic integrity check against misdelivery and data corruption over the entire packet. Applications that require end-to-end integrity of data are recommended to include a stronger integrity check of their payload data. The TCP checksum [RFC1071] [RFC2460] does not support partial payload protection (as in DCCP/UDP-Lite).
必須のチェックサムは、パケット全体の配信ミスとデータ破損に対する基本的な整合性チェックを提供します。データのエンドツーエンドの整合性を必要とするアプリケーションでは、ペイロードデータのより強力な整合性チェックを含めることをお勧めします。 TCPチェックサム[RFC1071] [RFC2460]は、部分的なペイロード保護をサポートしていません（DCCP / UDP-Liteなど）。
TCP supports only unicast connections.
TCPはユニキャスト接続のみをサポートします。
The User/TCP Interface defined in [RFC793] provides six user commands: Open, Send, Receive, Close, Status, and Abort. This interface does not describe configuration of TCP options or parameters aside from the use of the PUSH and URGENT flags.
[RFC793]で定義されているユーザー/ TCPインターフェースは、開く、送信、受信、閉じる、ステータス、および中止という6つのユーザーコマンドを提供します。このインターフェースは、PUSHフラグとURGENTフラグの使用を除いて、TCPオプションまたはパラメーターの構成を記述しません。
[RFC1122] describes extensions of the TCP/application-layer interface for:
[RFC1122]は、以下のTCP /アプリケーション層インターフェースの拡張について説明しています。
o reporting soft errors such as reception of ICMP error messages, extensive retransmission, or urgent pointer advance,
o ICMPエラーメッセージの受信、広範な再送信、緊急ポインタアドバンスなどのソフトエラーの報告
o providing a possibility to specify the Differentiated Services Code Point (DSCP) [RFC3260] (formerly, the Type-of-Service (TOS)) for segments,
o セグメントにDiffServコードポイント（DSCP）[RFC3260]（以前はサービスの種類（TOS））を指定する可能性を提供します。
o providing a flush call to empty the TCP send queue, and
o TCP送信キューを空にするためのフラッシュ呼び出しを提供します。
o multihoming support.
o マルチホーミングのサポート。
In API implementations derived from the BSD Sockets API, TCP sockets are created using the "SOCK_STREAM" socket type as described in the IEEE Portable Operating System Interface (POSIX) Base Specifications [POSIX]. The features used by a protocol instance may be set and tuned via this API. There are currently no documents in the RFC Series that describe this interface.
BSDソケットAPIから派生したAPI実装では、TCPソケットは、IEEEポータブルオペレーティングシステムインターフェイス（POSIX）基本仕様[POSIX]で説明されている「SOCK_STREAM」ソケットタイプを使用して作成されます。プロトコルインスタンスによって使用される機能は、このAPIを介して設定および調整できます。現在、このインターフェイスについて説明しているRFCシリーズのドキュメントはありません。
The transport features provided by TCP are:
TCPが提供するトランスポート機能は次のとおりです。
o connection-oriented transport with feature negotiation and application-to-port mapping (implemented using SYN segments and the TCP Option field to negotiate features),
o 機能ネゴシエーションとアプリケーションからポートへのマッピングを備えたコネクション型トランスポート（SYNセグメントとTCPオプションフィールドを使用して機能をネゴシエートするために実装）、
o unicast transport (though anycast TCP is implemented, at risk of instability due to rerouting),
o ユニキャストトランスポート（エニーキャストTCPが実装されていますが、再ルーティングにより不安定になるリスクがあります）、
o port multiplexing,
o ポートの多重化、
o unidirectional or bidirectional communication,
o 単方向または双方向通信、
o stream-oriented delivery in a single stream,
o 単一のストリームでのストリーム指向の配信、
o fully reliable delivery (implemented using ACKs sent from the receiver to confirm delivery),
o 完全に信頼できる配信（配信を確認するために受信者から送信されたACKを使用して実装）、
o error detection (implemented using a segment checksum to verify delivery to the correct endpoint and integrity of the data and options),
o エラー検出（セグメントチェックサムを使用して実装され、正しいエンドポイントへの配信とデータおよびオプションの整合性を検証します）、
o segmentation,
o セグメンテーション、
o data bundling (optional; uses Nagle's algorithm to coalesce data sent within the same RTT into full-sized segments),
o データバンドリング（オプション; Nagleのアルゴリズムを使用して、同じRTT内で送信されたデータをフルサイズのセグメントに結合します）、
o flow control (implemented using a window-based mechanism where the receiver advertises the window that it is willing to buffer), and
o フロー制御（ウィンドウベースのメカニズムを使用して実装され、レシーバーがバッファリングしようとするウィンドウをアドバタイズする）、および
o congestion control (usually implemented using a window-based mechanism and four algorithms for different phases of the transmission: slow start, congestion avoidance, fast retransmit, and fast recovery [RFC5681]).
o 輻輳制御（通常、ウィンドウベースのメカニズムと、送信のさまざまなフェーズの4つのアルゴリズム（スロースタート、輻輳回避、高速再送、高速リカバリ[RFC5681]）を使用して実装されます）。
Multipath TCP [RFC6824] is an extension for TCP to support multihoming for resilience, mobility, and load balancing. It is designed to be as indistinguishable to middleboxes from non-multipath TCP as possible. It does so by establishing regular TCP flows between a pair of source/destination endpoints and multiplexing the application's stream over these flows. Sub-flows can be started over IPv4 or IPv6 for the same session.
マルチパスTCP [RFC6824]は、復元力、モビリティ、および負荷分散のためのマルチホーミングをサポートするTCPの拡張機能です。これは、非マルチパスTCPとミドルボックスをできるだけ区別できないように設計されています。これは、送信元/宛先エンドポイントのペア間に通常のTCPフローを確立し、これらのフローを介してアプリケーションのストリームを多重化することによって行われます。サブフローは、同じセッションのIPv4またはIPv6で開始できます。
MPTCP uses TCP options for its control plane. They are used to signal multipath capabilities, as well as to negotiate data sequence numbers, advertise other available IP addresses, and establish new sessions between pairs of endpoints.
MPTCPは、そのコントロールプレーンにTCPオプションを使用します。これらは、マルチパス機能のシグナリング、データシーケンス番号のネゴシエーション、他の使用可能なIPアドレスのアドバタイズ、およびエンドポイントのペア間の新しいセッションの確立に使用されます。
By multiplexing one byte stream over separate paths, MPTCP can achieve a higher throughput than TCP in certain situations. However, if coupled congestion control [RFC6356] is used, it might limit this benefit to maintain fairness to other flows at the bottleneck. When aggregating capacity over multiple paths, and depending on the way packets are scheduled on each TCP subflow, additional delay and higher jitter might be observed before in-order delivery of data to the applications.
1つのバイトストリームを別々のパスで多重化することにより、特定の状況でMPTCPはTCPよりも高いスループットを実現できます。ただし、結合された輻輳制御[RFC6356]が使用されている場合、ボトルネックで他のフローへの公平性を維持するためにこの利点が制限される可能性があります。複数のパスを介して容量を集約する場合、各TCPサブフローでのパケットのスケジュール方法によっては、アプリケーションにデータを順番に配信する前に、追加の遅延とより高いジッターが観察される場合があります。
By default, MPTCP exposes the same interface as TCP to the application. [RFC6897], however, describes a richer API for MPTCP-aware applications.
デフォルトでは、MPTCPはTCPと同じインターフェースをアプリケーションに公開します。ただし、[RFC6897]は、MPTCP対応アプリケーション用のより豊富なAPIについて説明しています。
This Basic API describes how an application can:
この基本APIは、アプリケーションがどのようにできるかを説明します。
o enable or disable MPTCP.
o MPTCPを有効または無効にします。
o bind a socket to one or more selected local endpoints.
o 選択した1つ以上のローカルエンドポイントにソケットをバインドします。
o query local and remote endpoint addresses.
o ローカルおよびリモートのエンドポイントアドレスを照会します。
o get a unique connection identifier (similar to an address-port pair for TCP).
o 一意の接続識別子を取得します（TCPのアドレスとポートのペアに似ています）。
The document also recommends the use of extensions defined for SCTP [RFC6458] (see Section 3.5) to support multihoming for resilience and mobility.
このドキュメントでは、SCTP [RFC6458]（セクション3.5を参照）に対して定義された拡張機能を使用して、復元力とモビリティのためのマルチホーミングをサポートすることも推奨しています。
As an extension to TCP, MPTCP provides mostly the same features. By establishing multiple sessions between available endpoints, it can additionally provide soft failover solutions in the case that one of the paths becomes unusable.
TCPの拡張として、MPTCPはほとんど同じ機能を提供します。使用可能なエンドポイント間で複数のセッションを確立することにより、パスの1つが使用できなくなった場合に、ソフトフェイルオーバーソリューションをさらに提供できます。
Therefore, the transport features provided by MPTCP in addition to TCP are:
したがって、TCPに加えてMPTCPによって提供されるトランスポート機能は次のとおりです。
o multihoming for load balancing, with endpoint multiplexing of a single byte stream, using either coupled congestion control or throughput maximization,
o 結合された輻輳制御またはスループットの最大化のいずれかを使用した、シングルバイトストリームのエンドポイント多重化による負荷分散のためのマルチホーミング
o address family multiplexing (using IPv4 and IPv6 for the same session), and
o アドレスファミリの多重化（同じセッションでIPv4とIPv6を使用）、および
o resilience to network failure and/or handover.
o ネットワーク障害および/またはハンドオーバーへの回復力。
The User Datagram Protocol (UDP) [RFC768] [RFC2460] is an IETF Standards Track transport protocol. It provides a unidirectional datagram protocol that preserves message boundaries. It provides no error correction, congestion control, or flow control. It can be used to send broadcast datagrams (IPv4) or multicast datagrams (IPv4 and IPv6), in addition to unicast and anycast datagrams. IETF guidance on the use of UDP is provided in [RFC8085]. UDP is widely implemented and widely used by common applications, including DNS.
User Datagram Protocol（UDP）[RFC768] [RFC2460]は、IETF Standards Trackトランスポートプロトコルです。メッセージの境界を保持する単方向データグラムプロトコルを提供します。エラー訂正、輻輳制御、フロー制御は提供されません。ユニキャストおよびエニーキャストデータグラムに加えて、ブロードキャストデータグラム（IPv4）またはマルチキャストデータグラム（IPv4およびIPv6）を送信するために使用できます。 UDPの使用に関するIETFガイダンスは、[RFC8085]で提供されています。 UDPは広く実装されており、DNSを含む一般的なアプリケーションで広く使用されています。
UDP is a connectionless protocol that maintains message boundaries, with no connection setup or feature negotiation. The protocol uses independent messages, ordinarily called "datagrams". It provides detection of payload errors and misdelivery of packets to an unintended endpoint, both of which result in discard of received datagrams, with no indication to the user of the service.
UDPは、接続のセットアップや機能のネゴシエーションを行わずに、メッセージ境界を維持するコネクションレスプロトコルです。このプロトコルは、通常「データグラム」と呼ばれる独立したメッセージを使用します。ペイロードエラーの検出と、意図しないエンドポイントへのパケットの誤配信を検出します。どちらの場合も、サービスのユーザーに通知されることなく、受信したデータグラムが破棄されます。
It is possible to create IPv4 UDP datagrams with no checksum, and while this is generally discouraged [RFC1122] [RFC8085], certain special cases permit this use. These datagrams rely on the IPv4 header checksum to protect from misdelivery to an unintended endpoint. IPv6 does not permit UDP datagrams with no checksum, although in certain cases [RFC6936], this rule may be relaxed [RFC6935].
チェックサムなしでIPv4 UDPデータグラムを作成することは可能です。これは一般的には推奨されませんが[RFC1122] [RFC8085]、特定の特殊なケースでこの使用が許可されています。これらのデータグラムは、意図しないエンドポイントへの誤配信から保護するためにIPv4ヘッダーチェックサムに依存しています。 IPv6は、チェックサムなしのUDPデータグラムを許可しませんが、特定のケースでは[RFC6936]、このルールは緩和される場合があります[RFC6935]。
UDP does not provide reliability and does not provide retransmission. Messages may be reordered, lost, or duplicated in transit. Note that due to the relatively weak form of checksum used by UDP, applications that require end-to-end integrity of data are recommended to include a stronger integrity check of their payload data.
UDPは信頼性を提供せず、再送信も提供しません。メッセージは、転送中に並べ替えられたり、失われたり、複製されたりする場合があります。 UDPが使用するチェックサムの形式は比較的弱いため、データのエンドツーエンドの整合性を必要とするアプリケーションでは、ペイロードデータのより強力な整合性チェックを含めることをお勧めします。
Because UDP provides no flow control, a receiving application that is unable to run sufficiently fast, or frequently, may miss messages. The lack of congestion handling implies UDP traffic may experience loss when using an overloaded path and may cause the loss of messages from other protocols (e.g., TCP) when sharing the same network path.
UDPはフロー制御を提供しないため、十分に速く、または頻繁に実行できない受信アプリケーションは、メッセージを見逃す可能性があります。輻輳処理の欠如は、過負荷のパスを使用するとUDPトラフィックが失われる可能性があり、同じネットワークパスを共有しているときに他のプロトコル（TCPなど）からのメッセージが失われる可能性があることを意味します。
On transmission, UDP encapsulates each datagram into a single IP packet or several IP packet fragments. This allows a datagram to be larger than the effective path MTU. Fragments are reassembled before delivery to the UDP receiver, making this transparent to the user of the transport service. When jumbograms are supported, larger messages may be sent without performing fragmentation.
伝送時、UDPは各データグラムを単一のIPパケットまたは複数のIPパケットフラグメントにカプセル化します。これにより、データグラムを有効パスMTUより大きくすることができます。フラグメントはUDPレシーバーに配信される前に再構成され、トランスポートサービスのユーザーに対して透過的になります。ジャンボグラムがサポートされている場合、フラグメンテーションを実行せずに、より大きなメッセージが送信されることがあります。
UDP on its own does not provide support for segmentation, receiver flow control, congestion control, PMTUD/PLPMTUD, or ECN. Applications that require these features need to provide them on their own or use a protocol over UDP that provides them [RFC8085].
UDP自体は、セグメンテーション、レシーバーフロー制御、輻輳制御、PMTUD / PLPMTUD、またはECNのサポートを提供しません。これらの機能を必要とするアプリケーションは、それらを独自に提供するか、それらを提供するUDP経由のプロトコルを使用する必要があります[RFC8085]。
[RFC768] describes basic requirements for an API for UDP. Guidance on the use of common APIs is provided in [RFC8085].
[RFC768]は、UDPのAPIの基本要件を説明しています。一般的なAPIの使用に関するガイダンスは、[RFC8085]で提供されています。
A UDP endpoint consists of a tuple of (IP address, port number). De-multiplexing using multiple abstract endpoints (sockets) on the same IP address is supported. The same socket may be used by a single server to interact with multiple clients. (Note: This behavior differs from TCP, which uses a pair of tuples to identify a connection). Multiple server instances (processes) that bind to the same socket can cooperate to service multiple clients. The socket implementation arranges to not duplicate the same received unicast message to multiple server processes.
UDPエンドポイントは、（IPアドレス、ポート番号）のタプルで構成されます。同じIPアドレスで複数の抽象エンドポイント（ソケット）を使用した逆多重化がサポートされています。単一のサーバーが同じソケットを使用して、複数のクライアントと対話できます。 （注：この動作は、タプルのペアを使用して接続を識別するTCPとは異なります）。同じソケットにバインドする複数のサーバーインスタンス（プロセス）が連携して、複数のクライアントにサービスを提供できます。ソケット実装は、同じ受信ユニキャストメッセージを複数のサーバープロセスに複製しないように調整します。
Many operating systems also allow a UDP socket to be "connected", i.e., to bind a UDP socket to a specific (remote) UDP endpoint. Unlike TCP's connect primitive, 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 [RFC8085].
多くのオペレーティングシステムでは、UDPソケットを「接続」することもできます。つまり、UDPソケットを特定の（リモート）UDPエンドポイントにバインドできます。 TCPの接続プリミティブとは異なり、UDPの場合、これはローカルの送受信機能を簡素化し、指定されたアドレスとポートのトラフィックをフィルターする[RFC8085]だけのローカル操作です。
The transport features provided by UDP are:
UDPが提供するトランスポート機能は次のとおりです。
o unicast, multicast, anycast, or IPv4 broadcast transport,
o ユニキャスト、マルチキャスト、エニーキャスト、またはIPv4ブロードキャストトランスポート、
o port multiplexing (where a receiving port can be configured to receive datagrams from multiple senders),
o ポートの多重化（複数の送信者からデータグラムを受信するように受信ポートを構成できる場合）
o message-oriented delivery,
o メッセージ指向の配信、
o unidirectional or bidirectional communication where the transmissions in each direction are independent,
o 各方向の送信が独立している一方向または双方向通信
o non-reliable delivery,
o 信頼できない配信、
o unordered delivery, and
o 順不同の配送、および
o error detection (implemented using a segment checksum to verify delivery to the correct endpoint and integrity of the data; optional for IPv4 and optional under specific conditions for IPv6 where all or none of the payload data is protected).
o エラー検出（セグメントチェックサムを使用して実装され、正しいエンドポイントへの配信とデータの整合性を検証します。IPv4の場合は任意、ペイロードデータのすべてまたはまったく保護されていないIPv6の特定の条件下ではオプション）。
The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] is an IETF Standards Track transport protocol. It provides a unidirectional, datagram protocol that preserves message boundaries. IETF guidance on the use of UDP-Lite is provided in [RFC8085]. A UDP-Lite service may support IPv4 broadcast, multicast, anycast, and unicast, as well as IPv6 multicast, anycast, and unicast.
軽量ユーザーデータグラムプロトコル（UDP-Lite）[RFC3828]は、IETF標準トラック転送プロトコルです。メッセージの境界を維持する単方向のデータグラムプロトコルを提供します。 UDP-Liteの使用に関するIETFガイダンスは、[RFC8085]で提供されています。 UDP-Liteサービスは、IPv4ブロードキャスト、マルチキャスト、エニーキャスト、ユニキャスト、およびIPv6マルチキャスト、エニーキャスト、ユニキャストをサポートする場合があります。
Examples of use include a class of applications that can derive benefit from having partially damaged payloads delivered rather than discarded. One use is to provide header integrity checks but allow delivery of corrupted payloads to error-tolerant applications or to applications that use some other mechanism to provide payload integrity (see [RFC6936]).
使用例には、部分的に損傷したペイロードを破棄するのではなく配信することから利益を得ることができるアプリケーションのクラスが含まれます。 1つの用途は、ヘッダーの整合性チェックを提供することですが、破損したペイロードをエラー耐性のあるアプリケーションまたは他のメカニズムを使用してペイロードの整合性を提供するアプリケーションに配信できます（[RFC6936]を参照）。
Like UDP, UDP-Lite is a connectionless datagram protocol, with no connection setup or feature negotiation. It changes the semantics of the UDP Payload Length field to that of a Checksum Coverage Length field and is identified by a different IP protocol/next-header value. The Checksum Coverage Length field specifies the intended checksum coverage, with the remaining unprotected part of the payload called the "error-insensitive part". Therefore, applications using UDP-Lite cannot make assumptions regarding the correctness of the data received in the insensitive part of the UDP-Lite payload.
UDPと同様に、UDP-Liteはコネクションレスのデータグラムプロトコルであり、接続のセットアップや機能のネゴシエーションはありません。これは、UDPペイロード長フィールドのセマンティクスをチェックサムカバレッジ長フィールドのセマンティクスに変更し、別のIPプロトコル/次のヘッダー値によって識別されます。 「チェックサムカバレッジの長さ」フィールドは、意図するチェックサムカバレッジを指定します。ペイロードの残りの保護されていない部分は、「エラーに影響されない部分」と呼ばれます。したがって、UDP-Liteを使用するアプリケーションは、UDP-Liteペイロードの非依存部分で受信したデータの正確性に関する仮定を行うことができません。
Otherwise, UDP-Lite is semantically identical to UDP. In the same way as for UDP, mechanisms for receiver flow control, congestion control, PMTU or PLPMTU discovery, support for ECN, etc., need to be provided by upper-layer protocols [RFC8085].
それ以外の場合、UDP-Liteは意味的にUDPと同じです。 UDPと同様に、レシーバーフロー制御、輻輳制御、PMTUまたはPLPMTUディスカバリー、ECNのサポートなどのメカニズムは、上位層プロトコル[RFC8085]によって提供される必要があります。
There is no API currently specified in the RFC Series, but guidance on use of common APIs is provided in [RFC8085].
現在、RFCシリーズで指定されているAPIはありませんが、一般的なAPIの使用に関するガイダンスは[RFC8085]で提供されています。
The interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that communicates a checksum coverage length value. The checksum coverage may also be made visible to the application via the UDP-Lite MIB module [RFC5097].
UDP-Liteのインターフェースは、チェックサムカバレッジの長さの値を伝達する単一（ソケット）オプションが追加されている点で、UDPのインターフェースとは異なります。チェックサムカバレッジは、UDP-Lite MIBモジュール[RFC5097]を介してアプリケーションに表示することもできます。
The transport features provided by UDP-Lite are:
UDP-Liteが提供するトランスポート機能は次のとおりです。
o unicast, multicast, anycast, or IPv4 broadcast transport (same as for UDP),
o ユニキャスト、マルチキャスト、エニーキャスト、またはIPv4ブロードキャストトランスポート（UDPと同じ）、
o port multiplexing (same as for UDP),
o ポートの多重化（UDPと同じ）、
o message-oriented delivery (same as for UDP),
o メッセージ指向配信（UDPと同じ）、
o unidirectional or bidirectional communication where the transmissions in each direction are independent (same as for UDP),
o 各方向の送信が独立している単方向または双方向通信（UDPと同じ）、
o non-reliable delivery (same as for UDP),
o 信頼できない配信（UDPと同じ）、
o non-ordered delivery (same as for UDP), and
o 順不同配信（UDPと同じ）、および
o partial or full payload error detection (where the Checksum Coverage field indicates the size of the payload data covered by the checksum).
o 部分的または完全なペイロードエラー検出（チェックサムカバレッジフィールドは、チェックサムがカバーするペイロードデータのサイズを示します）。
SCTP is a message-oriented IETF Standards Track transport protocol. The base protocol is specified in [RFC4960]. It supports multihoming and path failover to provide resilience to path failures. An SCTP association has multiple streams in each direction, providing in-sequence delivery of user messages within each stream. This allows it to minimize head-of-line blocking. SCTP supports multiple stream- scheduling schemes controlling stream multiplexing, including priority and fair weighting schemes.
SCTPは、メッセージ指向のIETF標準トラック転送プロトコルです。基本プロトコルは[RFC4960]で指定されています。パスの障害に対する回復力を提供するために、マルチホーミングとパスのフェイルオーバーをサポートしています。 SCTPアソシエーションは、各方向に複数のストリームを持ち、各ストリーム内でユーザーメッセージの順次配信を提供します。これにより、行頭ブロッキングを最小限に抑えることができます。 SCTPは、優先度や公平な重み付けスキームなど、ストリームの多重化を制御する複数のストリームスケジューリングスキームをサポートしています。
SCTP was originally developed for transporting telephony signaling messages and is deployed in telephony signaling networks, especially in mobile telephony networks. It can also be used for other services, for example, in the WebRTC framework for data channels.
SCTPは、もともとはテレフォニーシグナリングメッセージを転送するために開発され、テレフォニーシグナリングネットワーク、特にモバイルテレフォニーネットワークに導入されています。また、データチャネルのWebRTCフレームワークなどの他のサービスにも使用できます。
SCTP is a connection-oriented protocol using a four-way handshake to establish an SCTP association and a three-way message exchange to gracefully shut it down. It uses the same port number concept as DCCP, TCP, UDP, and UDP-Lite. SCTP only supports unicast.
SCTPは、4方向のハンドシェイクを使用してSCTPアソシエーションを確立し、3方向のメッセージ交換を使用して正常にシャットダウンする、コネクション型プロトコルです。 DCCP、TCP、UDP、UDP-Liteと同じポート番号の概念を使用しています。 SCTPはユニキャストのみをサポートします。
SCTP uses the 32-bit CRC32c for protecting SCTP packets against bit errors and misdelivery of packets to an unintended endpoint. This is stronger than the 16-bit checksums used by TCP or UDP. However, partial payload checksum coverage as provided by DCCP or UDP-Lite is not supported.
SCTPは32ビットCRC32cを使用して、SCTPパケットをビットエラーや意図しないエンドポイントへのパケットの誤配信から保護します。これは、TCPまたはUDPで使用される16ビットのチェックサムよりも強力です。ただし、DCCPまたはUDP-Liteによって提供される部分的なペイロードチェックサムカバレッジはサポートされていません。
SCTP has been designed with extensibility in mind. A common header is followed by a sequence of chunks. [RFC4960] defines how a receiver processes chunks with an unknown chunk type. The support of extensions can be negotiated during the SCTP handshake. Currently defined extensions include mechanisms for dynamic reconfiguration of streams [RFC6525] and IP addresses [RFC5061]. Furthermore, the extension specified in [RFC3758] introduces the concept of partial reliability for user messages.
SCTPは拡張性を考慮して設計されています。共通ヘッダーの後に一連のチャンクが続きます。 [RFC4960]は、レシーバーが未知のチャンクタイプのチャンクを処理する方法を定義します。拡張機能のサポートは、SCTPハンドシェイク中にネゴシエートできます。現在定義されている拡張には、ストリーム[RFC6525]およびIPアドレス[RFC5061]の動的再構成のためのメカニズムが含まれています。さらに、[RFC3758]で指定されている拡張機能は、ユーザーメッセージの部分的な信頼性の概念を導入しています。
SCTP provides a message-oriented service. Multiple small user messages can be bundled into a single SCTP packet to improve efficiency. For example, this bundling may be done by delaying user messages at the sender, similar to Nagle's algorithm used by TCP. User messages that would result in IP packets larger than the MTU will be fragmented at the sender and reassembled at the receiver. There is no protocol limit on the user message size. For MTU discovery, the same mechanism as for TCP can be used [RFC1981] [RFC4821], as well as utilization of probe packets with padding chunks, as defined in [RFC4820].
SCTPはメッセージ指向のサービスを提供します。複数の小さなユーザーメッセージを1つのSCTPパケットにバンドルして、効率を向上させることができます。たとえば、このバンドリングは、TCPで使用されるNagleのアルゴリズムと同様に、送信者でユーザーメッセージを遅延させることで実行できます。 MTUよりも大きいIPパケットになるユーザーメッセージは、送信側でフラグメント化され、受信側で再構成されます。ユーザーメッセージのサイズにプロトコルの制限はありません。 MTUディスカバリでは、TCPと同じメカニズムを使用できます[RFC1981] [RFC4821]、および[RFC4820]で定義されているパディングチャンクを使用したプローブパケットの利用。
[RFC4960] specifies TCP-friendly congestion control to protect the network against overload. SCTP also uses sliding window flow control to protect receivers against overflow. Similar to TCP, SCTP also supports delaying acknowledgments. [RFC7053] provides a way for the sender of user messages to request immediate sending of the corresponding acknowledgments.
[RFC4960]は、TCPに適した輻輳制御を指定して、ネットワークを過負荷から保護します。 SCTPは、スライディングウィンドウフロー制御も使用して、オーバーフローからレシーバーを保護します。 TCPと同様に、SCTPも確認応答の遅延をサポートしています。 [RFC7053]は、ユーザーメッセージの送信者が対応する確認の即時送信を要求する方法を提供します。
Each SCTP association has between 1 and 65536 unidirectional streams in each direction. The number of streams can be different in each direction. Every user message is sent on a particular stream. User messages can be sent unordered or ordered upon request by the upper layer. Unordered messages can be delivered as soon as they are completely received. For user messages not requiring fragmentation, this minimizes head-of-line blocking. On the other hand, ordered messages sent on the same stream are delivered at the receiver in the same order as sent by the sender.
各SCTPアソシエーションには、各方向に1〜65536の単方向ストリームがあります。ストリームの数は、方向ごとに異なる場合があります。すべてのユーザーメッセージは特定のストリームで送信されます。ユーザーメッセージは、上位層からの要求に応じて、順序なしで送信することも、順序付けして送信することもできます。順序付けされていないメッセージは、完全に受信されるとすぐに配信できます。断片化を必要としないユーザーメッセージの場合、これにより行頭ブロッキングが最小限に抑えられます。一方、同じストリームで送信された順序付けされたメッセージは、送信者が送信したのと同じ順序で受信者に配信されます。
The base protocol defined in [RFC4960] does not allow interleaving of user messages. Large messages on one stream can therefore block the sending of user messages on other streams. [SCTP-NDATA] describes a method to overcome this limitation. This document also specifies multiple algorithms for the sender-side selection of which streams to send data from, supporting a variety of scheduling algorithms including priority-based methods. The stream reconfiguration extension defined in [RFC6525] allows streams to be reset during the lifetime of an association and to increase the number of streams, if the number of streams negotiated in the SCTP handshake becomes insufficient.
[RFC4960]で定義されている基本プロトコルでは、ユーザーメッセージのインターリーブは許可されていません。したがって、1つのストリーム上の大きなメッセージは、他のストリーム上のユーザーメッセージの送信をブロックする可能性があります。 [SCTP-NDATA]は、この制限を克服する方法を説明しています。また、このドキュメントでは、送信者側でデータを送信するストリームを選択するための複数のアルゴリズムを指定し、優先度に基づく方法を含むさまざまなスケジューリングアルゴリズムをサポートしています。 [RFC6525]で定義されているストリーム再構成拡張により、アソシエーションの存続期間中にストリームをリセットし、SCTPハンドシェイクでネゴシエートされるストリームの数が不十分になった場合にストリームの数を増やすことができます。
Each user message sent is delivered to the receiver or, in case of excessive retransmissions, the association is terminated in a non-graceful way [RFC4960], similar to TCP behavior. In addition to this reliable transfer, the partial reliability extension [RFC3758] allows a sender to abandon user messages. The application can specify the policy for abandoning user messages.
送信された各ユーザーメッセージは受信者に配信されます。過剰な再送信の場合、アソシエーションはTCPの動作と同様に、正常な方法[RFC4960]で終了します。この信頼性の高い転送に加えて、部分的信頼性拡張[RFC3758]により、送信者はユーザーメッセージを破棄できます。アプリケーションは、ユーザーメッセージを破棄するためのポリシーを指定できます。
SCTP supports multihoming. Each SCTP endpoint uses a list of IP addresses and a single port number. These addresses can be any mixture of IPv4 and IPv6 addresses. These addresses are negotiated during the handshake, and the address reconfiguration extension specified in [RFC5061] in combination with [RFC4895] can be used to change these addresses in an authenticated way during the lifetime of an SCTP association. This allows for transport-layer mobility. Multiple addresses are used for improved resilience. If a remote address becomes unreachable, the traffic is switched over to a reachable one, if one exists.
SCTPはマルチホーミングをサポートしています。各SCTPエンドポイントは、IPアドレスのリストと単一のポート番号を使用します。これらのアドレスは、IPv4アドレスとIPv6アドレスの任意の混合にすることができます。これらのアドレスはハンドシェイク中にネゴシエートされ、[RFC5061]で指定されたアドレス再構成拡張を[RFC4895]と組み合わせて使用して、SCTPアソシエーションの有効期間中に認証された方法でこれらのアドレスを変更できます。これにより、トランスポート層のモビリティが可能になります。回復力を高めるために、複数のアドレスが使用されます。リモートアドレスが到達不能になると、トラフィックは到達可能なアドレスに切り替えられます（存在する場合）。
For securing user messages, the use of TLS over SCTP has been specified in [RFC3436]. However, this solution does not support all services provided by SCTP, such as unordered delivery or partial reliability. Therefore, the use of DTLS over SCTP has been specified in [RFC6083] to overcome these limitations. When using DTLS over SCTP, the application can use almost all services provided by SCTP.
ユーザーメッセージを保護するために、SCTPを介したTLSの使用が[RFC3436]で指定されています。ただし、このソリューションは、無秩序な配信や部分的な信頼性など、SCTPによって提供されるすべてのサービスをサポートするわけではありません。したがって、SCTP over DTLSの使用は、これらの制限を克服するために[RFC6083]で指定されています。 DTP over SCTPを使用する場合、アプリケーションはSCTPが提供するほとんどすべてのサービスを使用できます。
[NAT-SUPP] defines methods for endpoints and middleboxes to provide NAT traversal for SCTP over IPv4. For legacy NAT traversal, [RFC6951] defines the UDP encapsulation of SCTP packets. Alternatively, SCTP packets can be encapsulated in DTLS packets as specified in [SCTP-DTLS-ENCAPS]. The latter encapsulation is used within the WebRTC [WEBRTC-TRANS] context.
[NAT-SUPP]は、IPv4上のSCTPにNATトラバーサルを提供するためのエンドポイントとミドルボックスのメソッドを定義します。レガシーNATトラバーサルの場合、[RFC6951]はSCTPパケットのUDPカプセル化を定義します。あるいは、[SCTP-DTLS-ENCAPS]で指定されているように、SCTPパケットをDTLSパケットにカプセル化できます。後者のカプセル化は、WebRTC [WEBRTC-TRANS]コンテキスト内で使用されます。
An SCTP ABORT chunk may be used to force a SCTP endpoint to close a session [RFC4960], aborting the connection.
SCTP ABORTチャンクを使用して、SCTPエンドポイントに強制的にセッションを強制終了させ[RFC4960]、接続を中止することができます。
SCTP has a well-defined API, described in the next subsection.
SCTPには明確に定義されたAPIがあり、次のサブセクションで説明します。
[RFC4960] defines an abstract API for the base protocol. This API describes the following functions callable by the upper layer of SCTP: Initialize, Associate, Send, Receive, Receive Unsent Message, Receive Unacknowledged Message, Shutdown, Abort, SetPrimary, Status, Change Heartbeat, Request Heartbeat, Get SRTT Report, Set Failure Threshold, Set Protocol Parameters, and Destroy. The following notifications are provided by the SCTP stack to the upper layer: COMMUNICATION UP, DATA ARRIVE, SHUTDOWN COMPLETE, COMMUNICATION LOST, COMMUNICATION ERROR, RESTART, SEND FAILURE, and NETWORK STATUS CHANGE.
[RFC4960]は、基本プロトコルの抽象APIを定義しています。このAPIは、SCTPの上位層から呼び出し可能な次の関数を記述します：初期化、関連付け、送信、受信、未送信メッセージの受信、未確認メッセージの受信、シャットダウン、中止、SetPrimary、ステータス、ハートビートの変更、ハートビートの要求、SRTTレポートの取得、失敗の設定しきい値、プロトコルパラメータの設定、破棄。 SCTPスタックから次の通知が上位層に提供されます。通信のアップ、データの到着、シャットダウンの完了、通信の喪失、通信エラー、再起動、送信の失敗、およびネットワークステータスの変更。
An extension to the BSD Sockets API is defined in [RFC6458] and covers:
BSDソケットAPIの拡張は[RFC6458]で定義されており、以下をカバーしています。
o the base protocol defined in [RFC4960]. The API allows control over local addresses and port numbers and the primary path. Furthermore, the application has fine control of parameters like retransmission thresholds, the path supervision, the delayed acknowledgment timeout, and the fragmentation point. The API provides a mechanism to allow the SCTP stack to notify the application about events if the application has requested them. These notifications provide information about status changes of the association and each of the peer addresses. In case of send failures, including drop of messages sent unreliably, the application can also be notified, and user messages can be returned to the application. When sending user messages, the application can indicate a stream id, a payload protocol identifier, and an indication of whether ordered delivery is requested. These parameters can also be provided on message reception. Additionally, a context can be provided when sending, which can be used in case of send failures. The sending of arbitrarily large user messages is supported.
o [RFC4960]で定義されている基本プロトコル。 APIを使用すると、ローカルアドレスとポート番号、およびプライマリパスを制御できます。さらに、アプリケーションでは、再送信のしきい値、パスの監視、遅延確認応答タイムアウト、断片化ポイントなどのパラメーターを細かく制御できます。 APIは、アプリケーションがイベントを要求した場合に、SCTPスタックがイベントについてアプリケーションに通知できるようにするメカニズムを提供します。これらの通知は、関連付けと各ピアアドレスのステータス変更に関する情報を提供します。信頼できない方法で送信されたメッセージのドロップなど、送信エラーが発生した場合は、アプリケーションに通知され、ユーザーメッセージをアプリケーションに返すことができます。ユーザーメッセージを送信するとき、アプリケーションは、ストリームID、ペイロードプロトコル識別子、および順序付けられた配信が要求されているかどうかの表示を示すことができます。これらのパラメータは、メッセージの受信時にも提供できます。さらに、送信時にコンテキストを提供できます。これは、送信が失敗した場合に使用できます。任意の大きなユーザーメッセージの送信がサポートされています。
o the SCTP Partial Reliability extension defined in [RFC3758] to specify for a user message the Partially Reliable SCTP (PR-SCTP) policy and the policy-specific parameter. Examples of these policies defined in [RFC3758] and [RFC7496] are:
o [RFC3758]で定義されているSCTP部分信頼性拡張機能。ユーザーメッセージに部分信頼性SCTP（PR-SCTP）ポリシーとポリシー固有のパラメーターを指定します。 [RFC3758]と[RFC7496]で定義されているこれらのポリシーの例は次のとおりです。
* limiting the time a user message is dealt with by the sender.
* ユーザーメッセージが送信者によって処理される時間を制限する。
* limiting the number of retransmissions for each fragment of a user message. If the number of retransmissions is limited to 0, one gets a service similar to UDP.
* ユーザーメッセージの各フラグメントの再送信回数を制限します。再送信の数が0に制限されている場合、UDPと同様のサービスが提供されます。
* abandoning messages of lower priority in case of a send buffer shortage.
* 送信バッファが不足した場合、優先度の低いメッセージを破棄します。
o the SCTP Authentication extension defined in [RFC4895] allowing management of the shared keys and allowing the HMAC to use and set the chunk types (which are only accepted in an authenticated way) and get the list of chunks that are accepted by the local and remote endpoints in an authenticated way.
o [RFC4895]で定義されているSCTP認証拡張により、共有キーの管理が可能になり、HMACがチャンクタイプ（認証された方法でのみ受け入れられる）を使用および設定し、ローカルおよびリモートで受け入れられるチャンクのリストを取得できるようになります。認証された方法でエンドポイント。
o the SCTP Dynamic Address Reconfiguration extension defined in [RFC5061]. It allows the manual addition and deletion of local addresses for SCTP associations, as well as the enabling of automatic address addition and deletion. Furthermore, the peer can be given a hint for choosing its primary path.
o [RFC5061]で定義されているSCTP動的アドレス再構成拡張。 SCTPアソシエーションのローカルアドレスを手動で追加および削除したり、自動アドレス追加および削除を有効にしたりできます。さらに、ピアには、プライマリパスを選択するためのヒントを与えることができます。
A BSD Sockets API extension has been defined in the documents that specify the following SCTP extensions:
BSDソケットAPI拡張は、次のSCTP拡張を指定するドキュメントで定義されています。
o the SCTP Stream Reconfiguration extension defined in [RFC6525]. The API allows triggering of the reset operation for incoming and outgoing streams and the whole association. It also provides a way to notify the association about the corresponding events. Furthermore, the application can increase the number of streams.
o [RFC6525]で定義されたSCTPストリーム再構成拡張。 APIを使用すると、着信ストリームと発信ストリーム、および関連付け全体のリセット操作をトリガーできます。また、対応するイベントについて協会に通知する方法も提供します。さらに、アプリケーションはストリームの数を増やすことができます。
o the UDP Encapsulation of SCTP packets extension defined in [RFC6951]. The API allows the management of the remote UDP encapsulation port.
o [RFC6951]で定義されているSCTPパケットのUDPカプセル化拡張。 APIを使用すると、リモートUDPカプセル化ポートを管理できます。
o the SCTP SACK-IMMEDIATELY extension defined in [RFC7053]. The API allows the sender of a user message to request the receiver to send the corresponding acknowledgment immediately.
o [RFC7053]で定義されているSCTP SACK-IMMEDIATELY拡張。 APIを使用すると、ユーザーメッセージの送信者は、対応する確認応答をすぐに送信するように受信者に要求できます。
o the additional PR-SCTP policies defined in [RFC7496]. The API allows enabling/disabling the PR-SCTP extension, choosing the PR-SCTP policies defined in the document, and providing statistical information about abandoned messages.
o [RFC7496]で定義されている追加のPR-SCTPポリシー。 APIを使用すると、PR-SCTP拡張を有効/無効にし、ドキュメントで定義されているPR-SCTPポリシーを選択し、破棄されたメッセージに関する統計情報を提供できます。
Future documents describing SCTP extensions are expected to describe the corresponding BSD Sockets API extension in a "Socket API Considerations" section.
SCTP拡張機能を説明する将来のドキュメントでは、「ソケットAPIの考慮事項」セクションで、対応するBSDソケットAPI拡張機能を説明することが期待されています。
The SCTP Socket API supports two kinds of sockets:
SCTPソケットAPIは、次の2種類のソケットをサポートしています。
o one-to-one style sockets (by using the socket type "SOCK_STREAM").
o 1対1スタイルのソケット（ソケットタイプ「SOCK_STREAM」を使用）。
o one-to-many style socket (by using the socket type "SOCK_SEQPACKET").
o 1対多スタイルのソケット（ソケットタイプ "SOCK_SEQPACKET"を使用）。
One-to-one style sockets are similar to TCP sockets; there is a 1:1 relationship between the sockets and the SCTP associations (except for listening sockets). One-to-many style SCTP sockets are similar to unconnected UDP sockets, where there is a 1:n relationship between the sockets and the SCTP associations.
1対1スタイルのソケットはTCPソケットに似ています。ソケットとSCTPアソシエーションの間には1：1の関係があります（リスニングソケットを除く）。 1対多スタイルのSCTPソケットは、接続されていないUDPソケットに似ており、ソケットとSCTPアソシエーションの間に1：nの関係があります。
The SCTP stack can provide information to the applications about state changes of the individual paths and the association whenever they occur. These events are delivered similarly to user messages but are specifically marked as notifications.
SCTPスタックは、個々のパスの状態変化とそれらが発生したときの関連付けに関する情報をアプリケーションに提供できます。これらのイベントはユーザーメッセージと同様に配信されますが、特に通知としてマークされます。
New functions have been introduced to support the use of multiple local and remote addresses. Additional SCTP-specific send and receive calls have been defined to permit SCTP-specific information to be sent without using ancillary data in the form of additional Control Message (cmsg) calls. These functions provide support for detecting partial delivery of user messages and notifications.
複数のローカルアドレスとリモートアドレスの使用をサポートするための新機能が導入されました。追加のSCTP固有の送受信呼び出しが定義され、追加の制御メッセージ（cmsg）呼び出しの形式で補助データを使用せずにSCTP固有の情報を送信できるようになりました。これらの関数は、ユーザーメッセージと通知の部分的な配信を検出するためのサポートを提供します。
The SCTP Socket API allows a fine-grained control of the protocol behavior through an extensive set of socket options.
SCTPソケットAPIを使用すると、ソケットオプションの広範なセットを介して、プロトコルの動作をきめ細かく制御できます。
The SCTP kernel implementations of FreeBSD, Linux, and Solaris follow mostly the specified extension to the BSD Sockets API for the base protocol and the corresponding supported protocol extensions.
FreeBSD、Linux、およびSolarisのSCTPカーネル実装は、基本プロトコルのBSDソケットAPIに指定された拡張と、対応するサポートされているプロトコル拡張に従います。
The transport features provided by SCTP are:
SCTPが提供するトランスポート機能は次のとおりです。
o connection-oriented transport with feature negotiation and application-to-port mapping,
o 機能ネゴシエーションとアプリケーションからポートへのマッピングを備えた接続指向のトランスポート、
o unicast transport,
o ユニキャストトランスポート、
o port multiplexing,
o ポートの多重化、
o unidirectional or bidirectional communication, o message-oriented delivery with durable message framing supporting multiple concurrent streams,
o単方向または双方向通信、o複数の同時ストリームをサポートする耐久性のあるメッセージフレーミングを備えたメッセージ指向の配信、
o fully reliable, partially reliable, or unreliable delivery (based on user-specified policy to handle abandoned user messages) with drop notification,
o 完全に信頼できる、部分的に信頼できる、または信頼できない配信（破棄されたユーザーメッセージを処理するユーザー指定のポリシーに基づく）、ドロップ通知付き
o ordered and unordered delivery within a stream,
o ストリーム内での順序付きおよび順序なしの配信
o support for stream scheduling prioritization,
o ストリームスケジューリングの優先順位付けのサポート
o segmentation,
o セグメンテーション、
o user message bundling,
o ユーザーメッセージのバンドル、
o flow control using a window-based mechanism,
o ウィンドウベースのメカニズムを使用したフロー制御、
o congestion control using methods similar to TCP,
o TCPと同様の方法を使用した輻輳制御
o strong error detection (CRC32c), and
o 強力なエラー検出（CRC32c）、および
o transport-layer multihoming for resilience and mobility.
o 回復力とモビリティのためのトランスポート層マルチホーミング。
The Datagram Congestion Control Protocol (DCCP) [RFC4340] is an IETF Standards Track bidirectional transport protocol that provides unicast connections of congestion-controlled messages without providing reliability.
データグラム輻輳制御プロトコル（DCCP）[RFC4340]は、信頼性を提供せずに輻輳制御メッセージのユニキャスト接続を提供するIETF標準トラック双方向トランスポートプロトコルです。
The DCCP Problem Statement [RFC4336] describes the goals that DCCP sought to address. It is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the trade-off between timeliness and reliability [RFC4336].
DCCP問題ステートメント[RFC4336]は、DCCPが対処しようとした目標について説明しています。かなり大量のデータを転送するアプリケーションに適しており、適時性と信頼性の間のトレードオフの制御から利益を得ることができます[RFC4336]。
DCCP offers low overhead, and many characteristics common to UDP, but can avoid "re-inventing the wheel" each time a new multimedia application emerges. Specifically, it includes core transport functions (feature negotiation, path state management, RTT calculation, PMTUD, etc.): DCCP applications select how they send packets and, where suitable, choose common algorithms to manage their functions. Examples of applications that can benefit from such transport services include interactive applications, streaming media, or on-line games [RFC4336].
DCCPは、オーバーヘッドが低く、UDPに共通する多くの特性を提供しますが、新しいマルチメディアアプリケーションが出現するたびに「車輪の再発明」を回避できます。具体的には、コアトランスポート機能（機能ネゴシエーション、パス状態管理、RTT計算、PMTUDなど）が含まれます。DCCPアプリケーションは、パケットの送信方法を選択し、適切な場合は、共通のアルゴリズムを選択して機能を管理します。このようなトランスポートサービスの恩恵を受けることができるアプリケーションの例には、インタラクティブアプリケーション、ストリーミングメディア、またはオンラインゲームが含まれます[RFC4336]。
DCCP is a connection-oriented datagram protocol that provides a three-way handshake to allow a client and server to set up a connection and provides mechanisms for orderly completion and immediate teardown of a connection.
DCCPは、クライアントとサーバーが接続をセットアップできるようにする3ウェイハンドシェイクを提供する接続指向のデータグラムプロトコルであり、接続の正常な完了と即時の破棄のためのメカニズムを提供します。
A DCCP protocol instance can be extended [RFC4340] and tuned using additional features. Some features are sender-side only, requiring no negotiation with the receiver; some are receiver-side only; and some are explicitly negotiated during connection setup.
DCCPプロトコルインスタンスは拡張でき[RFC4340]、追加機能を使用して調整できます。一部の機能は送信側のみであり、受信側とのネゴシエーションを必要としません。一部は受信側のみです。また、一部は接続のセットアップ中に明示的にネゴシエートされます。
DCCP uses a Connect packet to initiate a session and permits each endpoint to choose the features it wishes to support. Simultaneous open [RFC5596], as in TCP, can enable interoperability in the presence of middleboxes. The Connect packet includes a Service Code [RFC5595] that identifies the application or protocol using DCCP, providing middleboxes with information about the intended use of a connection.
DCCPは、接続パケットを使用してセッションを開始し、各エンドポイントがサポートする機能を選択できるようにします。同時オープン[RFC5596]は、TCPと同様に、ミドルボックスの存在下での相互運用性を可能にします。接続パケットには、DCCPを使用してアプリケーションまたはプロトコルを識別するサービスコード[RFC5595]が含まれており、ミドルボックスに接続の使用目的に関する情報を提供します。
The DCCP service is unicast-only.
DCCPサービスはユニキャストのみです。
It provides multiplexing to multiple sockets at each endpoint using port numbers. An active DCCP session is identified by its four-tuple of local and remote IP addresses and local and remote port numbers.
ポート番号を使用して、各エンドポイントで複数のソケットへの多重化を提供します。アクティブなDCCPセッションは、ローカルおよびリモートのIPアドレスの4つのタプルと、ローカルおよびリモートのポート番号によって識別されます。
The protocol segments data into messages that are typically sized to fit in IP packets but may be fragmented if they are smaller than the maximum packet size. A DCCP interface allows applications to request fragmentation for packets larger than PMTU, but not larger than the maximum packet size allowed by the current congestion control mechanism (Congestion Control Maximum Packet Size (CCMPS)) [RFC4340].
プロトコルは、データを通常はIPパケットに収まるサイズのメッセージに分割しますが、最大パケットサイズよりも小さい場合は断片化される可能性があります。 DCCPインターフェイスを使用すると、アプリケーションはPMTUよりも大きいが、現在の輻輳制御メカニズム（輻輳制御の最大パケットサイズ（CCMPS））で許可されている最大パケットサイズを超えないパケットのフラグメント化を要求できます[RFC4340]。
Each message is identified by a sequence number. The sequence number is used to identify segments in acknowledgments, to detect unacknowledged segments, to measure RTT, etc. The protocol may support unordered delivery of data and does not itself provide retransmission. DCCP supports reduced checksum coverage, a partial payload protection mechanism similar to UDP-Lite. There is also a Data Checksum option, which when enabled, contains a strong Cyclic Redundancy Check (CRC), to enable endpoints to detect application data corruption.
各メッセージはシーケンス番号で識別されます。シーケンス番号は、確認応答でのセグメントの識別、未確認のセグメントの検出、RTTの測定などに使用されます。プロトコルは、データの無秩序な配信をサポートする場合があり、それ自体は再送信を提供しません。 DCCPは、UDP-Liteと同様の部分的なペイロード保護メカニズムであるチェックサムカバレッジの削減をサポートしています。また、有効にすると強力な巡回冗長検査（CRC）が含まれるデータチェックサムオプションがあり、エンドポイントがアプリケーションデータの破損を検出できるようになります。
Receiver flow control is supported, which limits the amount of unacknowledged data that can be outstanding at a given time.
レシーバーフロー制御がサポートされます。これにより、特定の時点で未処理になる可能性がある未確認のデータの量が制限されます。
A DCCP Reset packet may be used to force a DCCP endpoint to close a session [RFC4340], aborting the connection.
DCCPリセットパケットを使用して、DCCPエンドポイントに強制的にセッションを終了させ[RFC4340]、接続を中止することができます。
DCCP supports negotiation of the congestion control profile between endpoints, to provide plug-and-play congestion control mechanisms. Examples of specified profiles include "TCP-like" [RFC4341], "TCP-friendly" [RFC4342], and "TCP-friendly for small packets" [RFC5622]. Additional mechanisms are recorded in an IANA registry (see <http://www.iana.org/assignments/dccp-parameters>).
DCCPは、プラグアンドプレイの輻輳制御メカニズムを提供するために、エンドポイント間の輻輳制御プロファイルのネゴシエーションをサポートしています。指定されたプロファイルの例には、「TCPのような」[RFC4341]、「TCPに適した」[RFC4342]、「小さなパケットに対してTCPに適した」[RFC5622]などがあります。追加のメカニズムはIANAレジストリに記録されます（<http://www.iana.org/assignments/dccp-parameters>を参照）。
A lightweight UDP-based encapsulation (DCCP-UDP) has been defined
[RFC6773] that permits DCCP to be used over paths where DCCP is not
natively supported. Support for DCCP in NAPT/NATs is defined in
[RFC4340] and [RFC5595]. Upper-layer protocols specified on top of
DCCP include DTLS [RFC5238], RTP [RFC5762], and Interactive
Connectivity Establishment / Session Description Protocol (ICE/SDP)
[RFC6773].
Functions expected for a DCCP API include: Open, Close, and Management of the progress a DCCP connection. The Open function provides feature negotiation, selection of an appropriate Congestion Control Identifier (CCID) for congestion control, and other parameters associated with the DCCP connection. A function allows an application to send DCCP datagrams, including setting the required checksum coverage and any required options. (DCCP permits sending datagrams with a zero-length payload.) A function allows reception of data, including indicating if the data was used or dropped. Functions can also make the status of a connection visible to an application, including detection of the maximum packet size and the ability to perform flow control by detecting a slow receiver at the sender.
DCCP APIに期待される機能は次のとおりです。DCCP接続の進行状況のオープン、クローズ、および管理。 Open機能は、機能ネゴシエーション、輻輳制御のための適切な輻輳制御識別子（CCID）の選択、およびDCCP接続に関連するその他のパラメーターを提供します。関数は、アプリケーションがDCCPデータグラムを送信できるようにします。これには、必要なチェックサムカバレッジと必要なオプションの設定が含まれます。 （DCCPは、長さがゼロのペイロードでデータグラムを送信することを許可します。）関数は、データが使用されたかドロップされたかを示すなど、データの受信を許可します。関数は、最大パケットサイズの検出や、送信側で低速の受信側を検出してフロー制御を実行する機能など、アプリケーションに接続のステータスを表示することもできます。
There is no API currently specified in the RFC Series.
現在、RFCシリーズで指定されているAPIはありません。
The transport features provided by DCCP are:
DCCPが提供するトランスポート機能は次のとおりです。
o unicast transport,
o ユニキャストトランスポート、
o connection-oriented communication with feature negotiation and application-to-port mapping,
o 機能ネゴシエーションとアプリケーションからポートへのマッピングによる接続指向の通信、
o signaling of application class for middlebox support (implemented using Service Codes),
o ミドルボックスサポートのアプリケーションクラスのシグナリング（サービスコードを使用して実装）
o port multiplexing,
o ポートの多重化、
o unidirectional or bidirectional communication, o message-oriented delivery,
o単方向または双方向の通信、メッセージ指向の配信、
o unreliable delivery with drop notification,
o ドロップ通知による信頼できない配信、
o unordered delivery,
o 順不同配送、
o flow control (implemented using the slow receiver function), and
o フロー制御（スローレシーバー機能を使用して実装）、および
o partial and full payload error detection (with optional strong integrity check).
o 部分的および完全なペイロードエラー検出（オプションの強力な整合性チェック付き）。
3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a Pseudotransport
3.7. 疑似トランスポートとしてのトランスポート層セキュリティ（TLS）およびデータグラムTLS（DTLS）
Transport Layer Security (TLS) [RFC5246] and Datagram TLS (DTLS) [RFC6347] are IETF protocols that provide several security-related features to applications. TLS is designed to run on top of a reliable streaming transport protocol (usually TCP), while DTLS is designed to run on top of a best-effort datagram protocol (UDP or DCCP [RFC5238]). At the time of writing, the current version of TLS is 1.2, defined in [RFC5246]; work on TLS version is 1.3 [TLS-1.3] nearing completion. DTLS provides nearly identical functionality to applications; it is defined in [RFC6347] and its current version is also 1.2. The TLS protocol evolved from the Secure Sockets Layer (SSL) [RFC6101] protocols developed in the mid-1990s to support protection of HTTP traffic.
トランスポート層セキュリティ（TLS）[RFC5246]およびデータグラムTLS（DTLS）[RFC6347]は、アプリケーションにいくつかのセキュリティ関連機能を提供するIETFプロトコルです。 TLSは信頼性の高いストリーミングトランスポートプロトコル（通常はTCP）の上で実行するように設計されていますが、DTLSはベストエフォートデータグラムプロトコル（UDPまたはDCCP [RFC5238]）の上で実行するように設計されています。執筆時点では、TLSの現在のバージョンは1.2であり、[RFC5246]で定義されています。 TLSバージョンの作業は1.3 [TLS-1.3]で、完成間近です。 DTLSはアプリケーションとほぼ同じ機能を提供します。 [RFC6347]で定義されており、現在のバージョンも1.2です。 TLSプロトコルは、1990年代半ばにHTTPトラフィックの保護をサポートするために開発されたSecure Sockets Layer（SSL）[RFC6101]プロトコルから発展しました。
While older versions of TLS and DTLS are still in use, they provide weaker security guarantees. [RFC7457] outlines important attacks on TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document that describes secure configurations for TLS and DTLS to counter these attacks. The recommendations are applicable for the vast majority of use cases.
古いバージョンのTLSとDTLSはまだ使用されていますが、セキュリティの保証は低くなっています。 [RFC7457]は、TLSおよびDTLSに対する重要な攻撃の概要を説明しています。 [RFC7525]は、これらの攻撃に対抗するためのTLSおよびDTLSの安全な構成を説明するベストカレントプラクティス（BCP）ドキュメントです。推奨事項は、ほとんどのユースケースに適用できます。
Both TLS and DTLS provide the same security features and can thus be discussed together. The features they provide are:
TLSとDTLSはどちらも同じセキュリティ機能を提供するため、一緒に議論することができます。それらが提供する機能は次のとおりです。
o Confidentiality
o 守秘義務
o Data integrity
o データの整合性
o Peer authentication (optional)
o ピア認証（オプション）
o Perfect forward secrecy (optional) The authentication of the peer entity can be omitted; a common web use case is where the server is authenticated and the client is not. TLS also provides a completely anonymous operation mode in which neither peer's identity is authenticated. It is important to note that TLS itself does not specify how a peering entity's identity should be interpreted. For example, in the common use case of authentication by means of an X.509 certificate, it is the application's decision whether the certificate of the peering entity is acceptable for authorization decisions.
o完全転送秘密（オプション）ピアエンティティの認証は省略できます。一般的なWebの使用例は、サーバーが認証され、クライアントが認証されない場合です。 TLSは、どちらのピアのIDも認証されない完全に匿名の操作モードも提供します。 TLS自体はピアリングエンティティのIDの解釈方法を指定しないことに注意することが重要です。たとえば、X.509証明書による認証の一般的な使用例では、ピアリングエンティティの証明書が承認の決定に受け入れられるかどうかはアプリケーションの決定です。
Perfect forward secrecy, if enabled and supported by the selected algorithms, ensures that traffic encrypted and captured during a session at time t0 cannot be later decrypted at time t1 (t1 > t0), even if the long-term secrets of the communicating peers are later compromised.
Perfect Forward Secrecyは、選択したアルゴリズムによって有効化およびサポートされている場合、通信するピアの長期的なシークレットが保持されている場合でも、時刻t0のセッション中に暗号化およびキャプチャされたトラフィックが、時刻t1（t1> t0）で後で復号化できないことを保証します。後で妥協。
As DTLS is generally used over an unreliable datagram transport such as UDP, applications will need to tolerate lost, reordered, or duplicated datagrams. Like TLS, DTLS conveys application data in a sequence of independent records. However, because records are mapped to unreliable datagrams, there are several features unique to DTLS that are not applicable to TLS:
DTLSは一般に、UDPなどの信頼性の低いデータグラムトランスポートで使用されるため、アプリケーションは、失われた、並べ替えられた、または重複したデータグラムを許容する必要があります。 TLSと同様に、DTLSはアプリケーションデータを一連の独立したレコードで伝達します。ただし、レコードは信頼できないデータグラムにマッピングされるため、TLSに適用できないDTLS固有の機能がいくつかあります。
o Record replay detection (optional).
o 記録リプレイ検出（オプション）。
o Record size negotiation (estimates of PMTU and record size expansion factor).
o レコードサイズネゴシエーション（PMTUおよびレコードサイズ拡張係数の推定）。
o Conveyance of IP don't fragment (DF) bit settings by application.
o IPの伝達は、アプリケーションごとに（DF）ビット設定を断片化しません。
o An anti-DoS stateless cookie mechanism (optional).
o アンチDoSステートレスCookieメカニズム（オプション）。
Generally, DTLS follows the TLS design as closely as possible. To operate over datagrams, DTLS includes a sequence number and limited forms of retransmission and fragmentation for its internal operations. The sequence number may be used for detecting replayed information, according to the windowing procedure described in Section 4.1.2.6 of [RFC6347]. DTLS forbids the use of stream ciphers, which are essentially incompatible when operating on independent encrypted records.
一般に、DTLSはTLS設計に可能な限り厳密に従います。データグラムを操作するために、DTLSには、シーケンス番号と、その内部操作のための再送信と断片化の制限された形式が含まれています。シーケンス番号は、[RFC6347]のセクション4.1.2.6で説明されているウィンドウ処理手順に従って、再生された情報を検出するために使用できます。 DTLSは、独立した暗号化レコードを操作する場合、本質的に互換性のないストリーム暗号の使用を禁止します。
TLS is commonly invoked using an API provided by packages such as OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the manipulation of several important abstractions, which fall into the following categories: long-term keys and algorithms, session state, and communications/connections.
TLSは通常、OpenSSL、wolfSSL、GnuTLSなどのパッケージによって提供されるAPIを使用して呼び出されます。このようなAPIを使用するには、いくつかの重要な抽象化を操作する必要があります。これらの抽象化は、長期キーとアルゴリズム、セッション状態、通信/接続のカテゴリに分類されます。
Considerable care is required in the use of TLS APIs to ensure creation of a secure application. The programmer should have at least a basic understanding of encryption and digital signature algorithms and their strengths, public key infrastructure (including X.509 certificates and certificate revocation), and the Sockets API. See [RFC7525] and [RFC7457], as mentioned above.
安全なアプリケーションの作成を確実にするために、TLS APIの使用にはかなりの注意が必要です。プログラマーは、暗号化とデジタル署名のアルゴリズムとその長所、公開鍵インフラストラクチャ（X.509証明書と証明書の失効を含む）、およびソケットAPIの少なくとも基本的な知識が必要です。上記のように、[RFC7525]と[RFC7457]を参照してください。
As an example, in the case of OpenSSL, the primary abstractions are the library itself, method (protocol), session, context, cipher, and connection. After initializing the library and setting the method, a cipher suite is chosen and used to configure a context object. Session objects may then be minted according to the parameters present in a context object and associated with individual connections. Depending on how precisely the programmer wishes to select different algorithmic or protocol options, various levels of details may be required.
例として、OpenSSLの場合、主要な抽象化は、ライブラリ自体、メソッド（プロトコル）、セッション、コンテキスト、暗号、および接続です。ライブラリを初期化してメソッドを設定した後、暗号スイートが選択され、コンテキストオブジェクトの構成に使用されます。次に、セッションオブジェクトは、コンテキストオブジェクトに存在し、個々の接続に関連付けられているパラメータに従って作成されます。プログラマーがさまざまなアルゴリズムまたはプロトコルのオプションをどれだけ正確に選択したいかに応じて、さまざまなレベルの詳細が必要になる場合があります。
Both TLS and DTLS employ a layered architecture. The lower layer is commonly called the "record protocol". It is responsible for:
TLSとDTLSはどちらも階層化アーキテクチャを採用しています。下層は一般に「レコードプロトコル」と呼ばれます。それは以下の責任があります：
o message fragmentation,
o メッセージの断片化、
o authentication and integrity via message authentication codes (MACs),
o メッセージ認証コード（MAC）による認証と整合性
o data encryption, and
o データの暗号化、および
o scheduling transmission using the underlying transport protocol.
o 基になるトランスポートプロトコルを使用して送信をスケジュールします。
DTLS augments the TLS record protocol with:
DTLSは、TLSレコードプロトコルを次のように拡張します。
o ordering and replay protection, implemented using sequence numbers.
o 順序番号を使用して実装された、注文と再生の保護。
Several protocols are layered on top of the record protocol. These include the handshake, alert, and change cipher spec protocols. There is also the data protocol, used to carry application traffic. The handshake protocol is used to establish cryptographic and compression parameters when a connection is first set up. In DTLS, this protocol also has a basic fragmentation and retransmission capability and a cookie-like mechanism to resist DoS attacks. (TLS compression is not recommended at present). The alert protocol is used to inform the peer of various conditions, most of which are terminal for the connection. The change cipher spec protocol is used to synchronize changes in cryptographic parameters for each peer.
いくつかのプロトコルは、レコードプロトコルの上に重ねられます。これには、ハンドシェイク、アラート、暗号仕様変更プロトコルが含まれます。アプリケーショントラフィックの伝送に使用されるデータプロトコルもあります。ハンドシェイクプロトコルは、接続が最初にセットアップされるときに、暗号化パラメータと圧縮パラメータを確立するために使用されます。 DTLSでは、このプロトコルには基本的な断片化および再送信機能と、DoS攻撃に対抗するためのCookieのようなメカニズムもあります。 （現在、TLS圧縮は推奨されていません）。アラートプロトコルは、ピアにさまざまな状態を通知するために使用されます。そのほとんどは接続の終端です。暗号仕様変更プロトコルは、各ピアの暗号パラメータの変更を同期するために使用されます。
The data protocol, when used with an appropriate cipher, provides:
データプロトコルを適切な暗号で使用すると、次の機能が提供されます。
o authentication of one end or both ends of a connection,
o 接続の一端または両端の認証
o confidentiality, and
o 機密性、および
o cryptographic integrity protection.
o 暗号整合性保護。
Both TLS and DTLS are unicast-only.
TLSとDTLSはどちらもユニキャストのみです。
RTP provides an end-to-end network transport service, suitable for applications transmitting real-time data, such as audio, video or data, over multicast or unicast transport services, including TCP, UDP, UDP-Lite, DCCP, TLS, and DTLS.
RTPは、TCP、UDP、UDP-Lite、DCCP、TLSなどのマルチキャストまたはユニキャストトランスポートサービスを介して、オーディオ、ビデオ、データなどのリアルタイムデータを送信するアプリケーションに適したエンドツーエンドのネットワークトランスポートサービスを提供します。 DTLS。
The RTP standard [RFC3550] defines a pair of protocols: RTP and the RTP Control Protocol (RTCP). The transport does not provide connection setup, instead relying on out-of-band techniques or associated control protocols to setup, negotiate parameters, or tear down a session.
RTP標準[RFC3550]は、RTPとRTP制御プロトコル（RTCP）の2つのプロトコルを定義しています。トランスポートは接続のセットアップを提供せず、代わりに帯域外技術または関連する制御プロトコルを使用して、セットアップ、パラメーターのネゴシエーション、またはセッションの破棄を行います。
An RTP sender encapsulates audio/video data into RTP packets to transport media streams. The RFC Series specifies RTP payload formats that allow packets to carry a wide range of media and specifies a wide range of multiplexing, error control, and other support mechanisms.
RTP送信側は、オーディオ/ビデオデータをRTPパケットにカプセル化して、メディアストリームを転送します。 RFCシリーズは、パケットが広範囲のメディアを伝送できるようにするRTPペイロード形式を規定し、広範囲の多重化、エラー制御、およびその他のサポートメカニズムを規定しています。
If a frame of media data is large, it will be fragmented into several RTP packets. Likewise, several small frames may be bundled into a single RTP packet.
メディアデータのフレームが大きい場合、いくつかのRTPパケットにフラグメント化されます。同様に、いくつかの小さなフレームが1つのRTPパケットにバンドルされる場合があります。
An RTP receiver collects RTP packets from the network, validates them for correctness, and sends them to the media decoder input queue. Missing packet detection is performed by the channel decoder. The playout buffer is ordered by time stamp and is used to reorder packets. Damaged frames may be repaired before the media payloads are decompressed to display or store the data. Some uses of RTP are able to exploit the partial payload protection features offered by DCCP and UDP-Lite.
RTPレシーバーは、ネットワークからRTPパケットを収集し、それらが正しいかどうかを検証して、メディアデコーダーの入力キューに送信します。欠落パケット検出は、チャネルデコーダーによって実行されます。プレイアウトバッファはタイムスタンプ順に並べられ、パケットの並べ替えに使用されます。破損したフレームは、データを表示または保存するためにメディアペイロードが解凍される前に修復される場合があります。 RTPの一部の用途では、DCCPとUDP-Liteが提供する部分的なペイロード保護機能を利用できます。
RTCP is a control protocol that works alongside an RTP flow. Both the RTP sender and receiver will send RTCP report packets. This is used to periodically send control information and report performance.
RTCPは、RTPフローと一緒に機能する制御プロトコルです。 RTP送信側と受信側の両方がRTCPレポートパケットを送信します。これは、定期的に制御情報を送信し、パフォーマンスを報告するために使用されます。
Based on received RTCP feedback, an RTP sender can adjust the transmission, e.g., perform rate adaptation at the application layer in the case of congestion.
受信したRTCPフィードバックに基づいて、RTP送信者は送信を調整できます。たとえば、輻輳が発生した場合にアプリケーションレイヤーでレートアダプテーションを実行できます。
An RTCP receiver report (RTCP RR) is returned to the sender periodically to report key parameters (e.g., the fraction of packets lost in the last reporting interval, the cumulative number of packets lost, the highest sequence number received, and the inter-arrival jitter). The RTCP RR packets also contain timing information that allows the sender to estimate the network round-trip time (RTT) to the receivers.
RTCP受信者レポート（RTCP RR）は定期的に送信者に返され、主要なパラメータ（最後のレポート間隔で失われたパケットの割合、失われたパケットの累積数、受信された最大シーケンス番号、および到着間など）をレポートします。ジッター）。 RTCP RRパケットには、送信者が受信者へのネットワークラウンドトリップ時間（RTT）を推定できるようにするタイミング情報も含まれています。
The interval between reports sent from each receiver tends to be on the order of a few seconds on average, although this varies with the session rate, and sub-second reporting intervals are possible for high rate sessions. The interval is randomized to avoid synchronization of reports from multiple receivers.
各受信者から送信されるレポートの間隔は、平均で数秒程度になる傾向がありますが、これはセッションレートによって異なり、高レートのセッションでは1秒未満のレポート間隔が可能です。複数の受信者からのレポートの同期を回避するために、間隔はランダム化されます。
There is no standard API defined for RTP or RTCP. Implementations are typically tightly integrated with a particular application and closely follow the principles of application-level framing and integrated layer processing [ClarkArch] in media processing [RFC2736], error recovery and concealment, rate adaptation, and security [RFC7202]. Accordingly, RTP implementations tend to be targeted at particular application domains (e.g., voice-over-IP, IPTV, or video conferencing), with a feature set optimized for that domain, rather than being general purpose implementations of the protocol.
RTPまたはRTCP用に定義された標準APIはありません。実装は通常、特定のアプリケーションと緊密に統合され、メディア処理[RFC2736]、エラー回復と隠蔽、レート調整、およびセキュリティ[RFC7202]におけるアプリケーションレベルのフレーミングと統合レイヤー処理[ClarkArch]の原則に厳密に従います。したがって、RTP実装は、特定のアプリケーションドメイン（Voice-over-IP、IPTV、ビデオ会議など）を対象とする傾向があり、プロトコルの汎用実装ではなく、そのドメイン用に最適化された機能セットを備えています。
The transport features provided by RTP are:
RTPが提供するトランスポート機能は次のとおりです。
o unicast, multicast, or IPv4 broadcast (provided by lower-layer protocol),
o ユニキャスト、マルチキャスト、またはIPv4ブロードキャスト（下位層プロトコルによって提供される）、
o port multiplexing (provided by lower-layer protocol),
o ポートの多重化（下位層プロトコルにより提供）、
o unidirectional or bidirectional communication (provided by lower-layer protocol),
o 単方向または双方向通信（下位層プロトコルにより提供）、
o message-oriented delivery with support for media types and other extensions,
o メディアタイプやその他の拡張機能をサポートするメッセージ指向の配信
o reliable delivery when using erasure coding or unreliable delivery with drop notification (if supported by lower-layer protocol),
o イレージャーコーディングを使用する場合の信頼性の高い配信またはドロップ通知付きの信頼性の低い配信（下位層プロトコルでサポートされている場合）、
o connection setup with feature negotiation (using associated protocols) and application-to-port mapping (provided by lower-layer protocol),
o 機能ネゴシエーション（関連プロトコルを使用）およびアプリケーションからポートへのマッピング（下位層プロトコルによって提供）を使用した接続設定、
o segmentation, and
o セグメンテーション、および
o performance metric reporting (using associated protocols).
o パフォーマンスメトリックレポート（関連するプロトコルを使用）。
The Hypertext Transfer Protocol (HTTP) is an application-level protocol widely used on the Internet. It provides object-oriented delivery of discrete data or files. Version 1.1 of the protocol is specified in [RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235], and version 2 is specified in [RFC7540]. HTTP is usually transported over TCP using ports 80 and 443, although it can be used with other transports. When used over TCP, it inherits TCP's properties.
ハイパーテキスト転送プロトコル（HTTP）は、インターネットで広く使用されているアプリケーションレベルのプロトコルです。個別のデータまたはファイルをオブジェクト指向で配信します。プロトコルのバージョン1.1は[RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235]で指定されており、バージョン2は[RFC7540]で指定されています。 HTTPは通常、ポート80と443を使用してTCP経由で転送されますが、他の転送でも使用できます。 TCPを介して使用すると、TCPのプロパティを継承します。
Application-layer protocols may use HTTP as a substrate with an existing method and data formats, or specify new methods and data formats. There are various reasons for this practice listed in [RFC3205]; these include being a well-known and well-understood protocol, reusability of existing servers and client libraries, easy use of existing security mechanisms such as HTTP digest authentication [RFC7235] and TLS [RFC5246], and the ability of HTTP to traverse firewalls, which allows it to work over many types of infrastructure and in cases where an application server often needs to support HTTP anyway.
アプリケーション層プロトコルは、既存のメソッドとデータ形式の基盤としてHTTPを使用するか、新しいメソッドとデータ形式を指定します。 [RFC3205]にリストされているこのプラクティスにはさまざまな理由があります。これらには、よく知られ、よく知られているプロトコル、既存のサーバーとクライアントライブラリの再利用性、HTTPダイジェスト認証[RFC7235]やTLS [RFC5246]などの既存のセキュリティメカニズムの簡単な使用、ファイアウォールを通過するHTTPの機能が含まれます。これにより、多くのタイプのインフラストラクチャ上で動作し、アプリケーションサーバーがHTTPをサポートする必要がある場合に役立ちます。
Depending on application need, the use of HTTP as a substrate protocol may add complexity and overhead in comparison to a special-purpose protocol (e.g., HTTP headers, suitability of the HTTP security model, etc.). [RFC3205] addresses this issue, provides some guidelines, and identifies concerns about the use of HTTP standard ports 80 and 443, the use of the HTTP URL scheme, and interaction with existing firewalls, proxies, and NATs.
アプリケーションのニーズに応じて、サブストレートプロトコルとしてHTTPを使用すると、専用プロトコル（HTTPヘッダー、HTTPセキュリティモデルの適合性など）と比較して、複雑さとオーバーヘッドが追加される可能性があります。 [RFC3205]はこの問題に対処し、いくつかのガイドラインを提供し、HTTP標準ポート80と443の使用、HTTP URLスキームの使用、および既存のファイアウォール、プロキシ、NATとの相互作用に関する懸念を特定します。
Representational State Transfer (REST) [REST] is another example of how applications can use HTTP as a transport protocol. REST is an architecture style that may be used to build applications using HTTP as a communication protocol.
表現状態転送（REST）[REST]は、アプリケーションが転送プロトコルとしてHTTPを使用する方法のもう1つの例です。 RESTは、通信プロトコルとしてHTTPを使用してアプリケーションを構築するために使用できるアーキテクチャスタイルです。
The Hypertext Transfer Protocol (HTTP) is a request/response protocol. A client sends a request containing a request method, URI, and protocol version followed by message whose design is inspired by MIME (see [RFC7231] for the differences between an HTTP object and a MIME message), containing information about the client and request modifiers. The message can also contain a message body carrying application data. The server responds with a status or error code followed by a message containing information about the server and information about the data. This may include a message body. It is possible to specify a data format for the message body using MIME media types [RFC2045]. The protocol has additional features; some relevant to pseudotransport are described below.
ハイパーテキスト転送プロトコル（HTTP）は、要求/応答プロトコルです。クライアントは、リクエストメソッド、URI、プロトコルバージョン、それに続いてMIMEにインスパイアされたメッセージ（HTTPオブジェクトとMIMEメッセージの違いについては[RFC7231]を参照）を含むリクエストを送信し、クライアントとリクエスト修飾子に関する情報を含みます。メッセージには、アプリケーションデータを運ぶメッセージ本文を含めることもできます。サーバーは、ステータスコードまたはエラーコードに続いて、サーバーに関する情報とデータに関する情報を含むメッセージで応答します。これにはメッセージ本文が含まれる場合があります。 MIMEメディアタイプ[RFC2045]を使用して、メッセージ本文のデータ形式を指定できます。プロトコルには追加の機能があります。疑似トランスポートに関連するいくつかを以下に説明します。
Content negotiation, specified in [RFC7231], is a mechanism provided by HTTP to allow selection of a representation for a requested resource. The client and server negotiate acceptable data formats, character sets, and data encoding (e.g., data can be transferred compressed using gzip). HTTP can accommodate exchange of messages as well as data streaming (using chunked transfer encoding [RFC7230]). It is also possible to request a part of a resource using an object range request [RFC7233]. The protocol provides powerful cache control signaling defined in [RFC7234].
[RFC7231]で指定されているコンテンツネゴシエーションは、要求されたリソースの表現を選択できるようにするHTTPによって提供されるメカニズムです。クライアントとサーバーは、受け入れ可能なデータ形式、文字セット、およびデータエンコーディングをネゴシエートします（たとえば、データはgzipを使用して圧縮して転送できます）。 HTTPは、メッセージの交換とデータストリーミングに対応できます（チャンク転送エンコーディング[RFC7230]を使用）。オブジェクト範囲リクエスト[RFC7233]を使用してリソースの一部をリクエストすることも可能です。このプロトコルは、[RFC7234]で定義されている強力なキャッシュ制御シグナリングを提供します。
The persistent connections of HTTP 1.1 and HTTP 2.0 allow multiple request/response transactions (streams) during the lifetime of a single HTTP connection. This reduces overhead during connection establishment and mitigates transport-layer slow-start that would have otherwise been incurred for each transaction. HTTP 2.0 connections can multiplex many request/response pairs in parallel on a single transport connection. Both are important to reduce latency for HTTP's primary use case.
HTTP 1.1とHTTP 2.0の永続的な接続により、単一のHTTP接続の存続期間中に複数の要求/応答トランザクション（ストリーム）が可能になります。これにより、接続確立時のオーバーヘッドが削減され、トランザクションごとに発生するトランスポート層のスロースタートが軽減されます。 HTTP 2.0接続は、単一のトランスポート接続で多数の要求/応答ペアを並列に多重化できます。どちらも、HTTPの主な使用例のレイテンシを減らすために重要です。
HTTP can be combined with security mechanisms, such as TLS (denoted by HTTPS). This adds protocol properties provided by such a mechanism (e.g., authentication and encryption). The TLS Application-Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used to negotiate the HTTP version within the TLS handshake, eliminating the latency incurred by additional round-trip exchanges. Arbitrary cookie strings, included as part of the request headers, are often used as bearer tokens in HTTP.
HTTPは、TLS（HTTPSで示される）などのセキュリティメカニズムと組み合わせることができます。これにより、そのようなメカニズム（認証や暗号化など）によって提供されるプロトコルプロパティが追加されます。 TLSアプリケーションレイヤープロトコルネゴシエーション（ALPN）拡張[RFC7301]を使用して、TLSハンドシェイク内でHTTPバージョンをネゴシエートし、追加の往復交換によって発生する待ち時間を排除できます。リクエストヘッダーの一部として含まれる任意のCookie文字列は、HTTPでベアラートークンとしてよく使用されます。
There are many HTTP libraries available exposing different APIs. The APIs provide a way to specify a request by providing a URI, a method, request modifiers, and, optionally, a request body. For the response, callbacks can be registered that will be invoked when the response is received. If HTTPS is used, the API exposes a registration of callbacks when a server requests client authentication and when certificate verification is needed.
さまざまなAPIを公開する多くのHTTPライブラリが利用可能です。 APIは、URI、メソッド、リクエスト修飾子、およびオプションでリクエスト本文を提供することにより、リクエストを指定する方法を提供します。応答については、応答の受信時に呼び出されるコールバックを登録できます。 HTTPSが使用されている場合、サーバーがクライアント認証を要求したとき、および証明書の検証が必要なときに、APIはコールバックの登録を公開します。
The World Wide Web Consortium (W3C) has standardized the XMLHttpRequest API [XHR]. This API can be used for sending HTTP/ HTTPS requests and receiving server responses. Besides the XML data format, the request and response data format can also be JSON, HTML, and plain text. JavaScript and XMLHttpRequest are ubiquitous programming models for websites and more general applications where native code is less attractive.
World Wide Web Consortium（W3C）は、XMLHttpRequest API [XHR]を標準化しました。このAPIは、HTTP / HTTPS要求の送信とサーバー応答の受信に使用できます。 XMLデータ形式のほかに、要求と応答のデータ形式は、JSON、HTML、プレーンテキストにすることもできます。 JavaScriptとXMLHttpRequestは、ネイティブコードがあまり魅力的でないWebサイトやより一般的なアプリケーション向けのユビキタスプログラミングモデルです。
The transport features provided by HTTP, when used as a pseudotransport, are:
疑似トランスポートとして使用される場合、HTTPによって提供されるトランスポート機能は次のとおりです。
o unicast transport (provided by the lower-layer protocol, usually TCP),
o ユニキャストトランスポート（下位層プロトコル、通常はTCPによって提供される）、
o unidirectional or bidirectional communication,
o 単方向または双方向通信、
o transfer of objects in multiple streams with object content type negotiation, supporting partial transmission of object ranges,
o オブジェクト範囲の部分的な送信をサポートするオブジェクトコンテンツタイプネゴシエーションを使用した複数のストリームでのオブジェクトの転送、
o ordered delivery (provided by the lower-layer protocol, usually TCP),
o 順序付けられた配信（下位層プロトコル、通常はTCPによって提供される）、
o fully reliable delivery (provided by the lower-layer protocol, usually TCP),
o 完全に信頼できる配信（下位層プロトコル、通常はTCPによって提供される）、
o flow control (provided by the lower-layer protocol, usually TCP), and
o フロー制御（下位層プロトコル、通常はTCPによって提供される）、および
o congestion control (provided by the lower-layer protocol, usually TCP).
o 輻輳制御（下位層プロトコル、通常はTCPによって提供される）。
HTTPS (HTTP over TLS) additionally provides the following features (as provided by TLS):
HTTPS（HTTP over TLS）は、さらに次の機能を提供します（TLSによって提供されます）。
o authentication (of one or both ends of a connection),
o 認証（接続の一端または両端）
o confidentiality, and
o 機密性、および
o integrity protection.
o 整合性保護。
3.10. File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast
3.10. 信頼性の高いマルチキャストのための単方向トランスポート/非同期レイヤードコーディング（FLUTE / ALC）によるファイル配信
FLUTE/ALC is an IETF Standards Track protocol specified in [RFC6726] and [RFC5775]. It provides object-oriented delivery of discrete data or files. Asynchronous Layer Coding (ALC) provides an underlying reliable transport service and FLUTE a file-oriented specialization of the ALC service (e.g., to carry associated metadata). [RFC6726] and [RFC5775] are non-backward-compatible updates of [RFC3926] and [RFC3450], which are Experimental protocols; these Experimental protocols are currently largely deployed in the 3GPP Multimedia Broadcast / Multicast Service (MBMS) (see [MBMS], Section 7) and similar contexts (e.g., the Japanese ISDB-Tmm standard).
FLUTE / ALCは、[RFC6726]および[RFC5775]で指定されているIETF標準トラックプロトコルです。個別のデータまたはファイルをオブジェクト指向で配信します。非同期レイヤーコーディング（ALC）は、基礎となる信頼性の高いトランスポートサービスを提供し、ALTサービスのファイル指向の特殊化をFLUTEで提供します（たとえば、関連するメタデータを運ぶため）。 [RFC6726]と[RFC5775]は、実験プロトコルである[RFC3926]と[RFC3450]の下位互換性のないアップデートです。これらの実験的プロトコルは現在、主に3GPPマルチメディアブロードキャスト/マルチキャストサービス（MBMS）（[MBMS]、セクション7を参照）および同様のコンテキスト（たとえば、日本のISDB-Tmm標準）で展開されています。
The FLUTE/ALC protocol has been designed to support massively scalable reliable bulk data dissemination to receiver groups of arbitrary size using IP Multicast over any type of delivery network, including unidirectional networks (e.g., broadcast wireless channels). However, the FLUTE/ALC protocol also supports point-to-point unicast transmissions.
FLUTE / ALCプロトコルは、単方向ネットワーク（ブロードキャストワイヤレスチャネルなど）を含むあらゆるタイプの配信ネットワーク上でIPマルチキャストを使用して、任意のサイズの受信者グループへの大規模にスケーラブルな信頼性のあるバルクデータ配信をサポートするように設計されています。ただし、FLUTE / ALCプロトコルはポイントツーポイントのユニキャスト送信もサポートしています。
FLUTE/ALC bulk data dissemination has been designed for discrete file or memory-based "objects". Although FLUTE/ALC is not well adapted to byte and message streaming, there is an exception: FLUTE/ALC is used to carry 3GPP Dynamic Adaptive Streaming over HTTP (DASH) when scalability is a requirement (see [MBMS], Section 5.6).
FLUTE / ALCバルクデータ配布は、ディスクリートファイルまたはメモリベースの「オブジェクト」用に設計されています。 FLUTE / ALCはバイトおよびメッセージストリーミングにうまく適合していませんが、例外があります。FLUTE/ ALCは、スケーラビリティが必要な場合に3GPP Dynamic Adaptive Streaming over HTTP（DASH）を伝送するために使用されます（[MBMS]、セクション5.6を参照）。
FLUTE/ALC's reliability, delivery mode, congestion control, and flow/ rate control mechanisms can be separately controlled to meet different application needs. Section 4.1 of [RFC8085] describes multicast congestion control requirements for UDP.
FLUTE / ALCの信頼性、配信モード、輻輳制御、フロー/レート制御メカニズムは、さまざまなアプリケーションのニーズに合わせて個別に制御できます。 [RFC8085]のセクション4.1は、UDPのマルチキャスト輻輳制御要件について説明しています。
The FLUTE/ALC protocol works on top of UDP (though it could work on top of any datagram delivery transport protocol), without requiring any connectivity from receivers to the sender. Purely unidirectional networks are therefore supported by FLUTE/ALC. This guarantees scalability to an unlimited number of receivers in a session, since the sender behaves exactly the same regardless of the number of receivers.
FLUTE / ALCプロトコルはUDPの上で動作します（ただし、データグラム配信トランスポートプロトコルの上で動作する可能性があります）。受信側から送信側への接続は必要ありません。したがって、純粋な単方向ネットワークはFLUTE / ALCによってサポートされます。送信者は受信者の数に関係なくまったく同じように動作するため、これにより、セッション内の無制限の数の受信者に対するスケーラビリティが保証されます。
FLUTE/ALC supports the transfer of bulk objects such as file or in-memory content, using either a push or an on-demand mode. In push mode, content is sent once to the receivers, while in on-demand mode, content is sent continuously during periods of time that can greatly exceed the average time required to download the session objects (see [RFC5651], Section 4.2).
FLUTE / ALCは、プッシュモードまたはオンデマンドモードを使用して、ファイルやメモリ内コンテンツなどのバルクオブジェクトの転送をサポートします。プッシュモードでは、コンテンツは1回レシーバーに送信されますが、オンデマンドモードでは、コンテンツは、セッションオブジェクトをダウンロードするのに必要な平均時間を大幅に超える可能性がある期間、継続的に送信されます（[RFC5651]、セクション4.2を参照）。
This enables receivers to join a session asynchronously, at their own discretion, receive the content, and leave the session. In this case, data content is typically sent continuously, in loops (also known as "carousels"). FLUTE/ALC also supports the transfer of an object stream, with loose real-time constraints. This is particularly useful to carry 3GPP DASH when scalability is a requirement and unicast transmissions over HTTP cannot be used ([MBMS], Section 5.6). In this case, packets are sent in sequence using push mode. FLUTE/ALC is not well adapted to byte and message streaming, and other solutions could be preferred (e.g., FECFRAME [RFC6363] with real-time flows).
これにより、受信者は独自の裁量で非同期にセッションに参加し、コンテンツを受信し、セッションを離れることができます。この場合、データコンテンツは通常、ループ（「カルーセル」とも呼ばれます）で連続的に送信されます。 FLUTE / ALCは、緩やかなリアルタイム制約のあるオブジェクトストリームの転送もサポートします。これは、スケーラビリティが要件であり、HTTPを介したユニキャスト送信を使用できない場合（[MBMS]、セクション5.6）に、3GPP DASHを実行するのに特に役立ちます。この場合、パケットはプッシュモードを使用して順番に送信されます。 FLUTE / ALCはバイトおよびメッセージのストリーミングに十分に適合していないため、他のソリューションが推奨される場合があります（例：リアルタイムフローのFECFRAME [RFC6363]）。
The FLUTE file delivery instantiation of ALC provides a metadata delivery service. Each object of the FLUTE/ALC session is described in a dedicated entry of a File Delivery Table (FDT), using an XML format (see [RFC6726], Section 3.2). This metadata can include, but is not restricted to, a URI attribute (to identify and locate the object), a media type attribute, a size attribute, an encoding attribute, or a message digest attribute. Since the set of objects sent within a session can be dynamic, with new objects being added and old ones removed, several instances of the FDT can be sent, and a mechanism is provided to identify a new FDT instance.
ALCのFLUTEファイル配信インスタンス化は、メタデータ配信サービスを提供します。 FLUTE / ALCセッションの各オブジェクトは、XML形式を使用して、ファイル配信テーブル（FDT）の専用エントリに記述されます（[RFC6726]、セクション3.2を参照）。このメタデータには、URIオブジェクト（オブジェクトを識別して特定するため）、メディアタイプ属性、サイズ属性、エンコーディング属性、またはメッセージダイジェスト属性を含めることができますが、これらに限定されません。セッション内で送信されるオブジェクトのセットは動的であり、新しいオブジェクトが追加され、古いオブジェクトが削除されるため、FDTのいくつかのインスタンスを送信でき、新しいFDTインスタンスを識別するメカニズムが提供されます。
Error detection and verification of the protocol control information relies on the underlying transport (e.g., UDP checksum).
プロトコル制御情報のエラー検出と検証は、基になるトランスポート（UDPチェックサムなど）に依存しています。
To provide robustness against packet loss and improve the efficiency of the on-demand mode, FLUTE/ALC relies on packet erasure coding (Application-Layer Forward Error Correction (AL-FEC)). AL-FEC encoding is proactive (since there is no feedback and therefore no (N)ACK-based retransmission), and ALC packets containing repair data are sent along with ALC packets containing source data. Several FEC Schemes have been standardized; FLUTE/ALC does not mandate the use of any particular one. Several strategies concerning the transmission order of ALC source and repair packets are possible, in particular, in on-demand mode where it can deeply impact the service provided (e.g., to favor the recovery of objects in sequence or, at the other extreme, to favor the recovery of all objects in parallel), and FLUTE/ALC does not mandate nor recommend the use of any particular one.
パケット損失に対する堅牢性を提供し、オンデマンドモードの効率を向上させるために、FLUTE / ALCはパケット消去コーディング（アプリケーションレイヤー転送エラー訂正（AL-FEC））に依存しています。 AL-FECエンコードはプロアクティブであり（フィードバックがないため（N）ACKベースの再送信がないため）、修復データを含むALCパケットがソースデータを含むALCパケットと共に送信されます。いくつかのFECスキームが標準化されました。 FLUTE / ALCは特定の使用を義務付けていません。特にオンデマンドモードでは、ALCソースの送信順序と修復パケットに関するいくつかの戦略が可能です。オンデマンドモードでは、提供されるサービスに深く影響する可能性があります（たとえば、オブジェクトを順番に、または極端に回復すると、すべてのオブジェクトを並行してリカバリすることを推奨します）。FLUTE/ ALCは特定のオブジェクトの使用を義務付けたり推奨したりしません。
A FLUTE/ALC session is composed of one or more channels, associated to different destination unicast and/or multicast IP addresses. ALC packets are sent in those channels at a certain transmission rate, with a rate that often differs depending on the channel. FLUTE/ALC does not mandate nor recommend any strategy to select which ALC packet to send on which channel. FLUTE/ALC can use a multiple rate congestion control building block (e.g., Wave and Equation Based Rate Control (WEBRC)) to provide congestion control that is feedback free, where receivers adjust their reception rates individually by joining and leaving channels associated with the session. To that purpose, the ALC header provides a specific field to carry congestion-control-specific information. However, FLUTE/ALC does not mandate the use of a particular congestion control mechanism although WEBRC is mandatory to support for the Internet ([RFC6726], Section 1.1.4). FLUTE/ALC is often used over a network path with pre-provisioned capacity [RFC8085] where there are no flows competing for capacity. In this case, a sender-based rate control mechanism and a single channel are sufficient.
FLUTE / ALCセッションは、1つ以上のチャネルで構成され、さまざまな宛先ユニキャストまたはマルチキャストIPアドレス、あるいはその両方に関連付けられています。 ALCパケットは、特定の伝送レートでこれらのチャネルに送信されます。レートは、チャネルによって異なる場合があります。 FLUTE / ALCは、どのALCパケットをどのチャネルに送信するかを選択する戦略を義務付けたり推奨したりしていません。 FLUTE / ALCは、マルチレートの輻輳制御ビルディングブロック（例：WaveおよびEquation Based Rate Control（WEBRC））を使用して、フィードバックのない輻輳制御を提供できます。この場合、受信機は、セッションに関連付けられたチャネルに参加したりチャネルから離れたりすることにより、受信レートを個別に調整します。 。そのために、ALCヘッダーは、輻輳制御固有の情報を伝達するための特定のフィールドを提供します。ただし、インターネットのサポートにはWEBRCが必須ですが（[RFC6726]、セクション1.1.4）、FLUTE / ALCは特定の輻輳制御メカニズムの使用を義務付けていません。 FLUTE / ALCは、事前にプロビジョニングされた容量[RFC8085]を備えたネットワークパス上で使用されることが多く、容量について競合するフローはありません。この場合、送信者ベースのレート制御メカニズムと単一のチャネルで十分です。
[RFC6584] provides per-packet authentication, integrity, and anti-replay protection in the context of the ALC and NORM protocols. Several mechanisms are proposed that seamlessly integrate into these protocols using the ALC and NORM header extension mechanisms.
[RFC6584]は、ALCおよびNORMプロトコルのコンテキストで、パケットごとの認証、整合性、およびアンチリプレイ保護を提供します。 ALCおよびNORMヘッダー拡張メカニズムを使用してこれらのプロトコルにシームレスに統合するいくつかのメカニズムが提案されています。
The FLUTE/ALC specification does not describe a specific API to control protocol operation. Although open source and commercial implementations have specified APIs, there is no IETF-specified API for FLUTE/ALC.
FLUTE / ALC仕様は、プロトコル操作を制御する特定のAPIを記述していません。オープンソースおよび商用の実装にはAPIが指定されていますが、FLUTE / ALCに対応するIETF指定のAPIはありません。
The transport features provided by FLUTE/ALC are:
FLUTE / ALCが提供するトランスポート機能は次のとおりです。
o unicast, multicast, anycast, or IPv4 broadcast transmission,
o ユニキャスト、マルチキャスト、エニーキャスト、またはIPv4ブロードキャスト送信、
o object-oriented delivery of discrete data or files and associated metadata,
o 個別のデータまたはファイルおよび関連するメタデータのオブジェクト指向の配信
o fully reliable or partially reliable delivery (of file or in-memory objects), using proactive packet erasure coding (AL-FEC) to recover from packet erasures,
o 完全に信頼できる、または部分的に信頼できる配信（ファイルまたはメモリ内オブジェクトの）、パケット消去からの回復に予防的パケット消去コーディング（AL-FEC）を使用
o ordered or unordered delivery (of file or in-memory objects),
o 順序付きまたは順序なしの配信（ファイルまたはメモリ内オブジェクトの）、
o error detection (based on the UDP checksum),
o エラー検出（UDPチェックサムに基づく）、
o per-packet authentication,
o パケットごとの認証、
o per-packet integrity,
o パケットごとの整合性、
o per-packet replay protection, and
o パケットごとのリプレイ保護、および
o congestion control for layered flows (e.g., with WEBRC).
o レイヤードフローの輻輳制御（例：WEBRCを使用）。
NORM is an IETF Standards Track protocol specified in [RFC5740]. It provides object-oriented delivery of discrete data or files.
NORMは、[RFC5740]で指定されたIETF標準トラックプロトコルです。個別のデータまたはファイルをオブジェクト指向で配信します。
The protocol was designed to support reliable bulk data dissemination to receiver groups using IP Multicast but also provides for point-to-point unicast operation. Support for bulk data dissemination includes discrete file or computer memory-based "objects" as well as byte and message streaming.
このプロトコルは、IPマルチキャストを使用してレシーバグループへの信頼性の高いバルクデータ配信をサポートするように設計されていますが、ポイントツーポイントのユニキャスト操作も提供します。バルクデータ配布のサポートには、ディスクリートファイルまたはコンピューターのメモリベースの「オブジェクト」のほか、バイトおよびメッセージのストリーミングが含まれます。
NORM can incorporate packet erasure coding as a part of its selective Automatic Repeat reQuest (ARQ) in response to negative acknowledgments from the receiver. The packet erasure coding can also be proactively applied for forward protection from packet loss. NORM transmissions are governed by TCP-Friendly Multicast Congestion Control (TFMCC) [RFC4654]. The reliability, congestion control, and flow control mechanisms can be separately controlled to meet different application needs.
NORMは、受信側からの否定応答に応答して、選択的自動繰り返し要求（ARQ）の一部としてパケット消去コーディングを組み込むことができます。パケット消去コーディングは、パケット損失からの前方保護にも積極的に適用できます。 NORM送信は、TCP-Friendly Multicast Congestion Control（TFMCC）[RFC4654]によって管理されています。信頼性、輻輳制御、およびフロー制御メカニズムを個別に制御して、さまざまなアプリケーションのニーズを満たすことができます。
The NORM protocol is encapsulated in UDP datagrams and thus provides multiplexing for multiple sockets on hosts using port numbers. For loosely coordinated IP Multicast, NORM is not strictly connection-oriented although per-sender state is maintained by receivers for protocol operation. [RFC5740] does not specify a handshake protocol for connection establishment. Separate session initiation can be used to coordinate port numbers. However, in-band "client-server" style connection establishment can be accomplished with the NORM congestion control signaling messages using port binding techniques like those for TCP client-server connections.
NORMプロトコルはUDPデータグラムにカプセル化されているため、ポート番号を使用してホスト上の複数のソケットに多重化を提供します。緩やかに調整されたIPマルチキャストの場合、NORMは厳密には接続指向ではありませんが、送信者ごとの状態はプロトコル操作のために受信者によって維持されます。 [RFC5740]は、接続確立のためのハンドシェイクプロトコルを指定していません。個別のセッション開始を使用して、ポート番号を調整できます。ただし、インバンド「クライアントサーバー」スタイルの接続確立は、TCPクライアントサーバー接続の場合と同様のポートバインディング手法を使用して、NORM輻輳制御シグナリングメッセージで実現できます。
NORM supports bulk "objects" such as file or in-memory content but also can treat a stream of data as a logical bulk object for purposes of packet erasure coding. In the case of stream transport, NORM can support either byte streams or message streams where application-defined message boundary information is carried in the NORM protocol messages. This allows the receiver(s) to join/rejoin and recover message boundaries mid-stream as needed. Application content is carried and identified by the NORM protocol with encoding symbol identifiers depending upon the Forward Error Correction (FEC) Scheme [RFC5052] configured. NORM uses NACK-based selective ARQ to reliably deliver the application content to the receiver(s). NORM proactively measures round-trip timing information to scale ARQ timers appropriately and to support congestion control. For multicast operation, timer-based feedback suppression is used to achieve group size scaling with low feedback traffic levels. The feedback suppression is not applied for unicast operation.
NORMは、ファイルやメモリ内コンテンツなどのバルク「オブジェクト」をサポートしますが、データのストリームをパケット消去コーディングの目的で論理的なバルクオブジェクトとして扱うこともできます。ストリーム転送の場合、NORMは、アプリケーション定義のメッセージ境界情報がNORMプロトコルメッセージで伝送されるバイトストリームまたはメッセージストリームをサポートできます。これにより、必要に応じて、レシーバーがストリームの途中でメッセージ境界を結合/再結合および回復できます。アプリケーションのコンテンツは、構成された転送エラー訂正（FEC）スキーム[RFC5052]に応じて、エンコードシンボル識別子を使用してNORMプロトコルによって伝送および識別されます。 NORMはNACKベースの選択的ARQを使用して、アプリケーションコンテンツを受信者に確実に配信します。 NORMは、往復のタイミング情報を積極的に測定して、ARQタイマーを適切にスケーリングし、輻輳制御をサポートします。マルチキャスト動作の場合、タイマーベースのフィードバック抑制を使用して、フィードバックトラフィックレベルを低くしてグループサイズのスケーリングを実現します。フィードバック抑制は、ユニキャスト操作には適用されません。
NORM uses rate-based congestion control based upon the TCP-Friendly Rate Control (TFRC) [RFC5348] principles that are also used in DCCP [RFC4340]. NORM uses control messages to measure RTT and collect congestion event information (e.g., reflecting a loss event or ECN event) from the receiver(s) to support dynamic adjustment or the rate. TCP-Friendly Multicast Congestion Control (TFMCC) [RFC4654] provides extra features to support multicast but is functionally equivalent to TFRC for unicast.
NORMは、DCCP [RFC4340]でも使用されているTCPフレンドリーレートコントロール（TFRC）[RFC5348]の原則に基づくレートベースの輻輳制御を使用します。 NORMは、制御メッセージを使用してRTTを測定し、動的な調整またはレートをサポートするために、レシーバーから輻輳イベント情報（損失イベントやECNイベントを反映するなど）を収集します。 TCP-Friendly Multicast Congestion Control（TFMCC）[RFC4654]は、マルチキャストをサポートする追加機能を提供しますが、機能的にはユニキャストのTFRCと同等です。
Error detection and verification of the protocol control information relies on the on the underlying transport (e.g., UDP checksum).
プロトコル制御情報のエラー検出と検証は、基になるトランスポート（UDPチェックサムなど）に依存しています。
The reliability mechanism is decoupled from congestion control. This allows invocation of alternative arrangements of transport services, for example, to support, fixed-rate reliable delivery or unreliable delivery (that may optionally be "better than best effort" via packet erasure coding) using TFRC. Alternative congestion control techniques may be applied, for example, TFRC with congestion event detection based on ECN.
信頼性メカニズムは、輻輳制御から切り離されています。これにより、たとえば、TFRCを使用して、固定レートの信頼できる配信または信頼できない配信（オプションでパケット消去コーディングによる「ベストエフォート」よりも優れている）をサポートするために、トランスポートサービスの代替配置を呼び出すことができます。代替の輻輳制御技術、たとえば、ECNに基づく輻輳イベント検出を備えたTFRCを適用できます。
While NORM provides NACK-based reliability, it also supports a positive acknowledgment (ACK) mechanism that can be used for receiver flow control. This mechanism is decoupled from the reliability and congestion control, supporting applications with different needs. One example is use of NORM for quasi-reliable delivery, where timely delivery of newer content may be favored over completely reliable delivery of older content within buffering and RTT constraints.
NORMはNACKベースの信頼性を提供しますが、受信側フロー制御に使用できる肯定応答（ACK）メカニズムもサポートします。このメカニズムは、信頼性と輻輳制御から切り離されており、さまざまなニーズを持つアプリケーションをサポートします。 1つの例は、準信頼性の高い配信のためのNORMの使用です。バッファリングとRTTの制約内で、古いコンテンツの完全に信頼できる配信よりも新しいコンテンツのタイムリーな配信が優先される場合があります。
The NORM specification does not describe a specific API to control protocol operation. A freely available, open-source reference implementation of NORM is available at <https://www.nrl.navy.mil/itd/ncs/products/norm>, and a documented API is provided for this implementation. While a sockets-like API is not currently documented, the existing API supports the necessary functions for that to be implemented.
NORM仕様では、プロトコルの動作を制御する特定のAPIについては説明していません。 NORMの無料で利用できるオープンソースのリファレンス実装は、<https://www.nrl.navy.mil/itd/ncs/products/norm>で入手でき、この実装用にドキュメント化されたAPIが提供されています。ソケットのようなAPIは現在ドキュメント化されていませんが、既存のAPIは、実装に必要な関数をサポートしています。
The transport features provided by NORM are:
NORMが提供するトランスポート機能は次のとおりです。
o unicast or multicast transport,
o ユニキャストまたはマルチキャスト転送、
o unidirectional communication,
o 単方向通信、
o stream-oriented delivery in a single stream or object-oriented delivery of in-memory data or file bulk content objects,
o 単一ストリームでのストリーム指向配信、またはインメモリデータまたはファイルバルクコンテンツオブジェクトのオブジェクト指向配信
o fully reliable (NACK-based) or partially reliable (using erasure coding both proactively and as part of ARQ) delivery,
o 完全に信頼できる（NACKベース）または部分的に信頼できる（予防的およびARQの一部としてイレイジャーコーディングを使用）配信、
o unordered delivery,
o 順不同配送、
o error detection (relies on UDP checksum),
o エラー検出（UDPチェックサムに依存）、
o segmentation,
o セグメンテーション、
o data bundling (using Nagle's algorithm),
o データバンドル（Nagleのアルゴリズムを使用）、
o flow control (timer-based and/or ACK-based), and
o フロー制御（タイマーベースおよび/またはACKベース）、および
o congestion control (also supporting fixed-rate reliable or unreliable delivery).
o 輻輳制御（固定レートの信頼できるまたは信頼できない配信もサポートします）。
The Internet Control Message Protocol (ICMP) [RFC792] for IPv4 and ICMP for IPv6 [RFC4443] are IETF Standards Track protocols. It is a connectionless unidirectional protocol that delivers individual messages, without error correction, congestion control, or flow control. Messages may be sent as unicast, IPv4 broadcast, or multicast datagrams (IPv4 and IPv6), in addition to anycast datagrams.
IPv4のインターネット制御メッセージプロトコル（ICMP）[RFC792]およびIPv6のICMP [RFC4443]は、IETF標準トラックプロトコルです。これは、エラー訂正、輻輳制御、またはフロー制御なしで個々のメッセージを配信するコネクションレス型の単方向プロトコルです。メッセージは、エニーキャストデータグラムに加えて、ユニキャスト、IPv4ブロードキャスト、またはマルチキャストデータグラム（IPv4およびIPv6）として送信できます。
While ICMP is not typically described as a transport protocol, it does position itself over the network layer, and the operation of other transport protocols can be closely linked to the functions provided by ICMP.
ICMPは通常、トランスポートプロトコルとして説明されていませんが、ネットワーク層の上に配置され、他のトランスポートプロトコルの動作は、ICMPによって提供される機能に密接にリンクできます。
Transport protocols and upper-layer protocols can use received ICMP messages to help them make appropriate decisions when network or endpoint errors are reported, for example, to implement ICMP-based Path MTU Discovery (PMTUD) [RFC1191] [RFC1981] or assist in Packetization Layer PMTUD (PLPMTUD) [RFC4821]. Such reactions to received messages need to protect from off-path data injection
トランスポートプロトコルと上位層プロトコルは、受信したICMPメッセージを使用して、ネットワークまたはエンドポイントのエラーが報告されたときに適切な決定を下すのに役立ちます。レイヤーPMTUD（PLPMTUD）[RFC4821]。受信したメッセージに対するそのような反応は、オフパスデータインジェクションから保護する必要があります
[RFC8085] to avoid an application receiving packets created by an unauthorized third party. An application therefore needs to ensure that all messages are appropriately validated by checking the payload of the messages to ensure they are received in response to actually transmitted traffic (e.g., a reported error condition that corresponds to a UDP datagram or TCP segment was actually sent by the application). This requires context [RFC6056], such as local state about communication instances to each destination (e.g., in TCP, DCCP, or SCTP). This state is not always maintained by UDP-based applications [RFC8085].
[RFC8085]許可されていない第三者によって作成されたパケットをアプリケーションが受信することを回避します。したがって、アプリケーションは、メッセージのペイロードをチェックしてすべてのメッセージが適切に検証され、実際に送信されたトラフィックに応答して受信されることを確認する必要があります（たとえば、UDPデータグラムまたはTCPセグメントに対応するエラー状態が実際に送信されたアプリケーション）。これには、各宛先への通信インスタンスに関するローカル状態（TCP、DCCP、SCTPなど）などのコンテキスト[RFC6056]が必要です。この状態は、UDPベースのアプリケーション[RFC8085]によって常に維持されるわけではありません。
ICMP is a connectionless unidirectional protocol. It delivers independent messages, called "datagrams". Each message is required to carry a checksum as an integrity check and to protect from misdelivery to an unintended endpoint.
ICMPはコネクションレス型の単方向プロトコルです。 「データグラム」と呼ばれる独立したメッセージを配信します。各メッセージは、整合性チェックとしてチェックサムを伝送し、意図しないエンドポイントへの誤配信から保護するために必要です。
ICMP messages typically relay diagnostic information from an endpoint [RFC1122] or network device [RFC1812] addressed to the sender of a flow. This usually contains the network protocol header of a packet that encountered a reported issue. Some formats of messages can also carry other payload data. Each message carries an integrity check calculated in the same way as for UDP; this checksum is not optional.
ICMPメッセージは通常、フローの送信者にアドレス指定されたエンドポイント[RFC1122]またはネットワークデバイス[RFC1812]からの診断情報を中継します。これには通常、報告された問題が発生したパケットのネットワークプロトコルヘッダーが含まれています。一部の形式のメッセージは、他のペイロードデータも伝送できます。各メッセージには、UDPと同じ方法で計算された整合性チェックが含まれます。このチェックサムはオプションではありません。
The RFC Series defines additional IPv6 message formats to support a range of uses. In the case of IPv6, the protocol incorporates neighbor discovery [RFC4861] [RFC3971] (provided by ARP for IPv4) and Multicast Listener Discovery (MLD) [RFC2710] group management functions (provided by IGMP for IPv4).
RFCシリーズでは、さまざまな用途をサポートするために、追加のIPv6メッセージ形式が定義されています。 IPv6の場合、プロトコルにはネイバー探索[RFC4861] [RFC3971]（IPv4のARPによって提供）およびマルチキャストリスナー探索（MLD）[RFC2710]グループ管理機能（IPv4のIGMPによって提供）が組み込まれています。
Reliable transmission cannot be assumed. A receiving application that is unable to run sufficiently fast, or frequently, may miss messages since there is no flow or congestion control. In addition, some network devices rate-limit ICMP messages.
信頼できる伝送は想定できません。十分に速く、または頻繁に実行できない受信アプリケーションは、フローまたは輻輳制御がないため、メッセージを見逃す可能性があります。さらに、一部のネットワークデバイスはICMPメッセージをレート制限します。
ICMP processing is integrated in many connection-oriented transports but, like other functions, needs to be provided by an upper-layer protocol when using UDP and UDP-Lite.
ICMP処理は、多くの接続指向のトランスポートに統合されていますが、UDPおよびUDP-Liteを使用する場合、他の機能と同様に、上位層プロトコルによって提供される必要があります。
On some stacks, a bound socket also allows a UDP application to be notified when ICMP error messages are received for its transmissions [RFC8085].
一部のスタックでは、バインドされたソケットを使用すると、ICMPエラーメッセージが受信されたときにUDPアプリケーションに通知されます[RFC8085]。
Any response to ICMP error messages ought to be robust to temporary routing failures (sometimes called "soft errors"), e.g., transient ICMP "unreachable" messages ought to not normally cause a communication abort [RFC5461] [RFC8085].
ICMPエラーメッセージへの応答は、一時的なルーティング障害（「ソフトエラー」と呼ばれることもあります）に対して堅牢である必要があります。たとえば、一時的なICMP「到達不能」メッセージは、通常、通信の中止を引き起こすべきではありません[RFC5461] [RFC8085]。
ICMP does not provide any transport service directly to applications. Used together with other transport protocols, it provides transmission of control, error, and measurement data between endpoints or from devices along the path to one endpoint.
ICMPは、アプリケーションに直接転送サービスを提供しません。他のトランスポートプロトコルと一緒に使用して、エンドポイント間またはパスに沿ったデバイスから1つのエンドポイントへの制御、エラー、および測定データの送信を提供します。
Congestion control is critical to the stable operation of the Internet. A variety of mechanisms are used to provide the congestion control needed by many Internet transport protocols. Congestion is detected based on sensing of network conditions, whether through explicit or implicit feedback. The congestion control mechanisms that can be applied by different transport protocols are largely orthogonal to the choice of transport protocol. This section provides an overview of the congestion control mechanisms available to the protocols described in Section 3.
輻輳制御は、インターネットの安定稼働に不可欠です。多くのインターネットトランスポートプロトコルで必要な輻輳制御を提供するために、さまざまなメカニズムが使用されます。輻輳は、明示的または暗黙的なフィードバックを通じて、ネットワーク状態の検知に基づいて検出されます。さまざまなトランスポートプロトコルで適用できる輻輳制御メカニズムは、トランスポートプロトコルの選択とほぼ直交しています。このセクションでは、セクション3で説明したプロトコルで使用可能な輻輳制御メカニズムの概要を説明します。
Many protocols use a separate window to determine the maximum sending rate that is allowed by the congestion control. The used congestion control mechanism will increase the congestion window if feedback is received that indicates that the currently used network path is not congested and will reduce the window otherwise. Window-based mechanisms often increase their window slowing over multiple RTTs, while decreasing strongly when the first indication of congestion is received. One example is an Additive Increase Multiplicative Decrease (AIMD) scheme, where the window is increased by a certain number of packets/bytes for each data segment that has been successfully transmitted, while the window decreases multiplicatively on the occurrence of a congestion event. This can lead to a rather unstable, oscillating sending rate but will resolve a congestion situation quickly. Examples of window-based AIMD schemes include TCP NewReno [RFC5681], TCP Cubic [CUBIC] (the default mechanism for TCP in Linux), and CCID 2 specified for DCCP [RFC4341].
多くのプロトコルは、別のウィンドウを使用して、輻輳制御によって許可される最大送信速度を決定します。使用されている輻輳制御メカニズムは、現在使用されているネットワークパスが輻輳していないことを示すフィードバックを受信した場合に輻輳ウィンドウを拡大し、そうでない場合はウィンドウを縮小します。多くの場合、ウィンドウベースのメカニズムでは、複数のRTTでウィンドウの速度が遅くなりますが、輻輳の最初の兆候が受信されると強く減少します。 1つの例は、加算的増加乗法的減少（AIMD）スキームです。この場合、ウィンドウは、正常に送信された各データセグメントの特定のパケット/バイト数だけ増加し、ウィンドウは輻輳イベントの発生時に乗法的に減少します。これにより、不安定な送信レートが不安定になる可能性がありますが、輻輳状況はすぐに解決されます。ウィンドウベースのAIMDスキームの例には、TCP NewReno [RFC5681]、TCP Cubic [CUBIC]（LinuxのTCPのデフォルトメカニズム）、およびDCCP [RFC4341]に指定されたCCID 2が含まれます。
Some classes of applications prefer to use a transport service that allows sending at a more stable rate that is slowly varied in response to congestion. Rate-based methods offer this type of congestion control and have been defined based on the loss ratio and observed round-trip time, such as TFRC [RFC5348] and TFRC-SP
一部のクラスのアプリケーションは、輻輳に応じてゆっくりと変化するより安定した速度で送信できるトランスポートサービスの使用を好みます。レートベースの方法はこのタイプの輻輳制御を提供し、TFRC [RFC5348]やTFRC-SPなどの損失率と観測されたラウンドトリップ時間に基づいて定義されています
[RFC4828]. These methods utilize a throughput equation to determine the maximum acceptable rate. Such methods are used with DCCP CCID 3 [RFC4342], CCID 4 [RFC5622], WEBRC [RFC3738], and other applications.
[RFC4828]。これらの方法は、スループットの方程式を利用して、最大許容レートを決定します。このような方法は、DCCP CCID 3 [RFC4342]、CCID 4 [RFC5622]、WEBRC [RFC3738]、およびその他のアプリケーションで使用されます。
Another class of applications prefers a transport service that yields to other (higher-priority) traffic, such as interactive transmissions. While most traffic in the Internet uses loss-based congestion control and therefore tends to fill the network buffers (to a certain level if Active Queue Management (AQM) is used), low-priority congestion control methods often react to changes in delay as an earlier indication of congestion. This approach tends to induce less loss than a loss-based method but does generally not compete well with loss-based traffic across shared bottleneck links. Therefore, methods such as LEDBAT [RFC6817] are deployed in the Internet for scavenger traffic that aims to only utilize otherwise unused capacity.
別のクラスのアプリケーションは、インタラクティブな送信など、他の（優先度の高い）トラフィックに譲るトランスポートサービスを優先します。インターネットのほとんどのトラフィックは、損失ベースの輻輳制御を使用しているため、ネットワークバッファーがいっぱいになる傾向があります（アクティブキュー管理（AQM）が使用されている場合は、一定のレベルまで）が、優先度の低い輻輳制御方法は、遅延の変化に輻輳の以前の兆候。このアプローチは、損失ベースの方法よりも損失が少ない傾向がありますが、一般に、共有のボトルネックリンク間で損失ベースのトラフィックとうまく競合しません。したがって、LEDBAT [RFC6817]などの方法は、他の方法では未使用の容量のみを利用することを目的としたスカベンジャートラフィック用にインターネットに導入されています。
The transport protocol features described in this document can be used as a basis for defining common transport features. These are listed below with the protocols supporting them:
このドキュメントで説明するトランスポートプロトコル機能は、一般的なトランスポート機能を定義するための基礎として使用できます。以下に、それらをサポートするプロトコルを示します。
o Control Functions
o 制御機能
* Addressing
* アドレッシング
+ unicast (TCP, MPTCP, UDP, UDP-Lite, SCTP, DCCP, TLS, RTP, HTTP, ICMP)
+ ユニキャスト（TCP、MPTCP、UDP、UDP-Lite、SCTP、DCCP、TLS、RTP、HTTP、ICMP）
+ multicast (UDP, UDP-Lite, RTP, ICMP, FLUTE/ALC, NORM). Note that, as TLS and DTLS are unicast-only, there is no widely deployed mechanism for supporting the features listed under the Security bullet (below) when using multicast addressing.
+ マルチキャスト（UDP、UDP-Lite、RTP、ICMP、FLUTE / ALC、NORM）。 TLSとDTLSはユニキャストのみであるため、マルチキャストアドレス指定を使用する場合、セキュリティ箇条書き（下記）に記載されている機能をサポートするための広く展開されたメカニズムはありません。
+ IPv4 broadcast (UDP, UDP-Lite, ICMP)
+ IPv4ブロードキャスト（UDP、UDP-Lite、ICMP）
+ anycast (UDP, UDP-Lite). Connection-oriented protocols such as TCP and DCCP have also been deployed using anycast addressing, with the risk that routing changes may cause connection failure.
+ エニーキャスト（UDP、UDP-Lite）。 TCPやDCCPなどの接続指向プロトコルもエニーキャストアドレッシングを使用して展開されており、ルーティングの変更によって接続障害が発生する可能性があります。
* Association type
* 関連タイプ
+ connection-oriented (TCP, MPTCP, DCCP, SCTP, TLS, RTP, HTTP, NORM)
+ コネクション型（TCP、MPTCP、DCCP、SCTP、TLS、RTP、HTTP、NORM）
+ connectionless (UDP, UDP-Lite, FLUTE/ALC)
+ コネクションレス（UDP、UDP-Lite、FLUTE / ALC）
* Multihoming support
* マルチホーミングのサポート
+ resilience and mobility (MPTCP, SCTP)
+ 回復力とモビリティ（MPTCP、SCTP）
+ load balancing (MPTCP)
+ 負荷分散（MPTCP）
+ address family multiplexing (MPTCP, SCTP)
+ アドレスファミリの多重化（MPTCP、SCTP）
* Middlebox cooperation
* ミドルボックス連携
+ application-class signaling to middleboxes (DCCP)
+ ミドルボックスへのアプリケーションクラスのシグナリング（DCCP）
+ error condition signaling from middleboxes and routers to endpoints (ICMP)
+ ミドルボックスおよびルーターからエンドポイントへのエラー状態のシグナリング（ICMP）
* Signaling
* シグナリング
+ control information and error signaling (ICMP)
+ 制御情報とエラー信号（ICMP）
+ application performance reporting (RTP)
+ アプリケーションパフォーマンスレポート（RTP）
o Delivery
o 配達
* Reliability
* 信頼性
+ fully reliable delivery (TCP, MPTCP, SCTP, TLS, HTTP, FLUTE/ ALC, NORM)
+ 完全に信頼できる配信（TCP、MPTCP、SCTP、TLS、HTTP、FLUTE / ALC、NORM）
+ partially reliable delivery (SCTP, NORM)
+ 部分的に信頼できる配信（SCTP、NORM）
- using packet erasure coding (RTP, FLUTE/ALC, NORM)
- パケット消去コーディングの使用（RTP、FLUTE / ALC、NORM）
- with specified policy for dropped messages (SCTP)
- ドロップされたメッセージ（SCTP）の指定されたポリシー
+ unreliable delivery (SCTP, UDP, UDP-Lite, DCCP, RTP)
+ 信頼できない配信（SCTP、UDP、UDP-Lite、DCCP、RTP）
- with drop notification to sender (SCTP, DCCP, RTP)
- 送信者へのドロップ通知あり（SCTP、DCCP、RTP）
+ error detection
+ エラー検出
- checksum for error detection (TCP, MPTCP, UDP, UDP-Lite, SCTP, DCCP, TLS, DTLS, FLUTE/ALC, NORM, ICMP)
- エラー検出のチェックサム（TCP、MPTCP、UDP、UDP-Lite、SCTP、DCCP、TLS、DTLS、FLUTE / ALC、NORM、ICMP）
- partial payload checksum protection (UDP-Lite, DCCP). Some uses of RTP can exploit partial payload checksum protection feature to provide a corruption-tolerant transport service.
- 部分的なペイロードチェックサム保護（UDP-Lite、DCCP）。 RTPの一部の用途では、部分的なペイロードチェックサム保護機能を利用して、破損に耐性のあるトランスポートサービスを提供できます。
- checksum optional (UDP). Possible with IPv4 and, in certain cases, with IPv6.
- オプションのチェックサム（UDP）。 IPv4で、場合によってはIPv6で可能です。
* Ordering
* ご注文
+ ordered delivery (TCP, MPTCP, SCTP, TLS, RTP, HTTP, FLUTE)
+ 順序付き配信（TCP、MPTCP、SCTP、TLS、RTP、HTTP、FLUTE）
+ unordered delivery permitted (UDP, UDP-Lite, SCTP, DCCP, RTP, NORM)
+ 順不同配信が許可されました（UDP、UDP-Lite、SCTP、DCCP、RTP、NORM）
* Type/framing
* タイプ/フレーミング
+ stream-oriented delivery (TCP, MPTCP, SCTP, TLS, HTTP)
+ ストリーム指向の配信（TCP、MPTCP、SCTP、TLS、HTTP）
- with multiple streams per association (SCTP, HTTP2)
- 関連付けごとに複数のストリーム（SCTP、HTTP2）
+ message-oriented delivery (UDP, UDP-Lite, SCTP, DCCP, DTLS, RTP)
+ メッセージ指向配信（UDP、UDP-Lite、SCTP、DCCP、DTLS、RTP）
+ object-oriented delivery of discrete data or files and associated metadata (HTTP, FLUTE/ALC, NORM)
+ 個別のデータまたはファイルおよび関連するメタデータのオブジェクト指向の配信（HTTP、FLUTE / ALC、NORM）
- with partial delivery of object ranges (HTTP)
- オブジェクト範囲の部分配信（HTTP）
* Directionality
* 方向性
+ unidirectional (UDP, UDP-Lite, DCCP, RTP, FLUTE/ALC, NORM)
+ 単方向（UDP、UDP-Lite、DCCP、RTP、FLUTE / ALC、NORM）
+ bidirectional (TCP, MPTCP, SCTP, TLS, HTTP)
+ 双方向（TCP、MPTCP、SCTP、TLS、HTTP）
o Transmission control
o トランスミッション制御
* flow control (TCP, MPTCP, SCTP, DCCP, TLS, RTP, HTTP)
* フロー制御（TCP、MPTCP、SCTP、DCCP、TLS、RTP、HTTP）
* congestion control (TCP, MPTCP, SCTP, DCCP, RTP, FLUTE/ALC, NORM). Congestion control can also provided by the transport supporting an upper-layer transport (e.g., TLS, RTP, HTTP).
* 輻輳制御（TCP、MPTCP、SCTP、DCCP、RTP、FLUTE / ALC、NORM）。輻輳制御は、上位層のトランスポート（TLS、RTP、HTTPなど）をサポートするトランスポートによって提供することもできます。
* segmentation (TCP, MPTCP, SCTP, TLS, RTP, HTTP, FLUTE/ALC, NORM)
* セグメンテーション（TCP、MPTCP、SCTP、TLS、RTP、HTTP、FLUTE / ALC、NORM）
* data/message bundling (TCP, MPTCP, SCTP, TLS, HTTP)
* データ/メッセージのバンドル（TCP、MPTCP、SCTP、TLS、HTTP）
* stream scheduling prioritization (SCTP, HTTP2)
* ストリームスケジューリングの優先順位付け（SCTP、HTTP2）
* endpoint multiplexing (MPTCP)
* エンドポイント多重化（MPTCP）
o Security
o 安全保障
* authentication of one end of a connection (TLS, DTLS, FLUTE/ ALC)
* 接続の一端の認証（TLS、DTLS、FLUTE / ALC）
* authentication of both ends of a connection (TLS, DTLS)
* 接続の両端の認証（TLS、DTLS）
* confidentiality (TLS, DTLS)
* 機密性（TLS、DTLS）
* cryptographic integrity protection (TLS, DTLS)
* 暗号整合性保護（TLS、DTLS）
* replay protection (TLS, DTLS, FLUTE/ALC)
* リプレイ保護（TLS、DTLS、FLUTE / ALC）
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
This document surveys existing transport protocols and protocols providing transport-like services. Confidentiality, integrity, and authenticity are among the features provided by those services. This document does not specify any new features or mechanisms for providing these features. Each RFC referenced by this document discusses the security considerations of the specification it contains.
このドキュメントでは、既存のトランスポートプロトコルと、トランスポートのようなサービスを提供するプロトコルについて概説します。これらのサービスが提供する機能には、機密性、完全性、信頼性があります。このドキュメントでは、これらの機能を提供するための新しい機能やメカニズムは指定していません。このドキュメントで参照されている各RFCでは、そこに含まれている仕様のセキュリティに関する考慮事項について説明しています。
[ClarkArch] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proceedings of ACM SIGCOMM, DOI 10.1145/99517.99553, 1990.
[ClarkArch] Clark、D.およびD. Tennenhouse、「新世代プロトコルのアーキテクチャに関する考慮事項」、ACM SIGCOMMの議事録、DOI 10.1145 / 99517.99553、1990。
[CUBIC] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", Work in Progress, draft-ietf-tcpm-cubic-04, February 2017.
[CUBIC] Rhee、I.、Xu、L.、Ha、S.、Zimmermann、A.、Eggert、L。、およびR. Scheffenegger、「CUBIC for Fast Long-Distance Networks」、Work in Progress、draft-ietf -tcpm-cubic-04、2017年2月。
[MBMS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346, 2015, <http://www.3gpp.org/DynaReport/26346.htm>.
[MBMS] 3GPP、「Multimedia Broadcast / Multicast Service（MBMS）; Protocols and codecs」、3GPP TS 26.346、2015、<http://www.3gpp.org/DynaReport/26346.htm>。
[NAT-SUPP] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", Work in Progress, draft-ietf-tsvwg-natsupp-09, May 2016.
[NAT-SUPP] Stewart、R.、Tuexen、M。、およびI. Ruengeler、「Stream Control Transmission Protocol（SCTP）Network Address Translation Support」、Work in Progress、draft-ietf-tsvwg-natsupp-09、May 2016 。
[POSIX] IEEE, "Standard for Information Technology -- Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7", IEEE 1003.1, DOI 10.1109/ieeestd.2016.7582338, <http://ieeexplore.ieee.org/document/7582338/>.
[POSIX] IEEE、「Standard for Information Technology-Portable Operating System Interface（POSIX（R））Base Specifications、Issue 7」、IEEE 1003.1、DOI 10.1109 / ieeestd.2016.7582338、<http://ieeexplore.ieee.org/ document / 7582338 />。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures, Chapter 5: Representational State Transfer", Ph.D. Dissertation, University of California, Irvine, 2000.
[REST]フィールディング、R。、「アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計、第5章：表現状態転送」、Ph.D。カリフォルニア大学アーバイン校、2000年。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<http://www.rfc-editor.org/info/rfc792>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the Internet checksum", RFC 1071, DOI 10.17487/RFC1071, September 1988, <http://www.rfc-editor.org/info/rfc1071>.
[RFC1071] Braden、R.、Borman、D。、およびC. Partridge、「Computing the Internet checksum」、RFC 1071、DOI 10.17487 / RFC1071、1988年9月、<http://www.rfc-editor.org/info / rfc1071>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<http://www.rfc-editor.org/info/ rfc1122>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<http://www.rfc-editor.org/info/rfc1191>。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <http://www.rfc-editor.org/info/rfc1812>.
[RFC1812]ベイカー、F。、編、「IPバージョン4ルーターの要件」、RFC 1812、DOI 10.17487 / RFC1812、1995年6月、<http://www.rfc-editor.org/info/rfc1812>。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「Path MTU Discovery for IP version 6」、RFC 1981、DOI 10.17487 / RFC1981、1996年8月、<http：//www.rfc-editor。 org / info / rfc1981>。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <http://www.rfc-editor.org/info/rfc2018>.
[RFC2018] Mathis、M.、Madhavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的確認応答オプション」、RFC 2018、DOI 10.17487 / RFC2018、1996年10月、<http：//www.rfc- editor.org/info/rfc2018>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<http：//www.rfc- editor.org/info/rfc2045>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <http://www.rfc-editor.org/info/rfc2710>.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、DOI 10.17487 / RFC2710、1999年10月、<http：//www.rfc-editor .org / info / rfc2710>。
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, DOI 10.17487/RFC2736, December 1999, <http://www.rfc-editor.org/info/rfc2736>.
[RFC2736] Handley、M。およびC. Perkins、「RTPペイロード形式仕様の作成者のためのガイドライン」、BCP 36、RFC 2736、DOI 10.17487 / RFC2736、1999年12月、<http://www.rfc-editor.org/ info / rfc2736>。
[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, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, DOI 10.17487/RFC3205, February 2002, <http://www.rfc-editor.org/info/rfc3205>.
[RFC3205]ムーアK.、「基質としてのHTTPの使用について」、BCP 56、RFC 3205、DOI 10.17487 / RFC3205、2002年2月、<http://www.rfc-editor.org/info/rfc3205> 。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, <http://www.rfc-editor.org/info/rfc3260>.
[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、DOI 10.17487 / RFC3260、2002年4月、<http://www.rfc-editor.org/info/rfc3260>。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, DOI 10.17487/RFC3436, December 2002, <http://www.rfc-editor.org/info/rfc3436>.
[RFC3436] Jungmaier、A.、Rescorla、E。、およびM. Tuexen、「Transport Layer Security over Stream Control Transmission Protocol」、RFC 3436、DOI 10.17487 / RFC3436、2002年12月、<http：//www.rfc-editor .org / info / rfc3436>。
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, DOI 10.17487/RFC3450, December 2002, <http://www.rfc-editor.org/info/rfc3450>.
[RFC3450] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L。、およびJ. Crowcroft、「Asynchronous Layered Coding（ALC）Protocol Instantiation」、RFC 3450、DOI 10.17487 / RFC3450、2002年12月、 <http://www.rfc-editor.org/info/rfc3450>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, DOI 10.17487/RFC3738, April 2004, <http://www.rfc-editor.org/info/rfc3738>.
[RFC3738] Luby、M。およびV. Goyal、「Wave and Equation Based Rate Control（WEBRC）Building Block」、RFC 3738、DOI 10.17487 / RFC3738、2004年4月、<http://www.rfc-editor.org/ info / rfc3738>。
[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, <http://www.rfc-editor.org/info/rfc3758>.
[RFC3758]スチュワート、R。、ラマーリョ、M.、Xie、Q.、Tuexen、M。、およびP.コンラッド、「ストリーム制御伝送プロトコル（SCTP）部分信頼性拡張」、RFC 3758、DOI 10.17487 / RFC3758、5月2004、<http://www.rfc-editor.org/info/rfc3758>。
[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, <http://www.rfc-editor.org/info/rfc3828>.
[RFC3828] Larzon、LA。、Degermark、M.、Pink、S.、Jonsson、LE。、Ed。、and G. Fairhurst、Ed。、 "The Lightweight User Datagram Protocol（UDP-Lite）"、RFC 3828、 DOI 10.17487 / RFC3828、2004年7月、<http://www.rfc-editor.org/info/rfc3828>。
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, DOI 10.17487/RFC3926, October 2004, <http://www.rfc-editor.org/info/rfc3926>.
[RFC3926] Paila、T.、Luby、M.、Lehtonen、R.、Roca、V。、およびR. Walsh、「FLUTE-単一方向トランスポートを介したファイル配信」、RFC 3926、DOI 10.17487 / RFC3926、2004年10月、< http://www.rfc-editor.org/info/rfc3926>。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、DOI 10.17487 / RFC3971、March 2005、<http：/ /www.rfc-editor.org/info/rfc3971>。
[RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement for the Datagram Congestion Control Protocol (DCCP)", RFC 4336, DOI 10.17487/RFC4336, March 2006, <http://www.rfc-editor.org/info/rfc4336>.
[RFC4336] Floyd、S.、Handley、M。、およびE. Kohler、「データグラム輻輳制御プロトコル（DCCP）の問題ステートメント」、RFC 4336、DOI 10.17487 / RFC4336、2006年3月、<http：// www。 rfc-editor.org/info/rfc4336>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、DOI 10.17487 / RFC4340、2006年3月、<http：//www.rfc-editor。 org / info / rfc4340>。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, <http://www.rfc-editor.org/info/rfc4341>.
[RFC4341] Floyd、S。およびE. Kohler、「Profile for Datagram Congestion Control Protocol（DCCP）Congestion Control ID 2：TCP-like Congestion Control」、RFC 4341、DOI 10.17487 / RFC4341、2006年3月、<http：// www.rfc-editor.org/info/rfc4341>。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, <http://www.rfc-editor.org/info/rfc4342>.
[RFC4342] Floyd、S.、Kohler、E。、およびJ. Padhye、「Datagram Congestion Control Protocol（DCCP）Congestion Control ID 3：TCP-Friendly Rate Control（TFRC）のプロファイル」、RFC 4342、DOI 10.17487 / RFC4342 、2006年3月、<http://www.rfc-editor.org/info/rfc4342>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443]コンタ、A。、ディアリング、S。、およびM.グプタ編、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、DOI 10.17487 / RFC4443、3月2006、<http://www.rfc-editor.org/info/rfc4443>。
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, DOI 10.17487/RFC4654, August 2006, <http://www.rfc-editor.org/info/rfc4654>.
[RFC4654] Widmer、J。およびM. Handley、「TCP-Friendly Multicast Congestion Control（TFMCC）：Protocol Specification」、RFC 4654、DOI 10.17487 / RFC4654、2006年8月、<http://www.rfc-editor.org / info / rfc4654>。
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, <http://www.rfc-editor.org/info/rfc4820>.
[RFC4820] Tuexen、M.、Stewart、R。、およびP. Lei、「Stream Control Transmission Protocol（SCTP）のパディングチャンクとパラメータ」、RFC 4820、DOI 10.17487 / RFC4820、2007年3月、<http：// www.rfc-editor.org/info/rfc4820>。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<http://www.rfc-editor.org/info/rfc4821>。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, DOI 10.17487/RFC4828, April 2007, <http://www.rfc-editor.org/info/rfc4828>.
[RFC4828]フロイド、S。およびE.コーラー、「TCP Friendly Rate Control（TFRC）：The Small-Packet（SP）Variant」、RFC 4828、DOI 10.17487 / RFC4828、2007年4月、<http：//www.rfc -editor.org/info/rfc4828>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http：/ /www.rfc-editor.org/info/rfc4861>。
[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, <http://www.rfc-editor.org/info/rfc4895>.
[RFC4895] Tuexen、M.、Stewart、R.、Lei、P。、およびE. Rescorla、「Authenticated Chunks for the Stream Control Transmission Protocol（SCTP）」、RFC 4895、DOI 10.17487 / RFC4895、2007年8月、<http ：//www.rfc-editor.org/info/rfc4895>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<http://www.rfc-editor.org/info/rfc4960>。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, DOI 10.17487/RFC5052, August 2007, <http://www.rfc-editor.org/info/rfc5052>.
[RFC5052] Watson、M.、Luby、M。、およびL. Vicisano、「Forward Error Correction（FEC）Building Block」、RFC 5052、DOI 10.17487 / RFC5052、2007年8月、<http：//www.rfc-editor .org / info / rfc5052>。
[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, <http://www.rfc-editor.org/info/rfc5061>.
[RFC5061] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「Stream Control Transmission Protocol（SCTP）Dynamic Address Reconfiguration」、RFC 5061、DOI 10.17487 / RFC5061、9月2007、<http://www.rfc-editor.org/info/rfc5061>。
[RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite protocol", RFC 5097, DOI 10.17487/RFC5097, January 2008, <http://www.rfc-editor.org/info/rfc5097>.
[RFC5097] Renker、G。およびG. Fairhurst、「MIB for the UDP-Lite protocol」、RFC 5097、DOI 10.17487 / RFC5097、2008年1月、<http://www.rfc-editor.org/info/rfc5097> 。
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, DOI 10.17487/RFC5238, May 2008, <http://www.rfc-editor.org/info/rfc5238>.
[RFC5238] Phelan、T。、「Datagram Congestion Control Protocol（DCCP）over Datagram Transport Layer Security（DTLS）over the Datagram Congestion Control Protocol（DCCP）」、RFC 5238、DOI 10.17487 / RFC5238、2008年5月、<http://www.rfc-editor.org / info / rfc5238>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <http://www.rfc-editor.org/info/rfc5348>.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 5348、DOI 10.17487 / RFC5348、2008年9月、<http： //www.rfc-editor.org/info/rfc5348>。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI 10.17487/RFC5461, February 2009, <http://www.rfc-editor.org/info/rfc5461>.
[RFC5461] Gont、F。、「ソフトエラーに対するTCPの反応」、RFC 5461、DOI 10.17487 / RFC5461、2009年2月、<http://www.rfc-editor.org/info/rfc5461>。
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, September 2009, <http://www.rfc-editor.org/info/rfc5595>.
[RFC5595] Fairhurst、G。、「The Datagram Congestion Control Protocol（DCCP）Service Codes」、RFC 5595、DOI 10.17487 / RFC5595、2009年9月、<http://www.rfc-editor.org/info/rfc5595>。
[RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/ Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, September 2009, <http://www.rfc-editor.org/info/rfc5596>.
[RFC5596] Fairhurst、G。、「NAT /ミドルボックストラバーサルを容易にするためのデータグラム輻輳制御プロトコル（DCCP）同時オープンテクニック」、RFC 5596、DOI 10.17487 / RFC5596、2009年9月、<http：//www.rfc-editor。 org / info / rfc5596>。
[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, DOI 10.17487/RFC5622, August 2009, <http://www.rfc-editor.org/info/rfc5622>.
[RFC5622]フロイド、S。およびE.コーラー、「Profile for Datagram Congestion Control Protocol（DCCP）Congestion ID 4：TCP-Friendly Rate Control for Small Packets（TFRC-SP）」、RFC 5622、DOI 10.17487 / RFC5622、8月2009、<http://www.rfc-editor.org/info/rfc5622>。
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, DOI 10.17487/RFC5651, October 2009, <http://www.rfc-editor.org/info/rfc5651>.
[RFC5651] Luby、M.、Watson、M。、およびL. Vicisano、「Layered Coding Transport（LCT）Building Block」、RFC 5651、DOI 10.17487 / RFC5651、2009年10月、<http：//www.rfc-editor .org / info / rfc5651>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<http://www.rfc-editor.org/info/ rfc5681>。
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, <http://www.rfc-editor.org/info/rfc5740>.
[RFC5740] Adamson、B.、Bormann、C.、Handley、M。、およびJ. Macker、「NACK-Oriented Reliable Multicast（NORM）Transport Protocol」、RFC 5740、DOI 10.17487 / RFC5740、2009年11月、<http： //www.rfc-editor.org/info/rfc5740>。
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April 2010, <http://www.rfc-editor.org/info/rfc5762>.
[RFC5762]パーキンス、C。、「RTPおよびデータグラム輻輳制御プロトコル（DCCP）」、RFC 5762、DOI 10.17487 / RFC5762、2010年4月、<http://www.rfc-editor.org/info/rfc5762>。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, DOI 10.17487/RFC5775, April 2010, <http://www.rfc-editor.org/info/rfc5775>.
[RFC5775] Luby、M.、Watson、M。、およびL. Vicisano、「Asynchronous Layered Coding（ALC）Protocol Instantiation」、RFC 5775、DOI 10.17487 / RFC5775、2010年4月、<http：//www.rfc-editor .org / info / rfc5775>。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.
[RFC6056] Larsen、M。およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、DOI 10.17487 / RFC6056、2011年1月、<http://www.rfc-editor.org/info / rfc6056>。
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/RFC6083, January 2011, <http://www.rfc-editor.org/info/rfc6083>.
[RFC6083] Tuexen、M.、Seggelmann、R。、およびE. Rescorla、「Data Control Transport Layer Security（DTLS）for Stream Control Transmission Protocol（SCTP）」、RFC 6083、DOI 10.17487 / RFC6083、2011年1月、<http： //www.rfc-editor.org/info/rfc6083>。
[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, <http://www.rfc-editor.org/info/rfc6093>.
[RFC6093] Gont、F。およびA. Yourtchenko、「TCP緊急メカニズムの実装について」、RFC 6093、DOI 10.17487 / RFC6093、2011年1月、<http://www.rfc-editor.org/info/rfc6093 >。
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 10.17487/RFC6101, August 2011, <http://www.rfc-editor.org/info/rfc6101>.
[RFC6101] Freier、A.、Karlton、P。、およびP. Kocher、「Secure Sockets Layer（SSL）Protocol Version 3.0」、RFC 6101、DOI 10.17487 / RFC6101、2011年8月、<http：//www.rfc -editor.org/info/rfc6101>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, <http://www.rfc-editor.org/info/rfc6356>.
[RFC6356] Raiciu、C.、Handley、M。、およびD. Wischik、「マルチパストランスポートプロトコルの結合された輻輳制御」、RFC 6356、DOI 10.17487 / RFC6356、2011年10月、<http：//www.rfc-editor。 org / info / rfc6356>。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <http://www.rfc-editor.org/info/rfc6363>.
[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「Forward Error Correction（FEC）Framework」、RFC 6363、DOI 10.17487 / RFC6363、2011年10月、<http：//www.rfc-editor。 org / info / rfc6363>。
[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, <http://www.rfc-editor.org/info/rfc6458>.
[RFC6458] Stewart、R.、Tuexen、M.、Poon、K.、Lei、P。、およびV. Yasevich、「Socket Controls Extensions for the Stream Control Transmission Protocol（SCTP）」、RFC 6458、DOI 10.17487 / RFC6458 、2011年12月、<http://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, <http://www.rfc-editor.org/info/rfc6525>.
[RFC6525] Stewart、R.、Tuexen、M。、およびP. Lei、「Stream Control Transmission Protocol（SCTP）Stream Reconfiguration」、RFC 6525、DOI 10.17487 / RFC6525、2012年2月、<http：//www.rfc- editor.org/info/rfc6525>。
[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, DOI 10.17487/RFC6582, April 2012, <http://www.rfc-editor.org/info/rfc6582>.
[RFC6582] Henderson、T.、Floyd、S.、Gurtov、A。、およびY. Nishida、「The NewReno Modification to TCP's Fast Recovery Algorithm」、RFC 6582、DOI 10.17487 / RFC6582、2012年4月、<http：// www.rfc-editor.org/info/rfc6582>。
[RFC6584] Roca, V., "Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6584, DOI 10.17487/RFC6584, April 2012, <http://www.rfc-editor.org/info/rfc6584>.
[RFC6584] Roca、V。、「Asynchronous Layered Coding（ALC）and NACK-Oriented Reliable Multicast（NORM）Protocolsの簡単な認証方式」、RFC 6584、DOI 10.17487 / RFC6584、2012年4月、<http：// www。 rfc-editor.org/info/rfc6584>。
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, <http://www.rfc-editor.org/info/rfc6726>.
[RFC6726] Paila、T.、Walsh、R.、Luby、M.、Roca、V。、およびR. Lehtonen、「FLUTE-単一方向トランスポートを介したファイル配信」、RFC 6726、DOI 10.17487 / RFC6726、2012年11月、< http://www.rfc-editor.org/info/rfc6726>。
[RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2012, <http://www.rfc-editor.org/info/rfc6773>.
[RFC6773] Phelan、T.、Fairhurst、G。、およびC. Perkins、「DCCP-UDP：A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal」、RFC 6773、DOI 10.17487 / RFC6773、2012年11月、<http：/ /www.rfc-editor.org/info/rfc6773>。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://www.rfc-editor.org/info/rfc6817>.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487 / RFC6817、2012年12月、<http：// 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, <http://www.rfc-editor.org/info/rfc6824>.
[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスを持つマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487 / RFC6824、2013年1月、<http：// 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, <http://www.rfc-editor.org/info/rfc6897>.
[RFC6897] Scharf、M。およびA. Ford、「マルチパスTCP（MPTCP）アプリケーションインターフェイスの考慮事項」、RFC 6897、DOI 10.17487 / RFC6897、2013年3月、<http://www.rfc-editor.org/info/rfc6897 >。
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, <http://www.rfc-editor.org/info/rfc6935>.
[RFC6935] Eubanks、M.、Chimento、P。、およびM. Westerlund、「トンネルパケットのIPv6およびUDPチェックサム」、RFC 6935、DOI 10.17487 / RFC6935、2013年4月、<http：//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, <http://www.rfc-editor.org/info/rfc6936>.
[RFC6936] Fairhurst、G。およびM. Westerlund、「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性声明」、RFC 6936、DOI 10.17487 / RFC6936、2013年4月、<http://www.rfc-editor.org / info / rfc6936>。
[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, <http://www.rfc-editor.org/info/rfc6951>.
[RFC6951] Tuexen、M。、およびR. Stewart、「エンドホストからエンドホストへの通信用のストリーム制御伝送プロトコル（SCTP）パケットのUDPカプセル化」、RFC 6951、DOI 10.17487 / RFC6951、2013年5月、<http：/ /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, <http://www.rfc-editor.org/info/rfc7053>.
[RFC7053] Tuexen、M.、Ruengeler、I。、およびR. Stewart、「SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol」、RFC 7053、DOI 10.17487 / RFC7053、2013年11月、<http：//www.rfc -editor.org/info/rfc7053>。
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7202] Perkins、C。およびM. Westerlund、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<http：//www.rfc- editor.org/info/rfc7202>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、DOI 10.17487 / RFC7232、2014年6月、<http://www.rfc-editor.org/info/rfc7232> 。
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <http://www.rfc-editor.org/info/rfc7233>.
[RFC7233] Fielding、R.、Ed。、Lafon、Y.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Range Requests"、RFC 7233、DOI 10.17487 / RFC7233、June 2014、<http://www.rfc-editor.org/info/rfc7233>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<http://www.rfc-editor.org/info/rfc7234>。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<http://www.rfc-editor.org/info/rfc7235>。
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <http://www.rfc-editor.org/info/rfc7301>.
[RFC7301] Friedl、S.、Popov、A.、Langley、A。、およびE. Stephan、「Transport Layer Security（TLS）Application-Layer Protocol Negotiation Extension」、RFC 7301、DOI 10.17487 / RFC7301、2014年7月、< http://www.rfc-editor.org/info/rfc7301>。
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <http://www.rfc-editor.org/info/rfc7323>.
[RFC7323] Borman、D.、Braden、B.、Jacobson、V。、およびR. Scheffenegger、編、「高性能のTCP拡張機能」、RFC 7323、DOI 10.17487 / RFC7323、2014年9月、<http：// www.rfc-editor.org/info/rfc7323>。
[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, <http://www.rfc-editor.org/info/rfc7414>.
[RFC7414]デューク、M。、ブレーデン、R。、エディ、W。、ブラントン、E。、およびA.ジマーマン、「A Transmission map for Transmission Control Protocol（TCP）Specification Documents」、RFC 7414、DOI 10.17487 / RFC7414、 2015年2月、<http://www.rfc-editor.org/info/rfc7414>。
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <http://www.rfc-editor.org/info/rfc7457>.
[RFC7457] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムTLS（DTLS）に対する既知の攻撃の要約」、RFC 7457、DOI 10.17487 / RFC7457、2015年2月、 <http://www.rfc-editor.org/info/rfc7457>。
[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, <http://www.rfc-editor.org/info/rfc7496>.
[RFC7496] Tuexen、M.、Seggelmann、R.、Stewart、R。、およびS. Loreto、「Partially Reliable Stream Control Transmission Protocol Extensionの追加ポリシー」、RFC 7496、DOI 10.17487 / RFC7496、2015年4月、<http ：//www.rfc-editor.org/info/rfc7496>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<http：// www.rfc-editor.org/info/rfc7540>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<http://www.rfc-editor.org / info / rfc8085>。
[SCTP-DTLS-ENCAPS] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", Work in Progress, draft-ietf-tsvwg-sctp-dtls-encaps-09, January 2015.
[SCTP-DTLS-ENCAPS] Tuexen、M.、Stewart、R.、Jesup、R。、およびS. Loreto、「SCTPパケットのDTLSカプセル化」、作業中、draft-ietf-tsvwg-sctp-dtls-encaps -09、2015年1月。
[SCTP-NDATA] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", Work in Progress, draft-ietf-tsvwg-sctp-ndata-08, October 2016.
[SCTP-NDATA] Stewart、R.、Tuexen、M.、Loreto、S。、およびR. Seggelmann、「Stream Control Transmission Protocolのストリームスケジューラとユーザーメッセージインターリービング」、Work in Progress、draft-ietf-tsvwg- sctp-ndata-08、2016年10月。
[TCP-SPEC] Eddy, W., Ed., "Transmission Control Protocol Specification", Work in Progress, draft-ietf-tcpm-rfc793bis-04, December 2016.
[TCP-SPEC] Eddy、W.、Ed。、「Transmission Control Protocol Specification」、Work in Progress、draft-ietf-tcpm-rfc793bis-04、2016年12月。
[TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-18, October 2016.
[TLS-1.3] Rescorla、E。、「Transport Layer Security（TLS）Protocol Version 1.3」、Work in Progress、draft-ietf-tls-tls13-18、2016年10月。
[WEBRTC-TRANS] Alvestrand, H., "Transports for WebRTC", Work in Progress, draft-ietf-rtcweb-transports-17, October 2016.
[WEBRTC-TRANS] Alvestrand、H。、「Transports for WebRTC」、Work in Progress、draft-ietf-rtcweb-transports-17、2016年10月。
[XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, "XMLHttpRequest Level 1", World Wide Web Consortium NOTE-XMLHttpRequest-20161006, October 2016, <http://www.w3.org/TR/XMLHttpRequest/>.
[XHR] van Kesteren、A.、Aubourg、J.、Song、J。、およびH. Steen、「XMLHttpRequest Level 1」、World Wide Web Consortium NOTE-XMLHttpRequest-20161006、2016年10月、<http：// www。 w3.org/TR/XMLHttpRequest/>。
Acknowledgments
謝辞
Thanks to Joe Touch, Michael Welzl, Spencer Dawkins, and the TAPS working group for the comments, feedback, and discussion. This work is supported by the European Commission under grant agreement No. 318627 mPlane and from the Horizon 2020 research and innovation program under grant agreements No. 644334 (NEAT) and No. 688421 (MAMI). This support does not imply endorsement.
コメント、フィードバック、ディスカッションを行ってくれたJoe Touch、Michael Welzl、Spencer Dawkins、およびTAPSワーキンググループに感謝します。この作業は、助成金契約番号318627 mPlaneに基づく欧州委員会、および助成金契約番号644334（NEAT）と番号688421（MAMI）に基づくHorizon 2020の研究および革新プログラムによってサポートされています。このサポートは保証を意味するものではありません。
Contributors
貢献者
In addition to the editors, this document is the work of Brian Adamson, Dragana Damjanovic, Kevin Fall, Simone Ferlin-Oliviera, Ralph Holz, Olivier Mehani, Karen Nielsen, Colin Perkins, Vincent Roca, and Michael Tuexen.
編集者に加えて、このドキュメントは、ブライアンアダムソン、ドラガナダムジャノビッチ、ケビンフォール、シモーヌフェルリンオリビエラ、ラルフホルツ、オリビエメカニ、カレンニールセン、コリンパーキンス、ヴィンセントロカ、マイケルトゥエクセンの作品です。
o Section 3.2 on MPTCP was contributed by Simone Ferlin-Oliviera (ferlin@simula.no) and Olivier Mehani (olivier.mehani@nicta.com.au).
o MPTCPのセクション3.2は、Simone Ferlin-Oliviera（ferlin@simula.no）およびOlivier Mehani（olivier.mehani@nicta.com.au）によって提供されました。
o Section 3.3 on UDP was contributed by Kevin Fall (kfall@kfall.com).
o UDPのセクション3.3は、Kevin Fall（kfall@kfall.com）によって提供されました。
o Section 3.5 on SCTP was contributed by Michael Tuexen (tuexen@fh-muenster.de) and Karen Nielsen (karen.nielsen@tieto.com).
o SCTPのセクション3.5は、Michael Tuexen（tuexen@fh-muenster.de）およびKaren Nielsen（karen.nielsen@tieto.com）によって提供されました。
o Section 3.7 on TLS and DTLS was contributed by Ralph Holz (ralph.holz@nicta.com.au) and Olivier Mehani (olivier.mehani@nicta.com.au).
o TLSおよびDTLSに関するセクション3.7は、Ralph Holz（ralph.holz@nicta.com.au）およびOlivier Mehani（olivier.mehani@nicta.com.au）によって寄稿されました。
o Section 3.8 on RTP contains contributions from Colin Perkins (csp@csperkins.org).
o RTPのセクション3.8には、Colin Perkins（csp@csperkins.org）からの寄稿が含まれています。
o Section 3.9 on HTTP was contributed by Dragana Damjanovic (ddamjanovic@mozilla.com).
o HTTPのセクション3.9はDragana Damjanovic（ddamjanovic@mozilla.com）によって寄贈されました。
o Section 3.10 on FLUTE/ALC was contributed by Vincent Roca (vincent.roca@inria.fr).
o FLUTE / ALCのセクション3.10は、Vincent Roca（vincent.roca@inria.fr）によって提供されました。
o Section 3.11 on NORM was contributed by Brian Adamson (brian.adamson@nrl.navy.mil).
o NORMのセクション3.11は、Brian Adamson（brian.adamson@nrl.navy.mil）によって提供されました。
Authors' Addresses
著者のアドレス
Godred Fairhurst (editor) University of Aberdeen School of Engineering, Fraser Noble Building Aberdeen AB24 3UE
Godred Fairhurst（編集者）アバディーン大学工学部、フレーザーノーブルビルディングアバディーンAB24 3UE
Email: gorry@erg.abdn.ac.uk
Brian Trammell (editor) ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland
ブライアントラメル（編集者）ETHチューリッヒGloriastrasse 35 8092チューリッヒスイス
Email: ietf@trammell.ch
Mirja Kuehlewind (editor) ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland
Mirja Kuehlewind（編集者）ETHチューリッヒGloriastrasse 35 8092チューリッヒスイス
Email: mirja.kuehlewind@tik.ee.ethz.ch