Network Working Group E. Kohler
Request for Comments: 4340 UCLA
Category: Standards Track M. Handley
UCL
S. Floyd
ICIR
March 2006
Network Working Group E. Kohler
Request for Comments: 4340 UCLA
Category: Standards Track M. Handley
UCL
S. Floyd
ICIR
March 2006
Datagram Congestion Control Protocol (DCCP)
数据报拥塞控制协议（DCCP）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability.
数据报拥塞控制协议（DCCP）是一种传输协议，提供拥塞控制的不可靠数据报的双向单播连接。DCCP适用于传输大量数据的应用程序，并且可以从控制及时性和可靠性之间的权衡中获益。
Table of Contents
目录
1. Introduction ....................................................5
2. Design Rationale ................................................6
3. Conventions and Terminology .....................................7
3.1. Numbers and Fields .........................................7
3.2. Parts of a Connection ......................................8
3.3. Features ...................................................9
3.4. Round-Trip Times ...........................................9
3.5. Security Limitation ........................................9
3.6. Robustness Principle ......................................10
4. Overview .......................................................10
4.1. Packet Types ..............................................10
4.2. Packet Sequencing .........................................11
4.3. States ....................................................12
4.4. Congestion Control Mechanisms .............................14
1. Introduction ....................................................5
2. Design Rationale ................................................6
3. Conventions and Terminology .....................................7
3.1. Numbers and Fields .........................................7
3.2. Parts of a Connection ......................................8
3.3. Features ...................................................9
3.4. Round-Trip Times ...........................................9
3.5. Security Limitation ........................................9
3.6. Robustness Principle ......................................10
4. Overview .......................................................10
4.1. Packet Types ..............................................10
4.2. Packet Sequencing .........................................11
4.3. States ....................................................12
4.4. Congestion Control Mechanisms .............................14
4.5. Feature Negotiation Options ...............................15
4.6. Differences from TCP ......................................16
4.7. Example Connection ........................................17
5. Packet Formats .................................................18
5.1. Generic Header ............................................19
5.2. DCCP-Request Packets ......................................22
5.3. DCCP-Response Packets .....................................23
5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets .............23
5.5. DCCP-CloseReq and DCCP-Close Packets ......................25
5.6. DCCP-Reset Packets ........................................25
5.7. DCCP-Sync and DCCP-SyncAck Packets ........................28
5.8. Options ...................................................29
5.8.1. Padding Option .....................................31
5.8.2. Mandatory Option ...................................31
6. Feature Negotiation ............................................32
6.1. Change Options ............................................32
6.2. Confirm Options ...........................................33
6.3. Reconciliation Rules ......................................33
6.3.1. Server-Priority ....................................34
6.3.2. Non-Negotiable .....................................34
6.4. Feature Numbers ...........................................35
6.5. Feature Negotiation Examples ..............................36
6.6. Option Exchange ...........................................37
6.6.1. Normal Exchange ....................................38
6.6.2. Processing Received Options ........................38
6.6.3. Loss and Retransmission ............................40
6.6.4. Reordering .........................................41
6.6.5. Preference Changes .................................42
6.6.6. Simultaneous Negotiation ...........................42
6.6.7. Unknown Features ...................................43
6.6.8. Invalid Options ....................................43
6.6.9. Mandatory Feature Negotiation ......................44
7. Sequence Numbers ...............................................44
7.1. Variables .................................................45
7.2. Initial Sequence Numbers ..................................45
7.3. Quiet Time ................................................46
7.4. Acknowledgement Numbers ...................................47
7.5. Validity and Synchronization ..............................47
7.5.1. Sequence and Acknowledgement Number Windows ........48
7.5.2. Sequence Window Feature ............................49
7.5.3. Sequence-Validity Rules ............................49
7.5.4. Handling Sequence-Invalid Packets ..................51
7.5.5. Sequence Number Attacks ............................52
7.5.6. Sequence Number Handling Examples ..................54
7.6. Short Sequence Numbers ....................................55
7.6.1. Allow Short Sequence Numbers Feature ...............55
7.6.2. When to Avoid Short Sequence Numbers ...............56
7.7. NDP Count and Detecting Application Loss ..................56
4.5. Feature Negotiation Options ...............................15
4.6. Differences from TCP ......................................16
4.7. Example Connection ........................................17
5. Packet Formats .................................................18
5.1. Generic Header ............................................19
5.2. DCCP-Request Packets ......................................22
5.3. DCCP-Response Packets .....................................23
5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets .............23
5.5. DCCP-CloseReq and DCCP-Close Packets ......................25
5.6. DCCP-Reset Packets ........................................25
5.7. DCCP-Sync and DCCP-SyncAck Packets ........................28
5.8. Options ...................................................29
5.8.1. Padding Option .....................................31
5.8.2. Mandatory Option ...................................31
6. Feature Negotiation ............................................32
6.1. Change Options ............................................32
6.2. Confirm Options ...........................................33
6.3. Reconciliation Rules ......................................33
6.3.1. Server-Priority ....................................34
6.3.2. Non-Negotiable .....................................34
6.4. Feature Numbers ...........................................35
6.5. Feature Negotiation Examples ..............................36
6.6. Option Exchange ...........................................37
6.6.1. Normal Exchange ....................................38
6.6.2. Processing Received Options ........................38
6.6.3. Loss and Retransmission ............................40
6.6.4. Reordering .........................................41
6.6.5. Preference Changes .................................42
6.6.6. Simultaneous Negotiation ...........................42
6.6.7. Unknown Features ...................................43
6.6.8. Invalid Options ....................................43
6.6.9. Mandatory Feature Negotiation ......................44
7. Sequence Numbers ...............................................44
7.1. Variables .................................................45
7.2. Initial Sequence Numbers ..................................45
7.3. Quiet Time ................................................46
7.4. Acknowledgement Numbers ...................................47
7.5. Validity and Synchronization ..............................47
7.5.1. Sequence and Acknowledgement Number Windows ........48
7.5.2. Sequence Window Feature ............................49
7.5.3. Sequence-Validity Rules ............................49
7.5.4. Handling Sequence-Invalid Packets ..................51
7.5.5. Sequence Number Attacks ............................52
7.5.6. Sequence Number Handling Examples ..................54
7.6. Short Sequence Numbers ....................................55
7.6.1. Allow Short Sequence Numbers Feature ...............55
7.6.2. When to Avoid Short Sequence Numbers ...............56
7.7. NDP Count and Detecting Application Loss ..................56
7.7.1. NDP Count Usage Notes ..............................57
7.7.2. Send NDP Count Feature .............................57
8. Event Processing ...............................................58
8.1. Connection Establishment ..................................58
8.1.1. Client Request .....................................58
8.1.2. Service Codes ......................................59
8.1.3. Server Response ....................................61
8.1.4. Init Cookie Option .................................62
8.1.5. Handshake Completion ...............................63
8.2. Data Transfer .............................................63
8.3. Termination ...............................................64
8.3.1. Abnormal Termination ...............................66
8.4. DCCP State Diagram ........................................66
8.5. Pseudocode ................................................67
9. Checksums ......................................................72
9.1. Header Checksum Field .....................................73
9.2. Header Checksum Coverage Field ............................73
9.2.1. Minimum Checksum Coverage Feature ..................74
9.3. Data Checksum Option ......................................75
9.3.1. Check Data Checksum Feature ........................76
9.3.2. Checksum Usage Notes ...............................76
10. Congestion Control ............................................76
10.1. TCP-like Congestion Control ..............................77
10.2. TFRC Congestion Control ..................................78
10.3. CCID-Specific Options, Features, and Reset Codes .........78
10.4. CCID Profile Requirements ................................80
10.5. Congestion State .........................................81
11. Acknowledgements ..............................................81
11.1. Acks of Acks and Unidirectional Connections ..............82
11.2. Ack Piggybacking .........................................83
11.3. Ack Ratio Feature ........................................84
11.4. Ack Vector Options .......................................85
11.4.1. Ack Vector Consistency ............................88
11.4.2. Ack Vector Coverage ...............................89
11.5. Send Ack Vector Feature ..................................90
11.6. Slow Receiver Option .....................................90
11.7. Data Dropped Option ......................................91
11.7.1. Data Dropped and Normal Congestion Response .......94
11.7.2. Particular Drop Codes .............................95
12. Explicit Congestion Notification ..............................96
12.1. ECN Incapable Feature ....................................96
12.2. ECN Nonces ...............................................97
12.3. Aggression Penalties .....................................98
13. Timing Options ................................................99
13.1. Timestamp Option .........................................99
13.2. Elapsed Time Option ......................................99
13.3. Timestamp Echo Option ...................................100
14. Maximum Packet Size ..........................................101
7.7.1. NDP Count Usage Notes ..............................57
7.7.2. Send NDP Count Feature .............................57
8. Event Processing ...............................................58
8.1. Connection Establishment ..................................58
8.1.1. Client Request .....................................58
8.1.2. Service Codes ......................................59
8.1.3. Server Response ....................................61
8.1.4. Init Cookie Option .................................62
8.1.5. Handshake Completion ...............................63
8.2. Data Transfer .............................................63
8.3. Termination ...............................................64
8.3.1. Abnormal Termination ...............................66
8.4. DCCP State Diagram ........................................66
8.5. Pseudocode ................................................67
9. Checksums ......................................................72
9.1. Header Checksum Field .....................................73
9.2. Header Checksum Coverage Field ............................73
9.2.1. Minimum Checksum Coverage Feature ..................74
9.3. Data Checksum Option ......................................75
9.3.1. Check Data Checksum Feature ........................76
9.3.2. Checksum Usage Notes ...............................76
10. Congestion Control ............................................76
10.1. TCP-like Congestion Control ..............................77
10.2. TFRC Congestion Control ..................................78
10.3. CCID-Specific Options, Features, and Reset Codes .........78
10.4. CCID Profile Requirements ................................80
10.5. Congestion State .........................................81
11. Acknowledgements ..............................................81
11.1. Acks of Acks and Unidirectional Connections ..............82
11.2. Ack Piggybacking .........................................83
11.3. Ack Ratio Feature ........................................84
11.4. Ack Vector Options .......................................85
11.4.1. Ack Vector Consistency ............................88
11.4.2. Ack Vector Coverage ...............................89
11.5. Send Ack Vector Feature ..................................90
11.6. Slow Receiver Option .....................................90
11.7. Data Dropped Option ......................................91
11.7.1. Data Dropped and Normal Congestion Response .......94
11.7.2. Particular Drop Codes .............................95
12. Explicit Congestion Notification ..............................96
12.1. ECN Incapable Feature ....................................96
12.2. ECN Nonces ...............................................97
12.3. Aggression Penalties .....................................98
13. Timing Options ................................................99
13.1. Timestamp Option .........................................99
13.2. Elapsed Time Option ......................................99
13.3. Timestamp Echo Option ...................................100
14. Maximum Packet Size ..........................................101
14.1. Measuring PMTU ..........................................102
14.2. Sender Behavior .........................................103
15. Forward Compatibility ........................................104
16. Middlebox Considerations .....................................105
17. Relations to Other Specifications ............................106
17.1. RTP .....................................................106
17.2. Congestion Manager and Multiplexing .....................108
18. Security Considerations ......................................108
18.1. Security Considerations for Partial Checksums ...........109
19. IANA Considerations ..........................................110
19.1. Packet Types Registry ...................................110
19.2. Reset Codes Registry ....................................110
19.3. Option Types Registry ...................................110
19.4. Feature Numbers Registry ................................111
19.5. Congestion Control Identifiers Registry .................111
19.6. Ack Vector States Registry ..............................111
19.7. Drop Codes Registry .....................................112
19.8. Service Codes Registry ..................................112
19.9. Port Numbers Registry ...................................112
20. Thanks .......................................................114
A. Appendix: Ack Vector Implementation Notes ....................116
A.1. Packet Arrival ..........................................118
A.1.1. New Packets ......................................118
A.1.2. Old Packets ......................................119
A.2. Sending Acknowledgements ................................120
A.3. Clearing State ..........................................120
A.4. Processing Acknowledgements .............................122
B. Appendix: Partial Checksumming Design Motivation .............123
Normative References .............................................124
Informative References ...........................................125
14.1. Measuring PMTU ..........................................102
14.2. Sender Behavior .........................................103
15. Forward Compatibility ........................................104
16. Middlebox Considerations .....................................105
17. Relations to Other Specifications ............................106
17.1. RTP .....................................................106
17.2. Congestion Manager and Multiplexing .....................108
18. Security Considerations ......................................108
18.1. Security Considerations for Partial Checksums ...........109
19. IANA Considerations ..........................................110
19.1. Packet Types Registry ...................................110
19.2. Reset Codes Registry ....................................110
19.3. Option Types Registry ...................................110
19.4. Feature Numbers Registry ................................111
19.5. Congestion Control Identifiers Registry .................111
19.6. Ack Vector States Registry ..............................111
19.7. Drop Codes Registry .....................................112
19.8. Service Codes Registry ..................................112
19.9. Port Numbers Registry ...................................112
20. Thanks .......................................................114
A. Appendix: Ack Vector Implementation Notes ....................116
A.1. Packet Arrival ..........................................118
A.1.1. New Packets ......................................118
A.1.2. Old Packets ......................................119
A.2. Sending Acknowledgements ................................120
A.3. Clearing State ..........................................120
A.4. Processing Acknowledgements .............................122
B. Appendix: Partial Checksumming Design Motivation .............123
Normative References .............................................124
Informative References ...........................................125
List of Tables
表格一览表
Table 1: DCCP Packet Types .......................................21
Table 2: DCCP Reset Codes ........................................28
Table 3: DCCP Options ............................................30
Table 4: DCCP Feature Numbers.....................................35
Table 5: DCCP Congestion Control Identifiers .....................77
Table 6: DCCP Ack Vector States ..................................86
Table 7: DCCP Drop Codes .........................................92
Table 1: DCCP Packet Types .......................................21
Table 2: DCCP Reset Codes ........................................28
Table 3: DCCP Options ............................................30
Table 4: DCCP Feature Numbers.....................................35
Table 5: DCCP Congestion Control Identifiers .....................77
Table 6: DCCP Ack Vector States ..................................86
Table 7: DCCP Drop Codes .........................................92
The Datagram Congestion Control Protocol (DCCP) is a transport protocol that implements bidirectional, unicast connections of congestion-controlled, unreliable datagrams. Specifically, DCCP provides the following:
数据报拥塞控制协议（DCCP）是一种传输协议，它实现拥塞控制的不可靠数据报的双向单播连接。具体而言，DCCP提供以下功能：
o Unreliable flows of datagrams.
o 不可靠的数据报流。
o Reliable handshakes for connection setup and teardown.
o 可靠的握手，用于连接设置和拆卸。
o Reliable negotiation of options, including negotiation of a suitable congestion control mechanism.
o 选项的可靠协商，包括合适的拥塞控制机制的协商。
o Mechanisms allowing servers to avoid holding state for unacknowledged connection attempts and already-finished connections.
o 允许服务器避免为未确认的连接尝试和已完成的连接保留状态的机制。
o Congestion control incorporating Explicit Congestion Notification (ECN) [RFC3168] and the ECN Nonce [RFC3540].
o 包含显式拥塞通知（ECN）[RFC3168]和ECN当前值[RFC3540]的拥塞控制。
o Acknowledgement mechanisms communicating packet loss and ECN information. Acks are transmitted as reliably as the relevant congestion control mechanism requires, possibly completely reliably.
o 通信分组丢失和ECN信息的确认机制。ACK按照相关拥塞控制机制的要求可靠地传输，可能完全可靠。
o Optional mechanisms that tell the sending application, with high reliability, which data packets reached the receiver, and whether those packets were ECN marked, corrupted, or dropped in the receive buffer.
o 可选机制，以高可靠性告知发送应用程序哪些数据包到达了接收器，以及这些数据包是否在接收缓冲区中被ECN标记、损坏或丢弃。
o Path Maximum Transmission Unit (PMTU) discovery [RFC1191].
o 路径最大传输单元（PMTU）发现[RFC1191]。
o A choice of modular congestion control mechanisms. Two mechanisms are currently specified: TCP-like Congestion Control [RFC4341] and TCP-Friendly Rate Control (TFRC) [RFC4342]. DCCP is easily extensible to further forms of unicast congestion control.
o 模块化拥塞控制机制的选择。目前指定了两种机制：类TCP拥塞控制[RFC4341]和TCP友好速率控制（TFRC）[RFC4342]。DCCP很容易扩展到其他形式的单播拥塞控制。
DCCP is intended for applications such as streaming media that can benefit from control over the tradeoffs between delay and reliable in-order delivery. TCP is not well suited for these applications, since reliable in-order delivery and congestion control can cause arbitrarily long delays. UDP avoids long delays, but UDP applications that implement congestion control must do so on their own. DCCP provides built-in congestion control, including ECN
DCCP适用于流媒体等应用程序，这些应用程序可以通过控制延迟和可靠有序交付之间的权衡而获益。TCP不太适合这些应用，因为可靠的顺序传递和拥塞控制可能导致任意长的延迟。UDP避免了长时间的延迟，但实现拥塞控制的UDP应用程序必须自己实现。DCCP提供内置的拥塞控制，包括ECN
support, for unreliable datagram flows, avoiding the arbitrary delays associated with TCP. It also implements reliable connection setup, teardown, and feature negotiation.
支持不可靠的数据报流，避免与TCP相关的任意延迟。它还实现了可靠的连接设置、拆卸和功能协商。
One DCCP design goal was to give most streaming UDP applications little reason not to switch to DCCP, once it is deployed. To facilitate this, DCCP was designed to have as little overhead as possible, both in terms of the packet header size and in terms of the state and CPU overhead required at end hosts. Only the minimal necessary functionality was included in DCCP, leaving other functionality, such as forward error correction (FEC), semi-reliability, and multiple streams, to be layered on top of DCCP as desired.
DCCP的一个设计目标是让大多数流式UDP应用程序在部署后没有理由不切换到DCCP。为了实现这一点，DCCP被设计为具有尽可能小的开销，无论是在数据包头大小方面，还是在终端主机所需的状态和CPU开销方面。DCCP中只包含了最低限度的必要功能，其他功能（如前向纠错（FEC）、半可靠性和多个流）将根据需要分层在DCCP之上。
Different forms of conformant congestion control are appropriate for different applications. For example, on-line games might want to make quick use of any available bandwidth, while streaming media might trade off this responsiveness for a steadier, less bursty rate. (Sudden rate changes can cause unacceptable UI glitches such as audible pauses or clicks in the playout stream.) DCCP thus allows applications to choose from a set of congestion control mechanisms. One alternative, TCP-like Congestion Control, halves the congestion window in response to a packet drop or mark, as in TCP. Applications using this congestion control mechanism will respond quickly to changes in available bandwidth, but must tolerate the abrupt changes in congestion window typical of TCP. A second alternative, TCP-Friendly Rate Control (TFRC) [RFC3448], a form of equation-based congestion control, minimizes abrupt changes in the sending rate while maintaining longer-term fairness with TCP. Other alternatives can be added as future congestion control mechanisms are standardized.
不同形式的一致拥塞控制适用于不同的应用。例如，在线游戏可能希望快速利用任何可用带宽，而流媒体可能会用更稳定、更少突发的速率来交换这种响应能力。（突然的速率变化可能会导致不可接受的UI故障，例如播放流中的声音暂停或点击。）DCCP因此允许应用程序从一组拥塞控制机制中进行选择。另一种选择，类似TCP的拥塞控制，将拥塞窗口减半以响应数据包丢失或标记，如TCP。使用这种拥塞控制机制的应用程序将快速响应可用带宽的变化，但必须容忍TCP典型的拥塞窗口的突然变化。第二种选择，TCP友好速率控制（TFRC）[RFC3448]，一种基于等式的拥塞控制形式，在保持TCP长期公平性的同时，最小化发送速率的突然变化。随着未来拥塞控制机制的标准化，可以添加其他替代方案。
DCCP also lets unreliable traffic safely use ECN. A UDP kernel Application Programming Interface (API) might not allow applications to set UDP packets as ECN capable, since the API could not guarantee that the application would properly detect or respond to congestion. DCCP kernel APIs will have no such issues, since DCCP implements congestion control itself.
DCCP还允许不可靠的通信安全地使用ECN。UDP内核应用程序编程接口（API）可能不允许应用程序将UDP数据包设置为支持ECN，因为API无法保证应用程序能够正确检测或响应拥塞。DCCP内核API将不会有这样的问题，因为DCCP本身实现拥塞控制。
We chose not to require the use of the Congestion Manager [RFC3124], which allows multiple concurrent streams between the same sender and receiver to share congestion control. The current Congestion Manager can only be used by applications that have their own end-to-end feedback about packet losses, but this is not the case for many of the applications currently using UDP. In addition, the current Congestion Manager does not easily support multiple congestion
我们选择不需要使用拥塞管理器[RFC3124]，它允许同一发送方和接收方之间的多个并发流共享拥塞控制。当前的拥塞管理器只能由具有自己的数据包丢失端到端反馈的应用程序使用，但对于当前使用UDP的许多应用程序来说，情况并非如此。此外，当前的拥塞管理器不容易支持多个拥塞
control mechanisms or mechanisms where the state about past packet drops or marks is maintained at the receiver rather than the sender. DCCP should be able to make use of CM where desired by the application, but we do not see any benefit in making the deployment of DCCP contingent on the deployment of CM itself.
控制机制或过去数据包丢弃或标记的状态在接收方而不是发送方保持的机制。DCCP应该能够在应用程序需要的地方使用CM，但我们认为DCCP的部署取决于CM本身的部署没有任何好处。
We intend for DCCP's protocol mechanisms, which are described in this document, to suit any application desiring unicast congestion-controlled streams of unreliable datagrams. However, the congestion control mechanisms currently approved for use with DCCP, which are described in separate Congestion Control ID Profiles [RFC4341, RFC4342], may cause problems for some applications, including high-bandwidth interactive video. These applications should be able to use DCCP once suitable Congestion Control ID Profiles are standardized.
我们希望DCCP的协议机制（在本文中描述）适用于任何需要不可靠数据报的单播拥塞控制流的应用。然而，目前批准用于DCCP的拥塞控制机制（在单独的拥塞控制ID配置文件[RFC4341，RFC4342]中描述）可能会导致某些应用出现问题，包括高带宽交互式视频。一旦合适的拥塞控制ID配置文件标准化，这些应用程序应该能够使用DCCP。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
All multi-byte numerical quantities in DCCP, such as port numbers, Sequence Numbers, and arguments to options, are transmitted in network byte order (most significant byte first).
DCCP中的所有多字节数字量，例如端口号、序列号和选项的参数，都是按网络字节顺序传输的（最高有效字节优先）。
We occasionally refer to the "left" and "right" sides of a bit field. "Left" means towards the most significant bit, and "right" means towards the least significant bit.
我们偶尔会提到位字段的“左”和“右”边。“左”表示朝向最高有效位，“右”表示朝向最低有效位。
Random numbers in DCCP are used for their security properties and SHOULD be chosen according to the guidelines in [RFC4086].
DCCP中的随机数用于其安全属性，应根据[RFC4086]中的指南进行选择。
All operations on DCCP sequence numbers use circular arithmetic modulo 2^48, as do comparisons such as "greater" and "greatest". This form of arithmetic preserves the relationships between sequence numbers as they roll over from 2^48 - 1 to 0. Implementation strategies for DCCP sequence numbers will resemble those for other circular arithmetic spaces, including TCP's sequence numbers [RFC793] and DNS's serial numbers [RFC1982]. It may make sense to store DCCP sequence numbers in the most significant 48 bits of 64-bit integers and set the least significant 16 bits to zero, since this supports a common technique that implements circular comparison A < B by testing whether (A - B) < 0 using conventional two's-complement arithmetic.
DCCP序列号上的所有操作都使用循环算术模2^48，如“更大”和“最大”等比较。当序列号从2^48-1滚动到0时，这种形式的算术保留了序列号之间的关系。DCCP序列号的实现策略将类似于其他循环算术空间的实现策略，包括TCP序列号[RFC793]和DNS序列号[RFC1982]。将DCCP序列号存储在64位整数的最高有效48位中并将最低有效16位设置为零可能是有意义的，因为这支持一种通用技术，即通过使用传统的二补算法测试（a-B）<0来实现循环比较a<B。
Reserved bitfields in DCCP packet headers MUST be set to zero by senders and MUST be ignored by receivers, unless otherwise specified. This allows for future protocol extensions. In particular, DCCP processors MUST NOT reset a DCCP connection simply because a Reserved field has non-zero value [RFC3360].
除非另有规定，否则发送方必须将DCCP数据包头中的保留位字段设置为零，接收方必须忽略。这允许将来进行协议扩展。特别是，DCCP处理器不能仅仅因为保留字段的值非零值而重置DCCP连接[RFC3360]。
Each DCCP connection runs between two hosts, which we often name DCCP A and DCCP B. Each connection is actively initiated by one of the hosts, which we call the client; the other, initially passive host is called the server. The term "DCCP endpoint" is used to refer to either of the two hosts explicitly named by the connection (the client and the server). The term "DCCP processor" refers more generally to any host that might need to process a DCCP header; this includes the endpoints and any middleboxes on the path, such as firewalls and network address translators.
每个DCCP连接在两台主机之间运行，我们通常将其命名为DCCP A和DCCP B。每个连接都由其中一台主机主动启动，我们称之为客户端；另一个最初是被动主机的主机称为服务器。术语“DCCP端点”用于指由连接显式命名的两台主机中的任何一台（客户端和服务器）。术语“DCCP处理器”更一般地指可能需要处理DCCP报头的任何主机；这包括端点和路径上的任何中间盒，如防火墙和网络地址转换器。
DCCP connections are bidirectional: data may pass from either endpoint to the other. This means that data and acknowledgements may flow in both directions simultaneously. Logically, however, a DCCP connection consists of two separate unidirectional connections, called half-connections. Each half-connection consists of the application data sent by one endpoint and the corresponding acknowledgements sent by the other endpoint. We can illustrate this as follows:
DCCP连接是双向的：数据可以从任一端点传递到另一端点。这意味着数据和确认可以同时向两个方向流动。但是，从逻辑上讲，DCCP连接由两个单独的单向连接组成，称为半连接。每个半连接由一个端点发送的应用程序数据和另一个端点发送的相应确认组成。我们可以这样说明：
+--------+ A-to-B half-connection: +--------+
| | --> application data --> | |
| | <-- acknowledgements <-- | |
| DCCP A | | DCCP B |
| | B-to-A half-connection: | |
| | <-- application data <-- | |
+--------+ --> acknowledgements --> +--------+
+--------+ A-to-B half-connection: +--------+
| | --> application data --> | |
| | <-- acknowledgements <-- | |
| DCCP A | | DCCP B |
| | B-to-A half-connection: | |
| | <-- application data <-- | |
+--------+ --> acknowledgements --> +--------+
Although they are logically distinct, in practice the half-connections overlap; a DCCP-DataAck packet, for example, contains application data relevant to one half-connection and acknowledgement information relevant to the other.
虽然它们在逻辑上是不同的，但在实践中，半连接重叠；例如，DCCP数据包包含与一半连接相关的应用程序数据和与另一半连接相关的确认信息。
In the context of a single half-connection, the terms "HC-Sender" and "HC-Receiver" denote the endpoints sending application data and acknowledgements, respectively. For example, DCCP A is the HC-Sender and DCCP B is the HC-Receiver in the A-to-B half-connection.
在单个半连接的上下文中，术语“HC发送方”和“HC接收方”分别表示发送应用程序数据和确认的端点。例如，DCCP A是A-to-B半连接中的HC发送方，DCCP B是HC接收方。
A DCCP feature is a connection attribute on whose value the two endpoints agree. Many properties of a DCCP connection are controlled by features, including the congestion control mechanisms in use on the two half-connections. The endpoints achieve agreement through the exchange of feature negotiation options in DCCP headers.
DCCP功能是两个端点的值一致的连接属性。DCCP连接的许多属性由功能控制，包括在两个半连接上使用的拥塞控制机制。端点通过在DCCP头中交换特性协商选项来达成一致。
DCCP features are identified by a feature number and an endpoint. The notation "F/X" represents the feature with feature number F located at DCCP endpoint X. Each valid feature number thus corresponds to two features, which are negotiated separately and need not have the same value. The two endpoints know, and agree on, the value of every valid feature. DCCP A is the "feature location" for all features F/A, and the "feature remote" for all features F/B.
DCCP特征由特征编号和端点标识。符号“F/X”表示特征编号F位于DCCP端点X处的特征。因此，每个有效特征编号对应两个特征，分别协商，不需要具有相同的值。两个端点知道并同意每个有效特征的值。DCCP A是所有功能F/A的“功能位置”，是所有功能F/B的“功能远程”。
DCCP round-trip time measurements are performed by congestion control mechanisms; different mechanisms may measure round-trip time in different ways, or not measure it at all. However, the main DCCP protocol does use round-trip times occasionally, such as in the initial values for certain timers. Each DCCP implementation thus defines a default round-trip time for use when no estimate is available. This parameter should default to not less than 0.2 seconds, a reasonably conservative round-trip time for Internet TCP connections. Protocol behavior specified in terms of "round-trip time" values actually refers to "a current round-trip time estimate taken by some CCID, or, if no estimate is available, the default round-trip time parameter".
DCCP往返时间测量由拥塞控制机制执行；不同的机制可能以不同的方式测量往返时间，或者根本不测量往返时间。然而，主DCCP协议偶尔使用往返时间，例如某些计时器的初始值。因此，每个DCCP实现都定义了一个默认的往返时间，以便在没有可用估计时使用。此参数默认值应不小于0.2秒，这是Internet TCP连接的合理保守往返时间。根据“往返时间”值指定的协议行为实际上指的是“某个CCID获取的当前往返时间估计值，或者，如果没有可用的估计值，则指默认的往返时间参数”。
The maximum segment lifetime, or MSL, is the maximum length of time a packet can survive in the network. The DCCP MSL should equal that of TCP, which is normally two minutes.
最大段生存期（MSL）是数据包在网络中能够生存的最大时间长度。DCCP MSL应等于TCP的MSL，通常为两分钟。
DCCP provides no protection against attackers who can snoop on a connection in progress, or who can guess valid sequence numbers in other ways. Applications desiring stronger security should use IPsec [RFC2401]; depending on the level of security required, application-level cryptography may also suffice. These issues are discussed further in Sections 7.5.5 and 18.
DCCP无法防止攻击者窥探正在进行的连接，或以其他方式猜测有效序列号。需要更高安全性的应用程序应使用IPsec[RFC2401]；根据所需的安全级别，应用程序级加密也可以满足要求。第7.5.5节和第18节将进一步讨论这些问题。
DCCP implementations will follow TCP's "general principle of
robustness": "be conservative in what you do, be liberal in what you
accept from others" [RFC793].
DCCP implementations will follow TCP's "general principle of
robustness": "be conservative in what you do, be liberal in what you
accept from others" [RFC793].
DCCP's high-level connection dynamics echo those of TCP. Connections progress through three phases: initiation, including a three-way handshake; data transfer; and termination. Data can flow both ways over the connection. An acknowledgement framework lets senders discover how much data has been lost and thus avoid unfairly congesting the network. Of course, DCCP provides unreliable datagram semantics, not TCP's reliable bytestream semantics. The application must package its data into explicit frames and must retransmit its own data as necessary. It may be useful to think of DCCP as TCP minus bytestream semantics and reliability, or as UDP plus congestion control, handshakes, and acknowledgements.
DCCP的高级连接动态响应TCP。连接过程分为三个阶段：启动，包括三次握手；数据传输；和终止。数据可以通过连接双向流动。确认框架让发送方发现丢失了多少数据，从而避免网络不公平地拥塞。当然，DCCP提供了不可靠的数据报语义，而不是TCP可靠的ByTestStream语义。应用程序必须将其数据打包到显式帧中，并且必须根据需要重新传输自己的数据。将DCCP视为TCP减去ByTestStream语义和可靠性，或者视为UDP加上拥塞控制、握手和确认，可能会很有用。
Ten packet types implement DCCP's protocol functions. For example, every new connection attempt begins with a DCCP-Request packet sent by the client. In this way a DCCP-Request packet resembles a TCP SYN, but since DCCP-Request is a packet type there is no way to send an unexpected flag combination, such as TCP's SYN+FIN+ACK+RST.
十种数据包类型实现了DCCP的协议功能。例如，每次新的连接尝试都从客户端发送的DCCP请求数据包开始。通过这种方式，DCCP请求数据包类似于TCP SYN，但由于DCCP请求是一种数据包类型，因此无法发送意外的标志组合，例如TCP的SYN+FIN+ACK+RST。
Eight packet types occur during the progress of a typical connection, shown here. Note the three-way handshakes during initiation and termination.
典型连接过程中会出现八种数据包类型，如下所示。注意启动和终止期间的三方握手。
Client Server
------ ------
(1) Initiation
DCCP-Request -->
<-- DCCP-Response
DCCP-Ack -->
(2) Data transfer
DCCP-Data, DCCP-Ack, DCCP-DataAck -->
<-- DCCP-Data, DCCP-Ack, DCCP-DataAck
(3) Termination
<-- DCCP-CloseReq
DCCP-Close -->
<-- DCCP-Reset
Client Server
------ ------
(1) Initiation
DCCP-Request -->
<-- DCCP-Response
DCCP-Ack -->
(2) Data transfer
DCCP-Data, DCCP-Ack, DCCP-DataAck -->
<-- DCCP-Data, DCCP-Ack, DCCP-DataAck
(3) Termination
<-- DCCP-CloseReq
DCCP-Close -->
<-- DCCP-Reset
The two remaining packet types are used to resynchronize after bursts of loss.
其余两种数据包类型用于在突发丢失后重新同步。
Every DCCP packet starts with a fixed-size generic header. Particular packet types include additional fixed-size header data; for example, DCCP-Acks include an Acknowledgement Number. DCCP options and any application data follow the fixed-size header.
每个DCCP数据包都以一个固定大小的通用报头开始。特定分组类型包括附加的固定大小报头数据；例如，DCCP确认包括一个确认号。DCCP选项和任何应用程序数据都遵循固定大小的标题。
The packet types are as follows:
数据包类型如下所示：
DCCP-Request Sent by the client to initiate a connection (the first part of the three-way initiation handshake).
由客户端发送的用于启动连接的DCCP请求（三方启动握手的第一部分）。
DCCP-Response Sent by the server in response to a DCCP-Request (the second part of the three-way initiation handshake).
服务器为响应DCCP请求而发送的DCCP响应（三向启动握手的第二部分）。
DCCP-Data Used to transmit application data.
用于传输应用程序数据的DCCP数据。
DCCP-Ack Used to transmit pure acknowledgements.
用于传输纯确认的DCCP Ack。
DCCP-DataAck Used to transmit application data with piggybacked acknowledgement information.
DCCP数据包，用于传输带有附带确认信息的应用程序数据。
DCCP-CloseReq Sent by the server to request that the client close the connection.
服务器发送DCCP CloseReq请求客户端关闭连接。
DCCP-Close Used by the client or the server to close the connection; elicits a DCCP-Reset in response.
客户端或服务器用于关闭连接的DCCP Close；引发DCCP重置作为响应。
DCCP-Reset Used to terminate the connection, either normally or abnormally.
DCCP重置用于终止连接（正常或异常）。
DCCP-Sync, DCCP-SyncAck Used to resynchronize sequence numbers after large bursts of loss.
DCCP Sync，DCCP SyncAck用于在大量丢失后重新同步序列号。
Each DCCP packet carries a sequence number so that losses can be detected and reported. Unlike TCP sequence numbers, which are byte-based, DCCP sequence numbers increment by one per packet. For example:
每个DCCP数据包都带有一个序列号，以便可以检测和报告丢失。与基于字节的TCP序列号不同，DCCP序列号每包增加一个。例如：
DCCP A DCCP B
------ ------
DCCP-Data(seqno 1) -->
DCCP-Data(seqno 2) -->
<-- DCCP-Ack(seqno 10, ackno 2)
DCCP-DataAck(seqno 3, ackno 10) -->
<-- DCCP-Data(seqno 11)
DCCP A DCCP B
------ ------
DCCP-Data(seqno 1) -->
DCCP-Data(seqno 2) -->
<-- DCCP-Ack(seqno 10, ackno 2)
DCCP-DataAck(seqno 3, ackno 10) -->
<-- DCCP-Data(seqno 11)
Every DCCP packet increments the sequence number, whether or not it contains application data. DCCP-Ack pure acknowledgements increment the sequence number; for instance, DCCP B's second packet above uses sequence number 11, since sequence number 10 was used for an acknowledgement. This lets endpoints detect all packet loss, including acknowledgement loss. It also means that endpoints can get out of sync after long bursts of loss. The DCCP-Sync and DCCP-SyncAck packet types are used to recover (Section 7.5).
无论是否包含应用程序数据，每个DCCP数据包都会增加序列号。DCCP Ack纯确认增加序列号；例如，上面DCCP B的第二个数据包使用序列号11，因为序列号10用于确认。这允许端点检测所有数据包丢失，包括确认丢失。这也意味着在长时间的突发性丢失之后，端点可能会失去同步。DCCP Sync和DCCP SyncAck数据包类型用于恢复（第7.5节）。
Since DCCP provides unreliable semantics, there are no retransmissions, and having a TCP-style cumulative acknowledgement field doesn't make sense. DCCP's Acknowledgement Number field equals the greatest sequence number received, rather than the smallest sequence number not received. Separate options indicate any intermediate sequence numbers that weren't received.
由于DCCP提供了不可靠的语义，因此不存在重传，并且使用TCP样式的累积确认字段没有意义。DCCP的确认号字段等于收到的最大序列号，而不是未收到的最小序列号。单独的选项表示未收到的任何中间序列号。
DCCP endpoints progress through different states during the course of a connection, corresponding roughly to the three phases of initiation, data transfer, and termination. The figure below shows the typical progress through these states for a client and server.
DCCP端点在连接过程中经历不同的状态，大致对应于启动、数据传输和终止三个阶段。下图显示了客户机和服务器在这些状态下的典型进度。
Client Server
------ ------
(0) No connection
CLOSED LISTEN
Client Server
------ ------
(0) No connection
CLOSED LISTEN
(1) Initiation REQUEST DCCP-Request --> <-- DCCP-Response RESPOND PARTOPEN DCCP-Ack or DCCP-DataAck -->
（1） 启动请求DCCP请求--><--DCCP响应部分打开DCCP确认或DCCP数据确认-->
(2) Data transfer OPEN <-- DCCP-Data, Ack, DataAck --> OPEN
（2） 数据传输打开<--DCCP数据，确认，数据确认-->打开
(3) Termination <-- DCCP-CloseReq CLOSEREQ CLOSING DCCP-Close --> <-- DCCP-Reset CLOSED TIMEWAIT CLOSED
（3） 终止<--DCCP关闭请求关闭请求关闭DCCP关闭--><--DCCP重置关闭时间等待关闭
The nine possible states are as follows. They are listed in increasing order, so that "state >= CLOSEREQ" means the same as "state = CLOSEREQ or state = CLOSING or state = TIMEWAIT". Section 8 describes the states in more detail.
九种可能的状态如下。它们按递增顺序列出，因此“state>=CLOSEREQ”的含义与“state=CLOSEREQ或state=CLOSING或state=TIMEWAIT”相同。第8节更详细地描述了这些州。
CLOSED Represents nonexistent connections.
CLOSED表示不存在的连接。
LISTEN Represents server sockets in the passive listening state. LISTEN and CLOSED are not associated with any particular DCCP connection.
LISTEN表示处于被动侦听状态的服务器套接字。侦听和关闭与任何特定DCCP连接都不关联。
REQUEST A client socket enters this state, from CLOSED, after sending a DCCP-Request packet to try to initiate a connection.
请求客户端套接字在发送DCCP请求数据包以尝试启动连接后，从关闭状态进入此状态。
RESPOND A server socket enters this state, from LISTEN, after receiving a DCCP-Request from a client.
响应服务器套接字在接收到来自客户端的DCCP请求后，从侦听进入此状态。
PARTOPEN A client socket enters this state, from REQUEST, after receiving a DCCP-Response from the server. This state represents the third phase of the three-way handshake. The client may send application data in this state, but it MUST include an Acknowledgement Number on all of its packets.
PARTOPEN客户端套接字在收到服务器的DCCP响应后，从请求进入此状态。此状态表示三方握手的第三阶段。客户端可以在这种状态下发送应用程序数据，但它必须在其所有数据包上包含一个确认号。
OPEN The central data transfer portion of a DCCP connection. Client and server sockets enter this state from PARTOPEN and RESPOND, respectively. Sometimes we speak of SERVER-OPEN and CLIENT-OPEN states, corresponding to the server's OPEN state and the client's OPEN state.
打开DCCP连接的中央数据传输部分。客户端和服务器套接字分别从PARTOPEN和RESPOND进入此状态。有时我们谈到服务器打开和客户机打开状态，对应于服务器的打开状态和客户机的打开状态。
CLOSEREQ A server socket enters this state, from SERVER-OPEN, to order the client to close the connection and to hold TIMEWAIT state.
CLOSEREQ服务器套接字从server-OPEN进入此状态，以命令客户端关闭连接并保持TIMEWAIT状态。
CLOSING Server and client sockets can both enter this state to close the connection.
关闭服务器和客户端套接字都可以进入此状态以关闭连接。
TIMEWAIT A server or client socket remains in this state for 2MSL (4 minutes) after the connection has been torn down, to prevent mistakes due to the delivery of old packets. Only one of the endpoints has to enter TIMEWAIT state (the other can enter CLOSED state immediately), and a server can request its client to hold TIMEWAIT state using the DCCP-CloseReq packet type.
TIMEWAIT在断开连接后，服务器或客户端套接字将保持此状态2MSL（4分钟），以防止由于传递旧数据包而出现错误。只有一个端点必须进入TIMEWAIT状态（另一个端点可以立即进入CLOSED状态），服务器可以使用DCCP CloseReq数据包类型请求其客户端保持TIMEWAIT状态。
DCCP connections are congestion controlled, but unlike in TCP, DCCP applications have a choice of congestion control mechanism. In fact, the two half-connections can be governed by different mechanisms. Mechanisms are denoted by one-byte congestion control identifiers, or CCIDs. The endpoints negotiate their CCIDs during connection initiation. Each CCID describes how the HC-Sender limits data packet rates, how the HC-Receiver sends congestion feedback via acknowledgements, and so forth. CCIDs 2 and 3 are currently defined; CCIDs 0, 1, and 4-255 are reserved. Other CCIDs may be defined in the future.
DCCP连接是拥塞控制的，但与TCP不同，DCCP应用程序可以选择拥塞控制机制。事实上，两个半连接可以由不同的机制控制。机制由单字节拥塞控制标识符（CCID）表示。端点在连接启动期间协商其CCID。每个CCID描述HC发送方如何限制数据包速率，HC接收方如何通过确认发送拥塞反馈，等等。CCID 2和3目前已定义；保留CCID 0、1和4-255。将来可能会定义其他CCID。
CCID 2 provides TCP-like Congestion Control, which is similar to that of TCP. The sender maintains a congestion window and sends packets until that window is full. Packets are acknowledged by the receiver. Dropped packets and ECN [RFC3168] indicate congestion; the response to congestion is to halve the congestion window. Acknowledgements in CCID 2 contain the sequence numbers of all received packets within some window, similar to a selective acknowledgement (SACK) [RFC2018].
CCID2提供了类似于TCP的拥塞控制。发送方保持一个拥塞窗口并发送数据包，直到该窗口已满。数据包由接收方确认。丢包和ECN[RFC3168]表示拥塞；应对拥堵的措施是将拥堵窗口减半。CCID 2中的确认包含某个窗口内所有接收数据包的序列号，类似于选择性确认（SACK）[RFC2018]。
CCID 3 provides TCP-Friendly Rate Control (TFRC), an equation-based form of congestion control intended to respond to congestion more smoothly than CCID 2. The sender maintains a transmit rate, which it updates using the receiver's estimate of the packet loss and mark
CCID3提供TCP友好速率控制（TFRC），这是一种基于等式的拥塞控制形式，旨在比CCID2更平滑地响应拥塞。发送方保持一个传输速率，它使用接收方对数据包丢失和标记的估计来更新该速率
rate. CCID 3 behaves somewhat differently than TCP in the short term, but is designed to operate fairly with TCP over the long term.
速度CCID3在短期内的行为与TCP稍有不同，但设计用于在长期内公平地使用TCP。
Section 10 describes DCCP's CCIDs in more detail. The behaviors of CCIDs 2 and 3 are fully defined in separate profile documents [RFC4341, RFC4342].
第10节更详细地描述了DCCP的CCID。CCID 2和3的行为在单独的概要文件[RFC4341、RFC4342]中有完整的定义。
DCCP endpoints use Change and Confirm options to negotiate and agree on feature values. Feature negotiation will almost always happen on the connection initiation handshake, but it can begin at any time.
DCCP端点使用更改和确认选项协商并商定特征值。功能协商几乎总是在连接启动握手时进行，但它可以在任何时候开始。
There are four feature negotiation options in all: Change L, Confirm L, Change R, and Confirm R. The "L" options are sent by the feature location and the "R" options are sent by the feature remote. A Change R option says to the feature location, "change this feature value as follows". The feature location responds with Confirm L, meaning, "I've changed it". Some features allow Change R options to contain multiple values sorted in preference order. For example:
共有四个功能协商选项：更改L、确认L、更改R和确认R。“L”选项由功能位置发送，“R”选项由功能远程发送。更改R选项对特征位置显示“按如下方式更改此特征值”。特征位置以“确认L”回应，意思是“我已经更改了”。某些功能允许Changer选项包含按首选项顺序排序的多个值。例如：
Client Server
------ ------
Change R(CCID, 2) -->
<-- Confirm L(CCID, 2)
* agreement that CCID/Server = 2 *
Client Server
------ ------
Change R(CCID, 2) -->
<-- Confirm L(CCID, 2)
* agreement that CCID/Server = 2 *
Change R(CCID, 3 4) -->
<-- Confirm L(CCID, 4, 4 2)
* agreement that CCID/Server = 4 *
Change R(CCID, 3 4) -->
<-- Confirm L(CCID, 4, 4 2)
* agreement that CCID/Server = 4 *
Both exchanges negotiate the CCID/Server feature's value, which is the CCID in use on the server-to-client half-connection. In the second exchange, the client requests that the server use either CCID 3 or CCID 4, with 3 preferred; the server chooses 4 and supplies its preference list, "4 2".
两个交换机协商CCID/服务器功能的值，即服务器到客户端半连接上使用的CCID。在第二次交换中，客户机请求服务器使用CCID 3或CCID 4，其中3个优先；服务器选择4并提供其首选项列表“4 2”。
The Change L and Confirm R options are used for feature negotiations initiated by the feature location. In the following example, the server requests that CCID/Server be set to 3 or 2, with 3 preferred, and the client agrees.
更改L和确认R选项用于由特征位置启动的特征协商。在下面的示例中，服务器请求将CCID/server设置为3或2，并选择3，客户机同意。
Client Server
------ ------
<-- Change L(CCID, 3 2)
Confirm R(CCID, 3, 3 2) -->
* agreement that CCID/Server = 3 *
Client Server
------ ------
<-- Change L(CCID, 3 2)
Confirm R(CCID, 3, 3 2) -->
* agreement that CCID/Server = 3 *
Section 6 describes the feature negotiation options further, including the retransmission strategies that make negotiation reliable.
第6节进一步描述了功能协商选项，包括使协商可靠的重传策略。
DCCP's differences from TCP apart from those discussed so far include the following:
DCCP与TCP的区别除了目前讨论的区别外，还包括以下方面：
o Copious space for options (up to 1008 bytes or the PMTU).
o 丰富的选项空间（最多1008字节或PMTU）。
o Different acknowledgement formats. The CCID for a connection determines how much acknowledgement information needs to be transmitted. For example, in CCID 2 (TCP-like), this is about one ack per 2 packets, and each ack must declare exactly which packets were received. In CCID 3 (TFRC), it is about one ack per round-trip time, and acks must declare at minimum just the lengths of recent loss intervals.
o 不同的确认格式。连接的CCID确定需要传输多少确认信息。例如，在CCID2（类似TCP）中，这大约是每2个数据包一个ack，每个ack必须准确地声明接收了哪些数据包。在CCID3（TFRC）中，每个往返时间大约有一个ack，ack必须至少声明最近丢失间隔的长度。
o Denial of Service (DoS) protection. Several mechanisms help limit the amount of state that possibly-misbehaving clients can force DCCP servers to maintain. An Init Cookie option analogous to TCP's SYN Cookies [SYNCOOKIES] avoids SYN-flood-like attacks. Only one connection endpoint has to hold TIMEWAIT state; the DCCP-CloseReq packet, which may only be sent by the server, passes that state to the client. Various rate limits let servers avoid attacks that might force extensive computation or packet generation.
o 拒绝服务（DoS）保护。有几种机制有助于限制可能行为不端的客户端可能强制DCCP服务器维护的状态量。类似于TCP的SYN Cookies[SYNCOOKIES]的Init Cookie选项可避免类似SYN洪水的攻击。只有一个连接端点必须保持TIMEWAIT状态；DCCP CloseReq数据包（只能由服务器发送）将该状态传递给客户端。通过各种速率限制，服务器可以避免可能导致大量计算或数据包生成的攻击。
o Distinguishing different kinds of loss. A Data Dropped option (Section 11.7) lets an endpoint declare that a packet was dropped because of corruption, because of receive buffer overflow, and so on. This facilitates research into more appropriate rate-control responses for these non-network-congestion losses (although currently such losses will cause a congestion response).
o 区分不同种类的损失。数据丢弃选项（第11.7节）允许端点声明由于损坏、接收缓冲区溢出等原因丢弃数据包。这有助于研究针对这些非网络拥塞损失的更合适的速率控制响应（尽管目前这种损失将导致拥塞响应）。
o Acknowledgeability. In TCP, a packet may be acknowledged only once the data is reliably queued for application delivery. This does not make sense in DCCP, where an application might, for example, request a drop-from-front receive buffer. A DCCP packet may be acknowledged as soon as its header has been successfully processed. Concretely, a packet becomes acknowledgeable at Step 8
o 可确认性。在TCP中，只有当数据可靠地排队等待应用程序交付时，才能确认数据包。这在DCCP中没有意义，例如，在DCCP中，应用程序可能会请求从前端接收缓冲区进行删除。一旦成功处理了DCCP数据包的报头，就可以对其进行确认。具体地说，在步骤8，数据包变为可确认的
of Section 8.5's packet processing pseudocode. Acknowledgeability does not guarantee data delivery, however: the Data Dropped option may later report that the packet's application data was discarded.
第8.5节的数据包处理伪码。然而，可确认性并不保证数据传递：数据丢弃选项可能会在稍后报告数据包的应用程序数据被丢弃。
o No receive window. DCCP is a congestion control protocol, not a flow control protocol.
o 没有接收窗口。DCCP是一种拥塞控制协议，而不是流量控制协议。
o No simultaneous open. Every connection has one client and one server.
o 没有同时打开。每个连接都有一个客户端和一个服务器。
o No half-closed states. DCCP has no states corresponding to TCP's FINWAIT and CLOSEWAIT, where one half-connection is explicitly closed while the other is still active. The Data Dropped option's Drop Code 1, Application Not Listening (Section 11.7), can achieve a similar effect, however.
o 没有半封闭状态。DCCP没有与TCP的FINWAIT和CLOSEWAIT相对应的状态，其中一半连接显式关闭，而另一半仍处于活动状态。但是，数据删除选项的删除代码1“应用程序不侦听”（第11.7节）可以实现类似的效果。
The progress of a typical DCCP connection is as follows. (This description is informative, not normative.)
典型DCCP连接的进度如下所示。（本说明仅供参考，非规范性说明。）
Client Server
------ ------
0. [CLOSED] [LISTEN]
1. DCCP-Request -->
2. <-- DCCP-Response
3. DCCP-Ack -->
4. DCCP-Data, DCCP-Ack, DCCP-DataAck -->
<-- DCCP-Data, DCCP-Ack, DCCP-DataAck
5. <-- DCCP-CloseReq
6. DCCP-Close -->
7. <-- DCCP-Reset
8. [TIMEWAIT]
Client Server
------ ------
0. [CLOSED] [LISTEN]
1. DCCP-Request -->
2. <-- DCCP-Response
3. DCCP-Ack -->
4. DCCP-Data, DCCP-Ack, DCCP-DataAck -->
<-- DCCP-Data, DCCP-Ack, DCCP-DataAck
5. <-- DCCP-CloseReq
6. DCCP-Close -->
7. <-- DCCP-Reset
8. [TIMEWAIT]
1. The client sends the server a DCCP-Request packet specifying the client and server ports, the service being requested, and any features being negotiated, including the CCID that the client would like the server to use. The client may optionally piggyback an application request on the DCCP-Request packet. The server may ignore this application request.
1. 客户端向服务器发送一个DCCP请求包，指定客户端和服务器端口、请求的服务以及正在协商的任何功能，包括客户端希望服务器使用的CCID。客户端可以选择性地在DCCP请求包上搭载应用程序请求。服务器可能会忽略此应用程序请求。
2. The server sends the client a DCCP-Response packet indicating that it is willing to communicate with the client. This response indicates any features and options that the server agrees to, begins other feature negotiations as desired, and optionally includes Init Cookies that wrap up all this information and that must be returned by the client for the connection to complete.
2. 服务器向客户端发送一个DCCP响应数据包，表明它愿意与客户端通信。此响应表示服务器同意的任何功能和选项，根据需要开始其他功能协商，并可选地包括封装所有这些信息的Init cookie，客户端必须返回这些信息才能完成连接。
3. The client sends the server a DCCP-Ack packet that acknowledges the DCCP-Response packet. This acknowledges the server's initial sequence number and returns any Init Cookies in the DCCP-Response. It may also continue feature negotiation. The client may piggyback an application-level request on this ack, producing a DCCP-DataAck packet.
3. 客户端向服务器发送确认DCCP响应数据包的DCCP Ack数据包。这将确认服务器的初始序列号，并在DCCP响应中返回任何初始cookie。它还可以继续功能协商。客户机可以在此ack上承载应用程序级请求，从而生成DCCP数据包。
4. The server and client then exchange DCCP-Data packets, DCCP-Ack packets acknowledging that data, and, optionally, DCCP-DataAck packets containing data with piggybacked acknowledgements. If the client has no data to send, then the server will send DCCP-Data and DCCP-DataAck packets, while the client will send DCCP-Acks exclusively. (However, the client may not send DCCP-Data packets before receiving at least one non-DCCP-Response packet from the server.)
4. 然后，服务器和客户机交换DCCP数据包、确认该数据的DCCP Ack数据包，以及（可选地）包含带有附带确认的数据的DCCP数据包。如果客户端没有要发送的数据，则服务器将发送DCCP数据和DCCP数据包，而客户端将以独占方式发送DCCP数据包。（然而，在从服务器接收至少一个非DCCP响应包之前，客户端可能不会发送DCCP数据包。）
5. The server sends a DCCP-CloseReq packet requesting a close.
5. 请求关闭DCCP的服务器发送一个数据包CloseReq。
6. The client sends a DCCP-Close packet acknowledging the close.
6. 客户端发送DCCP Close数据包，确认关闭。
7. The server sends a DCCP-Reset packet with Reset Code 1, "Closed", and clears its connection state. DCCP-Resets are part of normal connection termination; see Section 5.6.
7. 服务器发送一个带有重置代码1“Closed”的DCCP重置数据包，并清除其连接状态。DCCP重置是正常连接终止的一部分；见第5.6节。
8. The client receives the DCCP-Reset packet and holds state for two maximum segment lifetimes, or 2MSL, to allow any remaining packets to clear the network.
8. 客户端接收DCCP重置数据包，并将状态保持两个最长的段生存时间，或2MSL，以允许任何剩余数据包清除网络。
An alternative connection closedown sequence is initiated by the client:
另一种连接关闭顺序由客户端启动：
5b. The client sends a DCCP-Close packet closing the connection.
5b。客户端发送一个DCCP Close数据包来关闭连接。
6b. The server sends a DCCP-Reset packet with Reset Code 1, "Closed", and clears its connection state.
6b。服务器发送一个带有重置代码1“Closed”的DCCP重置数据包，并清除其连接状态。
7b. The client receives the DCCP-Reset packet and holds state for 2MSL to allow any remaining packets to clear the network.
7b。客户端接收DCCP重置数据包并保持2MSL状态，以允许任何剩余数据包清除网络。
The DCCP header can be from 12 to 1020 bytes long. The initial part of the header has the same semantics for all currently defined packet types. Following this comes any additional fixed-length fields required by the packet type, and then a variable-length list of options. The application data area follows the header. In some packet types, this area contains data for the application; in other packet types, its contents are ignored.
DCCP头的长度可以是12到1020字节。报头的初始部分对于所有当前定义的数据包类型具有相同的语义。接下来是数据包类型所需的任何其他固定长度字段，然后是可变长度选项列表。应用程序数据区域位于标题后面。在某些包类型中，此区域包含应用程序的数据；在其他数据包类型中，其内容被忽略。
+---------------------------------------+ -.
| Generic Header | |
+---------------------------------------+ |
| Additional Fields (depending on type) | +- DCCP Header
+---------------------------------------+ |
| Options (optional) | |
+=======================================+ -'
| Application Data Area |
+---------------------------------------+
+---------------------------------------+ -.
| Generic Header | |
+---------------------------------------+ |
| Additional Fields (depending on type) | +- DCCP Header
+---------------------------------------+ |
| Options (optional) | |
+=======================================+ -'
| Application Data Area |
+---------------------------------------+
The DCCP generic header takes different forms depending on the value of X, the Extended Sequence Numbers bit. If X is one, the Sequence Number field is 48 bits long, and the generic header takes 16 bytes, as follows.
DCCP通用头根据扩展序列号位X的值采取不同的形式。如果X为1，则序列号字段的长度为48位，通用标头的长度为16字节，如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X| | .
| Res | Type |=| Reserved | Sequence Number (high bits) .
| | |1| | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sequence Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X| | .
| Res | Type |=| Reserved | Sequence Number (high bits) .
| | |1| | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sequence Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If X is zero, only the low 24 bits of the Sequence Number are transmitted, and the generic header is 12 bytes long.
如果X为零，则仅传输序列号的低24位，且通用报头为12字节长。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X| |
| Res | Type |=| Sequence Number (low bits) |
| | |0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X| |
| Res | Type |=| Sequence Number (low bits) |
| | |0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The generic header fields are defined as follows.
通用标题字段定义如下。
Source and Destination Ports: 16 bits each These fields identify the connection, similar to the corresponding fields in TCP and UDP. The Source Port represents the relevant port on the endpoint that sent this packet, and the Destination Port represents the relevant port on the other endpoint. When initiating a connection, the client SHOULD choose its Source Port randomly to reduce the likelihood of attack.
源端口和目标端口：16位每个字段标识连接，类似于TCP和UDP中的相应字段。源端口表示发送此数据包的端点上的相关端口，目标端口表示另一个端点上的相关端口。启动连接时，客户端应随机选择其源端口，以降低攻击的可能性。
DCCP APIs should treat port numbers similarly to TCP and UDP port numbers. For example, machines that distinguish between "privileged" and "unprivileged" ports for TCP and UDP should do the same for DCCP.
DCCP API应该像对待TCP和UDP端口号一样对待端口号。例如，区分TCP和UDP的“特权”和“非特权”端口的计算机也应该对DCCP执行相同的操作。
Data Offset: 8 bits The offset from the start of the packet's DCCP header to the start of its application data area, in 32-bit words. The receiver MUST ignore packets whose Data Offset is smaller than the minimum-sized header for the given Type or larger than the DCCP packet itself.
数据偏移量：8位数据包DCCP报头开始到其应用程序数据区开始的偏移量，以32位字表示。接收器必须忽略数据偏移量小于给定类型的最小大小报头或大于DCCP数据包本身的数据包。
CCVal: 4 bits Used by the HC-Sender CCID. For example, the A-to-B CCID's sender, which is active at DCCP A, MAY send 4 bits of information per packet to its receiver by encoding that information in CCVal. The sender MUST set CCVal to zero unless its HC-Sender CCID specifies otherwise, and the receiver MUST ignore the CCVal field unless its HC-Receiver CCID specifies otherwise.
CCVal:HC发送器CCID使用的4位。例如，A-to-B CCID的发送方（其在DCCP A处是活动的）可以通过在CCVal中编码该信息来向其接收方发送每个分组的4比特信息。除非其HC发送方CCID另有规定，否则发送方必须将CCVal设置为零；除非其HC接收方CCID另有规定，否则接收方必须忽略CCVal字段。
Checksum Coverage (CsCov): 4 bits Checksum Coverage determines the parts of the packet that are covered by the Checksum field. This always includes the DCCP header and options, but some or all of the application data may be excluded. This can improve performance on noisy links for applications that can tolerate corruption. See Section 9.
校验和覆盖率（CsCov）：4位校验和覆盖率确定校验和字段覆盖的数据包部分。这始终包括DCCP头和选项，但可能会排除部分或全部应用程序数据。这可以提高可容忍损坏的应用程序在嘈杂链路上的性能。见第9节。
Checksum: 16 bits The Internet checksum of the packet's DCCP header (including options), a network-layer pseudoheader, and, depending on Checksum Coverage, all, some, or none of the application data. See Section 9.
校验和：16位数据包的DCCP报头（包括选项）、网络层伪报头的互联网校验和，以及根据校验和覆盖范围，所有、部分或无应用程序数据的互联网校验和。见第9节。
Reserved (Res): 3 bits Senders MUST set this field to all zeroes on generated packets, and receivers MUST ignore its value.
保留（Res）：3位发送方必须在生成的数据包上将此字段设置为全零，接收方必须忽略其值。
Type: 4 bits The Type field specifies the type of the packet. The following values are defined:
类型：4位类型字段指定数据包的类型。定义了以下值：
Type Meaning
---- -------
0 DCCP-Request
1 DCCP-Response
2 DCCP-Data
3 DCCP-Ack
4 DCCP-DataAck
5 DCCP-CloseReq
6 DCCP-Close
7 DCCP-Reset
8 DCCP-Sync
9 DCCP-SyncAck
10-15 Reserved
Type Meaning
---- -------
0 DCCP-Request
1 DCCP-Response
2 DCCP-Data
3 DCCP-Ack
4 DCCP-DataAck
5 DCCP-CloseReq
6 DCCP-Close
7 DCCP-Reset
8 DCCP-Sync
9 DCCP-SyncAck
10-15 Reserved
Table 1: DCCP Packet Types
表1:DCCP数据包类型
Receivers MUST ignore any packets with reserved type. That is, packets with reserved type MUST NOT be processed, and they MUST NOT be acknowledged as received.
接收方必须忽略任何保留类型的数据包。也就是说，不能处理保留类型的数据包，也不能将其确认为已接收。
Extended Sequence Numbers (X): 1 bit Set to one to indicate the use of an extended generic header with 48-bit Sequence and Acknowledgement Numbers. DCCP-Data, DCCP-DataAck, and DCCP-Ack packets MAY set X to zero or one. All DCCP-Request, DCCP-Response, DCCP-CloseReq, DCCP-Close, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck packets MUST set X to one; endpoints MUST ignore any such packets with X set to zero. High-rate connections SHOULD set X to one on all packets to gain increased protection against wrapped sequence numbers and attacks. See Section 7.6.
扩展序列号（X）：将1位设置为1，以指示使用具有48位序列号和确认号的扩展通用报头。DCCP数据、DCCP DataAck和DCCP Ack数据包可以将X设置为零或一。所有DCCP请求、DCCP响应、DCCP关闭请求、DCCP关闭、DCCP重置、DCCP同步和DCCP同步数据包必须将X设置为1；端点必须忽略X设置为零的任何此类数据包。高速连接应将所有数据包上的X设置为1，以增强对包装序列号和攻击的保护。见第7.6节。
Sequence Number: 48 or 24 bits Identifies the packet uniquely in the sequence of all packets the source sent on this connection. Sequence Number increases by one with every packet sent, including packets such as DCCP-Ack that carry no application data. See Section 7.
序列号：48或24位在源在此连接上发送的所有数据包的序列中唯一标识数据包。序列号随发送的每个数据包增加1，包括不携带应用程序数据的数据包（如DCCP Ack）。见第7节。
All currently defined packet types except DCCP-Request and DCCP-Data carry an Acknowledgement Number Subheader in the four or eight bytes immediately following the generic header. When X=1, its format is:
除DCCP请求和DCCP数据外，所有当前定义的数据包类型都在通用报头后面的四个或八个字节中携带一个确认号子标题。当X=1时，其格式为：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number .
| | (high bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Acknowledgement Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number .
| | (high bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Acknowledgement Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When X=0, only the low 24 bits of the Acknowledgement Number are transmitted, giving the Acknowledgement Number Subheader this format:
当X=0时，仅传输确认号的低24位，使确认号副标题采用以下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 16 or 8 bits Senders MUST set this field to all zeroes on generated packets, and receivers MUST ignore its value.
保留：16位或8位发送方必须在生成的数据包上将此字段设置为全零，接收方必须忽略其值。
Acknowledgement Number: 48 or 24 bits Generally contains GSR, the Greatest Sequence Number Received on any acknowledgeable packet so far. A packet is acknowledgeable if and only if its header was successfully processed by the receiver; Section 7.4 describes this further. Options such as Ack Vector (Section 11.4) combine with the Acknowledgement Number to provide precise information about which packets have arrived.
确认号：48或24位通常包含GSR，这是迄今为止任何可确认数据包上接收到的最大序列号。当且仅当接收方成功处理了数据包的报头时，数据包才是可确认的；第7.4节对此进行了进一步描述。诸如Ack Vector（第11.4节）之类的选项与确认号相结合，以提供关于哪些数据包已到达的准确信息。
Acknowledgement Numbers on DCCP-Sync and DCCP-SyncAck packets need not equal GSR. See Section 5.7.
DCCP Sync和DCCP SyncAck数据包上的确认号不必等于GSR。见第5.7节。
A client initiates a DCCP connection by sending a DCCP-Request packet. These packets MAY contain application data and MUST use 48-bit sequence numbers (X=1).
客户端通过发送DCCP请求数据包来启动DCCP连接。这些数据包可能包含应用程序数据，并且必须使用48位序列号（X=1）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header with X=1 (16 bytes) /
/ with Type=0 (DCCP-Request) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header with X=1 (16 bytes) /
/ with Type=0 (DCCP-Request) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Code: 32 bits Describes the application-level service to which the client application wants to connect. Service Codes are intended to provide information about which application protocol a connection intends to use, thus aiding middleboxes and reducing reliance on globally well-known ports. See Section 8.1.2.
服务代码：32位描述客户端应用程序要连接的应用程序级服务。服务代码旨在提供有关连接打算使用哪个应用程序协议的信息，从而帮助中间盒并减少对全球知名端口的依赖。见第8.1.2节。
The server responds to valid DCCP-Request packets with DCCP-Response packets. This is the second phase of the three-way handshake. DCCP-Response packets MAY contain application data and MUST use 48-bit sequence numbers (X=1).
服务器使用DCCP响应数据包响应有效的DCCP请求数据包。这是三方握手的第二阶段。DCCP响应数据包可能包含应用程序数据，并且必须使用48位序列号（X=1）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header with X=1 (16 bytes) /
/ with Type=1 (DCCP-Response) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header with X=1 (16 bytes) /
/ with Type=1 (DCCP-Response) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Acknowledgement Number: 48 bits Contains GSR. Since DCCP-Responses are only sent during connection initiation, this will always equal the Sequence Number on a received DCCP-Request.
确认号：48位包含GSR。由于DCCP响应仅在连接启动期间发送，因此始终等于接收到的DCCP请求的序列号。
Service Code: 32 bits MUST equal the Service Code on the corresponding DCCP-Request.
服务代码：32位必须等于相应DCCP请求上的服务代码。
The central data transfer portion of every DCCP connection uses DCCP-Data, DCCP-Ack, and DCCP-DataAck packets. These packets MAY use 24-bit sequence numbers, depending on the value of the Allow Short Sequence Numbers feature (Section 7.6.1). DCCP-Data packets carry application data without acknowledgements.
每个DCCP连接的中央数据传输部分使用DCCP数据、DCCP Ack和DCCP DataAck数据包。这些数据包可能使用24位序列号，具体取决于允许短序列号功能的值（第7.6.1节）。DCCP数据包在没有确认的情况下携带应用程序数据。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (16 or 12 bytes) /
/ with Type=2 (DCCP-Data) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (16 or 12 bytes) /
/ with Type=2 (DCCP-Data) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DCCP-Ack packets dispense with the data but contain an Acknowledgement Number. They are used for pure acknowledgements.
DCCP Ack数据包不包含数据，但包含一个确认号。它们是用来表示感谢的。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (16 or 12 bytes) /
/ with Type=3 (DCCP-Ack) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 or 4 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data Area (Ignored) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (16 or 12 bytes) /
/ with Type=3 (DCCP-Ack) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 or 4 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data Area (Ignored) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DCCP-DataAck packets carry both application data and an Acknowledgement Number. This piggybacks acknowledgement information on a data packet.
DCCP数据包携带应用程序数据和确认号。这将在数据包上承载确认信息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (16 or 12 bytes) /
/ with Type=4 (DCCP-DataAck) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 or 4 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (16 or 12 bytes) /
/ with Type=4 (DCCP-DataAck) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 or 4 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A DCCP-Data or DCCP-DataAck packet may have a zero-length application data area, which indicates that the application sent a zero-length datagram. This differs from DCCP-Request and DCCP-Response packets, where an empty application data area indicates the absence of
DCCP数据或DCCP数据包可具有零长度应用程序数据区，其指示应用程序发送零长度数据报。这与DCCP请求和DCCP响应数据包不同，在DCCP请求和DCCP响应数据包中，空的应用程序数据区表示没有
application data (not the presence of zero-length application data). The API SHOULD report any received zero-length datagrams to the receiving application.
应用程序数据（不存在零长度应用程序数据）。API应该向接收应用程序报告任何接收到的零长度数据报。
A DCCP-Ack packet MAY have a non-zero-length application data area, which essentially pads the DCCP-Ack to a desired length. Receivers MUST ignore the content of the application data area in DCCP-Ack packets.
DCCP Ack分组可以具有非零长度的应用数据区域，其基本上将DCCP Ack填充到所需长度。接收器必须忽略DCCP Ack数据包中应用程序数据区的内容。
DCCP-Ack and DCCP-DataAck packets often include additional acknowledgement options, such as Ack Vector, as required by the congestion control mechanism in use.
DCCP Ack和DCCP DATACK数据包通常包括额外的确认选项，如使用中的拥塞控制机制所要求的Ack向量。
DCCP-CloseReq and DCCP-Close packets begin the handshake that normally terminates a connection. Either client or server may send a DCCP-Close packet, which will elicit a DCCP-Reset packet. Only the server can send a DCCP-CloseReq packet, which indicates that the server wants to close the connection but does not want to hold its TIMEWAIT state. Both packet types MUST use 48-bit sequence numbers (X=1).
DCCP CloseReq和DCCP Close数据包开始通常终止连接的握手。客户机或服务器都可以发送DCCP关闭数据包，这将引发DCCP重置数据包。只有服务器可以发送DCCP CloseReq数据包，该数据包表示服务器希望关闭连接，但不希望保持其TIMEWAIT状态。两种数据包类型都必须使用48位序列号（X=1）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header with X=1 (16 bytes) /
/ with Type=5 (DCCP-CloseReq) or 6 (DCCP-Close) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data Area (Ignored) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header with X=1 (16 bytes) /
/ with Type=5 (DCCP-CloseReq) or 6 (DCCP-Close) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data Area (Ignored) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As with DCCP-Ack packets, DCCP-CloseReq and DCCP-Close packets MAY have non-zero-length application data areas, whose contents receivers MUST ignore.
与DCCP Ack数据包一样，DCCP CloseReq和DCCP Close数据包可能具有非零长度的应用程序数据区，其内容接收器必须忽略。
DCCP-Reset packets unconditionally shut down a connection. Connections normally terminate with a DCCP-Reset, but resets may be sent for other reasons, including bad port numbers, bad option behavior, incorrect ECN Nonce Echoes, and so forth. DCCP-Resets MUST use 48-bit sequence numbers (X=1).
DCCP重置数据包无条件关闭连接。连接通常会在DCCP重置时终止，但重置可能会由于其他原因而发送，包括错误的端口号、错误的选项行为、错误的ECN Nonce回波等。DCCP重置必须使用48位序列号（X=1）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header with X=1 (16 bytes) /
/ with Type=7 (DCCP-Reset) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reset Code | Data 1 | Data 2 | Data 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data Area (Error Text) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header with X=1 (16 bytes) /
/ with Type=7 (DCCP-Reset) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reset Code | Data 1 | Data 2 | Data 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data Area (Error Text) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reset Code: 8 bits Represents the reason that the sender reset the DCCP connection.
重置代码：8位表示发送方重置DCCP连接的原因。
Data 1, Data 2, and Data 3: 8 bits each The Data fields provide additional information about why the sender reset the DCCP connection. The meanings of these fields depend on the value of Reset Code.
数据1、数据2和数据3:8位每个数据字段提供有关发送方重置DCCP连接原因的附加信息。这些字段的含义取决于重置代码的值。
Application Data Area: Error Text If present, Error Text is a human-readable text string encoded in Unicode UTF-8, and preferably in English, that describes the error in more detail. For example, a DCCP-Reset with Reset Code 11, "Aggression Penalty", might contain Error Text such as "Aggression Penalty: Received 3 bad ECN Nonce Echoes, assuming misbehavior".
应用程序数据区：错误文本如果存在，错误文本是一个人类可读的文本字符串，用Unicode UTF-8编码，最好是英文，它更详细地描述了错误。例如，重置代码为11“侵略惩罚”的DCCP重置可能包含错误文本，如“侵略惩罚：收到3个错误ECN立即回波，假设行为不当”。
The following Reset Codes are currently defined. Unless otherwise specified, the Data 1, 2, and 3 fields MUST be set to 0 by the sender of the DCCP-Reset and ignored by its receiver. Section references describe concrete situations that will cause each Reset Code to be generated; they are not meant to be exhaustive.
当前定义了以下重置代码。除非另有规定，数据1、2和3字段必须由DCCP重置的发送方设置为0，并由接收方忽略。章节参考文件描述了导致生成每个重置代码的具体情况；它们并不意味着详尽无遗。
0, "Unspecified" Indicates the absence of a meaningful Reset Code. Use of Reset Code 0 is NOT RECOMMENDED: the sender should choose a Reset Code that more clearly defines why the connection is being reset.
0，“未指定”表示缺少有意义的重置代码。不建议使用重置代码0：发送方应选择一个重置代码，以更清楚地定义重置连接的原因。
1, "Closed" Normal connection close. See Section 8.3.
1、“关闭”正常连接关闭。见第8.3节。
2, "Aborted" The sending endpoint gave up on the connection because of lack of progress. See Sections 8.1.1 and 8.1.5.
2，“中止”由于缺少进度，发送端点放弃了连接。见第8.1.1节和第8.1.5节。
3, "No Connection" No connection exists. See Section 8.3.1.
3、“无连接”不存在连接。见第8.3.1节。
4, "Packet Error" A valid packet arrived with unexpected type. For example, a DCCP-Data packet with valid header checksum and sequence numbers arrived at a connection in the REQUEST state. See Section 8.3.1. The Data 1 field equals the offending packet type as an eight-bit number; thus, an offending packet with Type 2 will result in a Data 1 value of 2.
4，“数据包错误”以意外类型到达的有效数据包。例如，具有有效报头校验和和序列号的DCCP数据包在请求状态下到达连接。见第8.3.1节。数据1字段等于违规数据包类型，为8位数字；因此，类型为2的违规数据包将导致数据1的值为2。
5, "Option Error" An option was erroneous, and the error was serious enough to warrant resetting the connection. See Sections 6.6.7, 6.6.8, and 11.4. The Data 1 field equals the offending option type; Data 2 and Data 3 equal the first two bytes of option data (or zero if the option had less than two bytes of data).
5，“选项错误”选项错误，错误严重到足以保证重置连接。见第6.6.7、6.6.8和11.4节。数据1字段等于有问题的选项类型；数据2和数据3等于选项数据的前两个字节（如果选项的数据少于两个字节，则为零）。
6, "Mandatory Error" The sending endpoint could not process an option O that was immediately preceded by Mandatory. The Data fields report the option type and data of option O, using the format of Reset Code 5, "Option Error". See Section 5.8.2.
6，“强制错误”发送终结点无法处理紧跟在强制之前的选项O。数据字段使用重置代码5“选项错误”的格式报告选项O的选项类型和数据。见第5.8.2节。
7, "Connection Refused" The Destination Port didn't correspond to a port open for listening. Sent only in response to DCCP-Requests. See Section 8.1.3.
7，“连接被拒绝”目标端口与打开用于侦听的端口不对应。仅在响应DCCP请求时发送。见第8.1.3节。
8, "Bad Service Code" The Service Code didn't equal the service code attached to the Destination Port. Sent only in response to DCCP-Requests. See Section 8.1.3.
8，“错误的服务代码”服务代码不等于附加到目标端口的服务代码。仅在响应DCCP请求时发送。见第8.1.3节。
9, "Too Busy" The server is too busy to accept new connections. Sent only in response to DCCP-Requests. See Section 8.1.3.
9，“太忙”服务器太忙，无法接受新连接。仅在响应DCCP请求时发送。见第8.1.3节。
10, "Bad Init Cookie" The Init Cookie echoed by the client was incorrect or missing. See Section 8.1.4.
10，“错误的初始化Cookie”客户端回显的初始化Cookie不正确或丢失。见第8.1.4节。
11, "Aggression Penalty" This endpoint has detected congestion control-related misbehavior on the part of the other endpoint. See Section 12.3.
11，“攻击惩罚”此端点已检测到另一个端点上与拥塞控制相关的不当行为。见第12.3节。
12-127, Reserved Receivers should treat these codes as they do Reset Code 0, "Unspecified".
12-127，保留接收器应将这些代码视为重置代码0，“未指定”。
128-255, CCID-specific codes Semantics depend on the connection's CCIDs. See Section 10.3. Receivers should treat unknown CCID-specific Reset Codes as they do Reset Code 0, "Unspecified".
128-255，特定于CCID的代码语义取决于连接的CCID。见第10.3节。接收器应将未知的CCID特定重置代码视为重置代码0，“未指定”。
The following table summarizes this information.
下表总结了这些信息。
Reset
Code Name Data 1 Data 2 & 3
----- ---- ------ ----------
0 Unspecified 0 0
1 Closed 0 0
2 Aborted 0 0
3 No Connection 0 0
4 Packet Error pkt type 0
5 Option Error option # option data
6 Mandatory Error option # option data
7 Connection Refused 0 0
8 Bad Service Code 0 0
9 Too Busy 0 0
10 Bad Init Cookie 0 0
11 Aggression Penalty 0 0
12-127 Reserved
128-255 CCID-specific codes
Reset
Code Name Data 1 Data 2 & 3
----- ---- ------ ----------
0 Unspecified 0 0
1 Closed 0 0
2 Aborted 0 0
3 No Connection 0 0
4 Packet Error pkt type 0
5 Option Error option # option data
6 Mandatory Error option # option data
7 Connection Refused 0 0
8 Bad Service Code 0 0
9 Too Busy 0 0
10 Bad Init Cookie 0 0
11 Aggression Penalty 0 0
12-127 Reserved
128-255 CCID-specific codes
Table 2: DCCP Reset Codes
表2:DCCP重置代码
Options on DCCP-Reset packets are processed before the connection is shut down. This means that certain combinations of options, particularly involving Mandatory, may cause an endpoint to respond to a valid DCCP-Reset with another DCCP-Reset. This cannot lead to a reset storm; since the first endpoint has already reset the connection, the second DCCP-Reset will be ignored.
DCCP重置数据包上的选项在连接关闭之前处理。这意味着某些选项组合，特别是涉及强制选项的选项组合，可能会导致端点使用另一个DCCP重置来响应有效的DCCP重置。这不会导致重置风暴；由于第一个端点已重置连接，因此将忽略第二个DCCP重置。
DCCP-Sync packets help DCCP endpoints recover synchronization after bursts of loss and recover from half-open connections. Each valid received DCCP-Sync immediately elicits a DCCP-SyncAck. Both packet types MUST use 48-bit sequence numbers (X=1).
DCCP同步数据包帮助DCCP端点在突发丢失后恢复同步，并从半开放连接中恢复。每个有效接收到的DCCP同步都会立即引发DCCP同步。两种数据包类型都必须使用48位序列号（X=1）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header with X=1 (16 bytes) /
/ with Type=8 (DCCP-Sync) or 9 (DCCP-SyncAck) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data Area (Ignored) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header with X=1 (16 bytes) /
/ with Type=8 (DCCP-Sync) or 9 (DCCP-SyncAck) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Acknowledgement Number Subheader (8 bytes) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Options and Padding /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
/ Application Data Area (Ignored) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Acknowledgement Number field has special semantics for DCCP-Sync and DCCP-SyncAck packets. First, the packet corresponding to a DCCP-Sync's Acknowledgement Number need not have been acknowledgeable. Thus, receivers MUST NOT assume that a packet was processed simply because it appears in the Acknowledgement Number field of a DCCP-Sync packet. This differs from all other packet types, where the Acknowledgement Number by definition corresponds to an acknowledgeable packet. Second, the Acknowledgement Number on any DCCP-SyncAck packet MUST correspond to the Sequence Number on an acknowledgeable DCCP-Sync packet. In the presence of reordering, this might not equal GSR.
The Acknowledgement Number field has special semantics for DCCP-Sync and DCCP-SyncAck packets. First, the packet corresponding to a DCCP-Sync's Acknowledgement Number need not have been acknowledgeable. Thus, receivers MUST NOT assume that a packet was processed simply because it appears in the Acknowledgement Number field of a DCCP-Sync packet. This differs from all other packet types, where the Acknowledgement Number by definition corresponds to an acknowledgeable packet. Second, the Acknowledgement Number on any DCCP-SyncAck packet MUST correspond to the Sequence Number on an acknowledgeable DCCP-Sync packet. In the presence of reordering, this might not equal GSR.translate error, please retry
As with DCCP-Ack packets, DCCP-Sync and DCCP-SyncAck packets MAY have non-zero-length application data areas, whose contents receivers MUST ignore. Padded DCCP-Sync packets may be useful when performing Path MTU discovery; see Section 14.
与DCCP Ack数据包一样，DCCP Sync和DCCP SyncAck数据包可能具有非零长度的应用程序数据区，其内容接收器必须忽略。填充DCCP同步数据包在执行路径MTU发现时可能有用；见第14节。
Any DCCP packet may contain options, which occupy space at the end of the DCCP header. Each option is a multiple of 8 bits in length. Individual options are not padded to multiples of 32 bits, and any option may begin on any byte boundary. However, the combination of all options MUST add up to a multiple of 32 bits; Padding options MUST be added as necessary to fill out option space to a word boundary. Any options present are included in the header checksum.
任何DCCP数据包都可能包含选项，这些选项占用DCCP报头末尾的空间。每个选项的长度为8位的倍数。单个选项不会填充到32位的倍数，任何选项都可以从任何字节边界开始。然而，所有选项的组合必须加起来是32位的倍数；必须根据需要添加填充选项以填充单词边界的选项空间。存在的任何选项都包含在标题校验和中。
The first byte of an option is the option type. Options with types 0 through 31 are single-byte options. Other options are followed by a byte indicating the option's length. This length value includes the two bytes of option-type and option-length as well as any option-data bytes; it must therefore be greater than or equal to two.
选项的第一个字节是选项类型。类型为0到31的选项是单字节选项。其他选项后面跟着一个字节，表示该选项的长度。该长度值包括选项类型和选项长度的两个字节以及任何选项数据字节；因此，它必须大于或等于2。
Options MUST be processed sequentially, starting with the first option in the packet header. Options with unknown types MUST be
选项必须按顺序处理，从数据包头中的第一个选项开始。具有未知类型的选项必须为空
ignored. Also, options with nonsensical lengths (length byte less than two or more than the remaining space in the options portion of the header) MUST be ignored, and any option space following an option with nonsensical length MUST likewise be ignored. Unless otherwise specified, multiple occurrences of the same option MUST be processed independently; for some options, this will mean in practice that the last valid occurrence of an option takes precedence.
忽略。此外，必须忽略长度不合理的选项（长度字节小于标题选项部分剩余空间的两个或更多），并且必须同样忽略长度不合理的选项后面的任何选项空间。除非另有规定，同一选项的多次出现必须单独处理；对于某些选项，这意味着在实践中，选项的最后一次有效出现优先。
The following options are currently defined:
当前定义了以下选项：
Option DCCP- Section
Type Length Meaning Data? Reference
---- ------ ------- ----- ---------
0 1 Padding Y 5.8.1
1 1 Mandatory N 5.8.2
2 1 Slow Receiver Y 11.6
3-31 1 Reserved
32 variable Change L N 6.1
33 variable Confirm L N 6.2
34 variable Change R N 6.1
35 variable Confirm R N 6.2
36 variable Init Cookie N 8.1.4
37 3-8 NDP Count Y 7.7
38 variable Ack Vector [Nonce 0] N 11.4
39 variable Ack Vector [Nonce 1] N 11.4
40 variable Data Dropped N 11.7
41 6 Timestamp Y 13.1
42 6/8/10 Timestamp Echo Y 13.3
43 4/6 Elapsed Time N 13.2
44 6 Data Checksum Y 9.3
45-127 variable Reserved
128-255 variable CCID-specific options - 10.3
Option DCCP- Section
Type Length Meaning Data? Reference
---- ------ ------- ----- ---------
0 1 Padding Y 5.8.1
1 1 Mandatory N 5.8.2
2 1 Slow Receiver Y 11.6
3-31 1 Reserved
32 variable Change L N 6.1
33 variable Confirm L N 6.2
34 variable Change R N 6.1
35 variable Confirm R N 6.2
36 variable Init Cookie N 8.1.4
37 3-8 NDP Count Y 7.7
38 variable Ack Vector [Nonce 0] N 11.4
39 variable Ack Vector [Nonce 1] N 11.4
40 variable Data Dropped N 11.7
41 6 Timestamp Y 13.1
42 6/8/10 Timestamp Echo Y 13.3
43 4/6 Elapsed Time N 13.2
44 6 Data Checksum Y 9.3
45-127 variable Reserved
128-255 variable CCID-specific options - 10.3
Table 3: DCCP Options
表3:DCCP选项
Not all options are suitable for all packet types. For example, since the Ack Vector option is interpreted relative to the Acknowledgement Number, it isn't suitable on DCCP-Request and DCCP-Data packets, which have no Acknowledgement Number. If an option occurs on an unexpected packet type, it MUST generally be ignored; any such restrictions are mentioned in each option's description. The table summarizes the most common restriction: when the DCCP-Data? column value is N, the corresponding option MUST be ignored when received on a DCCP-Data packet. (Section 7.5.5 describes why such options are ignored as opposed to, say, causing a reset.)
并非所有选项都适用于所有数据包类型。例如，由于Ack Vector选项是相对于确认号来解释的，因此它不适用于没有确认号的DCCP请求和DCCP数据包。如果选项出现在意外的数据包类型上，通常必须忽略它；每个选项的说明中都提到了任何此类限制。该表总结了最常见的限制：何时使用DCCP数据？列值为N，在DCCP数据包上接收时必须忽略相应的选项。（第7.5.5节描述了为什么忽略这些选项，而不是导致重置。）
Options with invalid values MUST be ignored unless otherwise specified. For example, any Data Checksum option with option length
除非另有规定，否则必须忽略具有无效值的选项。例如，任何具有选项长度的数据校验和选项
4 MUST be ignored, since all valid Data Checksum options have option length 6.
4必须忽略，因为所有有效的数据校验和选项都具有选项长度6。
This section describes two generic options, Padding and Mandatory. Other options are described later.
本节介绍两个通用选项，填充和强制。其他选项将在后面描述。
+--------+
|00000000|
+--------+
Type=0
+--------+
|00000000|
+--------+
Type=0
Padding is a single-byte "no-operation" option used to pad between or after options. If the length of a packet's other options is not a multiple of 32 bits, then Padding options are REQUIRED to pad out the options area to the length implied by Data Offset. Padding may also be used between options; for example, to align the beginning of a subsequent option on a 32-bit boundary. There is no guarantee that senders will use this option, so receivers must be prepared to process options even if they do not begin on a word boundary.
填充是一个单字节“无操作”选项，用于在选项之间或之后填充。如果数据包的其他选项的长度不是32位的倍数，则需要填充选项将选项区域填充到数据偏移量所暗示的长度。选项之间也可以使用填充；例如，在32位边界上对齐后续选项的开头。无法保证发送方将使用此选项，因此接收方必须准备好处理选项，即使这些选项不是从单词边界开始的。
+--------+
|00000001|
+--------+
Type=1
+--------+
|00000001|
+--------+
Type=1
Mandatory is a single-byte option that marks the immediately following option as mandatory. Say that the immediately following option is O. Then the Mandatory option has no effect if the receiving DCCP endpoint understands and processes O. If the endpoint does not understand or process O, however, then it MUST reset the connection using Reset Code 6, "Mandatory Failure". For instance, the endpoint would reset the connection if it did not understand O's type; if it understood O's type, but not O's data; if O's data was invalid for O's type; if O was a feature negotiation option, and the endpoint did not understand the enclosed feature number; or if the endpoint understood O, but chose not to perform the action O implies. This list is not exhaustive and, in particular, individual option specifications may describe additional situations in which the endpoint should reset the connection and situations in which it should not.
强制是一个单字节选项，它将紧跟其后的选项标记为强制。假设紧跟其后的选项为O。如果接收DCCP端点理解并处理O，则强制选项无效。但是，如果端点不理解或处理O，则必须使用重置代码6“强制故障”重置连接。例如，如果端点不理解O的类型，它将重置连接；如果它了解O的类型，但不了解O的数据；如果O的数据对于O的类型无效；如果O是一个特征协商选项，且端点不理解所附特征编号；或者如果端点理解O，但选择不执行O所暗示的操作。此列表并非详尽无遗，特别是，单个选项规范可能会描述端点应重置连接的其他情况以及不应重置连接的情况。
Mandatory options MUST NOT be sent on DCCP-Data packets, and any Mandatory options received on DCCP-Data packets MUST be ignored.
不得在DCCP数据包上发送强制选项，并且必须忽略在DCCP数据包上接收的任何强制选项。
The connection is in error and should be reset with Reset Code 5, "Option Error", if option O is absent (Mandatory was the last byte of the option list), or if option O equals Mandatory. However, the combination "Mandatory Padding" is valid, and MUST behave like two bytes of Padding.
连接出错，如果选项O不存在（强制是选项列表的最后一个字节），或者如果选项O等于强制，则应使用重置代码5“选项错误”重置连接。但是，组合“强制填充”是有效的，并且其行为必须类似于两个字节的填充。
Section 6.6.9 describes the behavior of Mandatory feature negotiation options in more detail.
第6.6.9节更详细地描述了强制性功能协商选项的行为。
Four DCCP options, Change L, Confirm L, Change R, and Confirm R, are used to negotiate feature values. Change options initiate a negotiation; Confirm options complete that negotiation. The "L" options are sent by the feature location, and the "R" options are sent by the feature remote. Change options are retransmitted to ensure reliability.
四个DCCP选项更改L、确认L、更改R和确认R用于协商特征值。改变选择发起谈判；确认选项完成该谈判。“L”选项由功能部件位置发送，“R”选项由功能部件远程发送。更改选项被重新传输以确保可靠性。
All these options have the same format. The first byte of option data is the feature number, and the second and subsequent data bytes hold one or more feature values. The exact format of the feature value area depends on the feature type; see Section 6.3.
所有这些选项都具有相同的格式。选项数据的第一个字节是特征编号，第二个和后续数据字节包含一个或多个特征值。特征值区域的确切格式取决于特征类型；见第6.3节。
+--------+--------+--------+--------+--------
| Type | Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
+--------+--------+--------+--------+--------
| Type | Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Together, the feature number and the option type ("L" or "R") uniquely identify the feature to which an option applies. The exact format of the Value(s) area depends on the feature number.
特征编号和选项类型（“L”或“R”）共同唯一地标识选项适用的特征。值区域的确切格式取决于特征编号。
Feature negotiation options MUST NOT be sent on DCCP-Data packets, and any feature negotiation options received on DCCP-Data packets MUST be ignored.
不得在DCCP数据包上发送功能协商选项，并且必须忽略在DCCP数据包上接收的任何功能协商选项。
Change L and Change R options initiate feature negotiation. The option to use depends on the relevant feature's location: To start a negotiation for feature F/A, DCCP A will send a Change L option; to start a negotiation for F/B, it will send a Change R option. Change options are retransmitted until some response is received. They contain at least one Value, and thus have a length of at least 4.
更改L和更改R选项启动功能协商。使用的选项取决于相关功能的位置：要开始功能F/a的协商，DCCP a将发送更改L选项；要开始F/B的协商，它将发送一个更改R选项。更改选项将重新传输，直到收到一些响应。它们至少包含一个值，因此长度至少为4。
+--------+--------+--------+--------+--------
Change L: |00100000| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=32
+--------+--------+--------+--------+--------
Change L: |00100000| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=32
+--------+--------+--------+--------+--------
Change R: |00100010| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=34
+--------+--------+--------+--------+--------
Change R: |00100010| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=34
Confirm L and Confirm R options complete feature negotiation and are sent in response to Change R and Change L options, respectively. Confirm options MUST NOT be generated except in response to Change options. Confirm options need not be retransmitted, since Change options are retransmitted as necessary. The first byte of the Confirm option contains the feature number from the corresponding Change. Following this is the selected Value, and then possibly the sender's preference list.
Confirm L和Confirm R选项完成功能协商，并分别响应Change R和Change L选项发送。除非响应更改选项，否则不得生成确认选项。确认选项不需要重新传输，因为更改选项会根据需要重新传输。确认选项的第一个字节包含相应更改的特征编号。以下是所选值，然后可能是发件人的首选项列表。
+--------+--------+--------+--------+--------
Confirm L: |00100001| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=33
+--------+--------+--------+--------+--------
Confirm L: |00100001| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=33
+--------+--------+--------+--------+--------
Confirm R: |00100011| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=35
+--------+--------+--------+--------+--------
Confirm R: |00100011| Length |Feature#| Value(s) ...
+--------+--------+--------+--------+--------
Type=35
If an endpoint receives an invalid Change option -- with an unknown feature number, or an invalid value -- it will respond with an empty Confirm option containing the problematic feature number, but no value. Such options have length 3.
如果端点接收到无效的更改选项（具有未知的功能编号或无效的值），它将使用包含有问题的功能编号但没有值的空确认选项进行响应。这些选项的长度为3。
Reconciliation rules determine how the two sets of preferences for a given feature are resolved into a unique result. The reconciliation rule depends only on the feature number. Each reconciliation rule must have the property that the result is uniquely determined given the contents of Change options sent by the two endpoints.
协调规则确定如何将给定功能的两组首选项解析为唯一结果。对账规则仅取决于特征编号。每个对账规则必须具有这样一个属性：给定两个端点发送的更改选项的内容，结果是唯一确定的。
All current DCCP features use one of two reconciliation rules: server-priority ("SP") and non-negotiable ("NN").
所有当前DCCP功能都使用两种对账规则之一：服务器优先级（“SP”）和不可协商（“NN”）。
The feature value is a fixed-length byte string (length determined by the feature number). Each Change option contains a list of values ordered by preference, with the most preferred value coming first. Each Confirm option contains the confirmed value, followed by the confirmer's preference list. Thus, the feature's current value will generally appear twice in Confirm options' data, once as the current value and once in the confirmer's preference list.
特征值是一个固定长度的字节字符串（长度由特征编号确定）。每个更改选项都包含一个按首选项排序的值列表，首选值排在第一位。每个确认选项都包含确认值，后面是确认者的首选项列表。因此，特征的当前值通常会在确认选项的数据中出现两次，一次作为当前值，一次出现在确认者的首选项列表中。
To reconcile the preference lists, select the first entry in the server's list that also occurs in the client's list. If there is no shared entry, the feature's value MUST NOT change, and the Confirm option will confirm the feature's previous value (unless the Change option was Mandatory; see Section 6.6.9).
要协调首选项列表，请选择服务器列表中也出现在客户端列表中的第一个条目。如果没有共享条目，功能的值不得更改，确认选项将确认功能的先前值（除非更改选项是强制性的；请参见第6.6.9节）。
The feature value is a byte string. Each option contains exactly one feature value. The feature location signals a new value by sending a Change L option. The feature remote MUST accept any valid value, responding with a Confirm R option containing the new value, and it MUST send empty Confirm R options in response to invalid values (unless the Change L option was Mandatory; see Section 6.6.9). Change R and Confirm L options MUST NOT be sent for non-negotiable features; see Section 6.6.8. Non-negotiable features use the feature negotiation mechanism to achieve reliability.
特征值是一个字节字符串。每个选项仅包含一个特征值。特征位置通过发送Change L（更改L）选项发出新值的信号。远程功能必须接受任何有效值，并使用包含新值的确认R选项进行响应，并且必须发送空的确认R选项以响应无效值（除非更改L选项是强制性的；请参见第6.6.9节）。更改R和确认L选项不得发送给不可协商的功能；见第6.6.8节。不可协商的特征使用特征协商机制来实现可靠性。
This document defines the following feature numbers.
本文档定义了以下特征编号。
Rec'n Initial Section
Number Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
0 Reserved
1 Congestion Control ID (CCID) SP 2 Y 10
2 Allow Short Seqnos SP 0 Y 7.6.1
3 Sequence Window NN 100 Y 7.5.2
4 ECN Incapable SP 0 N 12.1
5 Ack Ratio NN 2 N 11.3
6 Send Ack Vector SP 0 N 11.5
7 Send NDP Count SP 0 N 7.7.2
8 Minimum Checksum Coverage SP 0 N 9.2.1
9 Check Data Checksum SP 0 N 9.3.1
10-127 Reserved
128-255 CCID-specific features 10.3
Rec'n Initial Section
Number Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
0 Reserved
1 Congestion Control ID (CCID) SP 2 Y 10
2 Allow Short Seqnos SP 0 Y 7.6.1
3 Sequence Window NN 100 Y 7.5.2
4 ECN Incapable SP 0 N 12.1
5 Ack Ratio NN 2 N 11.3
6 Send Ack Vector SP 0 N 11.5
7 Send NDP Count SP 0 N 7.7.2
8 Minimum Checksum Coverage SP 0 N 9.2.1
9 Check Data Checksum SP 0 N 9.3.1
10-127 Reserved
128-255 CCID-specific features 10.3
Table 4: DCCP Feature Numbers
表4:DCCP特征编号
Rec'n Rule The reconciliation rule used for the feature. SP means server-priority, NN means non-negotiable.
Rec'n Rule用于功能的对账规则。SP表示服务器优先级，NN表示不可协商。
Initial Value The initial value for the feature. Every feature has a known initial value.
初始值特征的初始值。每个特征都有一个已知的初始值。
Req'd This column is "Y" if and only if every DCCP implementation MUST understand the feature. If it is "N", then the feature behaves like an extension (see Section 15), and it is safe to respond to Change options for the feature with empty Confirm options. Of course, a CCID might require the feature; a DCCP that implements CCID 2 MUST support Ack Ratio and Send Ack Vector, for example.
如果且仅当每个DCCP实现必须了解该特性时，此列为“Y”。如果为“N”，则功能的行为类似于扩展（请参见第15节），并且可以安全地使用空的确认选项响应功能的更改选项。当然，CCID可能需要该功能；例如，实现CCID 2的DCCP必须支持Ack比率和发送Ack向量。
Here are three example feature negotiations for features located at the server, the first two for the Congestion Control ID feature, the last for the Ack Ratio.
以下是位于服务器上的功能的三个功能协商示例，前两个用于拥塞控制ID功能，最后一个用于Ack比率。
Client Server
------ ------
1. Change R(CCID, 2 3 1) -->
("2 3 1" is client's preference list)
2. <-- Confirm L(CCID, 3, 3 2 1)
(3 is the negotiated value;
"3 2 1" is server's pref list)
* agreement that CCID/Server = 3 *
Client Server
------ ------
1. Change R(CCID, 2 3 1) -->
("2 3 1" is client's preference list)
2. <-- Confirm L(CCID, 3, 3 2 1)
(3 is the negotiated value;
"3 2 1" is server's pref list)
* agreement that CCID/Server = 3 *
1. XXX <-- Change L(CCID, 3 2 1) 2. Retransmission: <-- Change L(CCID, 3 2 1) 3. Confirm R(CCID, 3, 2 3 1) --> * agreement that CCID/Server = 3 *
1. XXX<--变更L（CCID，3 2 1）2。重新传输：<--更改L（CCID，3 2 1）3。确认R（CCID，3，2 3 1）-->*CCID/Server=3的协议*
1. <-- Change L(Ack Ratio, 3)
2. Confirm R(Ack Ratio, 3) -->
* agreement that Ack Ratio/Server = 3 *
1. <-- Change L(Ack Ratio, 3)
2. Confirm R(Ack Ratio, 3) -->
* agreement that Ack Ratio/Server = 3 *
This example shows a simultaneous negotiation.
此示例显示了同时协商。
Client Server
------ ------
1a. Change R(CCID, 2 3 1) -->
b. <-- Change L(CCID, 3 2 1)
2a. <-- Confirm L(CCID, 3, 3 2 1)
b. Confirm R(CCID, 3, 2 3 1) -->
* agreement that CCID/Server = 3 *
Client Server
------ ------
1a. Change R(CCID, 2 3 1) -->
b. <-- Change L(CCID, 3 2 1)
2a. <-- Confirm L(CCID, 3, 3 2 1)
b. Confirm R(CCID, 3, 2 3 1) -->
* agreement that CCID/Server = 3 *
Here are the byte encodings of several Change and Confirm options. Each option is sent by DCCP A.
以下是几个更改和确认选项的字节编码。每个选项都由DCCP A发送。
Change L(CCID, 2 3) = 32,5,1,2,3 DCCP B should change CCID/A's value (feature number 1, a server-priority feature); DCCP A's preferred values are 2 and 3, in that preference order.
更改L（CCID，23）=32,5,1,2,3 DCCP B应更改CCID/A的值（功能编号1，服务器优先级功能）；DCCP A的首选值为2和3，按该首选顺序排列。
Change L(Sequence Window, 1024) = 32,9,3,0,0,0,0,4,0 DCCP B should change Sequence Window/A's value (feature number 3, a non-negotiable feature) to the 6-byte string 0,0,0,0,4,0 (the value 1024).
更改L（序列窗口，1024）=32,9,3,0,0,0,4,0 DCCP B应将序列窗口/A的值（特征编号3，不可协商的特征）更改为6字节字符串0,0,0,0,4,0（值1024）。
Confirm L(CCID, 2, 2 3) = 33,6,1,2,2,3 DCCP A has changed CCID/A's value to 2; its preferred values are 2 and 3, in that preference order.
确认L（CCID，2，23）=33,6,1,2,2,3 DCCP A已将CCID/A的值更改为2；其首选值为2和3，按该首选顺序排列。
Empty Confirm L(126) = 33,3,126 DCCP A doesn't implement feature number 126, or DCCP B's proposed value for feature 126/A was invalid.
空确认L（126）=33,3126 DCCP A未实现功能编号126，或DCCP B建议的功能126/A值无效。
Change R(CCID, 3 2) = 34,5,1,3,2 DCCP B should change CCID/B's value; DCCP A's preferred values are 3 and 2, in that preference order.
更改R（CCID，32）=34,5,1,3,2 DCCP B应更改CCID/B的值；DCCP A的首选值为3和2，按该首选顺序排列。
Confirm R(CCID, 2, 3 2) = 35,6,1,2,3,2 DCCP A has changed CCID/B's value to 2; its preferred values were 3 and 2, in that preference order.
确认R（CCID，2，3 2）=35,6,1,2,3,2 DCCP A已将CCID/B的值更改为2；它的首选值为3和2，按该首选顺序排列。
Confirm R(Sequence Window, 1024) = 35,9,3,0,0,0,0,4,0 DCCP A has changed Sequence Window/B's value to the 6-byte string 0,0,0,0,4,0 (the value 1024).
确认R（序列窗口，1024）=35,9,3,0,0,0,0,4,0 DCCP A已将序列窗口/B的值更改为6字节字符串0,0,0,0,4,0（值1024）。
Empty Confirm R(126) = 35,3,126 DCCP A doesn't implement feature number 126, or DCCP B's proposed value for feature 126/B was invalid.
空确认R（126）=35,3126 DCCP A未实现功能编号126，或DCCP B建议的功能126/B值无效。
A few basic rules govern feature negotiation option exchange.
一些基本规则控制特征协商选项交换。
1. Every non-reordered Change option gets a Confirm option in response.
1. 每个未重新排序的更改选项都会得到一个确认选项作为响应。
2. Change options are retransmitted until a response for the latest Change is received.
2. 更改选项将重新传输，直到收到最新更改的响应。
3. Feature negotiation options are processed in strictly-increasing order by Sequence Number.
3. 特征协商选项按序列号严格递增的顺序处理。
The rest of this section describes the consequences of these rules in more detail.
本节其余部分将更详细地描述这些规则的后果。
Change options are generated when a DCCP endpoint wants to change the value of some feature. Generally, this will happen at the beginning of a connection, although it may happen at any time. We say the endpoint "generates" or "sends" a Change L or Change R option, but of course the option must be attached to a packet. The endpoint may attach the option to a packet it would have generated anyway (such as a DCCP-Request), or it may create a "feature negotiation packet", often a DCCP-Ack or DCCP-Sync, just to carry the option. Feature negotiation packets are controlled by the relevant congestion control mechanism. For example, DCCP A may send a DCCP-Ack or DCCP-Sync for feature negotiation only if the B-to-A CCID would allow sending a DCCP-Ack. In addition, an endpoint SHOULD generate at most one feature negotiation packet per round-trip time.
当DCCP端点想要更改某些功能的值时，将生成更改选项。通常，这会发生在连接开始时，尽管它可能随时发生。我们说端点“生成”或“发送”一个Change L或Change R选项，但当然该选项必须附加到数据包。端点可以将该选项附加到它无论如何都会生成的数据包（例如DCCP请求），或者它可以创建一个“特征协商数据包”，通常是DCCP Ack或DCCP Sync，只是为了携带该选项。特征协商包由相关的拥塞控制机制控制。例如，仅当B-to-A CCID允许发送DCCP Ack时，DCCP A才可以发送用于特征协商的DCCP Ack或DCCP Sync。此外，端点在每次往返时间中最多应生成一个特性协商包。
On receiving a Change L or Change R option, a DCCP endpoint examines the included preference list, reconciles that with its own preference list, calculates the new value, and sends back a Confirm R or Confirm L option, respectively, informing its peer of the new value or that the feature was not understood. Every non-reordered Change option MUST result in a corresponding Confirm option, and any packet including a Confirm option MUST carry an Acknowledgement Number. (Section 6.6.4 describes how Change reordering is detected and handled.) Generated Confirm options may be attached to packets that would have been sent anyway (such as DCCP-Response or DCCP-SyncAck) or to new feature negotiation packets, as described above.
在接收到更改L或更改R选项时，DCCP端点检查包含的首选项列表，将其与自己的首选项列表进行核对，计算新值，并分别发回确认R或确认L选项，通知其对等方新值或未理解功能。每个未重新排序的更改选项都必须产生相应的确认选项，并且包括确认选项的任何数据包都必须带有确认号。（第6.6.4节描述了如何检测和处理更改重新排序。）生成的确认选项可附加到无论如何都会发送的数据包（如DCCP响应或DCCP SyncAck）或新功能协商数据包，如上所述。
The Change-sending endpoint MUST wait to receive a corresponding Confirm option before changing its stored feature value. The Confirm-sending endpoint changes its stored feature value as soon as it sends the Confirm.
在更改其存储的特征值之前，更改发送端点必须等待接收相应的确认选项。确认发送端点在发送确认后立即更改其存储的特征值。
A packet MAY contain more than one feature negotiation option, possibly including two options that refer to the same feature; as usual, the options are processed sequentially.
一个包可以包含多个特征协商选项，可能包括两个引用相同特征的选项；与往常一样，选项是按顺序处理的。
DCCP endpoints exist in one of three states relative to each feature. STABLE is the normal state, where the endpoint knows the feature's value and thinks the other endpoint agrees. An endpoint enters the CHANGING state when it first sends a Change for the feature and returns to STABLE once it receives a corresponding Confirm. The final state, UNSTABLE, indicates that an endpoint in CHANGING state changed its preference list but has not yet transmitted a Change option with the new preference list.
相对于每个特征，DCCP端点处于三种状态之一。稳定是正常状态，端点知道特征值并认为另一个端点同意。端点在第一次发送特性更改时进入更改状态，并在收到相应的确认后返回稳定状态。最终状态为不稳定，表示处于更改状态的端点更改了其首选项列表，但尚未使用新的首选项列表传输更改选项。
Feature state transitions at a feature location are implemented according to this diagram. The diagram ignores sequence number and option validity issues; these are handled explicitly in the pseudocode that follows.
特征位置处的特征状态转换根据此图实现。该图忽略了序列号和选项有效性问题；这些都在后面的伪代码中显式处理。
timeout/
rcv Confirm R app/protocol evt : snd Change L rcv non-ack
: ignore +---------------------------------------+ : snd Change L
+----+ | | +----+
| v | rcv Change R v | v
+------------+ rcv Confirm R : calc new value, +------------+
| | : accept value snd Confirm L | |
| STABLE |<-----------------------------------| CHANGING |
| | rcv empty Confirm R | |
+------------+ : revert to old value +------------+
| ^ | ^
+----+ pref list | | snd
rcv Change R changes | | Change L
: calc new value, snd Confirm L v |
+------------+
+---| |
rcv Confirm/Change R | | UNSTABLE |
: ignore +-->| |
+------------+
timeout/
rcv Confirm R app/protocol evt : snd Change L rcv non-ack
: ignore +---------------------------------------+ : snd Change L
+----+ | | +----+
| v | rcv Change R v | v
+------------+ rcv Confirm R : calc new value, +------------+
| | : accept value snd Confirm L | |
| STABLE |<-----------------------------------| CHANGING |
| | rcv empty Confirm R | |
+------------+ : revert to old value +------------+
| ^ | ^
+----+ pref list | | snd
rcv Change R changes | | Change L
: calc new value, snd Confirm L v |
+------------+
+---| |
rcv Confirm/Change R | | UNSTABLE |
: ignore +-->| |
+------------+
Feature locations SHOULD use the following pseudocode, which corresponds to the state diagram, to react to each feature negotiation option on each valid non-Data packet received. The pseudocode refers to "P.seqno" and "P.ackno", which are properties of the packet; "O.type" and "O.len", which are properties of the option; "FGSR" and "FGSS", which are properties of the connection and handle reordering as described in Section 6.6.4; "F.state", which is the feature's state (STABLE, CHANGING, or UNSTABLE); and "F.value", which is the feature's value.
特征位置应使用以下伪代码（对应于状态图）对接收到的每个有效非数据包上的每个特征协商选项作出反应。伪码是指“P.seqno”和“P.ackno”，它们是分组的属性；“O.type”和“O.len”是期权的属性；“FGSR”和“FGSS”，是第6.6.4节所述连接和手柄重新排序的属性；“F.状态”，即特征的状态（稳定、变化或不稳定）；和“F.value”，即特征值。
First, check for unknown features (Section 6.6.7);
If F is unknown,
If the option was Mandatory, /* Section 6.6.9 */
Reset connection and return
Otherwise, if O.type == Change R,
Send Empty Confirm L on a future packet
First, check for unknown features (Section 6.6.7);
If F is unknown,
If the option was Mandatory, /* Section 6.6.9 */
Reset connection and return
Otherwise, if O.type == Change R,
Send Empty Confirm L on a future packet
Return
回来
Second, check for reordering (Section 6.6.4);
If F.state == UNSTABLE or P.seqno <= FGSR
or (O.type == Confirm R and P.ackno < FGSS),
Ignore option and return
Second, check for reordering (Section 6.6.4);
If F.state == UNSTABLE or P.seqno <= FGSR
or (O.type == Confirm R and P.ackno < FGSS),
Ignore option and return
Third, process Change R options;
If O.type == Change R,
If the option's value is valid, /* Section 6.6.8 */
Calculate new value
Send Confirm L on a future packet
Set F.state := STABLE
Otherwise, if the option was Mandatory,
Reset connection and return
Otherwise,
Send Empty Confirm L on a future packet
/* Remain in existing state. If that's CHANGING, this
endpoint will retransmit its Change L option later. */
Third, process Change R options;
If O.type == Change R,
If the option's value is valid, /* Section 6.6.8 */
Calculate new value
Send Confirm L on a future packet
Set F.state := STABLE
Otherwise, if the option was Mandatory,
Reset connection and return
Otherwise,
Send Empty Confirm L on a future packet
/* Remain in existing state. If that's CHANGING, this
endpoint will retransmit its Change L option later. */
Fourth, process Confirm R options (but only in CHANGING state).
If F.state == CHANGING and O.type == Confirm R,
If O.len > 3, /* nonempty */
If the option's value is valid,
Set F.value := new value
Otherwise,
Reset connection and return
Set F.state := STABLE
Fourth, process Confirm R options (but only in CHANGING state).
If F.state == CHANGING and O.type == Confirm R,
If O.len > 3, /* nonempty */
If the option's value is valid,
Set F.value := new value
Otherwise,
Reset connection and return
Set F.state := STABLE
Versions of this diagram and pseudocode are also used by feature remotes; simply switch the "L"s and "R"s, so that the relevant options are Change R and Confirm L.
此图和伪代码的版本也可由功能遥控器使用；只需切换“L”和“R”，相关选项为更改R和确认L。
Packets containing Change and Confirm options might be lost or delayed by the network. Therefore, Change options are repeatedly transmitted to achieve reliability. We refer to this as "retransmission", although of course there are no packet-level retransmissions in DCCP: a Change option that is sent again will be sent on a new packet with a new sequence number.
包含更改和确认选项的数据包可能会丢失或被网络延迟。因此，更改选项会反复传输以实现可靠性。我们称之为“重传”，尽管在DCCP中当然没有包级重传：再次发送的更改选项将在具有新序列号的新包上发送。
A CHANGING endpoint transmits another Change option once it realizes that it has not heard back from the other endpoint. The new Change option need not contain the same payload as the original; reordering protection will ensure that agreement is reached based on the most recently transmitted option.
一旦一个正在更改的端点意识到它没有从另一个端点收到回音，它就会传输另一个更改选项。新的变更选项不需要包含与原始选项相同的有效载荷；重新排序保护将确保根据最近传输的选项达成协议。
A CHANGING endpoint MUST continue retransmitting Change options until it gets some response or the connection terminates.
正在更改的端点必须继续重新传输更改选项，直到收到响应或连接终止。
Endpoints SHOULD use an exponential-backoff timer to decide when to retransmit Change options. (Packets generated specifically for feature negotiation MUST use such a timer.) The timer interval is initially set to not less than one round-trip time, and should back
端点应该使用指数退避计时器来决定何时重新传输更改选项。（专门为功能协商生成的数据包必须使用此类计时器。）计时器间隔最初设置为不小于一个往返时间，并应返回
off to not less than 64 seconds. The backoff protects against delayed agreement due to the reordering protection algorithms described in the next section. Again, endpoints may piggyback Change options on packets they would have sent anyway or create new packets to carry the options. Any new packets are controlled by the relevant congestion-control mechanism.
关闭至不少于64秒。退避可以防止由于下一节中描述的重新排序保护算法而导致协议延迟。同样，端点可能会改变他们本来应该发送的数据包上的选项，或者创建新的数据包来携带这些选项。任何新数据包都由相关的拥塞控制机制控制。
Confirm options are never retransmitted, but the Confirm-sending endpoint MUST generate a Confirm option after every non-reordered Change.
确认选项永远不会重新传输，但确认发送端点必须在每次未重新排序的更改后生成确认选项。
Reordering might cause packets containing Change and Confirm options to arrive in an unexpected order. Endpoints MUST ignore feature negotiation options that do not arrive in strictly-increasing order by Sequence Number. The rest of this section presents two algorithms that fulfill this requirement.
重新排序可能会导致包含更改和确认选项的数据包以意外顺序到达。端点必须忽略未按序列号严格递增的顺序到达的功能协商选项。本节的其余部分介绍了满足此要求的两种算法。
The first algorithm introduces two sequence number variables that each endpoint maintains for the connection.
第一种算法引入两个序列号变量，每个端点为连接维护这两个序列号变量。
FGSR Feature Greatest Sequence Number Received: The greatest sequence number received, considering only valid packets that contained one or more feature negotiation options (Change and/or Confirm). This value is initialized to ISR - 1.
接收到的FGSR功能最大序列号：接收到的最大序列号，仅考虑包含一个或多个功能协商选项（更改和/或确认）的有效数据包。此值初始化为ISR-1。
FGSS Feature Greatest Sequence Number Sent: The greatest sequence number sent, considering only packets that contained one or more new Change options. A Change option is new if and only if it was generated during a transition from the STABLE or UNSTABLE state to the CHANGING state; Change options generated within the CHANGING state are retransmissions and MUST have exactly the same contents as previously transmitted options, allowing tolerance for reordering. FGSS is initialized to ISS.
FGSS功能发送的最大序列号：发送的最大序列号，仅考虑包含一个或多个新更改选项的数据包。当且仅当变更选项是在从稳定或不稳定状态过渡到变化状态期间生成时，变更选项才是新的；在更改状态中生成的更改选项是重新传输的，并且必须具有与先前传输的选项完全相同的内容，允许重新排序。FGSS初始化为ISS。
Each endpoint checks two conditions on sequence numbers to decide whether to process received feature negotiation options.
每个端点检查序列号上的两个条件，以决定是否处理接收到的特征协商选项。
1. If a packet's Sequence Number is less than or equal to FGSR, then its Change options MUST be ignored.
1. 如果数据包的序列号小于或等于FGSR，则必须忽略其更改选项。
2. If a packet's Sequence Number is less than or equal to FGSR, if it has no Acknowledgement Number, OR if its Acknowledgement Number is less than FGSS, then its Confirm options MUST be ignored.
2. 如果数据包的序列号小于或等于FGSR，如果它没有确认号，或者如果它的确认号小于FGSS，那么它的确认选项必须被忽略。
Alternatively, an endpoint MAY maintain separate FGSR and FGSS values for every feature. FGSR(F/X) would equal the greatest sequence number received, considering only packets that contained Change or Confirm options applying to feature F/X; FGSS(F/X) would be defined similarly. This algorithm requires more state, but is slightly more forgiving to multiple overlapped feature negotiations. Either algorithm MAY be used; the first algorithm, with connection-wide FGSR and FGSS variables, is RECOMMENDED.
或者，端点可以为每个特征保持单独的FGSR和FGSS值。FGSR（F/X）将等于接收到的最大序列号，仅考虑包含应用于特征F/X的变更或确认选项的数据包；FGSS（F/X）的定义类似。该算法需要更多的状态，但对多个重叠的特征协商稍微宽容一些。两种算法均可使用；建议使用第一种算法，使用连接范围宽的FGSR和FGSS变量。
One consequence of these rules is that a CHANGING endpoint will ignore any Confirm option that does not acknowledge the latest Change option sent. This ensures that agreement, once achieved, used the most recent available information about the endpoints' preferences.
这些规则的一个结果是，正在更改的端点将忽略任何不确认发送的最新更改选项的确认选项。这确保了一旦达成一致，就可以使用有关端点首选项的最新可用信息。
Endpoints are allowed to change their preference lists at any time. However, an endpoint that changes its preference list while in the CHANGING state MUST transition to the UNSTABLE state. It will transition back to CHANGING once it has transmitted a Change option with the new preference list. This ensures that agreement is based on active preference lists. Without the UNSTABLE state, simultaneous negotiation -- where the endpoints began independent negotiations for the same feature at the same time -- might lead to the negotiation's terminating with the endpoints thinking the feature had different values.
允许端点随时更改其首选项列表。但是，在处于更改状态时更改其首选项列表的端点必须转换为不稳定状态。一旦传输了带有新首选项列表的更改选项，它将转换回更改。这确保协议基于活动的首选项列表。如果没有不稳定状态，同时协商（端点同时开始对同一功能进行独立协商）可能导致协商终止，端点认为该功能具有不同的值。
The two endpoints might simultaneously open negotiation for the same feature, after which an endpoint in the CHANGING state will receive a Change option for the same feature. Such received Change options can act as responses to the original Change options. The CHANGING endpoint MUST examine the received Change's preference list, reconcile that with its own preference list (as expressed in its generated Change options), and generate the corresponding Confirm option. It can then transition to the STABLE state.
两个端点可能同时打开同一功能的协商，之后处于更改状态的端点将收到同一功能的更改选项。这些收到的更改选项可以作为对原始更改选项的响应。更改端点必须检查接收到的更改的首选项列表，将其与自己的首选项列表（在其生成的更改选项中表示）协调，并生成相应的确认选项。然后它可以过渡到稳定状态。
Endpoints may receive Change options referring to feature numbers they do not understand -- for instance, when an extended DCCP converses with a non-extended DCCP. Endpoints MUST respond to unknown Change options with Empty Confirm options (that is, Confirm options containing no data), which inform the CHANGING endpoint that the feature was not understood. However, if the Change option was Mandatory, the connection MUST be reset; see Section 6.6.9.
端点可能会收到涉及他们不理解的功能部件编号的更改选项——例如，当扩展DCCP与非扩展DCCP对话时。端点必须使用空的确认选项（即，不包含数据的确认选项）响应未知的更改选项，这会通知正在更改的端点未理解该功能。但是，如果更改选项是强制性的，则必须重置连接；见第6.6.9节。
On receiving an empty Confirm option for some feature, the CHANGING endpoint MUST transition back to the STABLE state, leaving the feature's value unchanged. Section 15 suggests that the default value for any extension feature correspond to "extension not available".
在接收到某个功能的空确认选项时，更改的端点必须转换回稳定状态，保持该功能的值不变。第15节建议，任何扩展特性的默认值对应于“扩展不可用”。
Some features are required to be understood by all DCCPs (see Section 6.4). The CHANGING endpoint SHOULD reset the connection (with Reset Code 5, "Option Error") if it receives an empty Confirm option for such a feature.
所有DCCP都需要了解一些特性（见第6.4节）。如果更改的端点收到此类功能的空确认选项，则应重置连接（重置代码为5，“选项错误”）。
Since Confirm options are generated only in response to Change options, an endpoint should never receive a Confirm option referring to a feature number it does not understand. Nevertheless, endpoints MUST ignore any such options they receive.
由于确认选项仅为响应更改选项而生成，因此端点不应收到引用其不了解的特征编号的确认选项。然而，端点必须忽略它们收到的任何此类选项。
A DCCP endpoint might receive a Change or Confirm option for a known feature that lists one or more values that it does not understand. Some, but not all, such options are invalid, depending on the relevant reconciliation rule (Section 6.3). For instance:
DCCP端点可能会收到已知功能的更改或确认选项，该选项列出了一个或多个它不理解的值。根据相关对账规则（第6.3节），部分但并非全部此类选项无效。例如：
o All features have length limitations, and options with invalid lengths are invalid. For example, the Ack Ratio feature takes 16-bit values, so valid "Confirm R(Ack Ratio)" options have option length 5.
o 所有功能都有长度限制，长度无效的选项无效。例如，确认比率功能采用16位值，因此有效的“确认R（确认比率）”选项具有选项长度5。
o Some non-negotiable features have value limitations. The Ack Ratio feature takes two-byte, non-zero integer values, so a "Change L(Ack Ratio, 0)" option is never valid. Note that server-priority features do not have value limitations, since unknown values are handled as a matter of course.
o 一些不可协商的特性具有价值限制。确认比率功能采用两个字节的非零整数值，因此“更改L（确认比率，0）”选项永远无效。请注意，服务器优先级功能没有值限制，因为未知值是理所当然地处理的。
o Any Confirm option that selects the wrong value, based on the two preference lists and the relevant reconciliation rule, is invalid.
o 任何基于两个首选项列表和相关对账规则选择错误值的确认选项均无效。
However, unexpected Confirm options -- that refer to unknown feature numbers, or that don't appear to be part of a current negotiation -- are not invalid, although they are ignored by the receiver.
但是，意外的确认选项（指未知的特征号，或似乎不属于当前协商的一部分）并非无效，尽管接收者会忽略它们。
An endpoint receiving an invalid Change option MUST respond with the corresponding empty Confirm option. An endpoint receiving an invalid Confirm option MUST reset the connection, with Reset Code 5, "Option Error".
接收无效更改选项的端点必须使用相应的空确认选项进行响应。接收无效确认选项的端点必须重置连接，重置代码为5，“选项错误”。
Change options may be preceded by Mandatory options (Section 5.8.2). Mandatory Change options are processed like normal Change options except that the following failure cases will cause the receiver to reset the connection with Reset Code 6, "Mandatory Failure", rather than send a Confirm option. The connection MUST be reset if:
变更选项之前可能有强制性选项（第5.8.2节）。强制更改选项的处理与正常更改选项类似，但以下故障情况将导致接收器使用重置代码6“强制故障”重置连接，而不是发送确认选项。在以下情况下，必须重置连接：
o the Change option's feature number was not understood;
o 变更选项的特征编号不清楚；
o the Change option's value was invalid, and the receiver would normally have sent an empty Confirm option in response; or
o 更改选项的值无效，接收方通常会发送一个空的确认选项作为响应；或
o for server-priority features, there was no shared entry in the two endpoints' preference lists.
o 对于服务器优先级功能，两个端点的首选项列表中没有共享项。
Other failure cases do not cause connection reset; in particular, reordering protection may cause a Mandatory Change option to be ignored without resetting the connection.
其他故障情况不会导致连接复位；特别是，重新排序保护可能会导致在不重置连接的情况下忽略强制更改选项。
Confirm options behave identically and have the same reset conditions whether or not they are Mandatory.
确认选项的行为相同，且具有相同的重置条件，无论它们是否为强制性选项。
DCCP uses sequence numbers to arrange packets into sequence, to detect losses and network duplicates, and to protect against attackers, half-open connections, and the delivery of very old packets. Every packet carries a Sequence Number; most packet types carry an Acknowledgement Number as well.
DCCP使用序列号将数据包按顺序排列，以检测丢失和网络重复，并防止攻击者、半开放连接和非常旧数据包的传递。每个包携带一个序列号；大多数数据包类型也带有一个确认号。
DCCP sequence numbers are packet based. That is, Sequence Numbers generated by each endpoint increase by one, modulo 2^48, per packet. Even DCCP-Ack and DCCP-Sync packets, and other packets that don't carry user data, increment the Sequence Number. Since DCCP is an unreliable protocol, there are no true retransmissions, but effective retransmissions, such as retransmissions of DCCP-Request packets, also increment the Sequence Number. This lets DCCP implementations
DCCP序列号基于数据包。也就是说，每个端点生成的序列号每包增加1，模2^48。即使是DCCP Ack和DCCP Sync数据包，以及其他不携带用户数据的数据包，也会增加序列号。由于DCCP是一种不可靠的协议，因此不存在真正的重传，但有效的重传（如DCCP请求数据包的重传）也会增加序列号。这让DCCP实现变得更加简单
detect network duplication, retransmissions, and acknowledgement loss; it is a significant departure from TCP practice.
检测网络复制、重传和确认丢失；这是对TCP实践的重大背离。
DCCP endpoints maintain a set of sequence number variables for each connection.
DCCP端点为每个连接维护一组序列号变量。
ISS The Initial Sequence Number Sent by this endpoint. This equals the Sequence Number of the first DCCP-Request or DCCP-Response sent.
ISS此端点发送的初始序列号。这等于发送的第一个DCCP请求或DCCP响应的序列号。
ISR The Initial Sequence Number Received from the other endpoint. This equals the Sequence Number of the first DCCP-Request or DCCP-Response received.
ISR从另一个端点接收的初始序列号。这等于接收到的第一个DCCP请求或DCCP响应的序列号。
GSS The Greatest Sequence Number Sent by this endpoint. Here, and elsewhere, "greatest" is measured in circular sequence space.
GSS此端点发送的最大序列号。在这里和其他地方，“最大”是在循环序列空间中度量的。
GSR The Greatest Sequence Number Received from the other endpoint on an acknowledgeable packet. (Section 7.4 defines this term.)
GSR可确认数据包上从另一个端点接收的最大序列号。（第7.4节定义了该术语。）
GAR The Greatest Acknowledgement Number Received from the other endpoint on an acknowledgeable packet that was not a DCCP-Sync.
GAR在非DCCP同步的可确认数据包上从另一个端点接收的最大确认号。
Some other variables are derived from these primitives.
其他一些变量是从这些原语派生的。
SWL and SWH (Sequence Number Window Low and High) The extremes of the validity window for received packets' Sequence Numbers.
SWL和SWH（序列号窗口低和高）接收数据包序列号的有效性窗口的极值。
AWL and AWH (Acknowledgement Number Window Low and High) The extremes of the validity window for received packets' Acknowledgement Numbers.
AWL和AWH（确认号码窗口低和高）接收数据包的确认号码的有效性窗口的极端值。
The endpoints' initial sequence numbers are set by the first DCCP-Request and DCCP-Response packets sent. Initial sequence numbers MUST be chosen to avoid two problems:
端点的初始序列号由发送的第一个DCCP请求和DCCP响应数据包设置。必须选择初始序列号以避免两个问题：
o delivery of old packets, where packets lingering in the network from an old connection are delivered to a new connection with the same addresses and port numbers; and
o 旧数据包的交付，其中从旧连接到网络中滞留的数据包被交付到具有相同地址和端口号的新连接；和
o sequence number attacks, where an attacker can guess the sequence numbers that a future connection would use [M85].
o 序列号攻击，攻击者可以猜测未来连接将使用的序列号[M85]。
These problems are the same as those faced by TCP, and DCCP implementations SHOULD use TCP's strategies to avoid them [RFC793, RFC1948]. The rest of this section explains these strategies in more detail.
这些问题与TCP面临的问题相同，DCCP实现应该使用TCP的策略来避免这些问题[RFC793，RFC1948]。本节其余部分将更详细地解释这些策略。
To address the first problem, an implementation MUST ensure that the initial sequence number for a given <source address, source port, destination address, destination port> 4-tuple doesn't overlap with recent sequence numbers on previous connections with the same 4-tuple. ("Recent" means sent within 2 maximum segment lifetimes, or 4 minutes.) The implementation MUST additionally ensure that the lower 24 bits of the initial sequence number don't overlap with the lower 24 bits of recent sequence numbers (unless the implementation plans to avoid short sequence numbers; see Section 7.6). An implementation that has state for a recent connection with the same 4-tuple can pick a good initial sequence number explicitly. Otherwise, it could tie initial sequence number selection to some clock, such as the 4-microsecond clock used by TCP [RFC793]. Two separate clocks may be required, one for the upper 24 bits and one for the lower 24 bits.
要解决第一个问题，实现必须确保给定的<source address，source port，destination address，destination port>4元组的初始序列号不会与具有相同4元组的以前连接上的最近序列号重叠。（“最近”是指在2个最长的段生存期内或4分钟内发送。）实施必须另外确保初始序列号的较低24位不与最近序列号的较低24位重叠（除非实施计划避免短序列号；见第7.6节）。对于具有相同4元组的最近连接，具有状态的实现可以显式地选择一个好的初始序列号。否则，它可能会将初始序列号选择与某些时钟相关联，例如TCP使用的4微秒时钟[RFC793]。可能需要两个单独的时钟，一个用于高24位，另一个用于低24位。
To address the second problem, an implementation MUST provide each 4-tuple with an independent initial sequence number space. Then, opening a connection doesn't provide any information about initial sequence numbers on other connections to the same host. [RFC1948] achieves this by adding a cryptographic hash of the 4-tuple and a secret to each initial sequence number. For the secret, [RFC1948] recommends a combination of some truly random data [RFC4086], an administratively installed passphrase, the endpoint's IP address, and the endpoint's boot time, but truly random data is sufficient. Care should be taken when the secret is changed; such a change alters all initial sequence number spaces, which might make an initial sequence number for some 4-tuple equal a recently sent sequence number for the same 4-tuple. To avoid this problem, the endpoint might remember dead connection state for each 4-tuple or stay quiet for 2 maximum segment lifetimes around such a change.
为了解决第二个问题，实现必须为每个4元组提供独立的初始序列号空间。然后，打开连接不会提供关于同一主机的其他连接的初始序列号的任何信息。[RFC1948]通过向每个初始序列号添加4元组的加密哈希和一个秘密来实现这一点。对于机密，[RFC1948]建议结合一些真正随机的数据[RFC4086]、管理安装的密码短语、端点的IP地址和端点的启动时间，但真正随机的数据就足够了。改变秘密时要小心；这样的更改会改变所有初始序列号空间，这可能会使某些4元组的初始序列号等于同一4元组最近发送的序列号。为了避免这个问题，端点可能会记住每个4元组的死连接状态，或者在这样的更改前后保持2个最大段生存期的安静状态。
DCCP endpoints, like TCP endpoints, must take care before initiating connections when they boot. In particular, they MUST NOT send packets whose sequence numbers are close to the sequence numbers of packets lingering in the network from before the boot. The simplest way to enforce this rule is for DCCP endpoints to avoid sending any packets until one maximum segment lifetime (2 minutes) after boot.
DCCP端点与TCP端点一样，在启动连接之前必须小心。特别是，它们不能发送序列号接近引导前网络中滞留的数据包序列号的数据包。强制执行此规则的最简单方法是DCCP端点在引导后的一个最长段生存期（2分钟）之前避免发送任何数据包。
Other enforcement mechanisms include remembering recent sequence numbers across boots and reserving the upper 8 or so bits of initial sequence numbers for a persistent counter that decrements by two each boot. (The latter mechanism would require disallowing packets with short sequence numbers; see Section 7.6.1.)
其他强制执行机制包括跨引导记住最近的序列号，并为每个引导递减2的持久计数器保留初始序列号的上8位左右。（后一种机制要求禁止使用短序列号的数据包；见第7.6.1节。）
Cumulative acknowledgements are meaningless in an unreliable protocol. Therefore, DCCP's Acknowledgement Number field has a different meaning from TCP's.
在不可靠的协议中，累积确认是没有意义的。因此，DCCP的确认号字段的含义与TCP的不同。
A received packet is classified as acknowledgeable if and only if its header was successfully processed by the receiving DCCP. In terms of the pseudocode in Section 8.5, a received packet becomes acknowledgeable when the receiving endpoint reaches Step 8. This means, for example, that all acknowledgeable packets have valid header checksums and sequence numbers. A sent packet's Acknowledgement Number MUST equal the sending endpoint's GSR, the Greatest Sequence Number Received on an acknowledgeable packet, for all packet types except DCCP-Sync and DCCP-SyncAck.
当且仅当接收DCCP成功处理了接收到的数据包的报头时，才将其分类为可确认数据包。根据第8.5节中的伪码，当接收端点到达步骤8时，接收到的数据包成为可确认的。这意味着，例如，所有可确认的数据包都具有有效的报头校验和和序列号。对于除DCCP Sync和DCCP SyncAck之外的所有数据包类型，发送数据包的确认号必须等于发送端点的GSR，即在可确认数据包上接收到的最大序列号。
"Acknowledgeable" does not refer to data processing. Even acknowledgeable packets may have their application data dropped, due to receive buffer overflow or corruption, for instance. Data Dropped options report these data losses when necessary, letting congestion control mechanisms distinguish between network losses and endpoint losses. This issue is discussed further in Sections 11.4 and 11.7.
“可确认”不指数据处理。例如，由于接收缓冲区溢出或损坏，即使是可确认的数据包也可能会丢弃其应用程序数据。数据丢失选项在必要时报告这些数据丢失，使拥塞控制机制能够区分网络丢失和端点丢失。第11.4节和第11.7节将进一步讨论该问题。
DCCP-Sync and DCCP-SyncAck packets' Acknowledgement Numbers differ as follows: The Acknowledgement Number on a DCCP-Sync packet corresponds to a received packet, but not necessarily to an acknowledgeable packet; in particular, it might correspond to an out-of-sync packet whose options were not processed. The Acknowledgement Number on a DCCP-SyncAck packet always corresponds to an acknowledgeable DCCP-Sync packet; it might be less than GSR in the presence of reordering.
DCCP Sync和DCCP SyncAck数据包的确认号不同如下：DCCP Sync数据包上的确认号对应于接收到的数据包，但不一定对应于可确认的数据包；特别是，它可能对应于未处理其选项的不同步数据包。DCCP SyncAck数据包上的确认号始终对应于可确认的DCCP Sync数据包；在存在重新排序的情况下，它可能小于GSR。
Any DCCP endpoint might receive packets that are not actually part of the current connection. For instance, the network might deliver an old packet, an attacker might attempt to hijack a connection, or the other endpoint might crash, causing a half-open connection.
任何DCCP端点都可能接收不属于当前连接的数据包。例如，网络可能传递旧数据包，攻击者可能试图劫持连接，或者另一个端点可能崩溃，导致连接半开放。
DCCP, like TCP, uses sequence number checks to detect these cases. Packets whose Sequence and/or Acknowledgement Numbers are out of range are called sequence-invalid and are not processed normally.
与TCP一样，DCCP使用序列号检查来检测这些情况。序列号和/或确认号超出范围的数据包称为序列无效，不能正常处理。
Unlike TCP, DCCP requires a synchronization mechanism to recover from large bursts of loss. One endpoint might send so many packets during a burst of loss that when one of its packets finally got through, the other endpoint would label its Sequence Number as invalid. A handshake of DCCP-Sync and DCCP-SyncAck packets recovers from this case.
与TCP不同，DCCP需要一种同步机制来从大的突发性丢失中恢复。一个端点可能会在突发丢失期间发送如此多的数据包，以至于当其中一个数据包最终通过时，另一个端点会将其序列号标记为无效。在此情况下，DCCP Sync和DCCP SyncAck数据包的握手将恢复。
Each DCCP endpoint defines sequence validity windows that are subsets of the Sequence and Acknowledgement Number spaces. These windows correspond to packets the endpoint expects to receive in the next few round-trip times. The Sequence and Acknowledgement Number windows always contain GSR and GSS, respectively. The window widths are controlled by Sequence Window features for the two half-connections.
每个DCCP端点定义序列有效性窗口，这些窗口是序列和确认号空间的子集。这些窗口对应于端点预期在接下来的几个往返时间内接收的数据包。序列号和确认号窗口始终分别包含GSR和GSS。窗口宽度由两个半连接的序列窗口特征控制。
The Sequence Number validity window for packets from DCCP B is [SWL, SWH]. This window always contains GSR, the Greatest Sequence Number Received on a sequence-valid packet from DCCP B. It is W packets wide, where W is the value of the Sequence Window/B feature. One-fourth of the sequence window, rounded down, is less than or equal to GSR, and three-fourths is greater than GSR. (This asymmetric placement assumes that bursts of loss are more common in the network than significant reorderings.)
来自DCCP B的数据包的序列号有效性窗口为[SWL，SWH]。此窗口始终包含GSR，即从DCCP B收到的序列有效数据包上的最大序列号。它是W数据包宽，其中W是序列窗口/B功能的值。四分之一的序列窗口向下舍入，小于或等于GSR，四分之三大于GSR。（这种不对称布局假设网络中的突发损失比重大重新排序更常见。）
invalid | valid Sequence Numbers | invalid
<---------*|*===========*=======================*|*--------->
GSR -|GSR + 1 - GSR GSR +|GSR + 1 +
floor(W/4)|floor(W/4) ceil(3W/4)|ceil(3W/4)
= SWL = SWH
invalid | valid Sequence Numbers | invalid
<---------*|*===========*=======================*|*--------->
GSR -|GSR + 1 - GSR GSR +|GSR + 1 +
floor(W/4)|floor(W/4) ceil(3W/4)|ceil(3W/4)
= SWL = SWH
The Acknowledgement Number validity window for packets from DCCP B is [AWL, AWH]. The high end of the window, AWH, equals GSS, the Greatest Sequence Number Sent by DCCP A; the window is W' packets wide, where W' is the value of the Sequence Window/A feature.
来自DCCP B的数据包的确认号有效性窗口为[AWL，AWH]。窗口的高端AWH等于GSS，即DCCP A发送的最大序列号；窗口为W'数据包宽，其中W'是序列窗口/A特征的值。
invalid | valid Acknowledgement Numbers | invalid
<---------*|*===================================*|*--------->
GSS - W'|GSS + 1 - W' GSS|GSS + 1
= AWL = AWH
invalid | valid Acknowledgement Numbers | invalid
<---------*|*===================================*|*--------->
GSS - W'|GSS + 1 - W' GSS|GSS + 1
= AWL = AWH
SWL and AWL are initially adjusted so that they are not less than the initial Sequence Numbers received and sent, respectively:
初始调整SWL和AWL，使其分别不小于接收和发送的初始序列号：
SWL := max(GSR + 1 - floor(W/4), ISR), AWL := max(GSS + 1 - W', ISS).
安全工作高度：=最大（地面安全防护+1层（带4层），ISR），锥度：=最大（地面安全防护+1层-带4层），ISS）。
These adjustments MUST be applied only at the beginning of the connection. (Long-lived connections may wrap sequence numbers so that they appear to be less than ISR or ISS; the adjustments MUST NOT be applied in that case.)
这些调整只能在连接开始时进行。（长寿命连接可能会包装序列号，使其看起来小于ISR或ISS；在这种情况下不得应用调整。）
The Sequence Window/A feature determines the width of the Sequence Number validity window used by DCCP B and the width of the Acknowledgement Number validity window used by DCCP A. DCCP A sends a "Change L(Sequence Window, W)" option to notify DCCP B that the Sequence Window/A value is W.
序列窗口/A功能确定DCCP B使用的序列号有效性窗口的宽度和DCCP A使用的确认号有效性窗口的宽度。DCCP A发送“更改L（序列窗口，W）”选项，通知DCCP B序列窗口/A值为W。
Sequence Window has feature number 3 and is non-negotiable. It takes 48-bit (6-byte) integer values, like DCCP sequence numbers. Change and Confirm options for Sequence Window are therefore 9 bytes long. New connections start with Sequence Window 100 for both endpoints. The minimum valid Sequence Window value is Wmin = 32. The maximum valid Sequence Window value is Wmax = 2^46 - 1 = 70368744177663. Change options suggesting Sequence Window values out of this range are invalid and MUST be handled accordingly.
序列窗口具有特征编号3，不可协商。它采用48位（6字节）整数值，如DCCP序列号。因此，序列窗口的更改和确认选项的长度为9字节。新连接从两个端点的序列窗口100开始。最小有效序列窗口值为Wmin=32。最大有效序列窗口值为Wmax=2^46-1=70368744177663。建议序列窗口值超出此范围的更改选项无效，必须进行相应处理。
A proper Sequence Window/A value must reflect the number of packets DCCP A expects to be in flight. Only DCCP A can anticipate this number. Values that are too small increase the risk of the endpoints getting out sync after bursts of loss, and values that are much too small can prevent productive communication whether or not there is loss. On the other hand, too-large values increase the risk of connection hijacking; Section 7.5.5 quantifies this risk. One good guideline is for each endpoint to set Sequence Window to about five times the maximum number of packets it expects to send in a round-trip time. Endpoints SHOULD send Change L(Sequence Window) options, as necessary, as the connection progresses. Also, an endpoint MUST NOT persistently send more than its Sequence Window number of packets per round-trip time; that is, DCCP A MUST NOT persistently send more than Sequence Window/A packets per RTT.
正确的序列窗口/A值必须反映DCCP A预期正在传输的数据包数量。只有DCCP A可以预测这个数字。太小的值会增加端点在突发丢失后失去同步的风险，太小的值可能会阻止生产性通信，无论是否有丢失。另一方面，太大的值会增加连接劫持的风险；第7.5.5节量化了该风险。一个很好的指导原则是，每个端点将序列窗口设置为其预期在往返时间内发送的最大数据包数的五倍左右。端点应在连接过程中根据需要发送Change L（序列窗口）选项。此外，端点每次往返时间发送的数据包数不得超过其序列窗口数；也就是说，DCCP A每次RTT发送的数据包不得超过序列窗口/A。
Sequence-validity depends on the received packet's type. This table shows the sequence and acknowledgement number checks applied to each packet; a packet is sequence-valid if it passes both tests, and sequence-invalid if it does not. Many of the checks refer to the sequence and acknowledgement number validity windows [SWL, SWH] and [AWL, AWH] defined in Section 7.5.1.
序列有效性取决于所接收数据包的类型。此表显示了应用于每个数据包的序列和确认号检查；如果数据包通过了这两个测试，则序列有效，否则序列无效。许多检查涉及第7.5.1节中定义的序列和确认号有效窗口[SWL，SWH]和[AWL，AWH]。
Acknowledgement Number
Packet Type Sequence Number Check Check
----------- --------------------- ----------------------
DCCP-Request SWL <= seqno <= SWH (*) N/A
DCCP-Response SWL <= seqno <= SWH (*) AWL <= ackno <= AWH
DCCP-Data SWL <= seqno <= SWH N/A
DCCP-Ack SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-DataAck SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-CloseReq GSR < seqno <= SWH GAR <= ackno <= AWH
DCCP-Close GSR < seqno <= SWH GAR <= ackno <= AWH
DCCP-Reset GSR < seqno <= SWH GAR <= ackno <= AWH
DCCP-Sync SWL <= seqno AWL <= ackno <= AWH
DCCP-SyncAck SWL <= seqno AWL <= ackno <= AWH
Acknowledgement Number
Packet Type Sequence Number Check Check
----------- --------------------- ----------------------
DCCP-Request SWL <= seqno <= SWH (*) N/A
DCCP-Response SWL <= seqno <= SWH (*) AWL <= ackno <= AWH
DCCP-Data SWL <= seqno <= SWH N/A
DCCP-Ack SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-DataAck SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-CloseReq GSR < seqno <= SWH GAR <= ackno <= AWH
DCCP-Close GSR < seqno <= SWH GAR <= ackno <= AWH
DCCP-Reset GSR < seqno <= SWH GAR <= ackno <= AWH
DCCP-Sync SWL <= seqno AWL <= ackno <= AWH
DCCP-SyncAck SWL <= seqno AWL <= ackno <= AWH
(*) Check not applied if connection is in LISTEN or REQUEST state.
（*）如果连接处于侦听或请求状态，则检查未应用。
In general, packets are sequence-valid if their Sequence and Acknowledgement Numbers lie within the corresponding valid windows, [SWL, SWH] and [AWL, AWH]. The exceptions to this rule are as follows:
通常，如果数据包的序列号和确认号位于相应的有效窗口[SWL，SWH]和[AWL，AWH]内，则数据包是序列有效的。本条规则的例外情况如下：
o Since DCCP-CloseReq, DCCP-Close, and DCCP-Reset packets end a connection, they cannot have Sequence Numbers less than or equal to GSR, or Acknowledgement Numbers less than GAR.
o 由于DCCP CloseReq、DCCP Close和DCCP Reset数据包结束连接，因此它们的序列号不能小于或等于GSR，也不能小于GAR。
o DCCP-Sync and DCCP-SyncAck Sequence Numbers are not strongly checked. These packet types exist specifically to get the endpoints back into sync; checking their Sequence Numbers would eliminate their usefulness.
o 未对DCCP Sync和DCCP SyncAck序列号进行严格检查。这些包类型的存在是为了让端点重新同步；检查它们的序列号会消除它们的有用性。
The lenient checks on DCCP-Sync and DCCP-SyncAck packets allow continued operation after unusual events, such as endpoint crashes and large bursts of loss, but there's no need for leniency in the absence of unusual events -- that is, during ongoing successful communication. Therefore, DCCP implementations SHOULD use the following, more stringent checks for active connections, where a connection is considered active if it has received valid packets from the other endpoint within the last three round-trip times.
对DCCP Sync和DCCP SyncAck数据包的宽大检查允许在异常事件（如端点崩溃和大量丢失）后继续操作，但在没有异常事件的情况下，也就是在持续的成功通信期间，不需要宽大检查。因此，DCCP实现应该对活动连接使用以下更严格的检查，其中，如果一个连接在最近三个往返时间内从另一个端点接收到有效数据包，则该连接被视为活动连接。
Acknowledgement Number
Packet Type Sequence Number Check Check
----------- --------------------- ----------------------
DCCP-Sync SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-SyncAck SWL <= seqno <= SWH AWL <= ackno <= AWH
Acknowledgement Number
Packet Type Sequence Number Check Check
----------- --------------------- ----------------------
DCCP-Sync SWL <= seqno <= SWH AWL <= ackno <= AWH
DCCP-SyncAck SWL <= seqno <= SWH AWL <= ackno <= AWH
Finally, an endpoint MAY apply the following more stringent checks to DCCP-CloseReq, DCCP-Close, and DCCP-Reset packets, further lowering the probability of successful blind attacks using those packet types.
最后，端点可以对DCCP CloseReq、DCCP Close和DCCP Reset分组应用以下更严格的检查，从而进一步降低使用这些分组类型的成功盲攻击的概率。
Since these checks can cause extra synchronization overhead and delay connection closing when packets are lost, they should be considered experimental.
由于这些检查可能会导致额外的同步开销，并在数据包丢失时延迟连接关闭，因此应将其视为实验性检查。
Acknowledgement Number
Packet Type Sequence Number Check Check
----------- --------------------- ----------------------
DCCP-CloseReq seqno == GSR + 1 GAR <= ackno <= AWH
DCCP-Close seqno == GSR + 1 GAR <= ackno <= AWH
DCCP-Reset seqno == GSR + 1 GAR <= ackno <= AWH
Acknowledgement Number
Packet Type Sequence Number Check Check
----------- --------------------- ----------------------
DCCP-CloseReq seqno == GSR + 1 GAR <= ackno <= AWH
DCCP-Close seqno == GSR + 1 GAR <= ackno <= AWH
DCCP-Reset seqno == GSR + 1 GAR <= ackno <= AWH
Note that sequence-validity is only one of the validity checks applied to received packets.
请注意，序列有效性只是应用于所接收数据包的有效性检查之一。
Endpoints respond to received sequence-invalid packets as follows.
端点响应接收到的序列无效数据包，如下所示。
o Any sequence-invalid DCCP-Sync or DCCP-SyncAck packet MUST be ignored.
o 必须忽略任何序列无效的DCCP Sync或DCCP SyncAck数据包。
o A sequence-invalid DCCP-Reset packet MUST elicit a DCCP-Sync packet in response (subject to a possible rate limit). This response packet MUST use a new Sequence Number, and thus will increase GSS; GSR will not change, however, since the received packet was sequence-invalid. The response packet's Acknowledgement Number MUST equal GSR.
o 序列无效的DCCP重置数据包必须引起DCCP同步数据包的响应（受可能的速率限制）。该响应包必须使用新的序列号，因此将增加GSS；然而，GSR不会改变，因为接收到的数据包序列无效。响应包的确认号必须等于GSR。
o Any other sequence-invalid packet MUST elicit a similar DCCP-Sync packet, except that the response packet's Acknowledgement Number MUST equal the sequence-invalid packet's Sequence Number.
o 任何其他序列无效数据包必须引发类似的DCCP同步数据包，但响应数据包的确认号必须等于序列无效数据包的序列号。
On receiving a sequence-valid DCCP-Sync packet, the peer endpoint (say, DCCP B) MUST update its GSR variable and reply with a DCCP-SyncAck packet. The DCCP-SyncAck packet's Acknowledgement Number will equal the DCCP-Sync's Sequence Number, which is not necessarily GSR. Upon receiving this DCCP-SyncAck, which will be sequence-valid since it acknowledges the DCCP-Sync, DCCP A will update its GSR variable, and the endpoints will be back in sync. As an exception, if the peer endpoint is in the REQUEST state, it MUST respond with a DCCP-Reset instead of a DCCP-SyncAck. This serves to clean up DCCP A's half-open connection.
在接收到序列有效的DCCP Sync数据包时，对等端点（如DCCP B）必须更新其GSR变量并使用DCCP SyncAck数据包进行回复。DCCP SyncAck数据包的确认号将等于DCCP Sync的序列号，这不一定是GSR。收到此DCCP SyncAck后，DCCP A将更新其GSR变量，端点将恢复同步，因为它确认DCCP同步，因此该序列将是有效的。作为例外，如果对等端点处于请求状态，则它必须使用DCCP重置而不是DCCP SyncAck进行响应。这用于清除DCCP A的半开放连接。
To protect against denial-of-service attacks, DCCP implementations SHOULD impose a rate limit on DCCP-Syncs sent in response to sequence-invalid packets, such as not more than eight DCCP-Syncs per second.
为了防止拒绝服务攻击，DCCP实现应该对响应序列无效数据包而发送的DCCP同步施加速率限制，例如每秒不超过8次DCCP同步。
DCCP endpoints MUST NOT process sequence-invalid packets except, perhaps, by generating a DCCP-Sync. For instance, options MUST NOT be processed. An endpoint MAY temporarily preserve sequence-invalid packets in case they become valid later, however; this can reduce the impact of bursts of loss by delivering more packets to the application. In particular, an endpoint MAY preserve sequence-invalid packets for up to 2 round-trip times. If, within that time, the relevant sequence windows change so that the packets become sequence-valid, the endpoint MAY process them again.
DCCP端点不得处理序列无效数据包，除非生成DCCP同步。例如，不能处理选项。然而，端点可以临时保留序列无效的数据包，以防它们以后变为有效；这可以通过向应用程序交付更多数据包来减少突发丢失的影响。特别地，端点可以将序列无效数据包保留多达2次往返时间。如果在该时间内，相关序列窗口发生变化，使得数据包成为序列有效，则端点可以再次处理它们。
Note that sequence-invalid DCCP-Reset packets cause DCCP-Syncs to be generated. This is because endpoints in an unsynchronized state (CLOSED, REQUEST, and LISTEN) might not have enough information to generate a proper DCCP-Reset on the first try. For example, if a peer endpoint is in CLOSED state and receives a DCCP-Data packet, it cannot guess the right Sequence Number to use on the DCCP-Reset it generates (since the DCCP-Data packet has no Acknowledgement Number). The DCCP-Sync generated in response to this bad reset serves as a challenge, and contains enough information for the peer to generate a proper DCCP-Reset. However, the new DCCP-Reset may carry a different Reset Code than the original DCCP-Reset; probably the new Reset Code will be 3, "No Connection". The endpoint SHOULD use information from the original DCCP-Reset when possible.
请注意，序列无效的DCCP重置数据包会导致生成DCCP同步。这是因为处于非同步状态（关闭、请求和侦听）的端点可能没有足够的信息在第一次尝试时生成正确的DCCP重置。例如，如果对等端点处于关闭状态并接收到DCCP数据包，则它无法猜测在其生成的DCCP重置上使用的正确序列号（因为DCCP数据包没有确认号）。为响应此错误重置而生成的DCCP Sync用作质询，并包含足够的信息供对等方生成正确的DCCP重置。然而，新的DCCP重置可能携带与原始DCCP重置不同的重置代码；新的重置代码可能是3，“无连接”。端点应尽可能使用原始DCCP重置中的信息。
Sequence and Acknowledgement Numbers form DCCP's main line of defense against attackers. An attacker that cannot guess sequence numbers cannot easily manipulate or hijack a DCCP connection, and requirements like careful initial sequence number choice eliminate the most serious attacks.
序列号和确认号构成了DCCP抵御攻击者的主要防线。无法猜测序列号的攻击者无法轻松操纵或劫持DCCP连接，而仔细选择初始序列号等要求可以消除最严重的攻击。
An attacker might still send many packets with randomly chosen Sequence and Acknowledgement Numbers, however. If one of those probes ends up sequence-valid, it may shut down the connection or otherwise cause problems. The easiest such attacks to execute are as follows:
然而，攻击者仍可能发送带有随机选择的序列号和确认号的许多数据包。如果其中一个探针终止序列有效，它可能会关闭连接或导致问题。最容易执行的此类攻击如下所示：
o Send DCCP-Data packets with random Sequence Numbers. If one of these packets hits the valid sequence number window, the attack packet's application data may be inserted into the data stream.
o 发送带有随机序列号的DCCP数据包。如果这些包中的一个到达有效序列号窗口，则攻击包的应用程序数据可能会插入数据流中。
o Send DCCP-Sync packets with random Sequence and Acknowledgement Numbers. If one of these packets hits the valid acknowledgement number window, the receiver will shift its sequence number window accordingly, getting out of sync with the correct endpoint -- perhaps permanently.
o 发送带有随机序列和确认号的DCCP同步数据包。如果这些数据包中有一个到达了有效的确认号窗口，那么接收方将相应地移动其序列号窗口，从而与正确的端点不同步——可能是永久性的。
The attacker has to guess both Source and Destination Ports for any of these attacks to succeed. Additionally, the connection would have to be inactive for the DCCP-Sync attack to succeed, assuming the victim implemented the more stringent checks for active connections recommended in Section 7.5.3.
攻击者必须猜测源端口和目标端口才能使这些攻击成功。此外，如果受害者对第7.5.3节中建议的活动连接实施了更严格的检查，则连接必须处于非活动状态，DCCP同步攻击才能成功。
To quantify the probability of success, let N be the number of attack packets the attacker is willing to send, W be the relevant sequence window width, and L be the length of sequence numbers (24 or 48). The attacker's best strategy is to space the attack packets evenly over sequence space. Then the probability of hitting one sequence number window is P = WN/2^L.
为了量化成功的概率，假设N是攻击者愿意发送的攻击数据包的数量，W是相关的序列窗口宽度，L是序列号的长度（24或48）。攻击者的最佳策略是将攻击数据包均匀地分布在序列空间上。那么命中一个序列号窗口的概率是P=WN/2^L。
The success probability for a DCCP-Data attack using short sequence numbers thus equals P = WN/2^24. For W = 100, then, the attacker must send more than 83,000 packets to achieve a 50% chance of success. For reference, the easiest TCP attack -- sending a SYN with a random sequence number, which will cause a connection reset if it falls within the window -- with W = 8760 (a common default) and L = 32 requires more than 245,000 packets to achieve a 50% chance of success.
因此，使用短序列号的DCCP数据攻击的成功概率等于P=WN/2^24。如果W=100，则攻击者必须发送83000多个数据包才能获得50%的成功几率。作为参考，最简单的TCP攻击——发送带有随机序列号的SYN，如果它在窗口内，将导致连接重置——W=8760（常见默认值）和L=32需要超过245000个数据包才能实现50%的成功几率。
A fast connection's W will generally be high, increasing the attack success probability for fixed N. If this probability gets uncomfortably high with L = 24, the endpoint SHOULD prevent the use of short sequence numbers by manipulating the Allow Short Sequence Numbers feature (see Section 7.6.1). The probability limit depends on the application, however. Some applications, such as those already designed to handle corruption, are quite resilient to data injection attacks.
快速连接的W通常会很高，从而增加固定N的攻击成功概率。如果L=24时该概率变得异常高，端点应通过操纵允许短序列号功能来防止使用短序列号（见第7.6.1节）。然而，概率极限取决于应用。一些应用程序（如已经设计用于处理损坏的应用程序）对数据注入攻击具有很强的弹性。
The DCCP-Sync attack has L = 48, since DCCP-Sync packets use long sequence numbers exclusively; in addition, the success probability is halved, since only half the Sequence Number space is valid. Attacks have a correspondingly smaller probability of success. For a large W of 2000 packets, then, the attacker must send more than 10^11 packets to achieve a 50% chance of success.
DCCP同步攻击的L=48，因为DCCP同步数据包专门使用长序列号；此外，成功概率减半，因为只有一半的序列号空间是有效的。攻击的成功概率相对较小。对于2000个数据包的大数据包，攻击者必须发送10^11个以上的数据包才能获得50%的成功几率。
Attacks involving DCCP-Ack, DCCP-DataAck, DCCP-CloseReq, DCCP-Close, and DCCP-Reset packets are more difficult, since Sequence and Acknowledgement Numbers must both be guessed. The probability of attack success for these packet types equals P = WXN/2^(2L), where W is the Sequence Number window, X is the Acknowledgement Number window, and N and L are as before.
涉及DCCP Ack、DCCP DataAck、DCCP CloseReq、DCCP Close和DCCP Reset数据包的攻击更加困难，因为序列号和确认号都必须猜测。这些数据包类型的攻击成功概率等于P=WXN/2^（2L），其中W是序列号窗口，X是确认号窗口，N和L与前面一样。
Since DCCP-Data attacks with short sequence numbers are relatively easy for attackers to execute, DCCP has been engineered to prevent these attacks from escalating to connection resets or other serious
由于具有短序列号的DCCP数据攻击相对容易被攻击者执行，因此设计DCCP是为了防止这些攻击升级为连接重置或其他严重攻击
consequences. In particular, any options whose processing might cause the connection to be reset are ignored when they appear on DCCP-Data packets.
后果。特别是，当其处理可能导致连接重置的任何选项出现在DCCP数据包上时，都会被忽略。
In the following example, DCCP A and DCCP B recover from a large burst of loss that runs DCCP A's sequence numbers out of DCCP B's appropriate sequence number window.
在下面的示例中，DCCP A和DCCP B从一个大的丢失突发中恢复，该突发从DCCP B的相应序列号窗口中运行DCCP A的序列号。
DCCP A DCCP B
(GSS=1,GSR=10) (GSS=10,GSR=1)
--> DCCP-Data(seq 2) XXX
...
--> DCCP-Data(seq 100) XXX
--> DCCP-Data(seq 101) --> ???
seqno out of range;
send Sync
OK <-- DCCP-Sync(seq 11, ack 101) <--
(GSS=11,GSR=1)
--> DCCP-SyncAck(seq 102, ack 11) --> OK
(GSS=102,GSR=11) (GSS=11,GSR=102)
DCCP A DCCP B
(GSS=1,GSR=10) (GSS=10,GSR=1)
--> DCCP-Data(seq 2) XXX
...
--> DCCP-Data(seq 100) XXX
--> DCCP-Data(seq 101) --> ???
seqno out of range;
send Sync
OK <-- DCCP-Sync(seq 11, ack 101) <--
(GSS=11,GSR=1)
--> DCCP-SyncAck(seq 102, ack 11) --> OK
(GSS=102,GSR=11) (GSS=11,GSR=102)
In the next example, a DCCP connection recovers from a simple blind attack.
在下一个示例中，DCCP连接从简单的盲攻击中恢复。
DCCP A DCCP B
(GSS=1,GSR=10) (GSS=10,GSR=1)
*ATTACKER* --> DCCP-Data(seq 10^6) --> ???
seqno out of range;
send Sync
??? <-- DCCP-Sync(seq 11, ack 10^6) <--
ackno out of range; ignore
(GSS=1,GSR=10) (GSS=11,GSR=1)
DCCP A DCCP B
(GSS=1,GSR=10) (GSS=10,GSR=1)
*ATTACKER* --> DCCP-Data(seq 10^6) --> ???
seqno out of range;
send Sync
??? <-- DCCP-Sync(seq 11, ack 10^6) <--
ackno out of range; ignore
(GSS=1,GSR=10) (GSS=11,GSR=1)
The final example demonstrates recovery from a half-open connection.
最后一个示例演示如何从半开放连接中恢复。
DCCP A DCCP B (GSS=1,GSR=10) (GSS=10,GSR=1) (Crash) CLOSED OPEN REQUEST --> DCCP-Request(seq 400) --> ??? !! <-- DCCP-Sync(seq 11, ack 400) <-- OPEN REQUEST --> DCCP-Reset(seq 401, ack 11) --> (Abort) REQUEST CLOSED REQUEST --> DCCP-Request(seq 402) --> ...
DCCP A DCCP B（GSS=1，GSR=10）（GSS=10，GSR=1）（崩溃）关闭打开请求-->DCCP请求（seq 400）-->？！！<--DCCP同步（序列号11，确认号400）<--打开请求-->DCCP重置（序列号401，确认号11）-->（中止）请求关闭请求-->DCCP请求（序列号402）-->。。。
DCCP sequence numbers are 48 bits long. This large sequence space protects DCCP connections against some blind attacks, such as the injection of DCCP-Resets into the connection. However, DCCP-Data, DCCP-Ack, and DCCP-DataAck packets, which make up the body of any DCCP connection, may reduce header space by transmitting only the lower 24 bits of the relevant Sequence and Acknowledgement Numbers. The receiving endpoint will extend these numbers to 48 bits using the following pseudocode:
DCCP序列号为48位长。这个大的序列空间保护DCCP连接免受一些盲攻击，例如将DCCP重置注入连接。然而，构成任何DCCP连接主体的DCCP数据、DCCP Ack和DCCP DataAck分组可以通过仅发送相关序列和确认号的较低24位来减少报头空间。接收端点将使用以下伪码将这些数字扩展到48位：
procedure Extend_Sequence_Number(S, REF)
/* S is a 24-bit sequence number from the packet header.
REF is the relevant 48-bit reference sequence number:
GSS if S is an Acknowledgement Number, and GSR if S is a
Sequence Number. */
Set REF_low := low 24 bits of REF
Set REF_hi := high 24 bits of REF
If REF_low (<) S /* circular comparison mod 2^24 */
and S |<| REF_low, /* conventional, non-circular
comparison */
Return (((REF_hi + 1) mod 2^24) << 24) | S
Otherwise, if S (<) REF_low and REF_low |<| S,
Return (((REF_hi - 1) mod 2^24) << 24) | S
Otherwise,
Return (REF_hi << 24) | S
procedure Extend_Sequence_Number(S, REF)
/* S is a 24-bit sequence number from the packet header.
REF is the relevant 48-bit reference sequence number:
GSS if S is an Acknowledgement Number, and GSR if S is a
Sequence Number. */
Set REF_low := low 24 bits of REF
Set REF_hi := high 24 bits of REF
If REF_low (<) S /* circular comparison mod 2^24 */
and S |<| REF_low, /* conventional, non-circular
comparison */
Return (((REF_hi + 1) mod 2^24) << 24) | S
Otherwise, if S (<) REF_low and REF_low |<| S,
Return (((REF_hi - 1) mod 2^24) << 24) | S
Otherwise,
Return (REF_hi << 24) | S
The two different kinds of comparison in the if statements detect when the low-order bits of the sequence space have wrapped. (The circular comparison "REF_low (<) S" returns true if and only if (S - REF_low), calculated using two's-complement arithmetic and then represented as an unsigned number, is less than or equal to 2^23 (mod 2^24).) When this happens, the high-order bits are incremented or decremented, as appropriate.
if语句中的两种不同类型的比较检测序列空间的低阶位何时被包装。（循环比较“REF_low（<）S”当且仅当（S-REF_low）（使用二元补码算法计算，然后表示为无符号数）小于或等于2^23（mod 2^24）时返回true。发生这种情况时，高阶位会酌情递增或递减。
Endpoints can require that all packets use long sequence numbers by leaving the Allow Short Sequence Numbers feature value at its default of zero. This can reduce the risk that data will be inappropriately injected into the connection. DCCP A sends a "Change L(Allow Short Seqnos, 1)" option to indicate its desire to send packets with short sequence numbers.
端点可以要求所有数据包使用长序列号，方法是将“允许短序列号”功能值保留为默认值零。这可以降低数据被不适当地注入连接的风险。DCCP A发送一个“Change L（允许短序列号，1）”选项，以表明其希望发送具有短序列号的数据包。
Allow Short Sequence Numbers has feature number 2 and is server-priority. It takes one-byte Boolean values. When Allow Short Seqnos/B is zero, DCCP B MUST NOT send packets with short sequence numbers and DCCP A MUST ignore any packets with short sequence
“允许短序列号”具有功能编号2，是服务器优先级。它需要一个字节的布尔值。当Allow Short Seqnos/B为零时，DCCP B不得发送具有短序列号的数据包，DCCP A必须忽略任何具有短序列号的数据包
numbers that are received. Values of two or more are reserved. New connections start with Allow Short Sequence Numbers 0 for both endpoints.
收到的号码。保留两个或两个以上的值。新连接以允许两个端点的短序列号0开始。
Short sequence numbers reduce the rate DCCP connections can safely achieve and increase the risks of certain kinds of attacks, including blind data injection. Very-high-rate DCCP connections, and connections with large sequence windows (Section 7.5.2), SHOULD NOT use short sequence numbers on their data packets. The attack risk issues have been discussed in Section 7.5.5; we discuss the rate limitation issue here.
短序列号降低了DCCP连接可以安全实现的速率，并增加了某些类型攻击的风险，包括盲数据注入。超高速DCCP连接和具有大序列窗口的连接（第7.5.2节）不应在其数据包上使用短序列号。第7.5.5节讨论了攻击风险问题；我们在此讨论利率限制问题。
The sequence-validity mechanism assumes that the network does not deliver extremely old data. In particular, it assumes that the network must have dropped any packet by the time the connection wraps around and uses its sequence number again. This constraint limits the maximum connection rate that can be safely achieved. Let MSL equal the maximum segment lifetime, P equal the average DCCP packet size in bits, and L equal the length of sequence numbers (24 or 48 bits). Then the maximum safe rate, in bits per second, is R = P*(2^L)/2MSL.
序列有效性机制假设网络不会传递非常旧的数据。特别是，它假设网络必须在连接结束并再次使用其序列号时丢弃任何数据包。此约束限制了可以安全实现的最大连接速率。让MSL等于最大段生存期，P等于平均DCCP数据包大小（以位为单位），L等于序列号的长度（24或48位）。然后，最大安全速率（以位/秒为单位）为R=P*（2^L）/2MSL。
For the default MSL of 2 minutes, 1500-byte DCCP packets, and short sequence numbers, the safe rate is therefore approximately 800 Mb/s. Although 2 minutes is a very large MSL for any networks that could sustain that rate with such small packets, long sequence numbers allow much higher rates under the same constraints: up to 14 petabits a second for 1500-byte packets and the default MSL.
因此，对于2分钟的默认MSL、1500字节DCCP数据包和短序列号，安全速率约为800 Mb/s。虽然2分钟对于任何网络来说都是一个非常大的MSL，可以用如此小的数据包维持这种速率，但在相同的限制条件下，长序列号允许更高的速率：1500字节数据包和默认MSL的速率高达每秒14 PB。
DCCP's sequence numbers increment by one on every packet, including non-data packets (packets that don't carry application data). This makes DCCP sequence numbers suitable for detecting any network loss, but not for detecting the loss of application data. The NDP Count option reports the length of each burst of non-data packets. This lets the receiving DCCP reliably determine when a burst of loss included application data.
DCCP的序列号在每个数据包上增加一个，包括非数据包（不携带应用程序数据的数据包）。这使得DCCP序列号适用于检测任何网络丢失，但不适用于检测应用程序数据的丢失。NDP Count选项报告每个非数据包突发的长度。这使接收DCCP能够可靠地确定丢失突发何时包括应用程序数据。
+--------+--------+-------- ... --------+
|00100101| Length | NDP Count |
+--------+--------+-------- ... --------+
Type=37 Len=3-8 (1-6 bytes)
+--------+--------+-------- ... --------+
|00100101| Length | NDP Count |
+--------+--------+-------- ... --------+
Type=37 Len=3-8 (1-6 bytes)
If a DCCP endpoint's Send NDP Count feature is one (see below), then that endpoint MUST send an NDP Count option on every packet whose
如果DCCP端点的Send NDP Count功能为一（见下文），则该端点必须在每个数据包上发送一个NDP Count选项
immediate predecessor was a non-data packet. Non-data packets consist of DCCP packet types DCCP-Ack, DCCP-Close, DCCP-CloseReq, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck. The other packet types, namely DCCP-Request, DCCP-Response, DCCP-Data, and DCCP-DataAck, are considered data packets, although not all DCCP-Request and DCCP-Response packets will actually carry application data.
直接前导是一个非数据包。非数据包由DCCP包类型DCCP Ack、DCCP Close、DCCP CloseReq、DCCP Reset、DCCP Sync和DCCP SyncAck组成。其他数据包类型，即DCCP请求、DCCP响应、DCCP数据和DCCP数据包被视为数据包，尽管并非所有DCCP请求和DCCP响应数据包都将实际携带应用程序数据。
The value stored in NDP Count equals the number of consecutive non-data packets in the run immediately previous to the current packet. Packets with no NDP Count option are considered to have NDP Count zero.
存储在NDP Count中的值等于当前数据包之前运行的连续非数据包数。没有NDP计数选项的数据包被视为NDP计数为零。
The NDP Count option can carry one to six bytes of data. The smallest option format that can hold the NDP Count SHOULD be used.
NDP计数选项可以携带一到六个字节的数据。应使用可容纳NDP计数的最小选项格式。
With NDP Count, the receiver can reliably tell only whether a burst of loss contained at least one data packet. For example, the receiver cannot always tell whether a burst of loss contained a non-data packet.
通过NDP计数，接收器可以可靠地仅判断丢失突发是否包含至少一个数据包。例如，接收器不能总是判断丢失突发是否包含非数据分组。
Say that K consecutive sequence numbers are missing in some burst of loss, and that the Send NDP Count feature is on. Then some application data was lost within those sequence numbers unless the packet following the hole contains an NDP Count option whose value is greater than or equal to K.
假设在某些突发丢失中丢失了K个连续序列号，并且启用了发送NDP计数功能。然后，一些应用程序数据在这些序列号中丢失，除非孔后面的数据包包含一个NDP Count选项，该选项的值大于或等于K。
For example, say that an endpoint sent the following sequence of non-data packets (Nx) and data packets (Dx).
例如，假设一个端点发送了以下非数据包（Nx）和数据包（Dx）序列。
N0 N1 D2 N3 D4 D5 N6 D7 D8 D9 D10 N11 N12 D13
N0 N1 D2 N3 D4 D5 N6 D7 D8 D9 D10 N11 N12 D13
Those packets would have NDP Counts as follows.
这些数据包的NDP计数如下所示。
N0 N1 D2 N3 D4 D5 N6 D7 D8 D9 D10 N11 N12 D13
- 1 2 - 1 - - 1 - - - - 1 2
N0 N1 D2 N3 D4 D5 N6 D7 D8 D9 D10 N11 N12 D13
- 1 2 - 1 - - 1 - - - - 1 2
NDP Count is not useful for applications that include their own sequence numbers with their packet headers.
NDP计数对于在数据包头中包含自己的序列号的应用程序不有用。
The Send NDP Count feature lets DCCP endpoints negotiate whether they should send NDP Count options on their packets. DCCP A sends a "Change R(Send NDP Count, 1)" option to ask DCCP B to send NDP Count options.
发送NDP计数功能允许DCCP端点协商是否应在其数据包上发送NDP计数选项。DCCP A发送“更改R（发送NDP计数，1）”选项，要求DCCP B发送NDP计数选项。
Send NDP Count has feature number 7 and is server-priority. It takes one-byte Boolean values. DCCP B MUST send NDP Count options as described above when Send NDP Count/B is one, although it MAY send NDP Count options even when Send NDP Count/B is zero. Values of two or more are reserved. New connections start with Send NDP Count 0 for both endpoints.
发送NDP计数具有功能编号7，并且是服务器优先级。它需要一个字节的布尔值。当“发送NDP计数”为1时，DCCP B必须如上所述发送NDP计数选项，但即使“发送NDP计数”为0，DCCP B也可以发送NDP计数选项。保留两个或两个以上的值。新连接从两个端点的发送NDP计数0开始。
This section describes how DCCP connections move between states and which packets are sent when. Note that feature negotiation takes place in parallel with the connection-wide state transitions described here.
本节介绍DCCP连接如何在状态之间移动以及何时发送数据包。请注意，特性协商与此处描述的连接范围内的状态转换并行进行。
DCCP connections' initiation phase consists of a three-way handshake: an initial DCCP-Request packet sent by the client, a DCCP-Response sent by the server in reply, and finally an acknowledgement from the client, usually via a DCCP-Ack or DCCP-DataAck packet. The client moves from the REQUEST state to PARTOPEN, and finally to OPEN; the server moves from LISTEN to RESPOND, and finally to OPEN.
DCCP连接的启动阶段由三方握手组成：客户端发送的初始DCCP请求数据包，服务器发送的DCCP响应，以及客户端通常通过DCCP Ack或DCCP DATACK数据包发出的确认。客户端从请求状态移动到PARTOPEN，最后移动到OPEN；服务器从侦听移动到响应，最后移动到打开。
Client State Server State
CLOSED LISTEN
1. REQUEST --> Request -->
2. <-- Response <-- RESPOND
3. PARTOPEN --> Ack, DataAck -->
4. <-- Data, Ack, DataAck <-- OPEN
5. OPEN <-> Data, Ack, DataAck <-> OPEN
Client State Server State
CLOSED LISTEN
1. REQUEST --> Request -->
2. <-- Response <-- RESPOND
3. PARTOPEN --> Ack, DataAck -->
4. <-- Data, Ack, DataAck <-- OPEN
5. OPEN <-> Data, Ack, DataAck <-> OPEN
When a client decides to initiate a connection, it enters the REQUEST state, chooses an initial sequence number (Section 7.2), and sends a DCCP-Request packet using that sequence number to the intended server.
当客户机决定启动连接时，它进入请求状态，选择初始序列号（第7.2节），并使用该序列号将DCCP请求数据包发送到预期的服务器。
DCCP-Request packets will commonly carry feature negotiation options that open negotiations for various connection parameters, such as preferred congestion control IDs for each half-connection. They may also carry application data, but the client should be aware that the server may not accept such data.
DCCP请求数据包通常带有特征协商选项，这些选项为各种连接参数打开协商，例如每个半连接的首选拥塞控制ID。它们也可能携带应用程序数据，但是客户机应该知道服务器可能不接受这些数据。
A client in the REQUEST state SHOULD use an exponential-backoff timer to send new DCCP-Request packets if no response is received. The first retransmission should occur after approximately one second, backing off to not less than one packet every 64 seconds; or the
如果没有收到响应，处于请求状态的客户端应使用指数回退计时器发送新的DCCP请求数据包。第一次重传应在大约1秒后发生，每64秒后退不少于一个数据包；或者
endpoint can use whatever retransmission strategy is followed for retransmitting TCP SYNs. Each new DCCP-Request MUST increment the Sequence Number by one and MUST contain the same Service Code and application data as the original DCCP-Request.
端点可以使用遵循的任何重传策略来重传TCP SYN。每个新的DCCP请求必须将序列号增加1，并且必须包含与原始DCCP请求相同的服务代码和应用程序数据。
A client MAY give up on its DCCP-Requests after some time (3 minutes, for example). When it does, it SHOULD send a DCCP-Reset packet to the server with Reset Code 2, "Aborted", to clean up state in case one or more of the Requests actually arrived. A client in REQUEST state has never received an initial sequence number from its peer, so the DCCP-Reset's Acknowledgement Number MUST be set to zero.
客户机可能在一段时间后（例如3分钟）放弃其DCCP请求。当它这样做时，它应该向服务器发送一个带有重置代码2“中止”的DCCP重置数据包，以便在一个或多个请求实际到达时清除状态。处于请求状态的客户端从未从其对等方接收到初始序列号，因此DCCP重置的确认号必须设置为零。
The client leaves the REQUEST state for PARTOPEN when it receives a DCCP-Response from the server.
当客户机从服务器接收到DCCP响应时，它会保留PARTOPEN的请求状态。
Each DCCP-Request contains a 32-bit Service Code, which identifies the application-level service to which the client application is trying to connect. Service Codes should correspond to application services and protocols. For example, there might be a Service Code for SIP control connections and one for RTP audio connections. Middleboxes, such as firewalls, can use the Service Code to identify the application running on a nonstandard port (assuming the DCCP header has not been encrypted).
每个DCCP请求都包含一个32位服务代码，用于标识客户端应用程序尝试连接到的应用程序级服务。服务代码应与应用程序服务和协议相对应。例如，可能有一个用于SIP控制连接的服务代码和一个用于RTP音频连接的服务代码。中间件（如防火墙）可以使用服务代码来标识在非标准端口上运行的应用程序（假设DCCP头未加密）。
Endpoints MUST associate a Service Code with every DCCP socket, both actively and passively opened. The application will generally supply this Service Code. Each active socket MUST have exactly one Service Code. Passive sockets MAY, at the implementation's discretion, be associated with more than one Service Code; this might let multiple applications, or multiple versions of the same application, listen on the same port, differentiated by Service Code. If the DCCP-Request's Service Code doesn't equal any of the server's Service Codes for the given port, the server MUST reject the request by sending a DCCP-Reset packet with Reset Code 8, "Bad Service Code". A middlebox MAY also send such a DCCP-Reset in response to packets whose Service Code is considered unsuitable.
端点必须将服务代码与每个主动和被动打开的DCCP套接字相关联。应用程序通常会提供此服务代码。每个活动套接字必须只有一个服务代码。被动插座可由实现自行决定与多个服务代码相关联；这可能会让多个应用程序或同一应用程序的多个版本在同一端口上侦听，并根据服务代码进行区分。如果DCCP请求的服务代码不等于给定端口的任何服务器服务代码，则服务器必须通过发送带有重置代码8“坏服务代码”的DCCP重置数据包来拒绝该请求。中间盒还可以发送这样的DCCP重置，以响应其服务代码被认为不合适的分组。
Service Codes are not intended to be DCCP-specific and are allocated by IANA. Following the policies outlined in [RFC2434], most Service Codes are allocated First Come First Served, subject to the following guidelines.
服务代码并非特定于DCCP，而是由IANA分配的。按照[RFC2434]中概述的政策，大多数服务代码按照以下指南分配，先到先得。
o Service Codes are allocated one at a time, or in small blocks. A short English description of the intended service is REQUIRED to obtain a Service Code assignment, but no specification, standards
o 服务代码一次分配一个，或以小块的形式分配。需要对预期服务进行简短的英语描述，以获得服务代码分配，但无规范、标准
track or otherwise, is necessary. IANA maintains an association of Service Codes to the corresponding phrases.
跟踪或其他，是必要的。IANA维护服务代码与相应短语的关联。
o Users request specific Service Code values. We suggest that users request Service Codes that can be represented using the "SC:" formatting convention described below. Thus, the "Frobodyne Plotz Protocol" might correspond to Service Code 17178548426 or, equivalently, "SC:fdpz". The canonical interpretation of a Service Code field is numeric.
o Users request specific Service Code values. We suggest that users request Service Codes that can be represented using the "SC:" formatting convention described below. Thus, the "Frobodyne Plotz Protocol" might correspond to Service Code 17178548426 or, equivalently, "SC:fdpz". The canonical interpretation of a Service Code field is numeric.translate error, please retry
o Service Codes whose bytes each have values in the set {32, 45-57, 65-90} use a Specification Required allocation policy. That is, these Service Codes are used for international standard or standards-track specifications, IETF or otherwise. (This set consists of the ASCII digits, uppercase letters, and characters space, '-', '.', and '/'.)
o 每个字节在集合{32，45-57，65-90}中都有值的服务代码使用规范要求的分配策略。也就是说，这些服务代码用于国际标准或标准轨道规范、IETF或其他。（此集合由ASCII数字、大写字母和字符空间“-”、“.”和“/”组成。）
o Service Codes whose high-order byte equals 63 (ASCII '?') are reserved for Private Use.
o 高阶字节等于63（ASCII“？”）的服务代码保留供私人使用。
o Service Code 0 represents the absence of a meaningful Service Code and MUST NOT be allocated.
o 服务代码0表示缺少有意义的服务代码，因此不能进行分配。
o The value 4294967295 is an invalid Service Code. Servers MUST reject any DCCP-Request with this Service Code value by sending a DCCP-Reset packet with Reset Code 8, "Bad Service Code".
o 值4294967295是无效的维修代码。服务器必须通过发送重置代码为8“坏服务代码”的DCCP重置数据包来拒绝任何具有此服务代码值的DCCP请求。
This design for Service Code allocation is based on the allocation of 4-byte identifiers for Macintosh resources, PNG chunks, and TrueType and OpenType tables.
服务代码分配的设计基于Macintosh资源、PNG块、TrueType和OpenType表的4字节标识符的分配。
In text settings, we recommend that Service Codes be written in one of three forms, prefixed by the ASCII letters SC and either a colon ":" or equals sign "=". These forms are interpreted as follows.
在文本设置中，我们建议使用三种形式之一编写服务代码，前缀为ASCII字母SC和冒号“：”或等号“=”。这些形式解释如下。
SC: Indicates a Service Code representable using a subset of the ASCII characters. The colon is followed by one to four characters taken from the following set: letters, digits, and the characters in "-_+.*/?@" (not including quotes). Numerically, these characters have values in {42-43, 45-57, 63-90, 95, 97-122}. The Service Code is calculated by padding the string on the right with spaces (value 32) and intepreting the four-character result as a 32-bit big-endian number.
SC：表示可使用ASCII字符子集表示的服务代码。冒号后面是从以下集合中提取的一到四个字符：字母、数字和“-+.*/？@”（不包括引号）中的字符。在数字上，这些字符的值在{42-43、45-57、63-90、95、97-122}中。服务代码是通过在右边的字符串中填充空格（值32）并将四个字符的结果解释为32位的大端数字来计算的。
SC= Indicates a decimal Service Code. The equals sign is followed by any number of decimal digits, which specify the Service Code. Values above 4294967294 are illegal.
SC=表示十进制服务代码。等号后跟任意数量的十进制数字，用于指定服务代码。高于4294967294的值是非法的。
SC=x or SC=X Indicates a hexadecimal Service Code. The "x" or "X" is followed by any number of hexadecimal digits (upper or lower case), which specify the Service Code. Values above 4294967294 are illegal.
SC=x或SC=x表示十六进制服务代码。“x”或“x”后跟任意数量的十六进制数字（大写或小写），用于指定服务代码。高于4294967294的值是非法的。
Thus, the Service Code 1717858426 might be represented in text as either SC:fdpz, SC=1717858426, or SC=x6664707A.
因此，服务代码1717858426可以在文本中表示为SC:fdpz、SC＝1717858426或SC＝x6664707A。
In the second phase of the three-way handshake, the server moves from the LISTEN state to RESPOND and sends a DCCP-Response message to the client. In this phase, a server will often specify the features it would like to use, either from among those the client requested or in addition to those. Among these options is the congestion control mechanism the server expects to use.
在三方握手的第二阶段，服务器从侦听状态移动到响应状态，并向客户端发送DCCP响应消息。在这个阶段，服务器通常会指定它想要使用的特性，或者是从客户机请求的特性中指定，或者是在这些特性之外指定。这些选项中包括服务器期望使用的拥塞控制机制。
The server MAY respond to a DCCP-Request packet with a DCCP-Reset packet to refuse the connection. Relevant Reset Codes for refusing a connection include 7, "Connection Refused", when the DCCP-Request's Destination Port did not correspond to a DCCP port open for listening; 8, "Bad Service Code", when the DCCP-Request's Service Code did not correspond to the service code registered with the Destination Port; and 9, "Too Busy", when the server is currently too busy to respond to requests. The server SHOULD limit the rate at which it generates these resets; for example, to not more than 1024 per second.
服务器可以使用DCCP重置数据包响应DCCP请求数据包以拒绝连接。用于拒绝连接的相关重置代码包括7，“拒绝连接”，当DCCP请求的目标端口与打开用于侦听的DCCP端口不对应时；8、“坏服务代码”，当DCCP请求的服务代码与目标端口注册的服务代码不对应时；和9，“太忙”，当服务器当前太忙而无法响应请求时。服务器应限制其生成这些重置的速率；例如，每秒不超过1024次。
The server SHOULD NOT retransmit DCCP-Response packets; the client will retransmit the DCCP-Request if necessary. (Note that the "retransmitted" DCCP-Request will have, at least, a different sequence number from the "original" DCCP-Request. The server can thus distinguish true retransmissions from network duplicates.) The server will detect that the retransmitted DCCP-Request applies to an existing connection because of its Source and Destination Ports. Every valid DCCP-Request received while the server is in the RESPOND state MUST elicit a new DCCP-Response. Each new DCCP-Response MUST increment the server's Sequence Number by one and MUST include the same application data, if any, as the original DCCP-Response.
服务器不应重新传输DCCP响应数据包；如有必要，客户端将重新传输DCCP请求。（请注意，“重新传输的”DCCP请求将至少具有与“原始”DCCP请求不同的序列号。因此，服务器可以区分真实的重新传输和网络副本。）服务器将检测到重新传输的DCCP请求由于其源端口和目标端口而适用于现有连接。服务器处于响应状态时收到的每个有效DCCP请求都必须引发新的DCCP响应。每个新的DCCP响应必须将服务器的序列号增加1，并且必须包含与原始DCCP响应相同的应用程序数据（如果有）。
The server MUST NOT accept more than one piece of DCCP-Request application data per connection. In particular, the DCCP-Response sent in reply to a retransmitted DCCP-Request with application data SHOULD contain a Data Dropped option, in which the retransmitted DCCP-Request data is reported with Drop Code 0, Protocol Constraints. The original DCCP-Request SHOULD also be reported in the Data Dropped option, either in a Normal Block (if the server accepted the data or
服务器在每个连接上不能接受多个DCCP请求应用程序数据。特别是，用应用程序数据回复重新传输的DCCP请求时发送的DCCP响应应包含数据删除选项，其中重新传输的DCCP请求数据使用删除代码0（协议约束）报告。原始DCCP请求也应该在数据删除选项中报告，或者在正常块中报告（如果服务器接受数据，或者
there was no data) or in a Drop Code 0 Drop Block (if the server refused the data the first time as well).
没有数据）或在Drop Code 0 Drop块中（如果服务器第一次也拒绝了数据）。
The Data Dropped and Init Cookie options are particularly useful for DCCP-Response packets (Sections 11.7 and 8.1.4).
数据丢弃和初始化Cookie选项对于DCCP响应数据包特别有用（第11.7节和第8.1.4节）。
The server leaves the RESPOND state for OPEN when it receives a valid DCCP-Ack from the client, completing the three-way handshake. It MAY also leave the RESPOND state for CLOSED after a timeout of not less than 4MSL (8 minutes); when doing so, it SHOULD send a DCCP-Reset with Reset Code 2, "Aborted", to clean up state at the client.
当服务器从客户端接收到有效的DCCP Ack并完成三方握手时，服务器将保持打开的响应状态。也可在不少于4MSL（8分钟）的超时后，保持关闭的响应状态；执行此操作时，应发送带有重置代码2“中止”的DCCP重置，以清除客户端的状态。
+--------+--------+--------+--------+--------+--------
|00100100| Length | Init Cookie Value ...
+--------+--------+--------+--------+--------+--------
Type=36
+--------+--------+--------+--------+--------+--------
|00100100| Length | Init Cookie Value ...
+--------+--------+--------+--------+--------+--------
Type=36
The Init Cookie option lets a DCCP server avoid having to hold any state until the three-way connection setup handshake has completed, in a similar fashion as for TCP SYN cookies [SYNCOOKIES]. The server wraps up the Service Code, server port, and any options it cares about from both the DCCP-Request and DCCP-Response in an opaque cookie. Typically the cookie will be encrypted using a secret known only to the server and will include a cryptographic checksum or magic value so that correct decryption can be verified. When the server receives the cookie back in the response, it can decrypt the cookie and instantiate all the state it avoided keeping. In the meantime, it need not move from the LISTEN state.
Init Cookie选项允许DCCP服务器避免在三方连接设置握手完成之前保持任何状态，其方式与TCP SYN Cookie[SYNCOOKIES]类似。服务器将DCCP请求和DCCP响应中的服务代码、服务器端口以及它关心的任何选项封装在一个不透明的cookie中。通常，cookie将使用只有服务器知道的秘密进行加密，并将包括加密校验和或魔术值，以便验证正确的解密。当服务器在响应中接收回cookie时，它可以解密cookie并实例化它避免保留的所有状态。同时，它不需要从侦听状态移动。
The Init Cookie option MUST NOT be sent on DCCP-Request or DCCP-Data packets. Any Init Cookie options received on DCCP-Request or DCCP-Data packets, or after the connection has been established (when the connection's state is >= OPEN), MUST be ignored. The server MAY include Init Cookie options in its DCCP-Response. If so, then the client MUST echo the same Init Cookie options, in the same order, in each succeeding DCCP packet until one of those packets is acknowledged (showing that the three-way handshake has completed) or the connection is reset. As a result, the client MUST NOT use DCCP-Data packets until the three-way handshake completes or the connection is reset. The Init Cookie options on a client packet MUST equal those received on the DCCP-Request indicated by the client packet's Acknowledgement Number. The server SHOULD design its Init Cookie format so that Init Cookies can be checked for tampering; it SHOULD respond to a tampered Init Cookie option by resetting the connection with Reset Code 10, "Bad Init Cookie".
不能在DCCP请求或DCCP数据包上发送Init Cookie选项。必须忽略在DCCP请求或DCCP数据包上或在建立连接后（当连接的状态为>=打开时）收到的任何Init Cookie选项。服务器可能在其DCCP响应中包含Init Cookie选项。如果是这样，则客户端必须在每个后续DCCP数据包中以相同的顺序回显相同的Init Cookie选项，直到其中一个数据包被确认（显示三方握手已完成）或连接被重置。因此，在三方握手完成或连接重置之前，客户端不得使用DCCP数据包。客户端数据包上的Init Cookie选项必须等于在由客户端数据包的确认号指示的DCCP请求上接收的选项。服务器应设计其Init Cookie格式，以便检查Init Cookie是否被篡改；它应该通过使用重置代码10“坏的初始化Cookie”重置连接来响应被篡改的初始化Cookie选项。
Init Cookie's precise implementation need not be specified here; since Init Cookies are opaque to the client, there are no interoperability concerns. An example cookie format might encrypt (using a secret key) the connection's initial sequence and acknowledgement numbers, ports, Service Code, any options included on the DCCP-Request packet and the corresponding DCCP-Response, a random salt, and a magic number. On receiving a reflected Init Cookie, the server would decrypt the cookie, validate it by checking its magic number, sequence numbers, and ports, and, if valid, create a corresponding socket using the options.
这里不需要指定Init Cookie的精确实现；由于Init cookie对客户端是不透明的，因此不存在互操作性问题。示例cookie格式可以加密（使用密钥）连接的初始序列和确认号、端口、服务代码、DCCP请求数据包上包含的任何选项以及相应的DCCP响应、随机salt和幻数。在接收到反射的Init Cookie时，服务器将解密Cookie，通过检查其幻数、序列号和端口来验证Cookie，如果有效，则使用选项创建相应的套接字。
Each individual Init Cookie option can hold at most 253 bytes of data, but a server can send multiple Init Cookie options to gain more space.
每个单独的Init Cookie选项最多可以保存253字节的数据，但服务器可以发送多个Init Cookie选项以获得更多空间。
When the client receives a DCCP-Response from the server, it moves from the REQUEST state to PARTOPEN and completes the three-way handshake by sending a DCCP-Ack packet to the server. The client remains in PARTOPEN until it can be sure that the server has received some packet the client sent from PARTOPEN (either the initial DCCP-Ack or a later packet). Clients in the PARTOPEN state that want to send data MUST do so using DCCP-DataAck packets, not DCCP-Data packets. This is because DCCP-Data packets lack Acknowledgement Numbers, so the server can't tell from a DCCP-Data packet whether the client saw its DCCP-Response. Furthermore, if the DCCP-Response included an Init Cookie, that Init Cookie MUST be included on every packet sent in PARTOPEN.
当客户端从服务器接收到DCCP响应时，它将从请求状态移动到部分打开状态，并通过向服务器发送DCCP Ack数据包来完成三方握手。客户端保持PARTOPEN状态，直到它可以确定服务器已收到客户端从PARTOPEN发送的某些数据包（初始DCCP Ack或稍后的数据包）。处于PARTOPEN状态且希望发送数据的客户端必须使用DCCP数据包，而不是DCCP数据包。这是因为DCCP数据包缺少确认号，因此服务器无法从DCCP数据包中判断客户端是否看到了其DCCP响应。此外，如果DCCP响应包含Init Cookie，则该Init Cookie必须包含在PARTOPEN中发送的每个数据包中。
The single DCCP-Ack sent when entering the PARTOPEN state might, of course, be dropped by the network. The client SHOULD ensure that some packet gets through eventually. The preferred mechanism would be a roughly 200-millisecond timer, set every time a packet is transmitted in PARTOPEN. If this timer goes off and the client is still in PARTOPEN, the client generates another DCCP-Ack and backs off the timer. If the client remains in PARTOPEN for more than 4MSL (8 minutes), it SHOULD reset the connection with Reset Code 2, "Aborted".
当然，当进入PARTOPEN状态时发送的单个DCCP Ack可能会被网络丢弃。客户机应确保某些数据包最终通过。首选的机制是一个大约200毫秒的计时器，每次以PARTOPEN传输数据包时都会设置该计时器。如果此计时器关闭且客户端仍处于部分打开状态，则客户端将生成另一个DCCP Ack并退出计时器。如果客户端保持部分打开状态超过4MSL（8分钟），则应使用重置代码2“中止”重置连接。
The client leaves the PARTOPEN state for OPEN when it receives a valid packet other than DCCP-Response, DCCP-Reset, or DCCP-Sync from the server.
当客户端从服务器接收到DCCP响应、DCCP重置或DCCP同步以外的有效数据包时，客户端将PARTOPEN状态保留为OPEN。
In the central data transfer phase of the connection, both server and client are in the OPEN state.
在连接的中心数据传输阶段，服务器和客户端都处于打开状态。
DCCP A sends DCCP-Data and DCCP-DataAck packets to DCCP B due to application events on host A. These packets are congestion-controlled by the CCID for the A-to-B half-connection. In contrast, DCCP-Ack packets sent by DCCP A are controlled by the CCID for the B-to-A half-connection. Generally, DCCP A will piggyback acknowledgement information on DCCP-Data packets when acceptable, creating DCCP-DataAck packets. DCCP-Ack packets are used when there is no data to send from DCCP A to DCCP B, or when the congestion state of the A-to-B CCID will not allow data to be sent.
由于主机A上的应用程序事件，DCCP A向DCCP B发送DCCP数据和DCCP数据包。这些数据包由A到B半连接的CCID控制拥塞。相反，DCCP A发送的DCCP Ack数据包由CCID控制，用于B对A连接。通常，DCCP A会在可接受时将确认信息携带到DCCP数据包上，从而创建DCCP数据包。当没有数据从DCCP A发送到DCCP B时，或者当A-to-B CCID的拥塞状态不允许发送数据时，使用DCCP Ack数据包。
DCCP-Sync and DCCP-SyncAck packets may also occur in the data transfer phase. Some cases causing DCCP-Sync generation are discussed in Section 7.5. One important distinction between DCCP-Sync packets and other packet types is that DCCP-Sync elicits an immediate acknowledgement. On receiving a valid DCCP-Sync packet, a DCCP endpoint MUST immediately generate and send a DCCP-SyncAck response (subject to any implementation rate limits); the Acknowledgement Number on that DCCP-SyncAck MUST equal the Sequence Number of the DCCP-Sync.
DCCP Sync和DCCP SyncAck数据包也可能发生在数据传输阶段。第7.5节讨论了导致DCCP同步生成的一些情况。DCCP同步数据包和其他数据包类型之间的一个重要区别是，DCCP同步会引发立即确认。在接收到有效的DCCP同步数据包时，DCCP端点必须立即生成并发送DCCP SyncAck响应（受任何实现速率限制）；该DCCP SyncAck上的确认号必须等于DCCP SYNCK的序列号。
A particular DCCP implementation might decide to initiate feature negotiation only once the OPEN state was reached, in which case it might not allow data transfer until some time later. Data received during that time SHOULD be rejected and reported using a Data Dropped Drop Block with Drop Code 0, Protocol Constraints (see Section 11.7).
特定的DCCP实现可能只在达到打开状态时才决定启动功能协商，在这种情况下，可能要过一段时间才能允许数据传输。在此期间接收到的数据应被拒绝，并使用数据删除块报告，删除代码为0，协议约束（见第11.7节）。
DCCP connection termination uses a handshake consisting of an optional DCCP-CloseReq packet, a DCCP-Close packet, and a DCCP-Reset packet. The server moves from the OPEN state, possibly through the CLOSEREQ state, to CLOSED; the client moves from OPEN through CLOSING to TIMEWAIT, and after 2MSL wait time (4 minutes) to CLOSED.
DCCP连接终止使用由可选DCCP CloseReq数据包、DCCP Close数据包和DCCP Reset数据包组成的握手。服务器从打开状态（可能通过CLOSEREQ状态）移动到关闭状态；客户端从打开到关闭移动到TIMEWAIT，并在2MSL等待时间（4分钟）后移动到关闭。
The sequence DCCP-CloseReq, DCCP-Close, DCCP-Reset is used when the server decides to close the connection but doesn't want to hold TIMEWAIT state:
当服务器决定关闭连接但不想保持TIMEWAIT状态时，使用顺序DCCP CloseReq、DCCP Close、DCCP Reset：
Client State Server State OPEN OPEN 1. <-- CloseReq <-- CLOSEREQ 2. CLOSING --> Close --> 3. <-- Reset <-- CLOSED (LISTEN) 4. TIMEWAIT 5. CLOSED
客户端状态服务器状态打开打开1。<--CloseReq<--CloseReq 2。关闭-->关闭-->3。<--重置<--关闭（侦听）4。时间等待5。关闭
A shorter sequence occurs when the client decides to close the connection.
当客户端决定关闭连接时，会出现较短的序列。
Client State Server State OPEN OPEN 1. CLOSING --> Close --> 2. <-- Reset <-- CLOSED (LISTEN) 3. TIMEWAIT 4. CLOSED
客户端状态服务器状态打开1。关闭-->关闭-->2。<--重置<--关闭（侦听）3。时间等待4。关闭
Finally, the server can decide to hold TIMEWAIT state:
最后，服务器可以决定保持TIMEWAIT状态：
Client State Server State OPEN OPEN 1. <-- Close <-- CLOSING 2. CLOSED --> Reset --> 3. TIMEWAIT 4. CLOSED (LISTEN)
客户端状态服务器状态打开打开1。<--关闭<--关闭2。关闭-->重置-->3。时间等待4。关闭（听）
In all cases, the receiver of the DCCP-Reset packet holds TIMEWAIT state for the connection. As in TCP, TIMEWAIT state, where an endpoint quietly preserves a socket for 2MSL (4 minutes) after its connection has closed, ensures that no connection duplicating the current connection's source and destination addresses and ports can start up while old packets might remain in the network.
在所有情况下，DCCP重置数据包的接收器都保持连接的TIMEWAIT状态。与TCP中一样，TIMEWAIT状态（端点在其连接关闭后安静地将套接字保留2MSL（4分钟））可确保在旧数据包可能保留在网络中时，不会启动复制当前连接的源和目标地址和端口的连接。
The termination handshake proceeds as follows. The receiver of a valid DCCP-CloseReq packet MUST respond with a DCCP-Close packet. The receiver of a valid DCCP-Close packet MUST respond with a DCCP-Reset packet with Reset Code 1, "Closed". The receiver of a valid DCCP-Reset packet -- which is also the sender of the DCCP-Close packet (and possibly the receiver of the DCCP-CloseReq packet) -- will hold TIMEWAIT state for the connection.
终止握手进行如下。有效DCCP CloseReq数据包的接收方必须使用DCCP Close数据包进行响应。有效DCCP关闭数据包的接收器必须使用重置代码为1“关闭”的DCCP重置数据包进行响应。有效DCCP重置数据包的接收方——也是DCCP Close数据包的发送方（也可能是DCCP CloseReq数据包的接收方）——将保持连接的TIMEWAIT状态。
A DCCP-Reset packet completes every DCCP connection, whether the termination is clean (due to application close; Reset Code 1, "Closed") or unclean. Unlike TCP, which has two distinct termination mechanisms (FIN and RST), DCCP ends all connections in a uniform manner. This is justified because some aspects of connection termination are the same independent of whether termination was clean. For instance, the endpoint that receives a valid DCCP-Reset SHOULD hold TIMEWAIT state for the connection. Processors that must distinguish between clean and unclean termination can examine the Reset Code. DCCP implementations generally transition to the CLOSED state after sending a DCCP-Reset packet.
DCCP重置数据包完成每个DCCP连接，无论终端是否干净（由于应用程序关闭；重置代码1，“关闭”）或不干净。与具有两种不同终止机制（FIN和RST）的TCP不同，DCCP以统一的方式结束所有连接。这是合理的，因为连接终止的某些方面与终止是否干净无关。例如，接收有效DCCP重置的端点应保持连接的TIMEWAIT状态。必须区分干净和不干净终端的处理器可以检查重置代码。DCCP实现通常在发送DCCP重置数据包后转换为关闭状态。
Endpoints in the CLOSEREQ and CLOSING states MUST retransmit DCCP-CloseReq and DCCP-Close packets, respectively, until leaving those
处于CLOSEREQ和CLOSING状态的端点必须分别重新传输DCCP CLOSEREQ和DCCP Close数据包，直到离开这些数据包
states. The retransmission timer should initially be set to go off in two round-trip times and should back off to not less than once every 64 seconds if no relevant response is received.
国家。重新传输计时器最初应设置为在两次往返时间内关闭，如果未收到相关响应，则应至少每64秒关闭一次。
Only the server can send a DCCP-CloseReq packet or enter the CLOSEREQ state. A server receiving a sequence-valid DCCP-CloseReq packet MUST respond with a DCCP-Sync packet and otherwise ignore the DCCP-CloseReq.
只有服务器可以发送DCCP CloseReq数据包或进入CloseReq状态。接收序列有效DCCP CloseReq数据包的服务器必须使用DCCP Sync数据包进行响应，否则将忽略DCCP CloseReq。
DCCP-Data, DCCP-DataAck, and DCCP-Ack packets received in CLOSEREQ or CLOSING states MAY be either processed or ignored.
在CLOSEREQ或CLOSING状态下接收的DCCP数据、DCCP数据包和DCCP Ack包可以被处理或忽略。
DCCP endpoints generate DCCP-Reset packets to terminate connections abnormally; a DCCP-Reset packet may be generated from any state. Resets sent in the CLOSED, LISTEN, and TIMEWAIT states use Reset Code 3, "No Connection", unless otherwise specified. Resets sent in the REQUEST or RESPOND states use Reset Code 4, "Packet Error", unless otherwise specified.
DCCP端点生成DCCP重置数据包以异常终止连接；可以从任何状态生成DCCP重置数据包。除非另有规定，否则在关闭、侦听和时间等待状态下发送的重置使用重置代码3“无连接”。除非另有规定，否则在请求或响应状态下发送的重置使用重置代码4“数据包错误”。
DCCP endpoints in CLOSED, LISTEN, or TIMEWAIT state may need to generate a DCCP-Reset packet in response to a packet received from a peer. Since these states have no associated sequence number variables, the Sequence and Acknowledgement Numbers on the DCCP-Reset packet R are taken from the received packet P, as follows.
处于关闭、侦听或时间等待状态的DCCP端点可能需要生成DCCP重置数据包，以响应从对等方接收的数据包。由于这些状态没有相关联的序列号变量，因此DCCP重置分组R上的序列号和确认号取自接收到的分组P，如下所示。
1. If P.ackno exists, then set R.seqno := P.ackno + 1. Otherwise, set R.seqno := 0.
1. 如果P.ackno存在，则设置R.seqno:=P.ackno+1。否则，设置R.seqno:=0。
2. Set R.ackno := P.seqno.
2. 设置R.ackno:=P.seqno。
3. If the packet used short sequence numbers (P.X == 0), then set the upper 24 bits of R.seqno and R.ackno to 0.
3. 如果数据包使用短序列号（P.X==0），则将R.seqno和R.ackno的上24位设置为0。
The most common state transitions discussed above can be summarized in the following state diagram. The diagram is illustrative; the text in Section 8.5 and elsewhere should be considered definitive. For example, there are arcs (not shown) from every state except CLOSED to TIMEWAIT, contingent on the receipt of a valid DCCP-Reset.
上面讨论的最常见的状态转换可以在下面的状态图中进行总结。该图是说明性的；第8.5节和其他章节中的文本应视为最终文本。例如，根据接收到有效的DCCP重置，除关闭到TIMEWAIT外，每个状态都有弧（未显示）。
+---------------------------+ +---------------------------+
| v v |
| +----------+ |
| +-------------+ CLOSED +------------+ |
| | passive +----------+ active | |
| | open open | |
| | snd Request | |
| v v |
| +----------+ +----------+ |
| | LISTEN | | REQUEST | |
| +----+-----+ +----+-----+ |
| | rcv Request rcv Response | |
| | snd Response snd Ack | |
| v v |
| +----------+ +----------+ |
| | RESPOND | | PARTOPEN | |
| +----+-----+ +----+-----+ |
| | rcv Ack/DataAck rcv packet | |
| | | |
| | +----------+ | |
| +------------>| OPEN |<-----------+ |
| +--+-+--+--+ |
| server active close | | | active close |
| snd CloseReq | | | or rcv CloseReq |
| | | | snd Close |
| | | | |
| +----------+ | | | +----------+ |
| | CLOSEREQ |<---------+ | +--------->| CLOSING | |
| +----+-----+ | +----+-----+ |
| | rcv Close | rcv Reset | |
| | snd Reset | | |
|<---------+ | v |
| | +----+-----+ |
| rcv Close | | TIMEWAIT | |
| snd Reset | +----+-----+ |
+-----------------------------+ | |
+-----------+
2MSL timer expires
+---------------------------+ +---------------------------+
| v v |
| +----------+ |
| +-------------+ CLOSED +------------+ |
| | passive +----------+ active | |
| | open open | |
| | snd Request | |
| v v |
| +----------+ +----------+ |
| | LISTEN | | REQUEST | |
| +----+-----+ +----+-----+ |
| | rcv Request rcv Response | |
| | snd Response snd Ack | |
| v v |
| +----------+ +----------+ |
| | RESPOND | | PARTOPEN | |
| +----+-----+ +----+-----+ |
| | rcv Ack/DataAck rcv packet | |
| | | |
| | +----------+ | |
| +------------>| OPEN |<-----------+ |
| +--+-+--+--+ |
| server active close | | | active close |
| snd CloseReq | | | or rcv CloseReq |
| | | | snd Close |
| | | | |
| +----------+ | | | +----------+ |
| | CLOSEREQ |<---------+ | +--------->| CLOSING | |
| +----+-----+ | +----+-----+ |
| | rcv Close | rcv Reset | |
| | snd Reset | | |
|<---------+ | v |
| | +----+-----+ |
| rcv Close | | TIMEWAIT | |
| snd Reset | +----+-----+ |
+-----------------------------+ | |
+-----------+
2MSL timer expires
This section presents an algorithm describing the processing steps a DCCP endpoint must go through when it receives a packet. A DCCP implementation need not implement the algorithm as it is described here, but any implementation MUST generate observable effects exactly as indicated by this pseudocode, except where allowed otherwise by another part of this document.
本节介绍一种算法，描述DCCP端点在接收数据包时必须经历的处理步骤。DCCP实现不需要实现此处所述的算法，但任何实现都必须生成与此伪代码完全相同的可观察效果，除非本文档另一部分另有规定。
The received packet is written as P, the socket as S. Socket variables are:
接收到的数据包写为P，套接字写为S。套接字变量为：
S.SWL - sequence number window low S.SWH - sequence number window high S.AWL - acknowledgement number window low S.AWH - acknowledgement number window high S.ISS - initial sequence number sent S.ISR - initial sequence number received S.OSR - first OPEN sequence number received S.GSS - greatest sequence number sent S.GSR - greatest valid sequence number received S.GAR - greatest valid acknowledgement number received on a non-Sync; initialized to S.ISS "Send packet" actions always use, and increment, S.GSS.
S.SWL-序列号窗口低S.SWH-序列号窗口高S.AWL-确认号窗口低S.AWH-确认号窗口高S.ISS-发送的初始序列号S.ISR-接收的初始序列号S.OSR-接收的第一个开放序列号S.GSS-发送的最大序列号S.GSR-最大有效序列号收到的编号S.GAR-在非同步上收到的最大有效确认编号；初始化为S.ISS“发送数据包”操作始终使用并递增S.GSS。
Step 1: Check header basics
/* This step checks for malformed packets. Packets that fail
these checks are ignored -- they do not receive Resets in
response */
If the packet is shorter than 12 bytes, drop packet and return
If P.type is not understood, drop packet and return
If P.Data Offset is smaller than the given packet type's
fixed header length or larger than the packet's length,
drop packet and return
If P.type is not Data, Ack, or DataAck and P.X == 0 (the packet
has short sequence numbers), drop packet and return
If the header checksum is incorrect, drop packet and return
If P.CsCov is too large for the packet size, drop packet and
return
Step 1: Check header basics
/* This step checks for malformed packets. Packets that fail
these checks are ignored -- they do not receive Resets in
response */
If the packet is shorter than 12 bytes, drop packet and return
If P.type is not understood, drop packet and return
If P.Data Offset is smaller than the given packet type's
fixed header length or larger than the packet's length,
drop packet and return
If P.type is not Data, Ack, or DataAck and P.X == 0 (the packet
has short sequence numbers), drop packet and return
If the header checksum is incorrect, drop packet and return
If P.CsCov is too large for the packet size, drop packet and
return
Step 2: Check ports and process TIMEWAIT state
/* Flow ID is <src addr, src port, dst addr, dst port> 4-tuple */
Look up flow ID in table and get corresponding socket
If no socket, or S.state == TIMEWAIT,
/* The following Reset's Sequence and Acknowledgement Numbers
are taken from the input packet; see Section 8.3.1. */
Generate Reset(No Connection) unless P.type == Reset
Drop packet and return
Step 2: Check ports and process TIMEWAIT state
/* Flow ID is <src addr, src port, dst addr, dst port> 4-tuple */
Look up flow ID in table and get corresponding socket
If no socket, or S.state == TIMEWAIT,
/* The following Reset's Sequence and Acknowledgement Numbers
are taken from the input packet; see Section 8.3.1. */
Generate Reset(No Connection) unless P.type == Reset
Drop packet and return
Step 3: Process LISTEN state
If S.state == LISTEN,
If P.type == Request or P contains a valid Init Cookie option,
/* Must scan the packet's options to check for Init
Cookies. Only Init Cookies are processed here,
however; other options are processed in Step 8. This
scan need only be performed if the endpoint uses Init
Cookies */
/* Generate a new socket and switch to that socket */
Set S := new socket for this port pair
S.state = RESPOND
Choose S.ISS (initial seqno) or set from Init Cookies
Initialize S.GAR := S.ISS
Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookies
Continue with S.state == RESPOND
/* A Response packet will be generated in Step 11 */
Otherwise,
Generate Reset(No Connection) unless P.type == Reset
Drop packet and return
Step 3: Process LISTEN state
If S.state == LISTEN,
If P.type == Request or P contains a valid Init Cookie option,
/* Must scan the packet's options to check for Init
Cookies. Only Init Cookies are processed here,
however; other options are processed in Step 8. This
scan need only be performed if the endpoint uses Init
Cookies */
/* Generate a new socket and switch to that socket */
Set S := new socket for this port pair
S.state = RESPOND
Choose S.ISS (initial seqno) or set from Init Cookies
Initialize S.GAR := S.ISS
Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookies
Continue with S.state == RESPOND
/* A Response packet will be generated in Step 11 */
Otherwise,
Generate Reset(No Connection) unless P.type == Reset
Drop packet and return
Step 4: Prepare sequence numbers in REQUEST
If S.state == REQUEST,
If (P.type == Response or P.type == Reset)
and S.AWL <= P.ackno <= S.AWH,
/* Set sequence number variables corresponding to the
other endpoint, so P will pass the tests in Step 6 */
Set S.GSR, S.ISR, S.SWL, S.SWH
/* Response processing continues in Step 10; Reset
processing continues in Step 9 */
Otherwise,
/* Only Response and Reset are valid in REQUEST state */
Generate Reset(Packet Error)
Drop packet and return
Step 4: Prepare sequence numbers in REQUEST
If S.state == REQUEST,
If (P.type == Response or P.type == Reset)
and S.AWL <= P.ackno <= S.AWH,
/* Set sequence number variables corresponding to the
other endpoint, so P will pass the tests in Step 6 */
Set S.GSR, S.ISR, S.SWL, S.SWH
/* Response processing continues in Step 10; Reset
processing continues in Step 9 */
Otherwise,
/* Only Response and Reset are valid in REQUEST state */
Generate Reset(Packet Error)
Drop packet and return
Step 5: Prepare sequence numbers for Sync
If P.type == Sync or P.type == SyncAck,
If S.AWL <= P.ackno <= S.AWH and P.seqno >= S.SWL,
/* P is valid, so update sequence number variables
accordingly. After this update, P will pass the tests
in Step 6. A SyncAck is generated if necessary in
Step 15 */
Update S.GSR, S.SWL, S.SWH
Otherwise,
Drop packet and return
Step 5: Prepare sequence numbers for Sync
If P.type == Sync or P.type == SyncAck,
If S.AWL <= P.ackno <= S.AWH and P.seqno >= S.SWL,
/* P is valid, so update sequence number variables
accordingly. After this update, P will pass the tests
in Step 6. A SyncAck is generated if necessary in
Step 15 */
Update S.GSR, S.SWL, S.SWH
Otherwise,
Drop packet and return
Step 6: Check sequence numbers
If P.X == 0 and the relevant Allow Short Seqnos feature is 0,
/* Packet has short seqnos, but short seqnos not allowed */
Drop packet and return
Otherwise, if P.X == 0,
Extend P.seqno and P.ackno to 48 bits using the procedure
in Section 7.6
Let LSWL = S.SWL and LAWL = S.AWL
If P.type == CloseReq or P.type == Close or P.type == Reset,
LSWL := S.GSR + 1, LAWL := S.GAR
If LSWL <= P.seqno <= S.SWH
and (P.ackno does not exist or LAWL <= P.ackno <= S.AWH),
Update S.GSR, S.SWL, S.SWH
If P.type != Sync,
Update S.GAR
Otherwise,
If P.type == Reset,
Send Sync packet acknowledging S.GSR
Otherwise,
Send Sync packet acknowledging P.seqno
Drop packet and return
Step 6: Check sequence numbers
If P.X == 0 and the relevant Allow Short Seqnos feature is 0,
/* Packet has short seqnos, but short seqnos not allowed */
Drop packet and return
Otherwise, if P.X == 0,
Extend P.seqno and P.ackno to 48 bits using the procedure
in Section 7.6
Let LSWL = S.SWL and LAWL = S.AWL
If P.type == CloseReq or P.type == Close or P.type == Reset,
LSWL := S.GSR + 1, LAWL := S.GAR
If LSWL <= P.seqno <= S.SWH
and (P.ackno does not exist or LAWL <= P.ackno <= S.AWH),
Update S.GSR, S.SWL, S.SWH
If P.type != Sync,
Update S.GAR
Otherwise,
If P.type == Reset,
Send Sync packet acknowledging S.GSR
Otherwise,
Send Sync packet acknowledging P.seqno
Drop packet and return
Step 7: Check for unexpected packet types
If (S.is_server and P.type == CloseReq)
or (S.is_server and P.type == Response)
or (S.is_client and P.type == Request)
or (S.state >= OPEN and P.type == Request
and P.seqno >= S.OSR)
or (S.state >= OPEN and P.type == Response
and P.seqno >= S.OSR)
or (S.state == RESPOND and P.type == Data),
Send Sync packet acknowledging P.seqno
Drop packet and return
Step 7: Check for unexpected packet types
If (S.is_server and P.type == CloseReq)
or (S.is_server and P.type == Response)
or (S.is_client and P.type == Request)
or (S.state >= OPEN and P.type == Request
and P.seqno >= S.OSR)
or (S.state >= OPEN and P.type == Response
and P.seqno >= S.OSR)
or (S.state == RESPOND and P.type == Data),
Send Sync packet acknowledging P.seqno
Drop packet and return
Step 8: Process options and mark acknowledgeable
/* Option processing is not specifically described here.
Certain options, such as Mandatory, may cause the connection
to be reset, in which case Steps 9 and on are not executed */
Mark packet as acknowledgeable (in Ack Vector terms, Received
or Received ECN Marked)
Step 8: Process options and mark acknowledgeable
/* Option processing is not specifically described here.
Certain options, such as Mandatory, may cause the connection
to be reset, in which case Steps 9 and on are not executed */
Mark packet as acknowledgeable (in Ack Vector terms, Received
or Received ECN Marked)
Step 9: Process Reset If P.type == Reset, Tear down connection S.state := TIMEWAIT Set TIMEWAIT timer Drop packet and return
步骤9：如果P.type==Reset，则处理Reset，断开连接S.state:=TIMEWAIT Set TIMEWAIT timer Drop数据包并返回
Step 10: Process REQUEST state (second part)
If S.state == REQUEST,
/* If we get here, P is a valid Response from the server (see
Step 4), and we should move to PARTOPEN state. PARTOPEN
means send an Ack, don't send Data packets, retransmit
Acks periodically, and always include any Init Cookie from
the Response */
S.state := PARTOPEN
Set PARTOPEN timer
Continue with S.state == PARTOPEN
/* Step 12 will send the Ack completing the three-way
handshake */
Step 10: Process REQUEST state (second part)
If S.state == REQUEST,
/* If we get here, P is a valid Response from the server (see
Step 4), and we should move to PARTOPEN state. PARTOPEN
means send an Ack, don't send Data packets, retransmit
Acks periodically, and always include any Init Cookie from
the Response */
S.state := PARTOPEN
Set PARTOPEN timer
Continue with S.state == PARTOPEN
/* Step 12 will send the Ack completing the three-way
handshake */
Step 11: Process RESPOND state
If S.state == RESPOND,
If P.type == Request,
Send Response, possibly containing Init Cookie
If Init Cookie was sent,
Destroy S and return
/* Step 3 will create another socket when the client
completes the three-way handshake */
Otherwise,
S.OSR := P.seqno
S.state := OPEN
Step 11: Process RESPOND state
If S.state == RESPOND,
If P.type == Request,
Send Response, possibly containing Init Cookie
If Init Cookie was sent,
Destroy S and return
/* Step 3 will create another socket when the client
completes the three-way handshake */
Otherwise,
S.OSR := P.seqno
S.state := OPEN
Step 12: Process PARTOPEN state
If S.state == PARTOPEN,
If P.type == Response,
Send Ack
Otherwise, if P.type != Sync,
S.OSR := P.seqno
S.state := OPEN
Step 12: Process PARTOPEN state
If S.state == PARTOPEN,
If P.type == Response,
Send Ack
Otherwise, if P.type != Sync,
S.OSR := P.seqno
S.state := OPEN
Step 13: Process CloseReq If P.type == CloseReq and S.state < CLOSEREQ, Generate Close S.state := CLOSING Set CLOSING timer
步骤13：如果P.type==CloseReq和S.state<CloseReq，则处理CloseReq，生成closes.state:=关闭设置关闭计时器
Step 14: Process Close If P.type == Close, Generate Reset(Closed) Tear down connection Drop packet and return
步骤14：如果P.type==Close，则处理Close，生成Reset（Closed）中断连接丢弃包并返回
Step 15: Process Sync If P.type == Sync, Generate SyncAck
步骤15：处理同步如果P.type==Sync，生成SyncAck
Step 16: Process data
/* At this point any application data on P can be passed to the
application, except that the application MUST NOT receive
data from more than one Request or Response */
Step 16: Process data
/* At this point any application data on P can be passed to the
application, except that the application MUST NOT receive
data from more than one Request or Response */
DCCP uses a header checksum to protect its header against corruption. Generally, this checksum also covers any application data. DCCP applications can, however, request that the header checksum cover only part of the application data, or perhaps no application data at all. Link layers may then reduce their protection on unprotected parts of DCCP packets. For some noisy links, and for applications that can tolerate corruption, this can greatly improve delivery rates and perceived performance.
DCCP使用报头校验和来保护其报头免受损坏。通常，该校验和还包括任何应用程序数据。然而，DCCP应用程序可以请求报头校验和只覆盖部分应用程序数据，或者根本不覆盖任何应用程序数据。然后，链路层可能会减少对DCCP数据包未受保护部分的保护。对于一些嘈杂的链接，以及能够容忍损坏的应用程序，这可以极大地提高交付率和感知性能。
Checksum coverage may eventually impact congestion control mechanisms as well. A packet with corrupt application data and complete checksum coverage is treated as lost. This incurs a heavy-duty loss response from the sender's congestion control mechanism, which can unfairly penalize connections on links with high background corruption. The combination of reduced checksum coverage and Data Checksum options may let endpoints report packets as corrupt rather than dropped, using Data Dropped options and Drop Code 3 (see Section 11.7). This may eventually benefit applications. However, further research is required to determine an appropriate response to corruption, which can sometimes correlate with congestion. Corrupt packets currently incur a loss response.
校验和覆盖率最终也可能影响拥塞控制机制。应用程序数据损坏且校验和覆盖率完全的数据包将被视为丢失。这会导致发送方的拥塞控制机制产生严重的丢失响应，这会不公平地惩罚具有高背景损坏的链接上的连接。减少的校验和覆盖率和数据校验和选项的组合可能会让端点使用数据丢弃选项和丢弃代码3（参见第11.7节）将数据包报告为损坏而不是丢弃。这最终可能会使应用程序受益。然而，还需要进一步研究，以确定对腐败的适当反应，腐败有时可能与拥堵有关。损坏的数据包当前导致丢失响应。
The Data Checksum option, which contains a strong CRC, lets endpoints detect application data corruption. An API can then be used to avoid delivering corrupt data to the application, even if links deliver corrupt data to the endpoint due to reduced checksum coverage. However, the use of reduced checksum coverage for applications that demand correct data is currently considered experimental. This is because the combined loss-plus-corruption rate for packets with reduced checksum coverage may be significantly higher than that for packets with full checksum coverage, although the loss rate will generally be lower. Actual behavior will depend on link design; further research and experience is required.
包含强CRC的数据校验和选项允许端点检测应用程序数据损坏。然后，可以使用API来避免向应用程序传递损坏的数据，即使由于校验和覆盖率降低而导致链接向端点传递损坏的数据。然而，对于需要正确数据的应用程序，使用减少的校验和覆盖率目前被认为是实验性的。这是因为校验和覆盖率降低的数据包的综合丢失加损坏率可能显著高于校验和覆盖率完全的数据包，尽管丢失率通常较低。实际行为将取决于链接设计；需要进一步的研究和经验。
Reduced checksum coverage introduces some security considerations; see Section 18.1. See Appendix B for further motivation and
减少校验和覆盖率引入了一些安全考虑；见第18.1节。参见附录B，了解更多动机和建议
discussion. DCCP's implementation of reduced checksum coverage was inspired by UDP-Lite [RFC3828].
讨论DCCP减少校验和覆盖率的实现受到UDP Lite[RFC3828]的启发。
DCCP uses the TCP/IP checksum algorithm. The Checksum field in the DCCP generic header (see Section 5.1) equals the 16-bit one's complement of the one's complement sum of all 16-bit words in the DCCP header, DCCP options, a pseudoheader taken from the network-layer header, and, depending on the value of the Checksum Coverage field, some or all of the application data. When calculating the checksum, the Checksum field itself is treated as 0. If a packet contains an odd number of header and payload bytes to be checksummed, 8 zero bits are added on the right to form a 16-bit word for checksum purposes. The pad byte is not transmitted as part of the packet.
DCCP使用TCP/IP校验和算法。DCCP通用报头中的校验和字段（见第5.1节）等于DCCP报头中所有16位字的16位一补和、DCCP选项、取自网络层报头的伪报头，以及根据校验和覆盖字段的值，部分或全部应用数据。计算校验和时，校验和字段本身被视为0。如果数据包包含奇数个要校验和的报头和有效负载字节，则在右侧添加8个零位以形成16位字，用于校验和。pad字节不作为数据包的一部分传输。
The pseudoheader is calculated as for TCP. For IPv4, it is 96 bits long and consists of the IPv4 source and destination addresses, the IP protocol number for DCCP (padded on the left with 8 zero bits), and the DCCP length as a 16-bit quantity (the length of the DCCP header with options, plus the length of any data); see [RFC793], Section 3.1. For IPv6, it is 320 bits long, and consists of the IPv6 source and destination addresses, the DCCP length as a 32-bit quantity, and the IP protocol number for DCCP (padded on the left with 24 zero bits); see [RFC2460], Section 8.1.
伪报头的计算方法与TCP相同。对于IPv4，其长度为96位，由IPv4源地址和目标地址、DCCP的IP协议号（左侧用8个零位填充）和16位数量的DCCP长度（带选项的DCCP头的长度加上任何数据的长度）组成；见[RFC793]，第3.1节。对于IPv6，其长度为320位，由IPv6源地址和目标地址、作为32位数量的DCCP长度以及DCCP的IP协议号（左侧用24个零位填充）组成；见[RFC2460]，第8.1节。
Packets with invalid header checksums MUST be ignored. In particular, their options MUST NOT be processed.
必须忽略具有无效标头校验和的数据包。特别是，不得处理其选项。
The Checksum Coverage field in the DCCP generic header (see Section 5.1) specifies what parts of the packet are covered by the Checksum field, as follows:
DCCP通用报头中的校验和覆盖范围字段（见第5.1节）指定校验和字段覆盖数据包的哪些部分，如下所示：
CsCov = 0 The Checksum field covers the DCCP header, DCCP options, network-layer pseudoheader, and all application data in the packet, possibly padded on the right with zeros to an even number of bytes.
CsCov=0校验和字段包括DCCP头、DCCP选项、网络层伪头和数据包中的所有应用程序数据，可能在右侧用零填充到偶数字节。
CsCov = 1-15 The Checksum field covers the DCCP header, DCCP options, network-layer pseudoheader, and the initial (CsCov-1)*4 bytes of the packet's application data.
CsCov=1-15校验和字段包括DCCP头、DCCP选项、网络层伪头和数据包应用数据的初始（CsCov-1）*4字节。
Thus, if CsCov is 1, none of the application data is protected by the header checksum. The value (CsCov-1)*4 MUST be less than or equal to the length of the application data. Packets with invalid CsCov values MUST be ignored; in particular, their options MUST NOT be
因此，如果CsCov为1，则没有任何应用程序数据受到报头校验和的保护。值（CsCov-1）*4必须小于或等于应用程序数据的长度。必须忽略具有无效CsCov值的数据包；特别是，他们的选择决不能被忽视
processed. The meanings of values other than 0 and 1 should be considered experimental.
处理。0和1以外的值的含义应视为实验性的。
Values other than 0 specify that corruption is acceptable in some or all of the DCCP packet's application data. In fact, DCCP cannot even detect corruption in areas not covered by the header checksum, unless the Data Checksum option is used. Applications should not make any assumptions about the correctness of received data not covered by the checksum and should, if necessary, introduce their own validity checks.
0以外的值指定在DCCP数据包的部分或全部应用程序数据中可以接受损坏。事实上，除非使用数据校验和选项，否则DCCP甚至无法检测头校验和未覆盖区域中的损坏。应用程序不应对校验和未涵盖的接收数据的正确性做出任何假设，如有必要，应引入自己的有效性检查。
A DCCP application interface should let sending applications suggest a value for CsCov for sent packets, defaulting to 0 (full coverage). The Minimum Checksum Coverage feature, described below, lets an endpoint refuse delivery of application data on packets with partial checksum coverage; by default, only fully covered application data is accepted. Lower layers that support partial error detection MAY use the Checksum Coverage field as a hint of where errors do not need to be detected. Lower layers MUST use a strong error detection mechanism to detect at least errors that occur in the sensitive part of the packet, and to discard damaged packets. The sensitive part consists of the bytes between the first byte of the IP header and the last byte identified by Checksum Coverage.
DCCP应用程序接口应允许发送应用程序为发送的数据包建议CsCov值，默认为0（完全覆盖）。下面描述的最小校验和覆盖特性允许端点在具有部分校验和覆盖的分组上拒绝应用程序数据的传递；默认情况下，只接受完全覆盖的应用程序数据。支持部分错误检测的较低层可以使用校验和覆盖率字段作为不需要检测错误的提示。较低层必须使用强大的错误检测机制，至少检测数据包敏感部分发生的错误，并丢弃损坏的数据包。敏感部分由IP头的第一个字节和校验和覆盖率标识的最后一个字节之间的字节组成。
For more details on application and lower-layer interface issues relating to partial checksumming, see [RFC3828].
有关与部分校验和相关的应用程序和下层接口问题的更多详细信息，请参阅[RFC3828]。
The Minimum Checksum Coverage feature lets a DCCP endpoint determine whether its peer is willing to accept packets with reduced Checksum Coverage. For example, DCCP A sends a "Change R(Minimum Checksum Coverage, 1)" option to DCCP B to check whether B is willing to accept packets with Checksum Coverage set to 1.
最小校验和覆盖率功能允许DCCP端点确定其对等方是否愿意接受校验和覆盖率降低的数据包。例如，DCCP A向DCCP B发送“更改R（最小校验和覆盖率，1）”选项，以检查B是否愿意接受校验和覆盖率设置为1的数据包。
Minimum Checksum Coverage has feature number 8 and is server-priority. It takes one-byte integer values between 0 and 15; values of 16 or more are reserved. Minimum Checksum Coverage/B reflects values of Checksum Coverage that DCCP B finds unacceptable. Say that the value of Minimum Checksum Coverage/B is MinCsCov. Then:
最小校验和覆盖率具有功能编号8，是服务器优先级。它采用0到15之间的一字节整数值；保留16或更多的值。最小校验和覆盖率/B反映DCCP B认为不可接受的校验和覆盖率值。假设最小校验和覆盖率/B的值为MinCsCov。然后：
o If MinCsCov = 0, then DCCP B only finds packets with CsCov = 0 acceptable.
o 如果MinCsCov=0，则DCCP B仅发现CsCov=0的数据包是可接受的。
o If MinCsCov > 0, then DCCP B additionally finds packets with CsCov >= MinCsCov acceptable.
o 如果MinCsCov>0，则DCCP B另外发现CsCov>=MinCsCov的数据包是可接受的。
DCCP B MAY refuse to process application data from packets with unacceptable Checksum Coverage. Such packets SHOULD be reported using Data Dropped options (Section 11.7) with Drop Code 0, Protocol Constraints. New connections start with Minimum Checksum Coverage 0 for both endpoints.
DCCP B可能拒绝处理来自具有不可接受校验和覆盖范围的数据包的应用程序数据。应使用数据丢弃选项（第11.7节）报告此类数据包，丢弃代码为0，协议约束。新连接从两个端点的最小校验和覆盖率0开始。
The Data Checksum option holds a 32-bit CRC-32c cyclic redundancy-check code of a DCCP packet's application data.
数据校验和选项保存DCCP数据包应用数据的32位CRC-32c循环冗余校验码。
+--------+--------+--------+--------+--------+--------+
|00101100|00000110| CRC-32c |
+--------+--------+--------+--------+--------+--------+
Type=44 Length=6
+--------+--------+--------+--------+--------+--------+
|00101100|00000110| CRC-32c |
+--------+--------+--------+--------+--------+--------+
Type=44 Length=6
The sending DCCP computes the CRC of the bytes comprising the application data area and stores it in the option data. The CRC-32c algorithm used for Data Checksum is the same as that used for SCTP [RFC3309]; note that the CRC-32c of zero bytes of data equals zero. The DCCP header checksum will cover the Data Checksum option, so the data checksum must be computed before the header checksum.
发送DCCP计算包含应用数据区域的字节的CRC，并将其存储在选项数据中。用于数据校验和的CRC-32c算法与用于SCTP的CRC-32c算法相同[RFC3309]；请注意，零字节数据的CRC-32c等于零。DCCP标头校验和将覆盖数据校验和选项，因此必须在标头校验和之前计算数据校验和。
A DCCP endpoint receiving a packet with a Data Checksum option either MUST or MAY check the Data Checksum; the choice depends on the value of the Check Data Checksum feature described below. If it checks the checksum, it computes the received application data's CRC-32c using the same algorithm as the sender and compares the result with the Data Checksum value. If the CRCs differ, the endpoint reacts in one of two ways:
接收具有数据校验和选项的数据包的DCCP端点必须或可以检查数据校验和；选择取决于下面描述的检查数据校验和功能的值。如果它检查校验和，则使用与发送方相同的算法计算接收到的应用程序数据的CRC-32c，并将结果与数据校验和值进行比较。如果CRC不同，端点会以以下两种方式之一作出反应：
o The receiving application may have requested delivery of known-corrupt data via some optional API. In this case, the packet's data MUST be delivered to the application, with a note that it is known to be corrupt. Furthermore, the receiving endpoint MUST report the packet as delivered corrupt using a Data Dropped option (Drop Code 7, Delivered Corrupt).
o 接收应用程序可能已通过某些可选API请求传递已知损坏的数据。在这种情况下，必须将数据包的数据发送到应用程序，并注意它已损坏。此外，接收端点必须使用数据丢弃选项（丢弃代码7，已交付损坏）将数据包报告为已交付损坏。
o Otherwise, the receiving endpoint MUST drop the application data and report that data as dropped due to corruption using a Data Dropped option (Drop Code 3, Corrupt).
o 否则，接收端点必须删除应用程序数据，并使用数据删除选项（删除代码3，损坏）报告由于损坏而删除的数据。
In either case, the packet is considered acknowledgeable (since its header was processed) and will therefore be acknowledged using the equivalent of Ack Vector's Received or Received ECN Marked states.
在任何一种情况下，数据包都被认为是可确认的（因为它的报头已被处理），因此将使用Ack向量的接收或接收到的ECN标记状态的等价物进行确认。
Although Data Checksum is intended for packets containing application data, it may be included on other packets, such as DCCP-Ack, DCCP-
尽管数据校验和用于包含应用程序数据的数据包，但它也可以包括在其他数据包中，例如DCCP Ack、DCCP Ack-
Sync, and DCCP-SyncAck. The receiver SHOULD calculate the application data area's CRC-32c on such packets, just as it does for DCCP-Data and similar packets. If the CRCs differ, the packets similarly MUST be reported using Data Dropped options (Drop Code 3), although their application data areas would not be delivered to the application in any case.
同步和DCCP同步。接收器应计算此类数据包上应用程序数据区的CRC-32c，就像它对DCCP数据和类似数据包所做的那样。如果CRC不同，则同样必须使用数据丢弃选项（丢弃代码3）报告数据包，尽管其应用程序数据区域在任何情况下都不会交付给应用程序。
The Check Data Checksum feature lets a DCCP endpoint determine whether its peer will definitely check Data Checksum options. DCCP A sends a Mandatory "Change R(Check Data Checksum, 1)" option to DCCP B to require it to check Data Checksum options (the connection will be reset if it cannot).
检查数据校验和功能允许DCCP端点确定其对等端是否一定会检查数据校验和选项。DCCP A向DCCP B发送一个强制的“更改R（检查数据校验和，1）”选项，要求其检查数据校验和选项（如果不能，连接将被重置）。
Check Data Checksum has feature number 9 and is server-priority. It takes one-byte Boolean values. DCCP B MUST check any received Data Checksum options when Check Data Checksum/B is one, although it MAY check them even when Check Data Checksum/B is zero. Values of two or more are reserved. New connections start with Check Data Checksum 0 for both endpoints.
校验数据校验和功能编号为9，为服务器优先级。它需要一个字节的布尔值。当check Data Checksum（检查数据校验和）为1时，DCCP B必须检查所有接收的数据校验和选项，尽管即使check Data Checksum（检查数据校验和）为0，DCCP B也可能会检查这些选项。保留两个或两个以上的值。新连接从两个端点的检查数据校验和0开始。
Internet links must normally apply strong integrity checks to the packets they transmit [RFC3828, RFC3819]. This is the default case when the DCCP header's Checksum Coverage value equals zero (full coverage). However, the DCCP Checksum Coverage value might not be zero. By setting partial Checksum Coverage, the application indicates that it can tolerate corruption in the unprotected part of the application data. Recognizing this, link layers may reduce error detection and/or correction strength when transmitting this unprotected part. This, in turn, can significantly increase the likelihood of the endpoint's receiving corrupt data; Data Checksum lets the receiver detect that corruption with very high probability.
互联网链路通常必须对其传输的数据包进行强完整性检查[RFC3828，RFC3819]。当DCCP头的校验和覆盖率值等于零（完全覆盖）时，这是默认情况。但是，DCCP校验和覆盖率值可能不是零。通过设置部分校验和覆盖率，应用程序表明它可以容忍应用程序数据中未受保护部分的损坏。认识到这一点，链路层可在传输该未保护部分时降低错误检测和/或校正强度。这反过来又会显著增加端点接收损坏数据的可能性；数据校验和允许接收器以极高的概率检测到损坏。
Each congestion control mechanism supported by DCCP is assigned a congestion control identifier, or CCID: a number from 0 to 255. During connection setup, and optionally thereafter, the endpoints negotiate their congestion control mechanisms by negotiating the values for their Congestion Control ID features. Congestion Control ID has feature number 1. The CCID/A value equals the CCID in use for the A-to-B half-connection. DCCP B sends a "Change R(CCID, K)" option to ask DCCP A to use CCID K for its data packets.
DCCP支持的每个拥塞控制机制都分配了一个拥塞控制标识符，或CCID：一个从0到255的数字。在连接设置期间以及之后，端点可以通过协商其拥塞控制ID特性的值来协商其拥塞控制机制。拥塞控制ID具有功能编号1。CCID/A值等于A到B半连接使用的CCID。DCCP B发送“更改R（CCID，K）”选项，要求DCCP a对其数据包使用CCID K。
CCID is a server-priority feature, so CCID negotiation options can list multiple acceptable CCIDs, sorted in descending order of priority. For example, the option "Change R(CCID, 2 3 4)" asks the receiver to use CCID 2 for its packets, although CCIDs 3 and 4 are also acceptable. (This corresponds to the bytes "35, 6, 1, 2, 3, 4": Change R option (35), option length (6), feature ID (1), CCIDs (2, 3, 4).) Similarly, "Confirm L(CCID, 2, 2 3 4)" tells the receiver that the sender is using CCID 2 for its packets, but that CCIDs 3 and 4 might also be acceptable.
CCID是服务器优先级特性，因此CCID协商选项可以列出多个可接受的CCID，并按优先级降序排序。例如，选项“Change R（CCID，2 3 4）”要求接收机对其分组使用CCID 2，尽管CCID 3和4也是可以接受的。（这对应于字节“35,6,1,2,3,4”：更改R选项（35）、选项长度（6）、特征ID（1）、CCID（2,3,4）。）类似地，“确认L（CCID，2,2,3,4）”告诉接收方发送方正在对其数据包使用CCID 2，但CCID 3和4也可以接受。
Currently allocated CCIDs are as follows:
目前分配的CCID如下：
CCID Meaning Reference
---- ------- ---------
0-1 Reserved
2 TCP-like Congestion Control [RFC4341]
3 TCP-Friendly Rate Control [RFC4342]
4-255 Reserved
CCID Meaning Reference
---- ------- ---------
0-1 Reserved
2 TCP-like Congestion Control [RFC4341]
3 TCP-Friendly Rate Control [RFC4342]
4-255 Reserved
Table 5: DCCP Congestion Control Identifiers
表5:DCCP拥塞控制标识符
New connections start with CCID 2 for both endpoints. If this is unacceptable for a DCCP endpoint, that endpoint MUST send Mandatory Change(CCID) options on its first packets.
新连接从两个端点的CCID 2开始。如果这对于DCCP端点是不可接受的，则该端点必须在其第一个数据包上发送强制更改（CCID）选项。
All CCIDs standardized for use with DCCP will correspond to congestion control mechanisms previously standardized by the IETF. We expect that for quite some time, all such mechanisms will be TCP friendly, but TCP-friendliness is not an explicit DCCP requirement.
与DCCP一起使用的所有标准化CCID将对应于IETF先前标准化的拥塞控制机制。我们预计在相当长的一段时间内，所有这些机制都将是TCP友好的，但TCP友好性并不是明确的DCCP要求。
A DCCP implementation intended for general use, such as an implementation in a general-purpose operating system kernel, SHOULD implement at least CCID 2. The intent is to make CCID 2 broadly available for interoperability, although particular applications might disallow its use.
用于一般用途的DCCP实现，如通用操作系统内核中的实现，应至少实现CCID2。其目的是使CCID2广泛用于互操作性，尽管特定的应用程序可能不允许使用它。
CCID 2, TCP-like Congestion Control, denotes Additive Increase, Multiplicative Decrease (AIMD) congestion control with behavior modelled directly on TCP, including congestion window, slow start, timeouts, and so forth [RFC2581]. CCID 2 achieves maximum bandwidth over the long term, consistent with the use of end-to-end congestion control, but halves its congestion window in response to each congestion event. This leads to the abrupt rate changes typical of TCP. Applications should use CCID 2 if they prefer maximum bandwidth utilization to steadiness of rate. This is often the case for applications that are not playing their data directly to the user.
CCID 2，类似TCP的拥塞控制，表示加性增加、乘性减少（AIMD）拥塞控制，其行为直接基于TCP建模，包括拥塞窗口、慢启动、超时等[RFC2581]。CCID 2在长期内实现最大带宽，与端到端拥塞控制的使用一致，但在响应每个拥塞事件时将其拥塞窗口减半。这会导致TCP典型的速率突变。如果应用程序更喜欢最大带宽利用率而不是稳定的速率，则应使用CCID2。对于不直接向用户播放数据的应用程序来说，情况往往如此。
For example, a hypothetical application that transferred files over DCCP, using application-level retransmissions for lost packets, would prefer CCID 2 to CCID 3. On-line games may also prefer CCID 2.
例如，假设一个应用程序通过DCCP传输文件，对丢失的数据包使用应用程序级重传，它更喜欢CCID 2而不是CCID 3。在线游戏也可能更喜欢CCID 2。
CCID 2 is further described in [RFC4341].
CCID 2在[RFC4341]中进一步描述。
CCID 3 denotes TCP-Friendly Rate Control (TFRC), an equation-based rate-controlled congestion control mechanism. TFRC is designed to be reasonably fair when competing for bandwidth with TCP-like flows, where a flow is "reasonably fair" if its sending rate is generally within a factor of two of the sending rate of a TCP flow under the same conditions. However, TFRC has a much lower variation of throughput over time compared with TCP, which makes CCID 3 more suitable than CCID 2 for applications such as streaming media where a relatively smooth sending rate is important.
CCID3表示TCP友好速率控制（TFRC），一种基于等式的速率控制拥塞控制机制。TFRC设计为在与类似TCP的流竞争带宽时合理公平，其中，如果在相同条件下，流的发送速率通常在TCP流发送速率的两倍以内，则流是“合理公平”的。然而，与TCP相比，TFRC的吞吐量随时间的变化要小得多，这使得CCID 3比CCID 2更适合于相对平滑的发送速率非常重要的流媒体等应用。
CCID 3 is further described in [RFC4342]. The TFRC congestion control algorithms were initially described in [RFC3448].
CCID 3在[RFC4342]中进一步描述。TFRC拥塞控制算法最初在[RFC3448]中描述。
Half of the option types, feature numbers, and Reset Codes are reserved for CCID-specific use. CCIDs may often need new options, for communicating acknowledgement or rate information, for example; reserved option spaces let CCIDs create options at will without polluting the global option space. Option 128 might have different meanings on a half-connection using CCID 4 and a half-connection using CCID 8. CCID-specific options and features will never conflict with global options and features introduced by later versions of this specification.
一半的选项类型、功能部件编号和重置代码保留给CCID专用。CCID可能经常需要新的选项，例如用于通信确认或速率信息；保留选项空间允许CCID随意创建选项，而不会污染全局选项空间。对于使用CCID 4的半连接和使用CCID 8的半连接，选项128可能具有不同的含义。CCID特定的选项和功能将永远不会与本规范更高版本引入的全局选项和功能冲突。
Any packet may contain information meant for either half-connection, so CCID-specific option types, feature numbers, and Reset Codes explicitly signal the half-connection to which they apply.
任何数据包都可能包含用于任何半连接的信息，因此CCID特定的选项类型、功能部件号和重置代码明确地向其应用的半连接发送信号。
o Option numbers 128 through 191 are for options sent from the HC-Sender to the HC-Receiver; option numbers 192 through 255 are for options sent from the HC-Receiver to the HC-Sender.
o 选项编号128到191用于从HC发送方发送到HC接收方的选项；选项编号192到255用于从HC接收器发送到HC发送器的选项。
o Reset Codes 128 through 191 indicate that the HC-Sender reset the connection (most likely because of some problem with acknowledgements sent by the HC-Receiver). Reset Codes 192 through 255 indicate that the HC-Receiver reset the connection (most likely because of some problem with data packets sent by the HC-Sender).
o 重置代码128到191表示HC发送方重置了连接（很可能是因为HC接收方发送的确认存在问题）。重置代码192到255表示HC接收器重置了连接（很可能是因为HC发送器发送的数据包存在一些问题）。
o Finally, feature numbers 128 through 191 are used for features located at the HC-Sender; feature numbers 192 through 255 are for features located at the HC-Receiver. Since Change L and Confirm L options for a feature are sent by the feature location, we know that any Change L(128) option was sent by the HC-Sender, while any Change L(192) option was sent by the HC-Receiver. Similarly, Change R(128) options are sent by the HC-Receiver, while Change R(192) options are sent by the HC-Sender.
o 最后，特征编号128到191用于位于HC发送器处的特征；功能部件编号192至255用于HC接收器处的功能部件。由于特征的更改L和确认L选项由特征位置发送，因此我们知道任何更改L（128）选项都是由HC发送方发送的，而任何更改L（192）选项都是由HC接收方发送的。类似地，更改R（128）选项由HC接收器发送，而更改R（192）选项由HC发送器发送。
For example, consider a DCCP connection where the A-to-B half-connection uses CCID 4 and the B-to-A half-connection uses CCID 5. Here is how a sampling of CCID-specific options are assigned to half-connections.
例如，考虑一个DCCP连接，其中A到B半连接使用CCID 4，B-A半连接使用CCID 5。以下是如何将CCID特定选项的采样分配给半连接。
Relevant Relevant
Packet Option Half-conn. CCID
------ ------ ---------- ----
A > B 128 A-to-B 4
A > B 192 B-to-A 5
A > B Change L(128, ...) A-to-B 4
A > B Change R(192, ...) A-to-B 4
A > B Confirm L(128, ...) A-to-B 4
A > B Confirm R(192, ...) A-to-B 4
A > B Change R(128, ...) B-to-A 5
A > B Change L(192, ...) B-to-A 5
A > B Confirm R(128, ...) B-to-A 5
A > B Confirm L(192, ...) B-to-A 5
B > A 128 B-to-A 5
B > A 192 A-to-B 4
B > A Change L(128, ...) B-to-A 5
B > A Change R(192, ...) B-to-A 5
B > A Confirm L(128, ...) B-to-A 5
B > A Confirm R(192, ...) B-to-A 5
B > A Change R(128, ...) A-to-B 4
B > A Change L(192, ...) A-to-B 4
B > A Confirm R(128, ...) A-to-B 4
B > A Confirm L(192, ...) A-to-B 4
Relevant Relevant
Packet Option Half-conn. CCID
------ ------ ---------- ----
A > B 128 A-to-B 4
A > B 192 B-to-A 5
A > B Change L(128, ...) A-to-B 4
A > B Change R(192, ...) A-to-B 4
A > B Confirm L(128, ...) A-to-B 4
A > B Confirm R(192, ...) A-to-B 4
A > B Change R(128, ...) B-to-A 5
A > B Change L(192, ...) B-to-A 5
A > B Confirm R(128, ...) B-to-A 5
A > B Confirm L(192, ...) B-to-A 5
B > A 128 B-to-A 5
B > A 192 A-to-B 4
B > A Change L(128, ...) B-to-A 5
B > A Change R(192, ...) B-to-A 5
B > A Confirm L(128, ...) B-to-A 5
B > A Confirm R(192, ...) B-to-A 5
B > A Change R(128, ...) A-to-B 4
B > A Change L(192, ...) A-to-B 4
B > A Confirm R(128, ...) A-to-B 4
B > A Confirm L(192, ...) A-to-B 4
Using CCID-specific options and feature options during a negotiation for the corresponding CCID feature is NOT RECOMMENDED, since it is difficult to predict which CCID will be in force when the option is processed. For example, if a DCCP-Request contains the option sequence "Change L(CCID, 3), 128", the CCID-specific option "128" may be processed either by CCID 3 (if the server supports CCID 3) or by the default CCID 2 (if it does not). However, it is safe to include CCID-specific options following certain Mandatory Change(CCID)
不建议在协商相应CCID功能时使用CCID特定选项和功能选项，因为很难预测处理选项时哪个CCID将生效。例如，如果DCCP请求包含选项序列“Change L（CCID，3），128”，则CCID特定选项“128”可由CCID 3（如果服务器支持CCID 3）或默认CCID 2（如果不支持）处理。但是，在某些强制性变更（CCID）之后，可以安全地包括CCID特定选项
options. For example, if a DCCP-Request contains the option sequence "Mandatory, Change L(CCID, 3), 128", then either the "128" option will be processed by CCID 3 or the connection will be reset.
选项。例如，如果DCCP请求包含选项序列“强制，更改L（CCID，3），128”，则CCID 3将处理“128”选项或重置连接。
Servers that do not implement the default CCID 2 might nevertheless receive CCID 2-specific options on a DCCP-Request packet. (Such a server MUST send Mandatory Change(CCID) options on its DCCP-Response, so CCID-specific options on any other packet won't refer to CCID 2.) The server MUST treat such options as non-understood. Thus, it will reset the connection on encountering a Mandatory CCID-specific option or feature negotiation request, send an empty Confirm for a non-Mandatory Change option for a CCID-specific feature, and ignore other CCID-specific options.
尽管如此，未实现默认CCID 2的服务器可能会在DCCP请求数据包上接收特定于CCID 2的选项。（这样的服务器必须在其DCCP响应上发送强制更改（CCID）选项，因此任何其他数据包上的CCID特定选项都不会引用CCID 2。）服务器必须将此类选项视为不可理解。因此，它将在遇到强制CCID特定选项或功能协商请求时重置连接，为CCID特定功能的非强制更改选项发送空确认，并忽略其他CCID特定选项。
Each CCID Profile document MUST address at least the following requirements:
每个CCID概要文件必须至少满足以下要求：
o The profile MUST include the name and number of the CCID being described.
o 配置文件必须包括正在描述的CCID的名称和编号。
o The profile MUST describe the conditions in which it is likely to be useful. Often the best way to do this is by comparison to existing CCIDs.
o 配置文件必须描述其可能有用的条件。通常最好的方法是与现有的CCID进行比较。
o The profile MUST list and describe any CCID-specific options, features, and Reset Codes and SHOULD list those general options and features described in this document that are especially relevant to the CCID.
o 配置文件必须列出并描述任何CCID特定选项、功能和重置代码，并应列出本文档中描述的与CCID特别相关的一般选项和功能。
o Any newly defined acknowledgement mechanism MUST include a way to transmit ECN Nonce Echoes back to the sender.
o 任何新定义的确认机制都必须包括将ECN Nonce回音发送回发送方的方法。
o The profile MUST describe the format of data packets, including any options that should be included and the setting of the CCval header field.
o 配置文件必须描述数据包的格式，包括应包括的任何选项和CCval头字段的设置。
o The profile MUST describe the format of acknowledgement packets, including any options that should be included.
o 配置文件必须描述确认数据包的格式，包括应包括的任何选项。
o The profile MUST define how data packets are congestion controlled. This includes responses to congestion events, to idle and application-limited periods, and to the DCCP Data Dropped and Slow Receiver options. CCIDs that implement per-packet congestion control SHOULD discuss how packet size is factored in to congestion control decisions.
o 配置文件必须定义如何控制数据包的拥塞。这包括对拥塞事件、空闲和应用程序限制期间以及DCCP数据丢弃和慢速接收器选项的响应。实现每包拥塞控制的CCID应该讨论如何将包大小考虑到拥塞控制决策中。
o The profile MUST specify when acknowledgement packets are generated and how they are congestion controlled.
o 配置文件必须指定何时生成确认数据包以及如何控制拥塞。
o The profile MUST define when a sender using the CCID is considered quiescent.
o 配置文件必须定义使用CCID的发送方何时被认为是静态的。
o The profile MUST say whether its CCID's acknowledgements ever need to be acknowledged and, if so, how often.
o 档案必须说明是否需要确认其CCID的确认，如果需要，多久确认一次。
Most congestion control algorithms depend on past history to determine the current allowed sending rate. In CCID 2, this congestion state includes a congestion window and a measurement of the number of packets outstanding in the network; in CCID 3, it includes the lengths of recent loss intervals. Both CCIDs use an estimate of the round-trip time. Congestion state depends on the network path and is invalidated by path changes. Therefore, DCCP senders and receivers SHOULD reset their congestion state -- essentially restarting congestion control from "slow start" or equivalent -- on significant changes in the end-to-end path. For example, an endpoint that sends or receives a Mobile IPv6 Binding Update message [RFC3775] SHOULD reset its congestion state for any corresponding DCCP connections.
大多数拥塞控制算法依赖于过去的历史来确定当前允许的发送速率。在CCID 2中，该拥塞状态包括拥塞窗口和对网络中未完成的分组的数量的测量；在CCID 3中，它包括最近损失间隔的长度。两个CCID都使用往返时间的估计值。拥塞状态取决于网络路径，并因路径更改而无效。因此，当端到端路径发生重大变化时，DCCP发送方和接收方应重置其拥塞状态——本质上是从“慢启动”或等效状态重新启动拥塞控制。例如，发送或接收移动IPv6绑定更新消息[RFC3775]的端点应为任何相应的DCCP连接重置其拥塞状态。
A DCCP implementation MAY also reset its congestion state when a CCID changes (that is, when a negotiation for the CCID feature completes successfully and the new feature value differs from the old value). Thus, a connection in a heavily congested environment might evade end-to-end congestion control by frequently renegotiating a CCID, just as it could evade end-to-end congestion control by opening new connections for the same session. This behavior is prohibited. To prevent it, DCCP implementations MAY limit the rate at which CCID can be changed -- for instance, by refusing to change a CCID feature value more than once per minute.
当CCID发生变化时（即，CCID特性的协商成功完成且新特性值与旧特性值不同时），DCCP实现还可以重置其拥塞状态。因此，严重拥塞环境中的连接可能通过频繁重新协商CCID来逃避端到端拥塞控制，就像它可以通过为同一会话打开新连接来逃避端到端拥塞控制一样。这种行为是被禁止的。为了防止这种情况发生，DCCP实现可能会限制CCID的更改速率——例如，拒绝每分钟更改CCID特征值一次以上。
Congestion control requires that receivers transmit information about packet losses and ECN marks to senders. DCCP receivers MUST report all congestion they see, as defined by the relevant CCID profile. Each CCID says when acknowledgements should be sent, what options they must use, and so on. DCCP acknowledgements are congestion controlled, although it is not required that the acknowledgement stream be more than very roughly TCP friendly; each CCID defines how acknowledgements are congestion controlled.
拥塞控制要求接收方向发送方发送有关数据包丢失和ECN标记的信息。DCCP接收器必须报告他们看到的所有拥塞，如相关CCID配置文件所定义。每个CCID都会说明何时发送确认，必须使用哪些选项，等等。DCCP确认是拥塞控制的，尽管不要求确认流对TCP非常友好；每个CCID定义了如何控制拥塞。
Most acknowledgements use DCCP options. For example, on a half-connection with CCID 2 (TCP-like), the receiver reports acknowledgement information using the Ack Vector option. This section describes common acknowledgement options and shows how acks using those options will commonly work. Full descriptions of the ack mechanisms used for each CCID are laid out in the CCID profile specifications.
大多数DCCP使用确认选项。例如，在与CCID 2（类似TCP）的半连接上，接收器使用Ack Vector选项报告确认信息。本节介绍常见的确认选项，并说明使用这些选项的ACK通常如何工作。CCID配置文件规范中列出了每个CCID使用的ack机制的完整描述。
Acknowledgement options, such as Ack Vector, depend on the DCCP Acknowledgement Number and are thus only allowed on packet types that carry that number. Acknowledgement options received on other packet types, namely DCCP-Request and DCCP-Data, MUST be ignored. Detailed acknowledgement options are not necessarily required on every packet that carries an Acknowledgement Number, however.
确认选项（如Ack Vector）取决于DCCP确认号，因此仅允许在携带该号码的数据包类型上使用。必须忽略在其他数据包类型（即DCCP请求和DCCP数据）上接收的确认选项。然而，在每个携带确认号码的数据包上不一定都需要详细的确认选项。
DCCP was designed to work well for both bidirectional and unidirectional flows of data, and for connections that transition between these states. However, acknowledgements required for a unidirectional connection are very different from those required for a bidirectional connection. In particular, unidirectional connections need to worry about acks of acks.
DCCP设计用于双向和单向数据流，以及在这些状态之间转换的连接。但是，单向连接所需的确认与双向连接所需的确认非常不同。特别是，单向连接需要担心ACK中的ACK。
The ack-of-acks problem arises because some acknowledgement mechanisms are reliable. For example, an HC-Receiver using CCID 2, TCP-like Congestion Control, sends Ack Vectors containing completely reliable acknowledgement information. The HC-Sender should occasionally inform the HC-Receiver that it has received an ack. If it did not, the HC-Receiver might resend complete Ack Vector information, going back to the start of the connection, with every DCCP-Ack packet! However, note that acks-of-acks need not be reliable themselves: when an ack-of-acks is lost, the HC-Receiver will simply maintain, and periodically retransmit, old acknowledgement-related state for a little longer. Therefore, there is no need for acks-of-acks-of-acks.
由于某些确认机制是可靠的，因此出现了ack-of-acks问题。例如，使用CCID2的HC接收机，类似TCP的拥塞控制，发送包含完全可靠的确认信息的Ack向量。HC发送方应偶尔通知HC接收方其已收到ack。如果没有，HC接收器可能会重新发送完整的Ack向量信息，返回到连接的开始，每个DCCP Ack数据包！然而，请注意，ack的ack本身不需要是可靠的：当ack的ack丢失时，HC接收机将简单地维持并周期性地重新传输旧的确认相关状态稍长一点。因此，不需要acks of acks of acks。
When communication is bidirectional, any required acks-of-acks are automatically contained in normal acknowledgements for data packets. On a unidirectional connection, however, the receiver DCCP sends no data, so the sender would not normally send acknowledgements. Therefore, the CCID in force on that half-connection must explicitly say whether, when, and how the HC-Sender should generate acks-of-acks.
当通信是双向的时，任何所需的确认都自动包含在数据包的正常确认中。然而，在单向连接上，接收方DCCP不发送数据，因此发送方通常不会发送确认。因此，在该半连接上生效的CCID必须明确说明HC发送方是否、何时以及如何生成ACK的ACK。
For example, consider a bidirectional connection where both half-connections use the same CCID (either 2 or 3), and where DCCP B goes "quiescent". This means that the connection becomes unidirectional:
例如，考虑一个双向连接，其中两个半连接使用相同的CIDD（2或3），而DCCP B则进入“静态”。这意味着连接变为单向：
DCCP B stops sending data and sends only DCCP-Ack packets to DCCP A. In CCID 2, TCP-like Congestion Control, DCCP B uses Ack Vector to reliably communicate which packets it has received. As described above, DCCP A must occasionally acknowledge a pure acknowledgement from DCCP B so that B can free old Ack Vector state. For instance, A might send a DCCP-DataAck packet instead of DCCP-Data every now and then. In CCID 3, however, acknowledgement state is generally bounded, so A does not need to acknowledge B's acknowledgements.
DCCP B停止发送数据，只向DCCP A发送DCCP Ack数据包。在CCID 2中，类似TCP的拥塞控制中，DCCP B使用Ack向量可靠地通信它已接收的数据包。如上所述，DCCP A必须偶尔确认来自DCCP B的纯确认，以便B可以释放旧的Ack向量状态。例如，A可能偶尔发送DCCP数据包而不是DCCP数据。然而，在CCID3中，确认状态通常是有界的，因此A不需要确认B的确认。
When communication is unidirectional, a single CCID -- in the example, the A-to-B CCID -- controls both DCCPs' acknowledgements, in terms of their content, their frequency, and so forth. For bidirectional connections, the A-to-B CCID governs DCCP B's acknowledgements (including its acks of DCCP A's acks) and the B-to-A CCID governs DCCP A's acknowledgements.
当通信是单向的时，单个CCID（在本例中为a-to-B CCID）控制两个DCCP的确认，包括其内容、频率等。对于双向连接，A-to-B CCID控制DCCP B的确认（包括其对DCCP A确认的确认），B-to-A CCID控制DCCP A的确认。
DCCP A switches its ack pattern from bidirectional to unidirectional when it notices that DCCP B has gone quiescent. It switches from unidirectional to bidirectional when it must acknowledge even a single DCCP-Data or DCCP-DataAck packet from DCCP B.
当DCCP A注意到DCCP B已静止时，它会将其ack模式从双向切换到单向。当它必须确认来自DCCP B的单个DCCP数据或DCCP数据包时，它会从单向切换到双向。
Each CCID defines how to detect quiescence on that CCID, and how that CCID handles acks-of-acks on unidirectional connections. The B-to-A CCID defines when DCCP B has gone quiescent. Usually, this happens when a period has passed without B sending any data packets; in CCID 2, for example, this period is the maximum of 0.2 seconds and two round-trip times. The A-to-B CCID defines how DCCP A handles acks-of-acks once DCCP B has gone quiescent.
每个CCID定义如何检测该CCID上的静止，以及该CCID如何处理单向连接上的ACK的ACK。B-to-A CCID定义了DCCP B何时处于静止状态。通常，这发生在一段时间后，B没有发送任何数据包；例如，在CCID 2中，该时间段的最大值为0.2秒和两个往返时间。A-to-B CCID定义了一旦DCCP B处于静止状态，DCCP A如何处理ACK的ACK。
Acknowledgements of A-to-B data MAY be piggybacked on data sent by DCCP B, as long as that does not delay the acknowledgement longer than the A-to-B CCID would find acceptable. However, data acknowledgements often require more than 4 bytes to express. A large set of acknowledgements prepended to a large data packet might exceed the allowed maximum packet size. In this case, DCCP B SHOULD send separate DCCP-Data and DCCP-Ack packets, or wait, but not too long, for a smaller datagram.
A-to-B数据的确认可以在DCCP B发送的数据上进行，只要确认延迟的时间不超过A-to-B CCID可以接受的时间。然而，数据确认通常需要超过4个字节来表示。为大数据包预先准备的一大组确认可能超过允许的最大数据包大小。在这种情况下，DCCP B应该发送单独的DCCP数据和DCCP Ack数据包，或者等待较小的数据报，但不要等待太久。
Piggybacking is particularly common at DCCP A when the B-to-A half-connection is quiescent -- that is, when DCCP A is just acknowledging DCCP B's acknowledgements. There are three reasons to acknowledge DCCP B's acknowledgements: to allow DCCP B to free up information about previously acknowledged data packets from A; to shrink the size of future acknowledgements; and to manipulate the rate at which future acknowledgements are sent. Since these are
当B-to-A半连接处于静止状态时（也就是说，当DCCP A只是确认DCCP B的确认时），在DCCP A中，Piggybacking尤其常见。确认DCCP B的确认有三个原因：允许DCCP B从A释放关于先前确认的数据包的信息；缩小未来确认的规模；以及操纵未来确认的发送速率。既然这些是
secondary concerns, DCCP A can generally afford to wait indefinitely for a data packet to piggyback its acknowledgement onto; if DCCP B wants to elicit an acknowledgement, it can send a DCCP-Sync.
其次，DCCP A通常可以无限期地等待一个数据包将其确认信息携带到数据包上；如果DCCP B想要获得确认，它可以发送DCCP同步。
Any restrictions on ack piggybacking are described in the relevant CCID's profile.
有关CCID的配置文件中描述了任何关于背驮的限制。
The Ack Ratio feature lets HC-Senders influence the rate at which HC-Receivers generate DCCP-Ack packets, thus controlling reverse-path congestion. This differs from TCP, which presently has no congestion control for pure acknowledgement traffic. Ack Ratio reverse-path congestion control does not try to be TCP friendly. It just tries to avoid congestion collapse, and to be somewhat better than TCP in the presence of a high packet loss or mark rate on the reverse path.
Ack Ratio特性允许HC发送方影响HC接收方生成DCCP Ack分组的速率，从而控制反向路径拥塞。这与TCP不同，TCP目前没有针对纯确认流量的拥塞控制。Ack比率反向路径拥塞控制不尝试对TCP友好。它只是试图避免拥塞崩溃，并且在反向路径上存在高丢包率或标记率的情况下比TCP要好一些。
Ack Ratio applies to CCIDs whose HC-Receivers clock acknowledgements off the receipt of data packets. The value of Ack Ratio/A equals the rough ratio of data packets sent by DCCP A to DCCP-Ack packets sent by DCCP B. Higher Ack Ratios correspond to lower DCCP-Ack rates; the sender raises Ack Ratio when the reverse path is congested and lowers Ack Ratio when it is not. Each CCID profile defines how it controls congestion on the acknowledgement path, and, particularly, whether Ack Ratio is used. CCID 2, for example, uses Ack Ratio for acknowledgement congestion control, but CCID 3 does not. However, each Ack Ratio feature has a value whether or not that value is used by the relevant CCID.
Ack Ratio适用于其HC接收器在接收数据包时时钟确认的CCID。Ack Ratio/A的值等于DCCP A发送的数据包与DCCP B发送的DCCP Ack包的粗略比率。较高的Ack比率对应较低的DCCP Ack速率；当反向路径拥挤时，发送方提高Ack比率，当反向路径不拥挤时，发送方降低Ack比率。每个CCID配置文件定义了它如何控制确认路径上的拥塞，特别是，是否使用Ack比率。例如，CCID2使用Ack比率进行确认拥塞控制，但CCID3不这样做。然而，无论相关CCID是否使用该值，每个Ack比率特征都具有一个值。
Ack Ratio has feature number 5 and is non-negotiable. It takes two-byte integer values. An Ack Ratio/A value of four means that DCCP B will send at least one acknowledgement packet for every four data packets sent by DCCP A. DCCP A sends a "Change L(Ack Ratio)" option to notify DCCP B of its ack ratio. An Ack Ratio value of zero indicates that the relevant half-connection does not use an Ack Ratio to control its acknowledgement rate. New connections start with Ack Ratio 2 for both endpoints; this Ack Ratio results in acknowledgement behavior analogous to TCP's delayed acks.
确认比率具有特征编号5，且不可协商。它需要两个字节的整数值。Ack Ratio/A值为4意味着DCCP B将为DCCP A发送的每四个数据包发送至少一个确认数据包。DCCP A发送“更改L（Ack Ratio）”选项以通知DCCP B其Ack Ratio。Ack Ratio值为零表示相关的半连接不使用Ack Ratio来控制其确认率。新连接从两个端点的Ack比率2开始；此Ack比率导致类似于TCP延迟Ack的确认行为。
Ack Ratio should be treated as a guideline rather than a strict requirement. We intend Ack Ratio-controlled acknowledgement behavior to resemble TCP's acknowledgement behavior when there is no reverse-path congestion, and to be somewhat more conservative when there is reverse-path congestion. Following this intent is more important than implementing Ack Ratio precisely. In particular:
确认率应被视为一个指导原则，而不是一个严格的要求。我们希望Ack比率控制的确认行为类似于TCP在没有反向路径拥塞时的确认行为，并且在有反向路径拥塞时更加保守。遵循这一意图比精确实现Ack比率更重要。特别地：
o Receivers MAY piggyback acknowledgement information on data packets, creating DCCP-DataAck packets. The Ack Ratio does not apply to piggybacked acknowledgements. However, if the data packets are too big to carry acknowledgement information, or if the data sending rate is lower than Ack Ratio would suggest, then DCCP B SHOULD send enough pure DCCP-Ack packets to maintain the rate of one acknowledgement per Ack Ratio received data packets.
o 接收器可以在数据包上携带确认信息，创建DCCP数据包。回执比率不适用于附带回执的确认。然而，如果数据分组太大而无法携带确认信息，或者如果数据发送速率低于Ack比率所建议的速率，则DCCP B应发送足够多的纯DCCP Ack分组，以保持每Ack比率接收到的数据分组一个确认的速率。
o Receivers MAY rate-pace their acknowledgements rather than send acknowledgements immediately upon the receipt of data packets. Receivers that rate-pace acknowledgements SHOULD pick a rate that approximates the effect of Ack Ratio and SHOULD include Elapsed Time options (Section 13.2) to help the sender calculate round-trip times.
o 接收器可以对其确认进行速率调整，而不是在收到数据包后立即发送确认。速率-速度-应答的接收器应选择一个近似于应答率影响的速率，并应包括经过时间选项（第13.2节），以帮助发送者计算往返时间。
o Receivers SHOULD implement delayed acknowledgement timers like TCP's, whereby any packet's acknowledgement is delayed by at most T seconds. This delay lets the receiver collect additional packets to acknowledge and thus reduce the per-packet overhead of acknowledgements; but if T seconds have passed by and the ack is still around, it is sent out right away. The default value of T should be 0.2 seconds, as is common in TCP implementations. This may lead to sending more acknowledgement packets than Ack Ratio would suggest.
o 接收器应实现延迟确认计时器，如TCP，任何数据包的确认最多延迟T秒。该延迟允许接收器收集额外的分组以进行确认，从而减少确认的每分组开销；但是，如果T秒过去了，并且ack仍然存在，它将立即被发送出去。T的默认值应为0.2秒，这在TCP实现中很常见。这可能会导致发送比Ack比率所建议的更多的确认数据包。
o Receivers SHOULD send acknowledgements immediately on receiving packets marked ECN Congestion Experienced or packets whose out-of-order sequence numbers potentially indicate loss. However, there is no need to send such immediate acknowledgements for marked packets more than once per round-trip time.
o 当接收到标记为ECN拥塞的数据包或顺序号错误可能表示丢失的数据包时，接收方应立即发送确认。但是，对于标记的数据包，无需在每次往返时间内多次发送此类即时确认。
o Receivers MAY ignore Ack Ratio if they perform their own congestion control on acknowledgements. For example, a receiver that knows the loss and mark rate for its DCCP-Ack packets might maintain a TCP-friendly acknowledgement rate on its own. Such a receiver MUST either ensure that it always obtains sufficient acknowledgement loss and mark information or fall back to Ack Ratio when sufficient information is not available, as might happen during periods when the receiver is quiescent.
o 如果接收器对确认执行自己的拥塞控制，则可能忽略确认比率。例如，知道其DCCP Ack数据包的丢失率和标记率的接收器可以自己保持TCP友好的确认率。这样的接收器必须确保它总是获得足够的确认丢失和标记信息，或者在没有足够的信息可用时返回到Ack比率，就像在接收器静止期间可能发生的那样。
The Ack Vector gives a run-length encoded history of data packets received at the client. Each byte of the vector gives the state of that data packet in the loss history, and the number of preceding packets with the same state. The option's data looks like this:
Ack向量给出在客户端接收的数据分组的运行长度编码历史。向量的每个字节给出丢失历史中该数据包的状态，以及具有相同状态的前一个数据包的数量。该选项的数据如下所示：
+--------+--------+--------+--------+--------+--------
|0010011?| Length |SSLLLLLL|SSLLLLLL|SSLLLLLL| ...
+--------+--------+--------+--------+--------+--------
Type=38/39 \___________ Vector ___________...
+--------+--------+--------+--------+--------+--------
|0010011?| Length |SSLLLLLL|SSLLLLLL|SSLLLLLL| ...
+--------+--------+--------+--------+--------+--------
Type=38/39 \___________ Vector ___________...
The two Ack Vector options (option types 38 and 39) differ only in the values they imply for ECN Nonce Echo. Section 12.2 describes this further.
两个Ack Vector选项（选项类型38和39）仅在它们对ECN Nonce Echo表示的值上有所不同。第12.2节对此作了进一步说明。
The vector itself consists of a series of bytes, each of whose encoding is:
向量本身由一系列字节组成，每个字节的编码为：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Sta| Run Length|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Sta| Run Length|
+-+-+-+-+-+-+-+-+
Sta[te] occupies the most significant two bits of each byte and can have one of four values, as follows:
Sta[te]占据每个字节的最高有效两位，可以有四个值中的一个，如下所示：
State Meaning
----- -------
0 Received
1 Received ECN Marked
2 Reserved
3 Not Yet Received
State Meaning
----- -------
0 Received
1 Received ECN Marked
2 Reserved
3 Not Yet Received
Table 6: DCCP Ack Vector States
表6:DCCP Ack向量状态
The term "ECN marked" refers to packets with ECN code point 11, CE (Congestion Experienced); packets received with this ECN code point MUST be reported using State 1, Received ECN Marked. Packets received with ECN code points 00, 01, or 10 (Non-ECT, ECT(0), or ECT(1), respectively) MUST be reported using State 0, Received.
术语“ECN标记”是指具有ECN代码点11 CE（经历拥塞）的分组；使用此ECN代码点接收的数据包必须使用状态1（已接收ECN标记）进行报告。使用ECN代码点00、01或10（分别为非ECT、ECT（0）或ECT（1））接收的数据包必须使用状态0，received进行报告。
Run Length, the least significant six bits of each byte, specifies how many consecutive packets have the given State. Run Length zero says the corresponding State applies to one packet only; Run Length 63 says it applies to 64 consecutive packets. Run lengths of 65 or more must be encoded in multiple bytes.
运行长度（每个字节的最低有效六位）指定给定状态下有多少个连续数据包。运行长度0表示对应的状态仅适用于一个数据包；运行长度63表示它适用于64个连续数据包。65或以上的运行长度必须以多个字节进行编码。
The first byte in the first Ack Vector option refers to the packet indicated in the Acknowledgement Number; subsequent bytes refer to older packets. Ack Vector MUST NOT be sent on DCCP-Data and DCCP-Request packets, which lack an Acknowledgement Number, and any Ack Vector options encountered on such packets MUST be ignored.
第一Ack向量选项中的第一字节是指在确认号码中指示的分组；后续字节指的是较旧的数据包。Ack向量不得在DCCP数据和DCCP请求数据包上发送，因为这些数据包没有确认号，因此必须忽略在这些数据包上遇到的任何Ack向量选项。
An Ack Vector containing the decimal values 0,192,3,64,5 and for which the Acknowledgement Number is decimal 100 indicates that:
包含十进制值0192,3,64,5且确认号为十进制100的Ack向量表示：
Packet 100 was received (Acknowledgement Number 100, State 0, Run Length 0);
接收到数据包100（确认号100，状态0，运行长度0）；
Packet 99 was lost (State 3, Run Length 0);
数据包99丢失（状态3，运行长度0）；
Packets 98, 97, 96 and 95 were received (State 0, Run Length 3);
接收数据包98、97、96和95（状态0，运行长度3）；
Packet 94 was ECN marked (State 1, Run Length 0); and
数据包94被ECN标记（状态1，运行长度0）；和
Packets 93, 92, 91, 90, 89, and 88 were received (State 0, Run Length 5).
接收到数据包93、92、91、90、89和88（状态0，运行长度5）。
A single Ack Vector option can acknowledge up to 16192 data packets. Should more packets need to be acknowledged than can fit in 253 bytes of Ack Vector, then multiple Ack Vector options can be sent; the second Ack Vector begins where the first left off, and so forth.
单个Ack向量选项最多可确认16192个数据包。如果需要确认的数据包超过253字节的Ack向量，则可以发送多个Ack向量选项；第二个Ack向量从第一个停止的位置开始，依此类推。
Ack Vector states are subject to two general constraints. (These principles SHOULD also be followed for other acknowledgement mechanisms; referring to Ack Vector states simplifies their explanation.)
确认向量状态受两个一般约束。（其他确认机制也应遵循这些原则；参考Ack向量状态可简化其解释。）
1. Packets reported as State 0 or State 1 MUST be acknowledgeable: their options have been processed by the receiving DCCP stack. Any data on the packet need not have been delivered to the receiving application; in fact, the data may have been dropped.
1. 报告为状态0或状态1的数据包必须可确认：它们的选项已由接收DCCP堆栈处理。数据包上的任何数据都不需要已经交付给接收应用程序；事实上，数据可能已被删除。
2. Packets reported as State 3 MUST NOT be acknowledgeable. Feature negotiations and options on such packets MUST NOT have been processed, and the Acknowledgement Number MUST NOT correspond to such a packet.
2. 报告为状态3的数据包不能被确认。此类数据包上的特征协商和选项不得已处理，且确认号不得对应于此类数据包。
Packets dropped in the application's receive buffer MUST be reported as Received or Received ECN Marked (States 0 and 1), depending on their ECN state; such packets' ECN Nonces MUST be included in the Nonce Echo. The Data Dropped option informs the sender that some packets reported as received actually had their application data dropped.
丢弃在应用程序接收缓冲区中的数据包必须根据其ECN状态报告为已接收或已接收ECN标记（状态0和1）；此类数据包的ECN Nonce必须包含在Nonce Echo中。Data Dropped（数据丢弃）选项通知发送方，一些报告为已接收的数据包实际上已丢弃其应用程序数据。
One or more Ack Vector options that, together, report the status of a packet with a sequence number less than ISN, the initial sequence number, SHOULD be considered invalid. The receiving DCCP SHOULD either ignore the options or reset the connection with Reset Code 5, "Option Error". No Ack Vector option can refer to a packet that has not yet been sent, as the Acknowledgement Number checks in Section
如果一个或多个Ack向量选项一起报告序列号小于初始序列号ISN的数据包的状态，则应视为无效。接收DCCP应忽略选项或使用重置代码5“选项错误”重置连接。没有Ack矢量选项可以指尚未发送的数据包，因为第节中检查了确认号
7.5.3 ensure, but because of attack, implementation bug, or misbehavior, an Ack Vector option can claim that a packet was received before it is actually delivered. Section 12.2 describes how this is detected and how senders should react. Packets that haven't been included in any Ack Vector option SHOULD be treated as "not yet received" (State 3) by the sender.
7.5.3 请确保，但由于攻击、实现错误或不当行为，Ack向量选项可以声明在实际交付数据包之前已收到数据包。第12.2节描述了如何检测到这种情况以及发送方应如何反应。发送方应将未包含在任何Ack向量选项中的数据包视为“尚未接收”（状态3）。
Appendix A provides a non-normative description of the details of DCCP acknowledgement handling in the context of an abstract Ack Vector implementation.
附录A提供了抽象Ack向量实现上下文中DCCP确认处理细节的非规范性描述。
A DCCP sender will commonly receive multiple acknowledgements for some of its data packets. For instance, an HC-Sender might receive two DCCP-Acks with Ack Vectors, both of which contained information about sequence number 24. (Information about a sequence number is generally repeated in every ack until the HC-Sender acknowledges an ack. In this case, perhaps the HC-Receiver is sending acks faster than the HC-Sender is acknowledging them.) In a perfect world, the two Ack Vectors would always be consistent. However, there are many reasons why they might not be. For example:
DCCP发送方通常会收到其某些数据包的多个确认。例如，HC发送方可能接收到两个带有Ack向量的DCCP Ack，这两个DCCP Ack都包含关于序列号24的信息。（关于序列号的信息通常在每个ack中重复，直到HC发送方确认ack为止。在这种情况下，可能HC接收方发送ack的速度比HC发送方确认ack的速度快。）在完美世界中，两个ack向量总是一致的。然而，有很多原因导致它们可能不是。例如：
o The HC-Receiver received packet 24 between sending its acks, so the first ack said 24 was not received (State 3) and the second said it was received or ECN marked (State 0 or 1).
o HC接收器在发送其ack之间接收到数据包24，因此第一个ack表示24未接收（状态3），第二个ack表示其已接收或ECN标记（状态0或1）。
o The HC-Receiver received packet 24 between sending its acks, and the network reordered the acks. In this case, the packet will appear to transition from State 0 or 1 to State 3.
o HC接收机在发送其ack之间接收到分组24，并且网络对ack重新排序。在这种情况下，数据包将从状态0或1转换为状态3。
o The network duplicated packet 24, and one of the duplicates was ECN marked. This might show up as a transition between States 0 and 1.
o 网络复制了数据包24，并且其中一个复制被ECN标记。这可能显示为状态0和1之间的转换。
To cope with these situations, HC-Sender DCCP implementations SHOULD combine multiple received Ack Vector states according to this table:
为了应对这些情况，HC发送方DCCP实现应根据下表组合多个接收到的Ack向量状态：
Received State
0 1 3
+---+---+---+
0 | 0 |0/1| 0 |
Old +---+---+---+
1 | 1 | 1 | 1 |
State +---+---+---+
3 | 0 | 1 | 3 |
+---+---+---+
Received State
0 1 3
+---+---+---+
0 | 0 |0/1| 0 |
Old +---+---+---+
1 | 1 | 1 | 1 |
State +---+---+---+
3 | 0 | 1 | 3 |
+---+---+---+
To read the table, choose the row corresponding to the packet's old state and the column corresponding to the packet's state in the newly received Ack Vector; then read the packet's new state off the table. For an old state of 0 (received non-marked) and received state of 1 (received ECN marked), the packet's new state may be set to either 0 or 1. The HC-Sender implementation will be indifferent to ack reordering if it chooses new state 1 for that cell.
要读取该表，在新接收到的Ack向量中选择对应于分组的旧状态的行和对应于分组的状态的列；然后从表中读取数据包的新状态。对于旧状态0（接收未标记）和接收状态1（接收ECN标记），分组的新状态可以设置为0或1。如果HC发送方实现为该单元选择新状态1，则它将不关心ack重新排序。
The HC-Receiver should collect information about received packets according to the following table:
HC接收器应根据下表收集有关接收数据包的信息：
Received Packet
0 1 3
+---+---+---+
0 | 0 |0/1| 0 |
Stored +---+---+---+
1 |0/1| 1 | 1 |
State +---+---+---+
3 | 0 | 1 | 3 |
+---+---+---+
Received Packet
0 1 3
+---+---+---+
0 | 0 |0/1| 0 |
Stored +---+---+---+
1 |0/1| 1 | 1 |
State +---+---+---+
3 | 0 | 1 | 3 |
+---+---+---+
This table equals the sender's table except that, when the stored state is 1 and the received state is 0, the receiver is allowed to switch its stored state to 0.
此表与发送方的表相同，只是当存储状态为1且接收状态为0时，允许接收方将其存储状态切换为0。
An HC-Sender MAY choose to throw away old information gleaned from the HC-Receiver's Ack Vectors, in which case it MUST ignore newly received acknowledgements from the HC-Receiver for those old packets. It is often kinder to save recent Ack Vector information for a while so that the HC-Sender can undo its reaction to presumed congestion when a "lost" packet unexpectedly shows up (the transition from State 3 to State 0).
HC发送方可以选择丢弃从HC接收机的Ack向量收集的旧信息，在这种情况下，它必须忽略来自HC接收机的针对那些旧分组的新接收的确认。将最近的Ack向量信息保存一段时间，以便HC发送方可以在意外出现“丢失”数据包时撤销其对假定拥塞的反应（从状态3过渡到状态0）。
We can divide the packets that have been sent from an HC-Sender to an HC-Receiver into four roughly contiguous groups. From oldest to youngest, these are:
我们可以将从HC发送方发送到HC接收方的数据包分成四个大致连续的组。从大到小，这些是：
1. Packets already acknowledged by the HC-Receiver, where the HC-Receiver knows that the HC-Sender has definitely received the acknowledgements;
1. 已经由HC接收机确认的分组，其中HC接收机知道HC发送方肯定已经接收到确认；
2. Packets already acknowledged by the HC-Receiver, where the HC-Receiver cannot be sure that the HC-Sender has received the acknowledgements;
2. 已经由HC接收器确认的数据包，其中HC接收器不能确保HC发送者已经收到确认；
3. Packets not yet acknowledged by the HC-Receiver; and
3. HC接收器尚未确认的数据包；和
4. Packets not yet received by the HC-Receiver.
4. HC接收器尚未接收到的数据包。
The union of groups 2 and 3 is called the Acknowledgement Window. Generally, every Ack Vector generated by the HC-Receiver will cover the whole Acknowledgement Window: Ack Vector acknowledgements are cumulative. (This simplifies Ack Vector maintenance at the HC-Receiver; see Appendix A, below.) As packets are received, this window both grows on the right and shrinks on the left. It grows because there are more packets, and shrinks because the HC-Sender's Acknowledgement Numbers will acknowledge previous acknowledgements, moving packets from group 2 into group 1.
组2和组3的联合称为确认窗口。通常，HC接收器生成的每个Ack向量将覆盖整个确认窗口：Ack向量确认是累积的。（这简化了HC接收器上的Ack向量维护；参见下面的附录A。）当接收到数据包时，该窗口在右侧增大，在左侧缩小。它的增长是因为有更多的数据包，而收缩是因为HC发送方的确认号将确认以前的确认，将数据包从组2移动到组1。
The Send Ack Vector feature lets DCCPs negotiate whether they should use Ack Vector options to report congestion. Ack Vector provides detailed loss information and lets senders report back to their applications whether particular packets were dropped. Send Ack Vector is mandatory for some CCIDs and optional for others.
发送确认向量功能允许DCCP协商是否应使用确认向量选项来报告拥塞。Ack Vector提供详细的丢失信息，并允许发送方向其应用程序报告是否丢弃了特定的数据包。发送确认向量对于某些CCID是必需的，对于其他CCID是可选的。
Send Ack Vector has feature number 6 and is server-priority. It takes one-byte Boolean values. DCCP A MUST send Ack Vector options on its acknowledgements when Send Ack Vector/A has value one, although it MAY send Ack Vector options even when Send Ack Vector/A is zero. Values of two or more are reserved. New connections start with Send Ack Vector 0 for both endpoints. DCCP B sends a "Change R(Send Ack Vector, 1)" option to DCCP A to ask A to send Ack Vector options as part of its acknowledgement traffic.
发送确认向量具有功能编号6，并且是服务器优先级。它需要一个字节的布尔值。当send Ack Vector/A的值为1时，DCCP A必须在其确认上发送Ack Vector选项，尽管即使send Ack Vector/A为零，DCCP A也可以发送Ack Vector选项。保留两个或两个以上的值。对于两个新端点，发送带有0的起始向量连接。DCCP B向DCCP a发送“更改R（发送确认向量，1）”选项，要求a发送确认向量选项，作为其确认流量的一部分。
An HC-Receiver sends the Slow Receiver option to its sender to indicate that it is having trouble keeping up with the sender's data. The HC-Sender SHOULD NOT increase its sending rate for approximately one round-trip time after seeing a packet with a Slow Receiver option. After one round-trip time, the effect of Slow Receiver disappears, allowing the HC-Sender to increase its rate. Therefore, the HC-Receiver SHOULD continue to send Slow Receiver options if it needs to prevent the HC-Sender from going faster in the long term. The Slow Receiver option does not indicate congestion, and the HC-Sender need not reduce its sending rate. (If necessary, the receiver can force the sender to slow down by dropping packets, with or without Data Dropped, or by reporting false ECN marks.) APIs should let receiver applications set Slow Receiver and sending applications determine whether their receivers are Slow.
HC接收器向其发送方发送Slow Receiver（慢速接收器）选项，以表明其无法跟上发送方的数据。HC发送方在看到具有慢速接收器选项的数据包后，不应在大约一个往返时间内增加其发送速率。经过一次往返时间后，慢速接收器的影响消失，允许HC发送器增加其速率。因此，如果需要长期防止HC发送器速度加快，HC接收器应继续发送慢速接收器选项。慢速接收器选项不表示拥塞，HC发送器不需要降低其发送速率。（如有必要，接收方可以通过丢弃数据包、丢弃数据或不丢弃数据，或通过报告错误的ECN标记，迫使发送方减速。）API应该让接收方应用程序设置slow receiver，发送应用程序确定其接收方是否慢。
Slow Receiver is a one-byte option.
慢速接收器是一个单字节选项。
+--------+
|00000010|
+--------+
Type=2
+--------+
|00000010|
+--------+
Type=2
Slow Receiver does not specify why the receiver is having trouble keeping up with the sender. Possible reasons include lack of buffer space, CPU overload, and application quotas. A sending application might react to Slow Receiver by reducing its application-level sending rate, for example.
Slow Receiver（慢速接收器）未指定接收器无法跟上发送者的原因。可能的原因包括缺少缓冲区空间、CPU过载和应用程序配额。例如，发送应用程序可能会通过降低其应用程序级别的发送速率来响应较慢的接收器。
The sending application should not react to Slow Receiver by sending more data, however. Although the optimal response to a CPU-bound receiver might be to reduce compression and send more data (a highly-compressed data format might overwhelm a slow CPU more seriously than would the higher memory requirements of a less-compressed data format), this kind of format change should be requested at the application level, not via the Slow Receiver option.
然而，发送应用程序不应通过发送更多数据来响应较慢的接收器。尽管对CPU受限接收器的最佳响应可能是减少压缩并发送更多数据（高压缩数据格式可能会比低压缩数据格式的更高内存要求更严重地压倒较慢的CPU），但这种格式更改应在应用程序级别请求，不是通过慢速接收器选项。
Slow Receiver implements a portion of TCP's receive window functionality.
Slow Receiver实现TCP接收窗口功能的一部分。
The Data Dropped option indicates that the application data on one or more received packets did not actually reach the application. Data Dropped additionally reports why the data was dropped: perhaps the data was corrupt, or perhaps the receiver cannot keep up with the sender's current rate and the data was dropped in some receive buffer. Using Data Dropped, DCCP endpoints can discriminate between different kinds of loss; this differs from TCP, in which all loss is reported the same way.
数据丢弃选项表示一个或多个接收数据包上的应用程序数据实际上没有到达应用程序。Data Dropped还报告了数据被丢弃的原因：可能数据已损坏，或者接收方无法跟上发送方的当前速率，并且数据被丢弃在某个接收缓冲区中。使用丢弃的数据，DCCP端点可以区分不同类型的丢失；这与TCP不同，TCP以相同的方式报告所有丢失。
Unless it is explicitly specified otherwise, DCCP congestion control mechanisms MUST react as if each Data Dropped packet was marked as ECN Congestion Experienced by the network. We intend for Data Dropped to enable research into richer congestion responses to corrupt and other endpoint-dropped packets, but DCCP CCIDs MUST react conservatively to Data Dropped until this behavior is standardized. Section 11.7.2, below, describes congestion responses for all current Drop Codes.
除非另有明确规定，否则DCCP拥塞控制机制必须作出反应，就像每个数据丢弃的数据包被标记为网络经历的ECN拥塞一样。我们打算对丢弃的数据进行研究，以便对损坏的和其他端点丢弃的数据包进行更丰富的拥塞响应，但DCCP CCID必须对丢弃的数据做出保守的反应，直到这种行为标准化。下文第11.7.2节描述了所有当前丢弃码的拥塞响应。
If a received packet's application data is dropped for one of the reasons listed below, this SHOULD be reported using a Data Dropped option. Alternatively, the receiver MAY choose to report as
如果接收到的数据包的应用程序数据由于下列原因之一而被丢弃，则应使用数据丢弃选项进行报告。或者，接收器可以选择报告为：
"received" only those packets whose data were not dropped, subject to the constraint that packets not reported as received MUST NOT have had their options processed.
“已接收”仅指数据未被丢弃的数据包，受未报告为已接收的数据包不得处理其选项的约束。
The option's data looks like this:
该选项的数据如下所示：
+--------+--------+--------+--------+--------+--------
|00101000| Length | Block | Block | Block | ...
+--------+--------+--------+--------+--------+--------
Type=40 \___________ Vector ___________ ...
+--------+--------+--------+--------+--------+--------
|00101000| Length | Block | Block | Block | ...
+--------+--------+--------+--------+--------+--------
Type=40 \___________ Vector ___________ ...
The Vector consists of a series of bytes, called Blocks, each of whose encoding corresponds to one of two choices:
向量由一系列称为块的字节组成，每个字节的编码对应于以下两种选择之一：
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| Run Length | or |1|DrpCd|Run Len|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Normal Block Drop Block
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| Run Length | or |1|DrpCd|Run Len|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Normal Block Drop Block
The first byte in the first Data Dropped option refers to the packet indicated by the Acknowledgement Number; subsequent bytes refer to older packets. Data Dropped MUST NOT be sent on DCCP-Data or DCCP-Request packets, which lack an Acknowledgement Number, and any Data Dropped options received on such packets MUST be ignored.
第一数据丢弃选项中的第一字节指由确认号指示的分组；后续字节指的是较旧的数据包。不能在DCCP数据或DCCP请求数据包上发送丢弃的数据，因为DCCP数据或DCCP请求数据包缺少确认号，并且必须忽略在此类数据包上接收到的任何数据丢弃选项。
Normal Blocks, which have high bit 0, indicate that any received packets in the Run Length had their data delivered to the application. Drop Blocks, which have high bit 1, indicate that received packets in the Run Len[gth] were not delivered as usual. The 3-bit Drop Code [DrpCd] field says what happened; generally, no data from that packet reached the application. Packets reported as "not yet received" MUST be included in Normal Blocks; packets not covered by any Data Dropped option are treated as if they were in a Normal Block. Defined Drop Codes for Drop Blocks are as follows.
具有高位0的普通块表示在运行长度中接收到的任何数据包都已将其数据传送到应用程序。具有高位1的丢弃块表示在Run Len[gth]中接收到的数据包没有像往常一样发送。3位丢弃码[DrpCd]字段表示发生了什么；通常，来自该包的数据没有到达应用程序。报告为“尚未接收”的数据包必须包含在正常块中；未被任何数据丢弃选项覆盖的数据包被视为处于正常块中。为放置块定义的放置代码如下所示。
Drop Code Meaning
--------- -------
0 Protocol Constraints
1 Application Not Listening
2 Receive Buffer
3 Corrupt
4-6 Reserved
7 Delivered Corrupt
Drop Code Meaning
--------- -------
0 Protocol Constraints
1 Application Not Listening
2 Receive Buffer
3 Corrupt
4-6 Reserved
7 Delivered Corrupt
Table 7: DCCP Drop Codes
表7:DCCP丢弃代码
In more detail:
更详细地说：
0 The packet data was dropped due to protocol constraints. For example, the data was included on a DCCP-Request packet, but the receiving application does not allow such piggybacking; or the data was included on a packet with inappropriately low Checksum Coverage.
0由于协议限制，数据包数据被丢弃。例如，数据包含在DCCP请求数据包中，但接收应用程序不允许这种搭载；或者数据包含在校验和覆盖率过低的数据包中。
1 The packet data was dropped because the application is no longer listening. See Section 11.7.2.
1由于应用程序不再侦听，数据包数据被丢弃。见第11.7.2节。
2 The packet data was dropped in a receive buffer, probably because of receive buffer overflow. See Section 11.7.2.
2数据包数据被丢弃在接收缓冲区中，可能是因为接收缓冲区溢出。见第11.7.2节。
3 The packet data was dropped due to corruption. See Section 9.3.
3由于损坏，数据包数据被丢弃。见第9.3节。
7 The packet data was corrupted but was delivered to the application anyway. See Section 9.3.
7数据包数据已损坏，但仍被传送到应用程序。见第9.3节。
For example, assume that a packet arrives with Acknowledgement Number 100, an Ack Vector reporting all packets as received, and a Data Dropped option containing the decimal values 0,160,3,162. Then:
例如，假设数据包到达时具有确认号100、报告接收到的所有数据包的Ack向量以及包含十进制值0160,3162的数据丢弃选项。然后：
Packet 100 was received (Acknowledgement Number 100, Normal Block, Run Length 0).
接收到数据包100（确认号100，正常块，运行长度0）。
Packet 99 was dropped in a receive buffer (Drop Block, Drop Code 2, Run Length 0).
数据包99被丢弃在接收缓冲区中（丢弃块，丢弃代码2，运行长度0）。
Packets 98, 97, 96, and 95 were received (Normal Block, Run Length 3).
接收到数据包98、97、96和95（正常块，运行长度3）。
Packets 95, 94, and 93 were dropped in the receive buffer (Drop Block, Drop Code 2, Run Length 2).
数据包95、94和93被丢弃在接收缓冲区中（丢弃块、丢弃代码2、运行长度2）。
Run lengths of more than 128 (for Normal Blocks) or 16 (for Drop Blocks) must be encoded in multiple Blocks. A single Data Dropped option can acknowledge up to 32384 Normal Block data packets, although the receiver SHOULD NOT send a Data Dropped option when all relevant packets fit into Normal Blocks. Should more packets need to be acknowledged than can fit in 253 bytes of Data Dropped, then multiple Data Dropped options can be sent. The second option will begin where the first left off, and so forth.
必须在多个块中编码超过128（对于正常块）或16（对于下降块）的运行长度。单个数据丢弃选项可以确认多达32384个正常块数据分组，尽管当所有相关分组适合正常块时，接收器不应发送数据丢弃选项。如果需要确认的数据包超过253字节丢弃数据的容量，则可以发送多个数据丢弃选项。第二个选项将从第一个选项停止的位置开始，依此类推。
One or more Data Dropped options that, together, report the status of more packets than have been sent, or that change the status of a packet, or that disagree with Ack Vector or equivalent options (by
一个或多个数据丢弃选项，这些选项一起报告已发送的多个数据包的状态，或更改数据包的状态，或与Ack矢量或等效选项不一致（通过
reporting a "not yet received" packet as "dropped in the receive buffer", for example) SHOULD be considered invalid. The receiving DCCP SHOULD either ignore such options, or respond by resetting the connection with Reset Code 5, "Option Error".
将“尚未接收”数据包报告为“已丢弃在接收缓冲区中”（例如），应视为无效。接收DCCP应忽略此类选项，或通过重置代码5“选项错误”重置连接进行响应。
A DCCP application interface should let receiving applications specify the Drop Codes corresponding to received packets. For example, this would let applications calculate their own checksums but still report "dropped due to corruption" packets via the Data Dropped option. The interface SHOULD NOT let applications reduce the "seriousness" of a packet's Drop Code; for example, the application should not be able to upgrade a packet from delivered corrupt (Drop Code 7) to delivered normally (no Drop Code).
DCCP应用程序接口应允许接收应用程序指定与接收到的数据包对应的丢弃码。例如，这将允许应用程序计算自己的校验和，但仍然通过数据丢弃选项报告“由于损坏而丢弃”的数据包。接口不应让应用程序降低数据包丢弃代码的“严重性”；例如，应用程序不能将数据包从已交付的损坏（丢弃代码7）升级为正常交付（无丢弃代码）。
Data Dropped information is transmitted reliably. That is, endpoints SHOULD continue to transmit Data Dropped options until receiving an acknowledgement indicating that the relevant options have been processed. In Ack Vector terms, each acknowledgement should contain Data Dropped options that cover the whole Acknowledgement Window (Section 11.4.2), although when every packet in that window would be placed in a Normal Block, no actual option is required.
数据丢弃信息可靠传输。也就是说，端点应继续传输数据丢弃选项，直到接收到指示相关选项已被处理的确认。在Ack向量术语中，每个确认应包含覆盖整个确认窗口的数据丢弃选项（第11.4.2节），尽管当该窗口中的每个数据包将被放置在正常块中时，不需要实际选项。
When deciding on a response to a particular acknowledgement or set of acknowledgements containing Data Dropped options, a congestion control mechanism MUST consider dropped packets, ECN Congestion Experienced marks (including marked packets that are included in Data Dropped), and packets singled out in Data Dropped. For window-based mechanisms, the valid response space is defined as follows.
当决定对包含数据丢弃选项的特定确认或确认集合的响应时，拥塞控制机制必须考虑丢弃的分组、ECN拥塞经历的标记（包括被丢弃的数据中包含的标记分组）和在丢弃的数据中选出的分组。对于基于窗口的机制，有效响应空间定义如下。
Assume an old window of W. Independently calculate a new window W_new1 that assumes no packets were Data Dropped (so W_new1 contains only the normal congestion response), and a new window W_new2 that assumes no packets were lost or marked (so W_new2 contains only the Data Dropped response). We are assuming that Data Dropped recommended a reduction in congestion window, so W_new2 < W.
假设旧窗口为W。独立计算一个新窗口W_new1，该窗口假设没有数据包被丢弃（因此W_new1仅包含正常拥塞响应），以及一个新窗口W_new2，该窗口假设没有数据包丢失或标记（因此W_new2仅包含数据丢弃响应）。我们假设丢弃的数据建议减少拥塞窗口，因此W_new2<W。
Then the actual new window W_new MUST NOT be larger than the minimum of W_new1 and W_new2; and the sender MAY combine the two responses, by setting
那么实际的新窗口W_new不得大于W_new1和W_new2的最小值；发送方可以通过设置
W_new = W + min(W_new1 - W, 0) + min(W_new2 - W, 0).
W_new=W+min（W_new1-W，0）+min（W_new2-W，0）。
The details of how this is accomplished are specified in CCID profile documents. Non-window-based congestion control mechanisms MUST behave analogously; again, CCID profiles define how.
CCID概要文件中详细说明了如何实现这一点。非基于窗口的拥塞控制机制必须具有相似的行为；同样，CCID配置文件定义了如何使用。
Drop Code 0, Protocol Constraints, does not indicate any kind of congestion, so the sender's CCID SHOULD react to packets with Drop Code 0 as if they were received (with or without ECN Congestion Experienced marks, as appropriate). However, the sending endpoint SHOULD NOT send data until it believes the protocol constraint no longer applies.
丢弃码0（协议约束）并不表示任何类型的拥塞，因此发送方的CCID应该对丢弃码为0的数据包做出反应，就好像它们被接收到一样（根据需要，有或没有ECN拥塞标记）。但是，发送端点在认为协议约束不再适用之前不应发送数据。
Drop Code 1, Application Not Listening, means the application running at the endpoint that sent the option is no longer listening for data. For example, a server might close its receiving half-connection to new data after receiving a complete request from the client. This would limit the amount of state available at the server for incoming data and thus reduce the potential damage from certain denial-of-service attacks. A Data Dropped option containing Drop Code 1 SHOULD be sent whenever received data is ignored due to a non-listening application. Once an endpoint reports Drop Code 1 for a packet, it SHOULD report Drop Code 1 for every succeeding data packet on that half-connection; once an endpoint receives a Drop State 1 report, it SHOULD expect that no more data will ever be delivered to the other endpoint's application, so it SHOULD NOT send more data.
删除代码1，Application Not Listening，表示在发送选项的端点上运行的应用程序不再侦听数据。例如，服务器可能在收到来自客户端的完整请求后关闭其与新数据的接收连接。这将限制服务器上可用于传入数据的状态量，从而减少某些拒绝服务攻击造成的潜在损害。由于非侦听应用程序而忽略接收的数据时，应发送包含删除代码1的数据删除选项。一旦一个端点报告一个数据包的丢弃代码1，它应该报告该半连接上每个后续数据包的丢弃代码1；一旦一个端点接收到Drop State 1报告，它应该认为不会有更多的数据发送到另一个端点的应用程序，因此它不应该发送更多的数据。
Drop Code 2, Receive Buffer, indicates congestion inside the receiving host. For instance, if a drop-from-tail kernel socket buffer is too full to accept a packet's application data, that packet should be reported as Drop Code 2. For a drop-from-head or more complex socket buffer, the dropped packet should be reported as Drop Code 2. DCCP implementations may also provide an API by which applications can mark received packets as Drop Code 2, indicating that the application ran out of space in its user-level receive buffer. (However, it is not generally useful to report packets as dropped due to Drop Code 2 after more than a couple of round-trip times have passed. The HC-Sender may have forgotten its acknowledgement state for the packet by that time, so the Data Dropped report will have no effect.) Every packet newly acknowledged as Drop Code 2 SHOULD reduce the sender's instantaneous rate by one packet per round-trip time, unless the sender is already sending one packet per RTT or less. Each CCID profile defines the CCID-specific mechanism by which this is accomplished.
丢弃代码2，接收缓冲区，表示接收主机内的拥塞。例如，如果从尾部内核套接字缓冲区丢弃的数据太满，无法接受数据包的应用程序数据，则该数据包应报告为丢弃代码2。对于从头部或更复杂的套接字缓冲区丢弃的数据包，应将丢弃的数据包报告为丢弃代码2。DCCP实现还可以提供一个API，通过该API，应用程序可以将接收到的数据包标记为丢弃码2，指示应用程序的用户级接收缓冲区中的空间不足。（但是，通常情况下，在经过两次以上的往返时间后，报告由于丢弃代码2而丢弃的数据包是没有用的。HC发送方可能在那时忘记了其对数据包的确认状态，因此数据丢弃报告将不起作用。）每一个新确认为丢弃码2的数据包应将发送方的瞬时速率每往返时间减少一个数据包，除非发送方已经在每RTT发送一个数据包或更少。每个CCID配置文件定义了实现这一点的CCID特定机制。
Currently, the other Drop Codes (namely Drop Code 3, Corrupt; Drop Code 7, Delivered Corrupt; and reserved Drop Codes 4-6) MUST cause the relevant CCID to behave as if the relevant packets were ECN marked (ECN Congestion Experienced).
目前，其他丢弃代码（即丢弃代码3，损坏；丢弃代码7，交付损坏；保留丢弃代码4-6）必须使相关CCID表现为相关数据包被ECN标记（ECN拥塞）。
The DCCP protocol is fully ECN-aware [RFC3168]. Each CCID specifies how its endpoints respond to ECN marks. Furthermore, DCCP, unlike TCP, allows senders to control the rate at which acknowledgements are generated (with options like Ack Ratio); since acknowledgements are congestion controlled, they also qualify as ECN-Capable Transport.
DCCP协议完全支持ECN[RFC3168]。每个CCID指定其端点如何响应ECN标记。此外，与TCP不同，DCCP允许发送方控制生成确认的速率（使用诸如Ack比率的选项）；由于确认是拥塞控制的，因此它们也可以作为支持ECN的传输。
Each CCID profile describes how that CCID interacts with ECN, both for data traffic and pure-acknowledgement traffic. A sender SHOULD set ECN-Capable Transport on its packets' IP headers unless the receiver's ECN Incapable feature is on or the relevant CCID disallows it.
每个CCID配置文件都描述了CCID如何与ECN交互，包括数据流量和纯确认流量。发送方应在其数据包的IP头上设置支持ECN的传输，除非接收方的不支持ECN功能已启用或相关CCID不允许。
The rest of this section describes the ECN Incapable feature and the interaction of the ECN Nonce with acknowledgement options such as Ack Vector.
本节的其余部分描述了ECN无能力特性以及ECN Nonce与确认选项（如Ack向量）的交互。
DCCP endpoints are ECN-aware by default, but the ECN Incapable feature lets an endpoint reject the use of Explicit Congestion Notification. The use of this feature is NOT RECOMMENDED. ECN incapability both avoids ECN's possible benefits and prevents senders from using the ECN Nonce to check for receiver misbehavior. A DCCP stack MAY therefore leave the ECN Incapable feature unimplemented, acting as if all connections were ECN capable. Note that the inappropriate firewall interactions that dogged TCP's implementation of ECN [RFC3360] involve TCP header bits, not the IP header's ECN bits; we know of no middlebox that would block ECN-capable DCCP packets but allow ECN-incapable DCCP packets.
DCCP endpoints are ECN-aware by default, but the ECN Incapable feature lets an endpoint reject the use of Explicit Congestion Notification. The use of this feature is NOT RECOMMENDED. ECN incapability both avoids ECN's possible benefits and prevents senders from using the ECN Nonce to check for receiver misbehavior. A DCCP stack MAY therefore leave the ECN Incapable feature unimplemented, acting as if all connections were ECN capable. Note that the inappropriate firewall interactions that dogged TCP's implementation of ECN [RFC3360] involve TCP header bits, not the IP header's ECN bits; we know of no middlebox that would block ECN-capable DCCP packets but allow ECN-incapable DCCP packets.translate error, please retry
ECN Incapable has feature number 4 and is server-priority. It takes one-byte Boolean values. DCCP A MUST be able to read ECN bits from received frames' IP headers when ECN Incapable/A is zero. (This is independent of whether it can set ECN bits on sent frames.) DCCP A thus sends a "Change L(ECN Inapable, 1)" option to DCCP B to inform it that A cannot read ECN bits. If the ECN Incapable/A feature is one, then all of DCCP B's packets MUST be sent as ECN incapable. New connections start with ECN Incapable 0 (that is, ECN capable) for both endpoints. Values of two or more are reserved.
ECN具有功能编号4，是服务器优先级。它需要一个字节的布尔值。当ECN/A为零时，DCCP A必须能够从接收帧的IP头读取ECN位。（这与是否可以在发送的帧上设置ECN位无关。）因此，DCCP A向DCCP B发送“更改L（ECN不可访问，1）”选项，通知其A无法读取ECN位。如果ECN NOABLE/A功能是一个，则DCCP B的所有数据包都必须作为ECN NOABLE发送。新连接从两个端点的ECN 0（即，ECN能力）开始。保留两个或两个以上的值。
If a DCCP is not ECN capable, it MUST send Mandatory "Change L(ECN Incapable, 1)" options to the other endpoint until acknowledged (by "Confirm R(ECN Incapable, 1)") or the connection closes. Furthermore, it MUST NOT accept any data until the other endpoint
如果DCCP不支持ECN，则必须向另一个端点发送强制的“更改L（ECN无法，1）”选项，直到确认（通过“确认R（ECN无法，1）”或连接关闭。此外，它必须在另一个端点之前不接受任何数据
sends "Confirm R(ECN Incapable, 1)". It SHOULD send Data Dropped options on its acknowledgements, with Drop Code 0 ("protocol constraints"), if the other endpoint does send data inappropriately.
发送“确认R（ECN，1）”。如果另一个端点确实不适当地发送数据，它应该在其确认上发送数据删除选项，删除代码为0（“协议约束”）。
Congestion avoidance will not occur, and the receiver will sometimes get its data faster, if the sender isn't told about congestion events. Thus, the receiver has some incentive to falsify acknowledgement information, reporting that marked or dropped packets were actually received unmarked. This problem is more serious with DCCP than with TCP, since TCP provides reliable transport: it is more difficult with TCP to lie about lost packets without breaking the application.
避免拥塞不会发生，如果发送方没有被告知拥塞事件，接收方有时会更快地获取数据。因此，接收方有一些动机伪造确认信息，报告已标记或丢弃的数据包实际上是未标记地接收到的。与TCP相比，DCCP的问题更严重，因为TCP提供了可靠的传输：TCP更难在不中断应用程序的情况下隐瞒丢失的数据包。
ECN Nonces are a general mechanism to prevent ECN cheating (or loss cheating). Two values for the two-bit ECN header field indicate ECN-Capable Transport, 01 and 10. The second code point, 10, is the ECN Nonce. In general, a protocol sender chooses between these code points randomly on its output packets, remembering the sequence it chose. On every acknowledgement, the protocol receiver reports the number of ECN Nonces it has received thus far. This is called the ECN Nonce Echo. Since ECN marking and packet dropping both destroy the ECN Nonce, a receiver that lies about an ECN mark or packet drop has a 50% chance of guessing right and avoiding discipline. The sender may react punitively to an ECN Nonce mismatch, possibly up to dropping the connection. The ECN Nonce Echo field need not be an integer; one bit is enough to catch 50% of infractions, and the probability of success drops exponentially as more packets are sent [RFC3540].
ECN Nonces是防止ECN欺骗（或丢失欺骗）的一般机制。两位ECN标头字段的两个值表示支持ECN的传输，01和10。第二个代码点10是ECN Nonce。通常，协议发送方在其输出数据包上随机选择这些代码点，记住它选择的序列。在每次确认时，协议接收器报告其迄今为止接收到的ECN nonce的数量。这被称为ECN Nonce Echo。由于ECN标记和数据包丢弃都会破坏ECN状态，因此在ECN标记或数据包丢弃附近撒谎的接收器有50%的机会猜对并避免遵守规则。发送方可能会对ECN暂时不匹配作出惩罚性反应，可能会中断连接。ECN Nonce Echo字段不需要是整数；一个比特足以捕获50%的违规行为，并且随着发送更多数据包，成功的概率呈指数下降[RFC3540]。
In DCCP, the ECN Nonce Echo field is encoded in acknowledgement options. For example, the Ack Vector option comes in two forms, Ack Vector [Nonce 0] (option 38) and Ack Vector [Nonce 1] (option 39), corresponding to the two values for a one-bit ECN Nonce Echo. The Nonce Echo for a given Ack Vector equals the one-bit sum (exclusive-or, or parity) of ECN nonces for packets reported by that Ack Vector as received and not ECN marked. Thus, only packets marked as State 0 matter for this calculation (that is, valid received packets that were not ECN marked). Every Ack Vector option is detailed enough for the sender to determine what the Nonce Echo should have been. It can check this calculation against the actual Nonce Echo and complain if there is a mismatch. (The Ack Vector could conceivably report every packet's ECN Nonce state, but this would severely limit its compressibility without providing much extra protection.)
在DCCP中，ECN Nonce Echo字段编码在确认选项中。例如，Ack向量选项有两种形式，Ack向量[Nonce 0]（选项38）和Ack向量[Nonce 1]（选项39），对应于一位ECN Nonce回波的两个值。给定Ack向量的Nonce Echo等于该Ack向量报告为已接收且未标记ECN的数据包的ECN Nonce的一位和（异或或奇偶校验）。因此，只有标记为状态0的数据包才与此计算有关（即，未标记ECN的有效接收数据包）。每个Ack Vector选项都足够详细，发送方可以确定Nonce Echo应该是什么。它可以根据实际的非同步回波检查此计算，并在不匹配时进行投诉。（可以想象，Ack向量可以报告每个数据包的ECN Nonce状态，但这将严重限制其可压缩性，而不会提供太多额外的保护。）
Each DCCP sender SHOULD set ECN Nonces on its packets and remember which packets had nonces. When a sender detects an ECN Nonce Echo
每个DCCP发送方应在其数据包上设置ECN nonce，并记住哪些数据包具有nonce。当发送方检测到ECN Nonce回波时
mismatch, it behaves as described in the next section. Each DCCP receiver MUST calculate and use the correct value for ECN Nonce Echo when sending acknowledgement options.
不匹配，其行为将如下一节所述。发送确认选项时，每个DCCP接收器必须计算并使用ECN Nonce Echo的正确值。
ECN incapability, as indicated by the ECN Incapable feature, is handled as follows: an endpoint sending packets to an ECN-incapable receiver MUST send its packets as ECN incapable, and an ECN-incapable receiver MUST use the value zero for all ECN Nonce Echoes.
如ECN NONCABLE特性所示，ECN NONCABLE的处理如下：向ECN NONCABLE接收器发送数据包的端点必须将其数据包作为ECN NONCABLE发送，并且ECN NONCABLE接收器必须对所有ECN Nonce回波使用值零。
DCCP endpoints have several mechanisms for detecting congestion-related misbehavior. For example:
DCCP端点有几种机制用于检测与拥塞相关的不当行为。例如：
o A sender can detect an ECN Nonce Echo mismatch, indicating possible receiver misbehavior.
o 发送方可以检测到ECN非同步回波不匹配，这表明可能的接收方错误行为。
o A receiver can detect whether the sender is responding to congestion feedback or Slow Receiver.
o 接收方可以检测发送方是对拥塞反馈做出响应，还是接收速度慢。
o An endpoint may be able to detect that its peer is reporting inappropriately small Elapsed Time values (Section 13.2).
o 端点可能能够检测到其对等方报告的耗用时间值过小（第13.2节）。
An endpoint that detects possible congestion-related misbehavior SHOULD try to verify that its peer is truly misbehaving. For example, a sending endpoint might send a packet whose ECN header field is set to Congestion Experienced, 11; a receiver that doesn't report a corresponding mark is most likely misbehaving.
检测可能与拥塞相关的异常行为的端点应尝试验证其对等方是否确实存在异常行为。例如，发送端点可以发送其ECN报头字段设置为拥塞经历的分组，11；没有报告相应标记的接收者最有可能行为不端。
Upon detecting possible misbehavior, a sender SHOULD respond as if the receiver had reported one or more recent packets as ECN-marked (instead of unmarked), while a receiver SHOULD report one or more recent non-marked packets as ECN-marked. Alternately, a sender might act as if the receiver had sent a Slow Receiver option, and a receiver might send Slow Receiver options. Other reactions that serve to slow the transfer rate are also acceptable. An entity that detects particularly egregious and ongoing misbehavior MAY also reset the connection with Reset Code 11, "Aggression Penalty".
在检测到可能的不当行为后，发送方应作出响应，就像接收方已将一个或多个最近的数据包报告为ECN标记（而不是未标记），而接收方应将一个或多个最近未标记的数据包报告为ECN标记。或者，发送方可能会表现得好像接收方发送了慢速接收方选项，而接收方可能会发送慢速接收方选项。其他有助于减缓转移速率的反应也是可以接受的。检测到异常和持续不当行为的实体也可以使用重置代码11“侵略惩罚”重置连接。
However, ECN Nonce mismatches and other warning signs can result from innocent causes, such as implementation bugs or attack. In particular, a successful DCCP-Data attack (Section 7.5.5) can cause the receiver to report an incorrect ECN Nonce Echo. Therefore, connection reset and other heavyweight mechanisms SHOULD be used only as last resorts, after multiple round-trip times of verified aggression.
然而，ECN Nonce不匹配和其他警告信号可能是由无辜的原因造成的，例如实现错误或攻击。特别是，成功的DCCP数据攻击（第7.5.5节）会导致接收器报告不正确的ECN立即回波。因此，连接重置和其他重量级机制只能在多次往返验证攻击后作为最后手段使用。
The Timestamp, Timestamp Echo, and Elapsed Time options help DCCP endpoints explicitly measure round-trip times.
时间戳、时间戳回显和运行时间选项有助于DCCP端点明确测量往返时间。
This option is permitted in any DCCP packet. The length of the option is 6 bytes.
此选项在任何DCCP数据包中都是允许的。该选项的长度为6字节。
+--------+--------+--------+--------+--------+--------+
|00101001|00000110| Timestamp Value |
+--------+--------+--------+--------+--------+--------+
Type=41 Length=6
+--------+--------+--------+--------+--------+--------+
|00101001|00000110| Timestamp Value |
+--------+--------+--------+--------+--------+--------+
Type=41 Length=6
The four bytes of option data carry the timestamp of this packet. The timestamp is a 32-bit integer that increases monotonically with time, at a rate of 1 unit per 10 microseconds. At this rate, Timestamp Value will wrap approximately every 11.9 hours. Endpoints need not measure time at this fine granularity; for example, an endpoint that preferred to measure time at millisecond granularity might send Timestamp Values that were all multiples of 100. The precise time corresponding to Timestamp Value zero is not specified: Timestamp Values are only meaningful relative to other Timestamp Values sent on the same connection. A DCCP receiving a Timestamp option SHOULD respond with a Timestamp Echo option on the next packet it sends.
选项数据的四个字节携带该数据包的时间戳。时间戳是一个32位整数，随时间单调递增，速率为每10微秒1个单位。按此速率，时间戳值将大约每11.9小时包装一次。端点不需要在这样精细的粒度上测量时间；例如，倾向于以毫秒粒度测量时间的端点可能发送的时间戳值都是100的倍数。未指定与时间戳值零对应的精确时间：时间戳值仅相对于在同一连接上发送的其他时间戳值有意义。接收时间戳选项的DCCP应在其发送的下一个数据包上响应时间戳回显选项。
This option is permitted in any DCCP packet that contains an Acknowledgement Number; such options received on other packet types MUST be ignored. It indicates how much time has elapsed since the packet being acknowledged -- the packet with the given Acknowledgement Number -- was received. The option may take 4 or 6 bytes, depending on the size of the Elapsed Time value. Elapsed Time helps correct round-trip time estimates when the gap between receiving a packet and acknowledging that packet may be long -- in CCID 3, for example, where acknowledgements are sent infrequently.
在包含确认号的任何DCCP数据包中允许此选项；必须忽略在其他数据包类型上收到的此类选项。它指示自接收到被确认的数据包（具有给定确认号的数据包）以来经过的时间。该选项可能需要4或6个字节，具体取决于所用时间值的大小。当接收数据包和确认数据包之间的间隔可能很长时，经过的时间有助于纠正往返时间估计值——例如，在CCID 3中，很少发送确认。
+--------+--------+--------+--------+
|00101011|00000100| Elapsed Time |
+--------+--------+--------+--------+
Type=43 Len=4
+--------+--------+--------+--------+
|00101011|00000100| Elapsed Time |
+--------+--------+--------+--------+
Type=43 Len=4
+--------+--------+--------+--------+--------+--------+
|00101011|00000110| Elapsed Time |
+--------+--------+--------+--------+--------+--------+
Type=43 Len=6
+--------+--------+--------+--------+--------+--------+
|00101011|00000110| Elapsed Time |
+--------+--------+--------+--------+--------+--------+
Type=43 Len=6
The option data, Elapsed Time, represents an estimated lower bound on the amount of time elapsed since the packet being acknowledged was received, with units of hundredths of milliseconds. If Elapsed Time is less than a half-second, the first, smaller form of the option SHOULD be used. Elapsed Times of more than 0.65535 seconds MUST be sent using the second form of the option. The special Elapsed Time value 4294967295, which corresponds to approximately 11.9 hours, is used to represent any Elapsed Time greater than 42949.67294 seconds. DCCP endpoints MUST NOT report Elapsed Times that are significantly larger than the true elapsed times. A connection MAY be reset with Reset Code 11, "Aggression Penalty", if one endpoint determines that the other is reporting a much-too-large Elapsed Time.
选项data，appeased Time，表示自接收到被确认的数据包以来经过的时间量的估计下限，单位为百分之一毫秒。如果经过的时间少于半秒，则应使用选项的第一个较小形式。必须使用选项的第二种形式发送超过0.65535秒的运行时间。特殊运行时间值4294967295对应于大约11.9小时，用于表示任何大于42949.67294秒的运行时间。DCCP端点报告的运行时间不得明显大于真实运行时间。如果一个端点确定另一个端点报告的运行时间太长，则可以使用重置代码11“攻击惩罚”重置连接。
Elapsed Time is measured in hundredths of milliseconds as a compromise between two conflicting goals. First, it provides enough granularity to reduce rounding error when measuring elapsed time over fast LANs; second, it allows many reasonable elapsed times to fit into two bytes of data.
作为两个相互冲突的目标之间的折衷，耗用时间以百分之一毫秒为单位。首先，它提供了足够的粒度，以减少在快速局域网上测量运行时间时的舍入误差；其次，它允许在两个字节的数据中容纳许多合理的运行时间。
This option is permitted in any DCCP packet, as long as at least one packet carrying the Timestamp option has been received. Generally, a DCCP endpoint should send one Timestamp Echo option for each Timestamp option it receives, and it should send that option as soon as is convenient. The length of the option is between 6 and 10 bytes, depending on whether Elapsed Time is included and how large it is.
只要至少收到一个带有时间戳选项的数据包，任何DCCP数据包中都允许使用此选项。通常，DCCP端点应该为接收到的每个时间戳选项发送一个时间戳回显选项，并且应该在方便的情况下尽快发送该选项。该选项的长度介于6到10字节之间，具体取决于是否包含经过的时间以及它的大小。
+--------+--------+--------+--------+--------+--------+
|00101010|00000110| Timestamp Echo |
+--------+--------+--------+--------+--------+--------+
Type=42 Len=6
+--------+--------+--------+--------+--------+--------+
|00101010|00000110| Timestamp Echo |
+--------+--------+--------+--------+--------+--------+
Type=42 Len=6
+--------+--------+------- ... -------+--------+--------+
|00101010|00001000| Timestamp Echo | Elapsed Time |
+--------+--------+------- ... -------+--------+--------+
Type=42 Len=8 (4 bytes)
+--------+--------+------- ... -------+--------+--------+
|00101010|00001000| Timestamp Echo | Elapsed Time |
+--------+--------+------- ... -------+--------+--------+
Type=42 Len=8 (4 bytes)
+--------+--------+------- ... -------+------- ... -------+
|00101010|00001010| Timestamp Echo | Elapsed Time |
+--------+--------+------- ... -------+------- ... -------+
Type=42 Len=10 (4 bytes) (4 bytes)
+--------+--------+------- ... -------+------- ... -------+
|00101010|00001010| Timestamp Echo | Elapsed Time |
+--------+--------+------- ... -------+------- ... -------+
Type=42 Len=10 (4 bytes) (4 bytes)
The first four bytes of option data, Timestamp Echo, carry a Timestamp Value taken from a preceding received Timestamp option. Usually, this will be the last packet that was received -- the packet indicated by the Acknowledgement Number, if any -- but it might be a preceding packet. Each Timestamp received will generally result in exactly one Timestamp Echo transmitted. If an endpoint has received multiple Timestamp options since the last time it sent a packet, then it MAY ignore all Timestamp options but the one included on the packet with the greatest sequence number. Alternatively, it MAY include multiple Timestamp Echo options in its response, each corresponding to a different Timestamp option.
选项数据的前四个字节Timestamp Echo携带一个从之前接收的Timestamp选项中获取的时间戳值。通常，这将是接收到的最后一个数据包——由确认号指示的数据包，如果有的话——但它可能是前一个数据包。接收到的每个时间戳通常会导致发送的时间戳回波恰好一个。如果端点自上次发送数据包以来已收到多个时间戳选项，则它可以忽略所有时间戳选项，但数据包上包含的序列号最大的时间戳选项除外。或者，它可以在其响应中包括多个时间戳回显选项，每个选项对应于不同的时间戳选项。
The Elapsed Time value, similar to that in the Elapsed Time option, indicates the amount of time elapsed since receiving the packet whose timestamp is being echoed. This time MUST have units of hundredths of milliseconds. Elapsed Time is meant to help the Timestamp sender separate the network round-trip time from the Timestamp receiver's processing time. This may be particularly important for CCIDs where acknowledgements are sent infrequently, so that there might be considerable delay between receiving a Timestamp option and sending the corresponding Timestamp Echo. A missing Elapsed Time field is equivalent to an Elapsed Time of zero. The smallest version of the option SHOULD be used that can hold the relevant Elapsed Time value.
与“已用时间”选项中的值类似，已用时间值指示自接收到其时间戳被回显的数据包以来已用的时间量。此时间必须以百分之一毫秒为单位。已用时间旨在帮助时间戳发送方将网络往返时间与时间戳接收方的处理时间分开。这对于很少发送确认的CCID来说可能特别重要，因此在接收时间戳选项和发送相应的时间戳回音之间可能存在相当大的延迟。缺失的已用时间字段相当于已用时间为零。应使用可保存相关已用时间值的最小版本的选项。
A DCCP implementation MUST maintain the maximum packet size (MPS) allowed for each active DCCP session. The MPS is influenced by the maximum packet size allowed by the current congestion control mechanism (CCMPS), the maximum packet size supported by the path's links (PMTU, the Path Maximum Transmission Unit) [RFC1191], and the lengths of the IP and DCCP headers.
DCCP实现必须保持每个活动DCCP会话允许的最大数据包大小（MPS）。MPS受当前拥塞控制机制（CCMPS）允许的最大数据包大小、路径链路（PMTU，路径最大传输单元）[RFC1191]支持的最大数据包大小以及IP和DCCP报头的长度的影响。
A DCCP application interface SHOULD let the application discover DCCP's current MPS. Generally, the DCCP implementation will refuse to send any packet bigger than the MPS, returning an appropriate error to the application. A DCCP interface MAY allow applications to request fragmentation for packets larger than PMTU, but not larger than CCMPS. (Packets larger than CCMPS MUST be rejected in any case.) Fragmentation SHOULD NOT be the default, since it decreases robustness: an entire packet is discarded if even one of its fragments is lost. Applications can usually get better error tolerance by producing packets smaller than the PMTU.
DCCP应用程序接口应允许应用程序发现DCCP的当前MPS。通常，DCCP实现将拒绝发送任何大于MPS的数据包，从而向应用程序返回适当的错误。DCCP接口可允许应用程序请求大于PMTU但不大于CCMP的数据包的分段。（在任何情况下，大于CCMP的数据包都必须被拒绝。）碎片不应是默认值，因为它会降低健壮性：即使丢失一个数据包的碎片，也会丢弃整个数据包。应用程序通常可以通过生成比PMTU更小的数据包来获得更好的容错能力。
The MPS reported to the application SHOULD be influenced by the size expected to be required for DCCP headers and options. If the application provides data that, when combined with the options the DCCP implementation would like to include, would exceed the MPS, the implementation should either send the options on a separate packet (such as a DCCP-Ack) or lower the MPS, drop the data, and return an appropriate error to the application.
向应用程序报告的MPS应受到DCCP标头和选项预期所需大小的影响。如果应用程序提供的数据与DCCP实现希望包含的选项结合使用时将超过MPS，则实现应在单独的数据包（如DCCP Ack）上发送选项，或降低MPS，丢弃数据，并向应用程序返回适当的错误。
Each DCCP endpoint MUST keep track of the current PMTU for each connection, except that this is not required for IPv4 connections whose applications have requested fragmentation. The PMTU SHOULD be initialized from the interface MTU that will be used to send packets. The MPS will be initialized with the minimum of the PMTU and the CCMPS, if any.
每个DCCP端点必须跟踪每个连接的当前PMTU，但对于其应用程序已请求分段的IPv4连接，这不是必需的。PMTU应从用于发送数据包的接口MTU初始化。MPS将使用最小的PMTU和CCMP（如有）进行初始化。
Classical PMTU discovery uses unfragmentable packets. In IPv4, these packets have the IP Don't Fragment (DF) bit set; in IPv6, all packets are unfragmentable once emitted by an end host. As specified in [RFC1191], when a router receives a packet with DF set that is larger than the next link's MTU, it sends an ICMP Destination Unreachable message back to the source whose Code indicates that an unfragmentable packet was too large to forward (a "Datagram Too Big" message). When a DCCP implementation receives a Datagram Too Big message, it decreases its PMTU to the Next-Hop MTU value given in the ICMP message. If the MTU given in the message is zero, the sender chooses a value for PMTU using the algorithm described in [RFC1191], Section 7. If the MTU given in the message is greater than the current PMTU, the Datagram Too Big message is ignored, as described in [RFC1191]. (We are aware that this may cause problems for DCCP endpoints behind certain firewalls.)
经典的PMTU发现使用不可拆分的数据包。在IPv4中，这些数据包设置了IP不分段（DF）位；在IPv6中，一旦终端主机发出，所有数据包都是不可分割的。如[RFC1191]中所述，当路由器接收到DF设置大于下一链路MTU的数据包时，它将ICMP目的地不可到达消息发送回源，该源的代码表明不可分割数据包太大而无法转发（“数据报太大”消息）。当DCCP实现接收到数据报过大消息时，它会将其PMTU降低到ICMP消息中给定的下一跳MTU值。如果消息中给出的MTU为零，则发送方使用[RFC1191]第7节中描述的算法为PMTU选择一个值。如果消息中给出的MTU大于当前PMTU，则忽略数据报过大消息，如[RFC1191]中所述。（我们知道，这可能会导致某些防火墙后面的DCCP端点出现问题。）
A DCCP implementation may allow the application occasionally to request that PMTU discovery be performed again. This will reset the PMTU to the outgoing interface's MTU. Such requests SHOULD be rate limited, to one per two seconds, for example.
DCCP实现可能允许应用程序偶尔请求再次执行PMTU发现。这会将PMTU重置为传出接口的MTU。此类请求的速率应限制为每两秒一个。
A DCCP sender MAY treat the reception of an ICMP Datagram Too Big message as an indication that the packet being reported was not lost due to congestion, and so for the purposes of congestion control it MAY ignore the DCCP receiver's indication that this packet did not arrive. However, if this is done, then the DCCP sender MUST check the ECN bits of the IP header echoed in the ICMP message and only perform this optimization if these ECN bits indicate that the packet did not experience congestion prior to reaching the router whose link MTU it exceeded.
DCCP发送方可将ICMP数据报过大消息的接收视为正在报告的数据包未因拥塞而丢失的指示，因此出于拥塞控制的目的，其可忽略DCCP接收方关于该数据包未到达的指示。但是，如果这样做，则DCCP发送方必须检查ICMP消息中回显的IP报头的ECN位，并且仅当这些ECN位指示数据包在到达其链路MTU超过的路由器之前未经历拥塞时，才执行此优化。
A DCCP implementation SHOULD ensure, as far as possible, that ICMP Datagram Too Big messages were actually generated by routers, so that attackers cannot drive the PMTU down to a falsely small value. The simplest way to do this is to verify that the Sequence Number on the ICMP error's encapsulated header corresponds to a Sequence Number that the implementation recently sent. (According to current specifications, routers should return the full DCCP header and payload up to a maximum of 576 bytes [RFC1812] or the minimum IPv6 MTU [RFC2463], although they are not required to return more than 64 bits [RFC792]. Any amount greater than 128 bits will include the Sequence Number.) ICMP Datagram Too Big messages with incorrect or missing Sequence Numbers may be ignored, or the DCCP implementation may lower the PMTU only temporarily in response. If more than three odd Datagram Too Big messages are received and the other DCCP endpoint reports more than three lost packets, however, the DCCP implementation SHOULD assume the presence of a confused router and either obey the ICMP messages' PMTU or (on IPv4 networks) switch to allowing fragmentation.
DCCP实现应尽可能确保路由器实际生成过大的ICMP数据报消息，以便攻击者无法将PMTU降低到错误的较小值。最简单的方法是验证ICMP错误的封装头上的序列号是否与实现最近发送的序列号相对应。（根据当前规范，路由器应返回完整的DCCP报头和有效负载，最大返回576字节[RFC1812]或最小IPv6 MTU[RFC2463]，尽管它们不需要返回超过64位[RFC792]。超过128位的任何数量都将包括序列号。）ICMP数据报过大且序列号不正确或缺失的消息可能会被忽略，或者DCCP实施可能仅在响应时暂时降低PMTU。但是，如果接收到三个以上的奇数数据报太大的消息，而另一个DCCP端点报告了三个以上的丢失数据包，则DCCP实现应假定存在混乱的路由器，并遵守ICMP消息的PMTU或（在IPv4网络上）切换以允许分段。
DCCP also allows upward probing of the PMTU [PMTUD], where the DCCP endpoint begins by sending small packets with DF set and then gradually increases the packet size until a packet is lost. This mechanism does not require any ICMP error processing. DCCP-Sync packets are the best choice for upward probing, since DCCP-Sync probes do not risk application data loss. The DCCP implementation inserts arbitrary data into the DCCP-Sync application area, padding the packet to the right length. Since every valid DCCP-Sync generates an immediate DCCP-SyncAck in response, the endpoint will have a pretty good idea of when a probe is lost.
DCCP还允许向上探测PMTU[PMTUD]，其中DCCP端点首先发送设置了DF的小数据包，然后逐渐增加数据包大小，直到数据包丢失。此机制不需要任何ICMP错误处理。DCCP同步数据包是向上探测的最佳选择，因为DCCP同步探测不存在应用程序数据丢失的风险。DCCP实现将任意数据插入DCCP同步应用程序区域，将数据包填充到正确的长度。由于每个有效的DCCP Sync都会生成一个立即的DCCP SyncAck响应，因此端点将非常清楚探针何时丢失。
A DCCP sender SHOULD send every packet as unfragmentable, as described above, with the following exceptions.
DCCP发送方应将每个数据包作为不可分割的数据包发送，如上所述，但以下情况除外。
o On IPv4 connections whose applications have requested fragmentation, the sender SHOULD send packets with the DF bit not set.
o 在应用程序已请求分段的IPv4连接上，发送方应发送未设置DF位的数据包。
o On IPv6 connections whose applications have requested fragmentation, the sender SHOULD use fragmentation extension headers to fragment packets larger than PMTU into suitably-sized chunks. (Those chunks are, of course, unfragmentable.)
o 在应用程序已请求分段的IPv6连接上，发送方应使用分段扩展头将大于PMTU的数据包分段为大小合适的数据块。（当然，这些块是不可分割的。）
o It is undesirable for PMTU discovery to occur on the initial connection setup handshake, as the connection setup process may not be representative of packet sizes used during the connection, and performing MTU discovery on the initial handshake might unnecessarily delay connection establishment. Thus, DCCP-Request and DCCP-Response packets SHOULD be sent as fragmentable. In addition, DCCP-Reset packets SHOULD be sent as fragmentable, although typically these would be small enough to not be a problem. For IPv4 connections, these packets SHOULD be sent with the DF bit not set; for IPv6 connections, they SHOULD be preemptively fragmented to a size not larger than the relevant interface MTU.
o 不希望在初始连接建立握手时发生PMTU发现，因为连接建立过程可能不代表在连接期间使用的分组大小，并且在初始握手上执行MTU发现可能不必要地延迟连接建立。因此，DCCP请求和DCCP响应数据包应作为可碎片发送。此外，DCCP重置数据包应作为可碎片发送，尽管这些数据包通常足够小，不会成为问题。对于IPv4连接，发送这些数据包时应未设置DF位；对于IPv6连接，它们应该以抢占方式分段，大小不超过相关接口MTU。
If the DCCP implementation has decreased the PMTU, the sending application has not requested fragmentation, and the sending application attempts to send a packet larger than the new MPS, the API MUST refuse to send the packet and return an appropriate error to the application. The application should then use the API to query the new value of MPS. The kernel might have some packets buffered for transmission that are smaller than the old MPS but larger than the new MPS. It MAY send these packets as fragmentable, or it MAY discard these packets; it MUST NOT send them as unfragmentable.
如果DCCP实现减少了PMTU，发送应用程序没有请求分段，并且发送应用程序尝试发送大于新MPS的数据包，则API必须拒绝发送数据包，并向应用程序返回适当的错误。然后应用程序应使用API查询MPS的新值。内核可能会缓冲一些数据包以进行传输，这些数据包比旧MPS小，但比新MPS大。它可以将这些数据包作为碎片发送，也可以丢弃这些数据包；它决不能把它们当作不可分割的东西。
Future versions of DCCP may add new options and features. A few simple guidelines will let extended DCCPs interoperate with normal DCCPs.
DCCP的未来版本可能会添加新的选项和功能。一些简单的指导原则将允许扩展DCCP与普通DCCP互操作。
o DCCP processors MUST NOT act punitively towards options and features they do not understand. For example, DCCP processors MUST NOT reset the connection if some field marked Reserved in this specification is non-zero; if some unknown option is present; or if some feature negotiation option mentions an unknown feature. Instead, DCCP processors MUST ignore these events. The Mandatory option is the single exception: if Mandatory precedes some unknown option or feature, the connection MUST be reset.
o DCCP处理器不得对其不了解的选项和功能采取惩罚性行动。例如，如果本规范中标记为保留的某些字段为非零，则DCCP处理器不得重置连接；如果存在未知选项；或者如果某个功能协商选项提到未知功能。相反，DCCP处理器必须忽略这些事件。强制选项是唯一的例外：如果强制在某个未知选项或功能之前，则必须重置连接。
o DCCP processors MUST anticipate the possibility of unknown feature values, which might occur as part of a negotiation for a known feature. For server-priority features, unknown values are handled as a matter of course: since the non-extended DCCP's priority list will not contain unknown values, the result of the negotiation
o DCCP处理器必须预测未知特征值的可能性，这可能是已知特征协商的一部分。对于服务器优先级特性，未知值是理所当然的：因为非扩展DCCP的优先级列表将不包含未知值，所以协商的结果
cannot be an unknown value. A DCCP MUST respond with an empty Confirm option if it is assigned an unacceptable value for some non-negotiable feature.
不能是未知值。如果为某些不可协商的特性分配了不可接受的值，则DCCP必须使用空的确认选项进行响应。
o Each DCCP extension SHOULD be controlled by some feature. The default value of this feature SHOULD correspond to "extension not available". If an extended DCCP wants to use the extension, it SHOULD attempt to change the feature's value using a Change L or Change R option. Any non-extended DCCP will ignore the option, thus leaving the feature value at its default, "extension not available".
o 每个DCCP扩展都应该由某些功能控制。此功能的默认值应对应于“扩展不可用”。如果扩展DCCP想要使用扩展，它应该尝试使用change L或change R选项更改功能的值。任何非扩展DCCP都将忽略该选项，从而将特征值保留为其默认值“扩展不可用”。
Section 19 lists DCCP assigned numbers reserved for experimental and testing purposes.
第19节列出了为实验和测试目的保留的DCCP分配编号。
This section describes properties of DCCP that firewalls, network address translators, and other middleboxes should consider, including parts of the packet that middleboxes should not change. The intent is to draw attention to aspects of DCCP that may be useful, or dangerous, for middleboxes, or that differ significantly from TCP.
本节描述了防火墙、网络地址转换器和其他中间框应该考虑的DCCP的属性，包括中间包不应该更改的部分数据包。其目的是提请注意DCCP的一些方面，这些方面可能对中间盒有用，也可能危险，或者与TCP有显著区别。
The Service Code field in DCCP-Request packets provides information that may be useful for stateful middleboxes. With Service Code, a middlebox can tell what protocol a connection will use without relying on port numbers. Middleboxes can disallow connections that attempt to access unexpected services by sending a DCCP-Reset with Reset Code 8, "Bad Service Code". Middleboxes should not modify the Service Code unless they are really changing the service a connection is accessing.
DCCP请求数据包中的服务代码字段提供了可能对有状态中间盒有用的信息。通过服务代码，中间盒可以告诉连接将使用什么协议，而不依赖端口号。通过发送重置代码为8“错误服务代码”的DCCP重置，中间盒可以禁止尝试访问意外服务的连接。中间盒不应修改服务代码，除非它们确实在更改连接正在访问的服务。
The Source and Destination Port fields are in the same packet locations as the corresponding fields in TCP and UDP, which may simplify some middlebox implementations.
源端口和目标端口字段与TCP和UDP中的相应字段位于相同的数据包位置，这可能会简化一些中间盒实现。
The forward compatibility considerations in Section 15 apply to middleboxes as well. In particular, middleboxes generally shouldn't act punitively towards options and features they do not understand.
第15节中的前向兼容性考虑也适用于中间盒。特别是，中间商通常不应该对他们不了解的选项和功能采取惩罚性的行动。
Modifying DCCP Sequence Numbers and Acknowledgement Numbers is more tedious and dangerous than modifying TCP sequence numbers. A middlebox that added packets to or removed packets from a DCCP connection would have to modify acknowledgement options, such as Ack Vector, and CCID-specific options, such as TFRC's Loss Intervals, at minimum. On ECN-capable connections, the middlebox would have to keep track of ECN Nonce information for packets it introduced or removed, so that the relevant acknowledgement options continued to
修改DCCP序列号和确认号比修改TCP序列号更繁琐和危险。向DCCP连接添加数据包或从DCCP连接中删除数据包的中间盒必须至少修改确认选项（如Ack向量）和CCID特定选项（如TFRC的丢失间隔）。在支持ECN的连接上，中间盒必须跟踪其引入或移除的数据包的ECN Nonce信息，以便相关的确认选项继续有效
have correct ECN Nonce Echoes, or risk the connection being reset for "Aggression Penalty". We therefore recommend that middleboxes not modify packet streams by adding or removing packets.
有正确的ECN立即回音，或冒着因“攻击惩罚”而重置连接的风险。因此，我们建议中间盒不要通过添加或删除数据包来修改数据包流。
Note that there is less need to modify DCCP's per-packet sequence numbers than to modify TCP's per-byte sequence numbers; for example, a middlebox can change the contents of a packet without changing its sequence number. (In TCP, sequence number modification is required to support protocols like FTP that carry variable-length addresses in the data stream. If such an application were deployed over DCCP, middleboxes would simply grow or shrink the relevant packets as necessary without changing their sequence numbers. This might involve fragmenting the packet.)
注意，与修改TCP的每字节序列号相比，修改DCCP的每数据包序列号的需要更少；例如，中间盒可以在不更改其序列号的情况下更改数据包的内容。（在TCP中，需要修改序列号以支持FTP等协议，这些协议在数据流中携带可变长度的地址。如果通过DCCP部署此类应用程序，则中间盒只需根据需要增加或减少相关数据包，而无需更改其序列号。这可能涉及对数据包进行分段。）
Middleboxes may, of course, reset connections in progress. Clearly, this requires inserting a packet into one or both packet streams, but the difficult issues do not arise.
当然，中间盒可能会重置正在进行的连接。显然，这需要将一个数据包插入一个或两个数据包流中，但不会出现困难的问题。
DCCP is somewhat unfriendly to "connection splicing" [SHHP00], in which clients' connection attempts are intercepted, but possibly later "spliced in" to external server connections via sequence number manipulations. A connection splicer at minimum would have to ensure that the spliced connections agreed on all relevant feature values, which might take some renegotiation.
DCCP对“连接拼接”[SHHP00]有些不友好，在“连接拼接”[SHHP00]中，客户端的连接尝试被截获，但可能稍后通过序列号操作“拼接”到外部服务器连接。连接拼接器至少必须确保拼接连接在所有相关特征值上达成一致，这可能需要重新协商。
The contents of this section should not be interpreted as a wholesale endorsement of stateful middleboxes.
本节内容不应被解释为对有状态的中间箱的全面认可。
The Real-Time Transport Protocol, RTP [RFC3550], is currently used over UDP by many of DCCP's target applications (for instance, streaming media). Therefore, it is important to examine the relationship between DCCP and RTP and, in particular, the question of whether any changes in RTP are necessary or desirable when it is layered over DCCP instead of UDP.
实时传输协议RTP[RFC3550]目前被许多DCCP的目标应用程序（例如，流媒体）通过UDP使用。因此，重要的是检查DCCP和RTP之间的关系，特别是当RTP在DCCP而不是UDP上分层时，RTP中的任何更改是否必要或可取。
There are two potential sources of overhead in the RTP-over-DCCP combination: duplicated acknowledgement information and duplicated sequence numbers. Together, these sources of overhead add slightly more than 4 bytes per packet relative to RTP-over-UDP, and eliminating the redundancy would not reduce the overhead.
在RTP over DCCP组合中有两个潜在的开销来源：重复的确认信息和重复的序列号。这些开销来源加在一起，相对于UDP上的RTP，每个数据包增加了略多于4个字节的开销，消除冗余不会减少开销。
First, consider acknowledgements. Both RTP and DCCP report feedback about loss rates to data senders, via RTP Control Protocol Sender and Receiver Reports (RTCP SR/RR packets) and via DCCP acknowledgement
首先，考虑确认。RTP和DCCP都通过RTP控制协议发送方和接收方报告（RTCP SR/RR数据包）和DCCP确认向数据发送方报告有关丢失率的反馈
options. These feedback mechanisms are potentially redundant. However, RTCP SR/RR packets contain information not present in DCCP acknowledgements, such as "interarrival jitter", and DCCP's acknowledgements contain information not transmitted by RTCP, such as the ECN Nonce Echo. Neither feedback mechanism makes the other redundant.
选项。这些反馈机制可能是多余的。然而，RTCP SR/RR数据包包含DCCP确认中不存在的信息，如“到达间抖动”，而DCCP的确认包含RTCP未发送的信息，如ECN Nonce Echo。任何一种反馈机制都不会使另一种机制变得多余。
Sending both types of feedback need not be particularly costly either. RTCP reports may be sent relatively infrequently: once every 5 seconds on average, for low-bandwidth flows. In DCCP, some feedback mechanisms are expensive -- Ack Vector, for example, is frequent and verbose -- but others are relatively cheap: CCID 3 (TFRC) acknowledgements take between 16 and 32 bytes of options sent once per round-trip time. (Reporting less frequently than once per RTT would make congestion control less responsive to loss.) We therefore conclude that acknowledgement overhead in RTP-over-DCCP need not be significantly higher than for RTP-over-UDP, at least for CCID 3.
发送这两种类型的反馈也不需要特别昂贵。RTCP报告的发送频率可能相对较低：对于低带宽流，平均每5秒发送一次。在DCCP中，一些反馈机制是昂贵的——例如，Ack向量是频繁且冗长的——但其他反馈机制相对便宜：CCID 3（TFRC）确认在每个往返时间发送一次16到32字节的选项。（每个RTT报告少于一次的频率会使拥塞控制对丢失的响应变差。）因此，我们得出结论，DCCP上RTP的确认开销不必明显高于UDP上RTP，至少对于CCID 3而言。
One clear redundancy can be addressed at the application level. The verbose packet-by-packet loss reports sent in RTCP Extended Reports Loss RLE Blocks [RFC3611] can be derived from DCCP's Ack Vector options. (The converse is not true, since Loss RLE Blocks contain no ECN information.) Since DCCP implementations should provide an API for application access to Ack Vector information, RTP-over-DCCP applications might request either DCCP Ack Vectors or RTCP Extended Report Loss RLE Blocks, but not both.
可以在应用程序级别解决一个明显的冗余问题。RTCP扩展报告丢失RLE块[RFC3611]中发送的详细逐包丢失报告可以从DCCP的确认向量选项中派生。（反之亦然，因为丢失RLE块不包含ECN信息。）由于DCCP实现应提供应用程序访问Ack向量信息的API，DCCP上的RTP应用程序可能会请求DCCP Ack向量或RTCP扩展报告丢失RLE块，但不能同时请求二者。
Now consider sequence number redundancy on data packets. The embedded RTP header contains a 16-bit RTP sequence number. Most data packets will use the DCCP-Data type; DCCP-DataAck and DCCP-Ack packets need not usually be sent. The DCCP-Data header is 12 bytes long without options, including a 24-bit sequence number. This is 4 bytes more than a UDP header. Any options required on data packets would add further overhead, although many CCIDs (for instance, CCID 3, TFRC) don't require options on most data packets.
现在考虑数据包上的序列号冗余。嵌入式RTP报头包含一个16位RTP序列号。大多数数据包将使用DCCP数据类型；通常不需要发送DCCP DATACK和DCCP Ack数据包。DCCP数据头的长度为12字节，没有选项，包括24位序列号。这比UDP头多4个字节。数据包上需要的任何选项都会增加额外的开销，尽管许多CCID（例如，CCID3、TFRC）在大多数数据包上不需要选项。
The DCCP sequence number cannot be inferred from the RTP sequence number since it increments on non-data packets as well as data packets. The RTP sequence number cannot be inferred from the DCCP sequence number either [RFC3550]. Furthermore, removing RTP's sequence number would not save any header space because of alignment issues. We therefore recommend that RTP transmitted over DCCP use the same headers currently defined. The 4 byte header cost is a reasonable tradeoff for DCCP's congestion control features and access to ECN. Truly bandwidth-starved endpoints should use some header compression scheme.
无法从RTP序列号推断DCCP序列号，因为它在非数据包和数据包上都是递增的。无法从DCCP序列号推断RTP序列号[RFC3550]。此外，由于对齐问题，删除RTP的序列号不会节省任何标头空间。因此，我们建议通过DCCP传输的RTP使用当前定义的相同报头。对于DCCP的拥塞控制功能和对ECN的访问，4字节的报头成本是一个合理的折衷。真正缺乏带宽的端点应该使用一些报头压缩方案。
Since DCCP doesn't provide reliable, ordered delivery, multiple application sub-flows may be multiplexed over a single DCCP connection with no inherent performance penalty. Thus, there is no need for DCCP to provide built-in support for multiple sub-flows. This differs from SCTP [RFC2960].
由于DCCP不提供可靠的、有序的交付，多个应用程序子流可以在单个DCCP连接上进行多路复用，而不会产生固有的性能损失。因此，DCCP不需要为多个子流提供内置支持。这与SCTP[RFC2960]不同。
Some applications might want to share congestion control state among multiple DCCP flows that share the same source and destination addresses. This functionality could be provided by the Congestion Manager [RFC3124], a generic multiplexing facility. However, the CM would not fully support DCCP without change; it does not gracefully handle multiple congestion control mechanisms, for example.
某些应用程序可能希望在共享相同源地址和目标地址的多个DCCP流之间共享拥塞控制状态。该功能可由拥塞管理器[RFC3124]提供，该管理器是一种通用多路复用设备。然而，CM不会在不改变的情况下完全支持DCCP；例如，它不能优雅地处理多个拥塞控制机制。
DCCP does not provide cryptographic security guarantees. Applications desiring cryptographic security services (integrity, authentication, confidentiality, access control, and anti-replay protection) should use IPsec or end-to-end security of some kind; Secure RTP is one candidate protocol [RFC3711].
DCCP不提供加密安全保证。需要加密安全服务（完整性、身份验证、机密性、访问控制和防重放保护）的应用程序应使用IPsec或某种类型的端到端安全；安全RTP是一种候选协议[RFC3711]。
Nevertheless, DCCP is intended to protect against some classes of attackers: Attackers cannot hijack a DCCP connection (close the connection unexpectedly, or cause attacker data to be accepted by an endpoint as if it came from the sender) unless they can guess valid sequence numbers. Thus, as long as endpoints choose initial sequence numbers well, a DCCP attacker must snoop on data packets to get any reasonable probability of success. Sequence number validity checks provide this guarantee. Section 7.5.5 describes sequence number security further. This security property only holds assuming that DCCP's random numbers are chosen according to the guidelines in [RFC4086].
然而，DCCP旨在防止某些类别的攻击者：攻击者无法劫持DCCP连接（意外关闭连接，或使攻击者数据被端点接受，就好像它来自发送方一样），除非他们能够猜到有效的序列号。因此，只要端点选择好初始序列号，DCCP攻击者就必须窥探数据包以获得合理的成功概率。序列号有效性检查提供了这一保证。第7.5.5节进一步描述了序列号安全性。此安全属性仅适用于假设DCCP的随机数是根据[RFC4086]中的指南选择的。
DCCP also provides mechanisms to limit the potential impact of some denial-of-service attacks. These mechanisms include Init Cookie (Section 8.1.4), the DCCP-CloseReq packet (Section 5.5), the Application Not Listening Drop Code (Section 11.7.2), limitations on the processing of options that might cause connection reset (Section 7.5.5), limitations on the processing of some ICMP messages (Section 14.1), and various rate limits, which let servers avoid extensive computation or packet generation (Sections 7.5.3, 8.1.3, and others).
DCCP还提供了限制某些拒绝服务攻击潜在影响的机制。这些机制包括Init Cookie（第8.1.4节）、DCCP CloseReq数据包（第5.5节）、应用程序未侦听丢弃代码（第11.7.2节）、对可能导致连接重置的选项处理的限制（第7.5.5节）、对某些ICMP消息处理的限制（第14.1节）以及各种速率限制，这使得服务器可以避免大量计算或数据包生成（第7.5.3节、第8.1.3节和其他章节）。
DCCP provides no protection against attackers that can snoop on data packets.
DCCP不提供任何保护，防止攻击者窥探数据包。
The partial checksum facility has a separate security impact, particularly in its interaction with authentication and encryption mechanisms. The impact is the same in DCCP as in the UDP-Lite protocol, and what follows was adapted from the corresponding text in the UDP-Lite specification [RFC3828].
部分校验和功能具有单独的安全影响，特别是在与身份验证和加密机制的交互中。DCCP中的影响与UDP Lite协议中的影响相同，以下内容改编自UDP Lite规范[RFC3828]中的相应文本。
When a DCCP packet's Checksum Coverage field is not zero, the uncovered portion of a packet may change in transit. This is contrary to the idea behind most authentication mechanisms: authentication succeeds if the packet has not changed in transit. Unless authentication mechanisms that operate only on the sensitive part of packets are developed and used, authentication will always fail for partially-checksummed DCCP packets whose uncovered part has been damaged.
当DCCP数据包的校验和覆盖范围字段不为零时，数据包的未覆盖部分可能会在传输过程中发生变化。这与大多数身份验证机制背后的想法相反：如果数据包在传输过程中没有更改，则身份验证成功。除非开发和使用仅在数据包的敏感部分上运行的身份验证机制，否则对于未覆盖部分已损坏的部分校验和DCCP数据包，身份验证将始终失败。
The IPsec integrity check (Encapsulation Security Protocol, ESP, or Authentication Header, AH) is applied (at least) to the entire IP packet payload. Corruption of any bit within that area will then result in the IP receiver's discarding a DCCP packet, even if the corruption happened in an uncovered part of the DCCP application data.
IPsec完整性检查（封装安全协议，ESP或身份验证头，AH）至少应用于整个IP数据包有效负载。该区域内任何位的损坏将导致IP接收器丢弃DCCP数据包，即使损坏发生在DCCP应用程序数据的未覆盖部分。
When IPsec is used with ESP payload encryption, a link can not determine the specific transport protocol of a packet being forwarded by inspecting the IP packet payload. In this case, the link MUST provide a standard integrity check covering the entire IP packet and payload. DCCP partial checksums provide no benefit in this case.
当IPsec与ESP有效负载加密一起使用时，链路无法通过检查IP数据包有效负载来确定转发数据包的特定传输协议。在这种情况下，链路必须提供覆盖整个IP数据包和有效负载的标准完整性检查。在这种情况下，DCCP部分校验和没有任何好处。
Encryption (e.g., at the transport or application levels) may be used. Note that omitting an integrity check can, under certain circumstances, compromise confidentiality [B98].
可以使用加密（例如，在传输或应用级别）。请注意，在某些情况下，省略完整性检查可能会损害机密性[B98]。
If a few bits of an encrypted packet are damaged, the decryption transform will typically spread errors so that the packet becomes too damaged to be of use. Many encryption transforms today exhibit this behavior. There exist encryption transforms, stream ciphers, that do not cause error propagation. Proper use of stream ciphers can be quite difficult, especially when authentication checking is omitted [BB01]. In particular, an attacker can cause predictable changes to the ultimate plaintext, even without being able to decrypt the ciphertext.
如果加密数据包的一些位被损坏，解密转换通常会传播错误，从而使数据包损坏得无法使用。如今，许多加密转换都表现出这种行为。存在不会导致错误传播的加密转换（流密码）。正确使用流密码可能非常困难，尤其是在省略身份验证检查的情况下[BB01]。特别是，即使无法解密密文，攻击者也可以对最终明文进行可预测的更改。
IANA has assigned IP Protocol Number 33 to DCCP.
IANA已将IP协议编号33分配给DCCP。
DCCP introduces eight sets of numbers whose values should be allocated by IANA. We refer to allocation policies, such as Standards Action, outlined in [RFC2434], and most registries reserve some values for experimental and testing use [RFC3692]. In addition, DCCP requires that the IANA Port Numbers registry be opened for DCCP port registrations; Section 19.9 describes how. The IANA should feel free to contact the DCCP Expert Reviewer with questions on any registry, regardless of the registry policy, for clarification or if there is a problem with a request.
DCCP引入了八组数字，其值应由IANA分配。我们参考分配策略，如[RFC2434]中概述的标准操作，大多数注册中心保留一些值供实验和测试使用[RFC3692]。此外，DCCP要求为DCCP端口注册打开IANA端口号注册表；第19.9节描述了如何进行。IANA应随时联系DCCP专家评审员，询问任何注册处的问题，无论注册处的政策如何，以进行澄清或请求是否存在问题。
Each entry in the DCCP Packet Types registry contains a packet type, which is a number in the range 0-15; a packet type name, such as DCCP-Request; and a reference to the RFC defining the packet type. The registry is initially populated using the values in Table 1 (Section 5.1). This document allocates packet types 0-9, and packet type 14 is permanently reserved for experimental and testing use. Packet types 10-13 and 15 are currently reserved and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.
DCCP数据包类型注册表中的每个条目都包含一个数据包类型，该数据包类型是0-15范围内的数字；数据包类型名称，如DCCP请求；以及对定义分组类型的RFC的引用。注册表最初使用表1（第5.1节）中的值填充。本文档分配数据包类型0-9，数据包类型14永久保留供实验和测试使用。数据包类型10-13和15目前是保留的，应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC发布。
Each entry in the DCCP Reset Codes registry contains a Reset Code, which is a number in the range 0-255; a short description of the Reset Code, such as "No Connection"; and a reference to the RFC defining the Reset Code. The registry is initially populated using the values in Table 2 (Section 5.6). This document allocates Reset Codes 0-11, and Reset Codes 120-126 are permanently reserved for experimental and testing use. Reset Codes 12-119 and 127 are currently reserved and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards track or not) with IESG review and approval. Reset Codes 128-255 are permanently reserved for CCID-specific registries; each CCID Profile document describes how the corresponding registry is managed.
DCCP重置代码注册表中的每个条目都包含一个重置代码，该代码是一个范围在0-255之间的数字；重置代码的简短说明，如“无连接”；以及对定义重置代码的RFC的引用。注册表最初使用表2中的值填充（第5.6节）。本文件分配重置代码0-11，重置代码120-126永久保留供实验和测试使用。重置代码12-119和127目前保留，应与IETF共识政策一起分配，要求IETF RFC出版物（标准跟踪或非标准跟踪）经IESG审查和批准。重置代码128-255永久保留给CCID特定注册表；每个CCID配置文件文档都描述了如何管理相应的注册表。
Each entry in the DCCP option types registry contains an option type, which is a number in the range 0-255; the name of the option, such as "Slow Receiver"; and a reference to the RFC defining the option type. The registry is initially populated using the values in Table 3 (Section 5.8). This document allocates option types 0-2 and 32-44,
DCCP选项类型注册表中的每个条目都包含一个选项类型，它是一个范围为0-255的数字；选项的名称，如“慢速接收器”；定义对RFC的类型和引用。注册表最初使用表3（第5.8节）中的值填充。本文件分配选项类型0-2和32-44，
and option types 31 and 120-126 are permanently reserved for experimental and testing use. Option types 3-30, 45-119, and 127 are currently reserved and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards track or not) with IESG review and approval. Option types 128-255 are permanently reserved for CCID-specific registries; each CCID Profile document describes how the corresponding registry is managed.
选项类型31和120-126永久保留供实验和测试使用。选项类型3-30、45-119和127目前保留，应与IETF共识政策一起分配，要求IETF RFC出版物（标准跟踪与否）经IESG审查和批准。选项类型128-255永久保留给CCID特定注册表；每个CCID配置文件文档都描述了如何管理相应的注册表。
Each entry in the DCCP feature numbers registry contains a feature number, which is a number in the range 0-255; the name of the feature, such as "ECN Incapable"; and a reference to the RFC defining the feature number. The registry is initially populated using the values in Table 4 (Section 6). This document allocates feature numbers 0-9, and feature numbers 120-126 are permanently reserved for experimental and testing use. Feature numbers 10-119 and 127 are currently reserved and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards track or not) with IESG review and approval. Feature numbers 128-255 are permanently reserved for CCID-specific registries; each CCID Profile document describes how the corresponding registry is managed.
DCCP要素编号注册表中的每个条目都包含一个要素编号，该编号的范围为0-255；功能的名称，如“ECN无法”；以及对定义特征编号的RFC的引用。注册表最初使用表4（第6节）中的值填充。本文件分配特征编号0-9，特征编号120-126永久保留供实验和测试使用。功能编号10-119和127目前保留，应与IETF共识政策一起分配，要求IETF RFC出版物（标准跟踪与否）经IESG审查和批准。功能编号128-255永久保留给CCID特定注册表；每个CCID配置文件文档都描述了如何管理相应的注册表。
Each entry in the DCCP Congestion Control Identifiers (CCIDs) registry contains a CCID, which is a number in the range 0-255; the name of the CCID, such as "TCP-like Congestion Control"; and a reference to the RFC defining the CCID. The registry is initially populated using the values in Table 5 (Section 10). CCIDs 2 and 3 are allocated by concurrently published profiles, and CCIDs 248-254 are permanently reserved for experimental and testing use. CCIDs 0, 1, 4-247, and 255 are currently reserved and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards track or not) with IESG review and approval.
DCCP拥塞控制标识符（CCID）注册表中的每个条目都包含一个CCID，它是一个范围为0-255的数字；CCID的名称，如“类似TCP的拥塞控制”；以及对定义CCID的RFC的引用。注册表最初使用表5（第10节）中的值填充。CCID2和3由同时发布的配置文件分配，CCID248-254永久保留供实验和测试使用。CCID 0、1、4-247和255目前保留，应与IETF共识政策一起分配，要求IETF RFC出版物（标准跟踪与否）经IESG审查和批准。
Each entry in the DCCP Ack Vector States registry contains an Ack Vector State, which is a number in the range 0-3; the name of the State, such as "Received ECN Marked"; and a reference to the RFC defining the State. The registry is initially populated using the values in Table 6 (Section 11.4). This document allocates States 0, 1, and 3. State 2 is currently reserved and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.
DCCP Ack Vector States注册表中的每个条目都包含一个Ack Vector State，它是一个范围为0-3的数字；状态名称，如“已接收ECN标记”；以及对定义状态的RFC的引用。注册表最初使用表6（第11.4节）中的值填充。此文档分配状态0、1和3。国家2目前保留，应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC发布。
Each entry in the DCCP Drop Codes registry contains a Data Dropped Drop Code, which is a number in the range 0-7; the name of the Drop Code, such as "Application Not Listening"; and a reference to the RFC defining the Drop Code. The registry is initially populated using the values in Table 7 (Section 11.7). This document allocates Drop Codes 0-3 and 7. Drop Codes 4-6 are currently reserved, and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.
DCCP删除代码注册表中的每个条目都包含一个数据删除代码，该代码是一个范围为0-7的数字；放置代码的名称，例如“应用程序未侦听”；以及对定义丢弃代码的RFC的引用。注册表最初使用表7（第11.7节）中的值填充。本文档分配放置代码0-3和7。Drop代码4-6目前保留，应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC发布。
Each entry in the Service Codes registry contains a Service Code, which is a number in the range 0-4294967294; a short English description of the intended service; and an optional reference to an RFC or other publicly available specification defining the Service Code. The registry should list the Service Code's numeric value as a decimal number. When the Service Code may be represented in "SC:" format according to the rules in Section 8.1.2, the registry should also show the corresponding ASCII interpretation of the Service Code minus the "SC:" prefix. Thus, the number 1717858426 would additionally appear as "fdpz". Service Codes are not DCCP-specific. Service Code 0 is permanently reserved (it represents the absence of a meaningful Service Code), and Service Codes 1056964608-1073741823 (high byte ASCII "?") are reserved for Private Use. Note that 4294967295 is not a valid Service Code. Most of the remaining Service Codes are allocated First Come First Served, with no RFC publication required; exceptions are listed in Section 8.1.2. This document allocates a single Service Code, 1145656131 ("DISC"). This corresponds to the discard service, which discards all data sent to the service and sends no data in reply.
服务代码注册表中的每个条目都包含一个服务代码，它是一个范围在0-4294967294之间的数字；预期服务的简短英文描述；以及对定义服务代码的RFC或其他公开可用规范的可选引用。注册表应将服务代码的数值列为十进制数。根据第8.1.2节中的规则，当服务代码可能以“SC:”格式表示时，注册表还应显示服务代码减去“SC:”前缀的相应ASCII解释。因此，数字1717858426将另外显示为“fdpz”。服务代码不是特定于DCCP的。服务代码0是永久保留的（它表示没有有意义的服务代码），服务代码1056964608-1073741823（高字节ASCII“？”）保留供私人使用。请注意，4294967295不是有效的服务代码。其余大部分服务代码分配为先到先得，无需发布RFC；第8.1.2节列出了例外情况。本文档分配一个服务代码11456131（“DISC”）。这对应于discard服务，该服务丢弃发送给该服务的所有数据，并且不发送任何数据作为响应。
DCCP services may use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is therefore requested to open the existing Port Numbers registry for DCCP using the following rules, which we intend to mesh well with existing Port Numbers registration procedures.
DCCP服务可以使用联系人端口号向未知呼叫者提供服务，如TCP和UDP。因此，IANA被要求使用以下规则打开DCCP的现有端口号注册表，我们打算将这些规则与现有端口号注册程序很好地结合起来。
Port numbers are divided into three ranges. The Well Known Ports are those from 0 through 1023, the Registered Ports are those from 1024 through 49151, and the Dynamic and/or Private Ports are those from 49152 through 65535. Well Known and Registered Ports are intended for use by server applications that desire a default contact point on a system. On most systems, Well Known Ports can only be used by system (or root) processes or by programs executed by privileged
端口号分为三个范围。已知端口是从0到1023的端口，注册端口是从1024到49151的端口，动态和/或专用端口是从49152到65535的端口。已知端口和注册端口旨在供需要系统上的默认联系人的服务器应用程序使用。在大多数系统上，已知端口只能由系统（或根）进程或由特权用户执行的程序使用
users, while Registered Ports can be used by ordinary user processes or programs executed by ordinary users. Dynamic and/or Private Ports are intended for temporary use, including client-side ports, out-of-band negotiated ports, and application testing prior to registration of a dedicated port; they MUST NOT be registered.
注册端口可由普通用户进程或由普通用户执行的程序使用。动态和/或专用端口用于临时使用，包括客户端端口、带外协商端口，以及注册专用端口之前的应用程序测试；他们不得注册。
The Port Numbers registry should accept registrations for DCCP ports in the Well Known Ports and Registered Ports ranges. Well Known and Registered Ports SHOULD NOT be used without registration. Although in some cases -- such as porting an application from UDP to DCCP -- it may seem natural to use a DCCP port before registration completes, we emphasize that IANA will not guarantee registration of particular Well Known and Registered Ports. Registrations should be requested as early as possible.
端口号注册表应接受已知端口和已注册端口范围内DCCP端口的注册。未经注册，不得使用知名和注册的端口。尽管在某些情况下（例如将应用程序从UDP移植到DCCP），在注册完成之前使用DCCP端口似乎是很自然的，但我们强调IANA不会保证特定的已知和已注册端口的注册。应尽早申请注册。
Each port registration SHALL include the following information:
每个港口注册应包括以下信息：
o A short port name, consisting entirely of letters (A-Z and a-z), digits (0-9), and punctuation characters from "-_+./*" (not including the quotes).
o 一种短端口名，完全由字母（A-Z和A-Z）、数字（0-9）和“-+./*”（不包括引号）中的标点字符组成。
o The port number that is requested to be registered.
o 请求注册的端口号。
o A short English phrase describing the port's purpose. This MUST include one or more space-separated textual Service Code descriptors naming the port's corresponding Service Codes (see Section 8.1.2).
o 描述港口用途的简短英语短语。这必须包括一个或多个以空格分隔的文本服务代码描述符，用于命名端口的相应服务代码（见第8.1.2节）。
o Name and contact information for the person or entity performing the registration, and possibly a reference to a document defining the port's use. Registrations coming from IETF working groups need only name the working group, but indicating a contact person is recommended.
o 执行注册的人员或实体的姓名和联系信息，以及对定义端口使用的文档的引用。来自IETF工作组的注册只需命名工作组，但建议指定联系人。
Registrants are encouraged to follow these guidelines when submitting a registration.
鼓励注册人在提交注册时遵循这些指南。
o A port name SHOULD NOT be registered for more than one DCCP port number.
o 不应为多个DCCP端口号注册端口名。
o A port name registered for UDP MAY be registered for DCCP as well. Any such registration SHOULD use the same port number as the existing UDP registration.
o 为UDP注册的端口名也可以为DCCP注册。任何此类注册都应使用与现有UDP注册相同的端口号。
o Concrete intent to use a port SHOULD precede port registration. For example, existing UDP ports SHOULD NOT be registered in advance of any intent to use those ports for DCCP.
o 使用港口的具体意图应先于港口注册。例如，在打算将现有UDP端口用于DCCP之前，不应注册这些端口。
o A port name generally associated with TCP and/or SCTP SHOULD NOT be registered for DCCP, since that port name implies reliable transport. For example, we discourage registration of any "http" port for DCCP. However, if such a registration makes sense (that is, if there is concrete intent to use such a port), the DCCP registration SHOULD use the same port number as the existing registration.
o 通常与TCP和/或SCTP关联的端口名不应注册为DCCP，因为该端口名意味着可靠的传输。例如，我们不鼓励为DCCP注册任何“http”端口。但是，如果这种注册有意义（即，如果有使用这种端口的具体意图），则DCCP注册应使用与现有注册相同的端口号。
o Multiple DCCP registrations for the same port number are allowed as long as the registrations' Service Codes do not overlap.
o 只要注册的服务代码不重叠，就允许对同一端口号进行多个DCCP注册。
This document registers the following port. (This should be considered a model registration.)
此文档注册以下端口。（这应被视为模型注册。）
discard 9/dccp Discard SC:DISC
# IETF dccp WG, Eddie Kohler <kohler@cs.ucla.edu>, [RFC4340]
discard 9/dccp Discard SC:DISC
# IETF dccp WG, Eddie Kohler <kohler@cs.ucla.edu>, [RFC4340]
The discard service, which accepts DCCP connections on port 9, discards all incoming application data and sends no data in response. Thus, DCCP's discard port is analogous to TCP's discard port, and might be used to check the health of a DCCP stack.
discard服务接受端口9上的DCCP连接，丢弃所有传入的应用程序数据，不发送任何数据作为响应。因此，DCCP的丢弃端口类似于TCP的丢弃端口，可用于检查DCCP堆栈的运行状况。
Thanks to Jitendra Padhye for his help with early versions of this specification.
感谢Jitendra Padhye对本规范早期版本的帮助。
Thanks to Junwen Lai and Arun Venkataramani, who, as interns at ICIR, built a prototype DCCP implementation. In particular, Junwen Lai recommended that the old feature negotiation mechanism be scrapped and co-designed the current mechanism. Arun Venkataramani's feedback improved Appendix A.
感谢Junwen Lai和Arun Venkataramani，他们作为ICIR的实习生，构建了一个原型DCCP实现。特别是，赖俊文建议废除旧的功能协商机制，并共同设计当前的机制。Arun Venkataramani的反馈改进了附录A。
We thank the staff and interns of ICIR and, formerly, ACIRI, the members of the End-to-End Research Group, and the members of the Transport Area Working Group for their feedback on DCCP. We especially thank the DCCP expert reviewers Greg Minshall, Eric Rescorla, and Magnus Westerlund for detailed written comments and problem spotting, and Rob Austein and Steve Bellovin for verbal comments and written notes. We also especially thank Aaron Falk, the working group chair during the development of this specification.
我们感谢ICIR和前ACIRI的工作人员和实习生、端到端研究小组的成员以及运输区工作组的成员对DCCP的反馈。我们特别感谢DCCP专家评审员Greg Minshall、Eric Rescorla和Magnus Westerlund的详细书面评论和问题发现，以及Rob Austein和Steve Bellovin的口头评论和书面注释。在制定本规范期间，我们还特别感谢工作组主席Aaron Falk。
We also thank those who provided comments and suggestions via the DCCP BOF, Working Group, and mailing lists, including Damon Lanphear, Patrick McManus, Colin Perkins, Sara Karlberg, Kevin Lai, Bernard Aboba, Youngsoo Choi, Pengfei Di, Dan Duchamp, Lars Eggert, Gorry Fairhurst, Derek Fawcus, David Timothy Fleeman, John Loughney, Ghyslain Pelletier, Hagen Paul Pfeifer, Tom Phelan, Stanislav
我们还感谢通过DCCP BOF、工作组和邮件列表提供意见和建议的人，包括Damon Lanphear、Patrick McManus、Colin Perkins、Sara Karlberg、Kevin Lai、Bernard Aboba、Youngsoo Choi、Pengfei Di、Dan Duchamp、Lars Eggert、Gorry Fairhurst、Derek Fawcus、David Timothy Fleeman、John Loughney、Ghyslain Pelletier、，哈根·保罗·普费弗、汤姆·费兰、斯坦尼斯拉夫
Shalunov, Somsak Vanit-Anunchai, David Vos, Yufei Wang, and Michael Welzl. In particular, Colin Perkins provided extensive, detailed feedback, Michael Welzl suggested the Data Checksum option, Gorry Fairhurst provided extensive feedback on various checksum issues, and Somsak Vanit-Anunchai, Jonathan Billington, and Tul Kongprakaiwoot's Colored Petri Net model [VBK05] discovered several problems with message exchange.
沙卢诺夫、索姆萨克·瓦尼特·阿努奇、大卫·沃斯、王宇飞和迈克尔·韦尔兹尔。特别是，Colin Perkins提供了广泛、详细的反馈，Michael Welzl建议使用数据校验和选项，Gorry Fairhurst就各种校验和问题提供了广泛的反馈，Somsak Vanit Anunchai、Jonathan Billington和Tul Kongprakaiwoot的有色Petri网模型[VBK05]发现了消息交换的几个问题。
A. Appendix: Ack Vector Implementation Notes
A.附录：确认向量实施说明
This appendix discusses particulars of DCCP acknowledgement handling in the context of an abstract implementation for Ack Vector. It is informative and not normative.
本附录讨论了在Ack向量的抽象实现上下文中DCCP确认处理的细节。它是信息性的，而不是规范性的。
The first part of our implementation runs at the HC-Receiver, and therefore acknowledges data packets. It generates Ack Vector options. The implementation has the following characteristics:
我们实现的第一部分在HC接收器上运行，因此确认数据包。它生成Ack向量选项。实施具有以下特点：
o At most one byte of state per acknowledged packet.
o 每个已确认的数据包最多有一个字节的状态。
o O(1) time to update that state when a new packet arrives (normal case).
o O（1）当新数据包到达时更新该状态的时间（正常情况）。
o Cumulative acknowledgements.
o 累积确认。
o Quick removal of old state.
o 快速清除旧状态。
The basic data structure is a circular buffer containing information about acknowledged packets. Each byte in this buffer contains a state and run length; the state can be 0 (packet received), 1 (packet ECN marked), or 3 (packet not yet received). The buffer grows from right to left. The implementation maintains five variables, aside from the buffer contents:
基本数据结构是一个包含已确认数据包信息的循环缓冲区。该缓冲区中的每个字节都包含一个状态和运行长度；状态可以是0（已接收数据包）、1（已标记数据包ECN）或3（尚未接收数据包）。缓冲区从右向左增长。除了缓冲区内容外，实现还维护五个变量：
o "buf_head" and "buf_tail", which mark the live portion of the buffer.
o “buf_head”和“buf_tail”，表示缓冲区的活动部分。
o "buf_ackno", the Acknowledgement Number of the most recent packet acknowledged in the buffer. This corresponds to the "head" pointer.
o “buf_ackno”，缓冲区中最近确认的数据包的确认号。这对应于“head”指针。
o "buf_nonce", the one-bit sum (exclusive-or, or parity) of the ECN Nonces received on all packets acknowledged by the buffer with State 0.
o “buf_nonce”，缓冲区以0状态确认的所有数据包上接收的ECN nonce的一位和（异或或奇偶校验）。
We draw acknowledgement buffers like this:
我们绘制的确认缓冲区如下所示：
+---------------------------------------------------------------+
|S,L|S,L|S,L|S,L| | | | |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|
+---------------------------------------------------------------+
^ ^
buf_tail buf_head, buf_ackno = A buf_nonce = E
+---------------------------------------------------------------+
|S,L|S,L|S,L|S,L| | | | |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|
+---------------------------------------------------------------+
^ ^
buf_tail buf_head, buf_ackno = A buf_nonce = E
<=== buf_head and buf_tail move this way <===
<=== buf_head and buf_tail move this way <===
Each "S,L" represents a State/Run length byte. We will draw these buffers showing only their live portion and will add an annotation showing the Acknowledgement Number for the last live byte in the buffer. For example:
每个“S，L”表示一个状态/运行长度字节。我们将绘制这些缓冲区，仅显示其活动部分，并添加注释，显示缓冲区中最后一个活动字节的确认号。例如：
+-----------------------------------------------+
A |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L| T BN[E]
+-----------------------------------------------+
+-----------------------------------------------+
A |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L| T BN[E]
+-----------------------------------------------+
Here, buf_nonce equals E and buf_ackno equals A.
这里，buf_nonce等于E，buf_ackno等于A。
We will use this buffer as a running example.
我们将使用此缓冲区作为运行示例。
+---------------------------+
10 |0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1] [Example Buffer]
+---------------------------+
+---------------------------+
10 |0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1] [Example Buffer]
+---------------------------+
In concrete terms, its meaning is as follows:
具体而言，其含义如下：
Packet 10 was received. (The head of the buffer has sequence number 10, state 0, and run length 0.)
收到第10包。（缓冲区的头具有序列号10、状态0和运行长度0。）
Packets 9, 8, and 7 have not yet been received. (The three bytes preceding the head each have state 3 and run length 0.)
数据包9、8和7尚未收到。（头前面的三个字节分别具有状态3和运行长度0。）
Packets 6, 5, 4, 3, and 2 were received.
收到数据包6、5、4、3和2。
Packet 1 was ECN marked.
包1带有ECN标记。
Packet 0 was received.
已收到数据包0。
The one-bit sum of the ECN Nonces on packets 10, 6, 5, 4, 3, 2, and 0 equals 1.
包10、6、5、4、3、2和0上的ECN nonce的一位和等于1。
Additionally, the HC-Receiver must keep some information about the Ack Vectors it has recently sent. For each packet sent carrying an Ack Vector, it remembers four variables:
Additionally, the HC-Receiver must keep some information about the Ack Vectors it has recently sent. For each packet sent carrying an Ack Vector, it remembers four variables:translate error, please retry
o "ack_seqno", the Sequence Number used for the packet. This is an HC-Receiver sequence number.
o “ack_seqno”，用于数据包的序列号。这是HC接收器序列号。
o "ack_ptr", the value of buf_head at the time of acknowledgement.
o “确认ptr”，确认时buf_头的值。
o "ack_runlen", the run length stored in the byte of buffer data at buf_head at the time of acknowledgement.
o “ack_runlen”，确认时存储在buf_头缓冲区数据字节中的运行长度。
o "ack_ackno", the Acknowledgement Number used for the packet. This is an HC-Sender sequence number. Since acknowledgements are cumulative, this single number completely specifies all necessary information about the packets acknowledged by this Ack Vector.
o “ack_ackno”，用于数据包的确认号。这是HC发送方序列号。由于确认是累积的，所以这个数字完全指定了关于该确认向量确认的数据包的所有必要信息。
o "ack_nonce", the one-bit sum of the ECN Nonces for all State 0 packets in the buffer from buf_head to ack_ackno, inclusive. Initially, this equals the Nonce Echo of the acknowledgement's Ack Vector (or, if the ack packet contained more than one Ack Vector, the exclusive-or of all the acknowledgement's Ack Vectors). It changes as information about old acknowledgements is removed (so ack_ptr and buf_head diverge) and as old packets arrive (so they change from State 3 or State 1 to State 0).
o “ack_nonce”，缓冲区中从buf_头到ack_ackno（含）的所有状态0数据包的ECN nonce的一位总和。最初，这等于确认的Ack向量的Nonce Echo（或者，如果Ack分组包含多个Ack向量，则等于所有确认的Ack向量的异或）。它随着有关旧确认的信息被删除（因此ack_ptr和buf_head发散）和旧数据包到达（因此它们从状态3或状态1更改为状态0）而改变。
This section describes how the HC-Receiver updates its acknowledgement buffer as packets arrive from the HC-Sender.
本节描述当数据包从HC发送方到达时，HC接收方如何更新其确认缓冲区。
When a packet with Sequence Number greater than buf_ackno arrives, the HC-Receiver updates buf_head (by moving it to the left appropriately), buf_ackno (which is set to the new packet's Sequence Number), and possibly buf_nonce (if the packet arrived unmarked with ECN Nonce 1), in addition to the buffer itself. For example, if HC-Sender packet 11 arrived ECN marked, the Example Buffer above would enter this new state (changes are marked with stars):
当序列号大于buf_ackno的数据包到达时，HC接收器除了更新缓冲区本身外，还更新buf_头（通过将其适当地向左移动）、buf_ackno（设置为新数据包的序列号）以及可能的buf_nonce（如果数据包到达时未标记ECN nonce 1）。例如，如果HC发送方数据包11到达ECN标记，则上面的示例缓冲区将进入此新状态（更改用星号标记）：
** +***----------------------------+
11 |1,0|0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1]
** +***----------------------------+
** +***----------------------------+
11 |1,0|0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1]
** +***----------------------------+
If the packet's state equals the state at the head of the buffer, the HC-Receiver may choose to increment its run length (up to the maximum). For example, if HC-Sender packet 11 arrived without ECN marking and with ECN Nonce 0, the Example Buffer might enter this state instead:
如果数据包的状态等于缓冲区头部的状态，HC接收器可以选择增加其运行长度（最大）。例如，如果HC发送方数据包11到达时没有ECN标记且ECN Nonce为0，则示例缓冲区可能会进入此状态：
** +--*------------------------+
11 |0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1]
** +--*------------------------+
** +--*------------------------+
11 |0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1]
** +--*------------------------+
Of course, the new packet's sequence number might not equal the expected sequence number. In this case, the HC-Receiver will enter the intervening packets as State 3. If several packets are missing, the HC-Receiver may prefer to enter multiple bytes with run length 0, rather than a single byte with a larger run length; this simplifies table updates if one of the missing packets arrives. For example, if HC-Sender packet 12 arrived with ECN Nonce 1, the Example Buffer would enter this state:
当然，新数据包的序列号可能不等于预期的序列号。在这种情况下，HC接收机将进入作为状态3的中间分组。如果缺少多个数据包，HC接收器可能更愿意输入运行长度为0的多个字节，而不是运行长度较大的单个字节；这简化了丢失的数据包到达时的表更新。例如，如果HC发送方数据包12以ECN Nonce 1到达，则示例缓冲区将进入以下状态：
** +*******----------------------------+ *
12 |0,0|3,0|0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[0]
** +*******----------------------------+ *
** +*******----------------------------+ *
12 |0,0|3,0|0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[0]
** +*******----------------------------+ *
Of course, the circular buffer may overflow when the HC-Sender is sending data at a very high rate, when the HC-Receiver's acknowledgements are not reaching the HC-Sender, or when the HC-Sender is forgetting to acknowledge those acks (so the HC-Receiver is unable to clean up old state). In this case, the HC-Receiver should either compress the buffer (by increasing run lengths when possible), transfer its state to a larger buffer, or, as a last resort, drop all received packets, without processing them at all, until its buffer shrinks again.
当然，当HC发送方以非常高的速率发送数据时，当HC接收方的确认没有到达HC发送方时，或者当HC发送方忘记确认这些确认时（因此HC接收方无法清除旧状态），循环缓冲区可能溢出。在这种情况下，HC接收器应该压缩缓冲区（尽可能增加运行长度），将其状态转移到更大的缓冲区，或者，作为最后手段，丢弃所有接收到的数据包，而不进行任何处理，直到其缓冲区再次收缩。
When a packet with Sequence Number S <= buf_ackno arrives, the HC-Receiver will scan the table for the byte corresponding to S. (Indexing structures could reduce the complexity of this scan.) If S was previously lost (State 3), and it was stored in a byte with run length 0, the HC-Receiver can simply change the byte's state. For example, if HC-Sender packet 8 was received with ECN Nonce 0, the Example Buffer would enter this state:
当序列号为S<=buf_ackno的数据包到达时，HC接收器将扫描表中对应于S的字节（索引结构可以降低此扫描的复杂性）。如果S先前丢失（状态3），并且存储在运行长度为0的字节中，HC接收器可以简单地更改字节的状态。例如，如果接收到带有ECN Nonce 0的HC发送方数据包8，则示例缓冲区将进入以下状态：
+--------*------------------+
10 |0,0|3,0|0,0|3,0|0,4|1,0|0,0| 0 BN[1]
+--------*------------------+
+--------*------------------+
10 |0,0|3,0|0,0|3,0|0,4|1,0|0,0| 0 BN[1]
+--------*------------------+
If S was not marked as lost, or if it was not contained in the table, the packet is probably a duplicate and should be ignored. (The new packet's ECN marking state might differ from the state in the buffer; Section 11.4.1 describes what is allowed then.) If S's buffer byte has a non-zero run length, then the buffer might need to be reshuffled to make space for one or two new bytes.
如果S没有标记为丢失，或者它没有包含在表中，则该数据包可能是重复的，应该忽略。（新数据包的ECN标记状态可能与缓冲区中的状态不同；第11.4.1节描述了允许的情况。）如果s的缓冲区字节具有非零运行长度，则可能需要重新排列缓冲区，以便为一个或两个新字节留出空间。
The ack_nonce fields may also need manipulation when old packets arrive. In particular, when S transitions from State 3 or State 1 to State 0, and S had ECN Nonce 1, then the implementation should flip the value of ack_nonce for every acknowledgement with ack_ackno >= S.
当旧数据包到达时，确认字段也可能需要处理。特别是，当S从状态3或状态1转换到状态0，并且S具有ECN Nonce 1时，则对于ack\U ackno>=S的每个确认，实现应翻转ack\U Nonce的值。
It is impossible with this data structure to shift packets from State 0 to State 1, since the buffer doesn't store individual packets' ECN Nonces.
这种数据结构不可能将数据包从状态0转移到状态1，因为缓冲区不存储单个数据包的ECN nonce。
Whenever the HC-Receiver needs to generate an acknowledgement, the buffer's contents can simply be copied into one or more Ack Vector options. Copied Ack Vectors might not be maximally compressed; for example, the Example Buffer above contains three adjacent 3,0 bytes that could be combined into a single 3,2 byte. The HC-Receiver might, therefore, choose to compress the buffer in place before sending the option, or to compress the buffer while copying it; either operation is simple.
每当HC接收器需要生成确认时，缓冲器的内容可以简单地复制到一个或多个Ack向量选项中。复制的Ack向量可能不会被最大限度地压缩；例如，上面的示例缓冲区包含三个相邻的3,0字节，可以组合成一个3,2字节。因此，HC接收器可以选择在发送选项之前就地压缩缓冲区，或者在复制缓冲区时压缩缓冲区；两种操作都很简单。
Every acknowledgement sent by the HC-Receiver SHOULD include the entire state of the buffer. That is, acknowledgements are cumulative.
HC接收器发送的每个确认都应包括缓冲区的整个状态。也就是说，确认是累积的。
If the acknowledgement fits in one Ack Vector, that Ack Vector's Nonce Echo simply equals buf_nonce. For multiple Ack Vectors, more care is required. The Ack Vectors should be split at points corresponding to previous acknowledgements, since the stored ack_nonce fields provide enough information to calculate correct Nonce Echoes. The implementation should therefore acknowledge data at least once per 253 bytes of buffer state. (Otherwise, there'd be no way to calculate a Nonce Echo.)
如果确认符合一个Ack向量，则该Ack向量的Nonce Echo仅等于buf_Nonce。对于多个Ack向量，需要更加小心。由于存储的确认字段提供足够的信息来计算正确的非确认回波，因此应在对应于先前确认的点处分割确认向量。因此，实现应至少每253字节的缓冲区状态确认数据一次。（否则，就无法计算当前回波。）
For each acknowledgement it sends, the HC-Receiver will add an acknowledgement record. ack_seqno will equal the HC-Receiver sequence number it used for the ack packet; ack_ptr will equal buf_head; ack_runlen will equal the run length stored in the buffer's buf_head byte; ack_ackno will equal buf_ackno; and ack_nonce will equal buf_nonce.
对于它发送的每个确认，HC接收器将添加一个确认记录。ack_seqno将等于它用于ack分组的HC接收机序列号；ack_ptr将等于buf_头；ack_runlen将等于存储在缓冲区的buf_头字节中的运行长度；ack_ackno等于buf_ackno；确认时间等于确认时间。
Some of the HC-Sender's packets will include acknowledgement numbers, which ack the HC-Receiver's acknowledgements. When such an ack is received, the HC-Receiver finds the acknowledgement record R with the appropriate ack_seqno and then does the following:
HC发送方的一些数据包将包括确认号，确认HC接收方的确认。当接收到这样的ack时，HC接收机找到具有适当ack_seqno的确认记录R，然后执行以下操作：
o If the run length in the buffer's R.ack_ptr byte is greater than R.ack_runlen, then it decrements that run length by R.ack_runlen + 1 and sets buf_tail to R.ack_ptr. Otherwise, it sets buf_tail to R.ack_ptr + 1.
o 如果缓冲区的R.ack_ptr字节中的运行长度大于R.ack_runlen，则它将该运行长度递减R.ack_runlen+1，并将buf_tail设置为R.ack_ptr。否则，它将buf_tail设置为R.ack_ptr+1。
o If R.ack_nonce is 1, it flips buf_nonce, and the value of ack_nonce for every later ack record.
o 如果R.ack\u nonce为1，则会翻转buf\u nonce，并为以后的每个ack记录翻转ack\u nonce的值。
o It throws away R and every preceding ack record.
o 它丢弃R和之前的所有ack记录。
(The HC-Receiver may choose to keep some older information, in case a lost packet shows up late.) For example, say that the HC-Receiver storing the Example Buffer had sent two acknowledgements already:
（HC接收器可以选择保留一些旧信息，以防丢失的数据包延迟显示。）例如，假设存储示例缓冲区的HC接收器已经发送了两个确认：
1. ack_seqno = 59, ack_runlen = 1, ack_ackno = 3, ack_nonce = 1.
1. 确认序号=59，确认运行=1，确认序号=3，确认当前=1。
2. ack_seqno = 60, ack_runlen = 0, ack_ackno = 10, ack_nonce = 0.
2. 确认序号=60，确认运行=0，确认序号=10，确认当前=0。
Say the HC-Receiver then received a DCCP-DataAck packet with Acknowledgement Number 59 from the HC-Sender. This informs the HC-Receiver that the HC-Sender received, and processed, all the information in HC-Receiver packet 59. This packet acknowledged HC-Sender packet 3, so the HC-Sender has now received HC-Receiver's acknowledgements for packets 0, 1, 2, and 3. The Example Buffer should enter this state:
假设HC接收机随后从HC发送方接收到确认号为59的DCCP数据包。这通知HC接收器HC发送器接收并处理HC接收器分组59中的所有信息。发送方收到了3个数据包的确认信息，发送方收到了3个数据包的确认信息，接收方收到了3个数据包的确认信息。示例缓冲区应进入以下状态：
+------------------*+ * *
10 |0,0|3,0|3,0|3,0|0,2| 4 BN[0]
+------------------*+ * *
+------------------*+ * *
10 |0,0|3,0|3,0|3,0|0,2| 4 BN[0]
+------------------*+ * *
The tail byte's run length was adjusted, since packet 3 was in the middle of that byte. Since R.ack_nonce was 1, the buf_nonce field was flipped, as were the ack_nonce fields for later acknowledgements (here, the HC-Receiver Ack 60 record, not shown, has its ack_nonce flipped to 1). The HC-Receiver can also throw away stored information about HC-Receiver Ack 59 and any earlier acknowledgements.
调整尾部字节的运行长度，因为数据包3位于该字节的中间。由于R.ack_nonce为1，buf_nonce字段被翻转，后续确认的ack_nonce字段也被翻转（此处，未显示的HC接收器ack 60记录的ack_nonce被翻转为1）。HC接收器还可以丢弃关于HC接收器Ack 59和任何先前确认的存储信息。
A careful implementation might try to ensure reasonable robustness to reordering. Suppose that the Example Buffer is as before, but that packet 9 now arrives, out of sequence. The buffer would enter this state:
仔细的实现可能会尝试确保对重新排序具有合理的健壮性。假设示例缓冲区与以前一样，但数据包9现在到达，顺序不一致。缓冲区将进入以下状态：
+----*----------------------+
10 |0,0|0,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1]
+----*----------------------+
+----*----------------------+
10 |0,0|0,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1]
+----*----------------------+
The danger is that the HC-Sender might acknowledge the HC-Receiver's previous acknowledgement (with sequence number 60), which says that Packet 9 was not received, before the HC-Receiver has a chance to send a new acknowledgement saying that Packet 9 actually was received. Therefore, when packet 9 arrived, the HC-Receiver might modify its acknowledgement record as follows:
危险在于，HC发送方可能在HC接收方有机会发送新的确认之前确认HC接收方的先前确认（序列号为60），该确认表示没有接收到分组9。因此，当分组9到达时，HC接收机可以如下修改其确认记录：
1. ack_seqno = 59, ack_ackno = 3, ack_nonce = 1.
1. 确认序号=59，确认序号=3，确认时间=1。
2. ack_seqno = 60, ack_ackno = 3, ack_nonce = 1.
2. 确认序号=60，确认序号=3，确认时间=1。
That is, Ack 60 is now treated like a duplicate of Ack 59. This would prevent the Tail pointer from moving past packet 9 until the HC-Receiver knows that the HC-Sender has seen an Ack Vector indicating that packet's arrival.
也就是说，Ack 60现在被视为Ack 59的副本。这将防止尾部指针移动超过数据包9，直到HC接收器知道HC发送方已看到指示该数据包到达的Ack向量。
When the HC-Sender receives an acknowledgement, it generally cares about the number of packets that were dropped and/or ECN marked. It simply reads this off the Ack Vector. Additionally, it should check the ECN Nonce for correctness. (As described in Section 11.4.1, it may want to keep more detailed information about acknowledged packets in case packets change states between acknowledgements, or in case the application queries whether a packet arrived.)
当HC发送方收到确认时，它通常关心丢弃和/或ECN标记的数据包的数量。它只是从Ack向量中读取。此外，还应检查ECN Nonce的正确性。（如第11.4.1节所述，如果数据包在确认之间改变状态，或者应用程序询问数据包是否到达，则可能需要保留关于已确认数据包的更详细信息。）
The HC-Sender must also acknowledge the HC-Receiver's acknowledgements so that the HC-Receiver can free old Ack Vector state. (Since Ack Vector acknowledgements are reliable, the HC-Receiver must maintain and resend Ack Vector information until it is sure that the HC-Sender has received that information.) A simple algorithm suffices: since Ack Vector acknowledgements are cumulative, a single acknowledgement number tells HC-Receiver how much ack information has arrived. Assuming that the HC-Receiver sends no data, the HC-Sender can ensure that at least once a round-trip time, it sends a DCCP-DataAck packet acknowledging the latest DCCP-Ack packet it has received. Of course, the HC-Sender only needs to acknowledge the HC-Receiver's acknowledgements if the HC-Sender is also sending data. If the HC-Sender is not sending data, then the HC-Receiver's Ack Vector state is stable, and there is no need to shrink it. The HC-Sender must watch for drops and ECN marks on received DCCP-Ack packets so that it can adjust the HC-Receiver's ack-sending rate in response to congestion, for example, with Ack Ratio.
HC发送方还必须确认HC接收方的确认，以便HC接收方能够释放旧的Ack向量状态。（由于确认向量确认是可靠的，HC接收器必须保持并重新发送确认向量信息，直到确定HC发送方已收到该信息。）一个简单的算法就足够了：由于确认向量确认是累积的，单个确认号告诉HC接收器有多少确认信息已到达。假设HC接收器不发送数据，HC发送器可确保至少在往返时间发送一次DCCP DataAck数据包，确认其已接收的最新DCCP Ack数据包。当然，如果HC发送方也在发送数据，HC发送方只需要确认HC接收方的确认。如果HC发送方没有发送数据，则HC接收方的Ack向量状态是稳定的，不需要收缩它。HC发送方必须注意接收到的DCCP Ack数据包上的丢包和ECN标记，以便它可以调整HC接收方的Ack发送速率以响应拥塞，例如，使用Ack比率。
If the other half-connection is not quiescent -- that is, the HC-Receiver is sending data to the HC-Sender, possibly using another CCID -- then the acknowledgements on that half-connection are sufficient for the HC-Receiver to free its state.
如果另一半连接不是静态的——也就是说，HC接收方正在向HC发送方发送数据，可能使用另一个CCID——那么该一半连接上的确认就足以让HC接收方释放其状态。
B. Appendix: Partial Checksumming Design Motivation
附录：部分校验和设计动机
A great deal of discussion has taken place regarding the utility of allowing a DCCP sender to restrict the checksum so that it does not cover the complete packet. This section attempts to capture some of the rationale behind specific details of DCCP design.
关于允许DCCP发送方限制校验和以使其不覆盖整个数据包的实用性，已经进行了大量讨论。本节试图抓住DCCP设计具体细节背后的一些基本原理。
Many of the applications that we envisage using DCCP are resilient to some degree of data loss, or they would typically have chosen a reliable transport. Some of these applications may also be resilient to data corruption -- some audio payloads, for example. These resilient applications might rather receive corrupted data than have DCCP drop corrupted packets. This is particularly because of congestion control: DCCP cannot tell the difference between packets dropped due to corruption and packets dropped due to congestion, and so it must reduce the transmission rate accordingly. This response may cause the connection to receive less bandwidth than it is due; corruption in some networking technologies is independent of, or at least not always correlated to, congestion. Therefore, corrupted packets do not need to cause as strong a reduction in transmission rate as the congestion response would dictate (as long as the DCCP header and options are not corrupt).
我们设想使用DCCP的许多应用程序都具有一定程度的数据丢失恢复能力，或者它们通常会选择可靠的传输。这些应用程序中的一些可能还能够抵御数据损坏——例如，一些音频有效负载。这些弹性应用程序可能更愿意接收损坏的数据，而不是让DCCP丢弃损坏的数据包。这尤其是因为拥塞控制：DCCP无法区分由于损坏而丢弃的数据包和由于拥塞而丢弃的数据包之间的区别，因此它必须相应地降低传输速率。此响应可能会导致连接接收的带宽小于其应接收的带宽；某些网络技术中的腐败与拥塞无关，或者至少不总是与拥塞相关。因此，损坏的数据包不需要像拥塞响应所指示的那样导致传输速率的大幅降低（只要DCCP报头和选项没有损坏）。
Thus DCCP allows the checksum to cover all of the packet, just the DCCP header, or both the DCCP header and some number of bytes from the application data. If the application cannot tolerate any data corruption, then the checksum must cover the whole packet. If the application would prefer to tolerate some corruption rather than have the packet dropped, then it can set the checksum to cover only part of the packet (but always the DCCP header). In addition, if the application wishes to decouple checksumming of the DCCP header from checksumming of the application data, it may do so by including the Data Checksum option. This would allow DCCP to discard corrupted application data without mistaking the corruption for network congestion.
因此，DCCP允许校验和覆盖所有数据包，仅覆盖DCCP报头，或同时覆盖DCCP报头和应用程序数据中的某些字节数。如果应用程序不能容忍任何数据损坏，那么校验和必须覆盖整个数据包。如果应用程序希望容忍某些损坏而不是丢弃数据包，那么它可以将校验和设置为仅覆盖数据包的一部分（但始终覆盖DCCP报头）。此外，如果应用程序希望将DCCP报头的校验和与应用程序数据的校验和分离，则可以通过包括数据校验和选项来实现。这将允许DCCP丢弃损坏的应用程序数据，而不会将损坏误认为是网络拥塞。
Thus, from the application point of view, partial checksums seem to be a desirable feature. However, the usefulness of partial checksums depends on partially corrupted packets being delivered to the receiver. If the link-layer CRC always discards corrupted packets, then this will not happen, and so the usefulness of partial checksums would be restricted to corruption that occurred in routers and other places not covered by link CRCs. There does not appear to be consensus on how likely it is that future network links that suffer significant corruption will not cover the entire packet with a single strong CRC. DCCP makes it possible to tailor such links to the application, but it is difficult to predict if this will be compelling for future link technologies.
因此，从应用的角度来看，部分校验和似乎是一个理想的特性。然而，部分校验和的有用性取决于发送到接收器的部分损坏的数据包。如果链路层CRC总是丢弃损坏的数据包，则不会发生这种情况，因此部分校验和的用途将仅限于路由器和链路CRC未覆盖的其他地方发生的损坏。对于未来遭受严重损坏的网络链路不使用单一强CRC覆盖整个数据包的可能性，似乎没有达成共识。DCCP可以根据应用程序定制此类链接，但很难预测这对未来的链接技术是否具有吸引力。
In addition, partial checksums do not co-exist well with IP-level authentication mechanisms such as IPsec AH, which cover the entire packet with a cryptographic hash. Thus, if cryptographic authentication mechanisms are required to co-exist with partial checksums, the authentication must be carried in the application data. A possible mode of usage would appear to be similar to that of Secure RTP. However, such "application-level" authentication does not protect the DCCP option negotiation and state machine from forged packets. An alternative would be to use IPsec ESP, and to use encryption to protect the DCCP headers against attack, while using the DCCP header validity checks to authenticate that the header is from someone who possessed the correct key. While this is resistant to replay (due to the DCCP sequence number), it is not by itself resistant to some forms of man-in-the-middle attacks because the application data is not tightly coupled to the packet header. Thus, an application-level authentication probably needs to be coupled with IPsec ESP or a similar mechanism to provide a reasonably complete security solution. The overhead of such a solution might be unacceptable for some applications that would otherwise wish to use partial checksums.
此外，部分校验和与IP级身份验证机制（如IPsec AH）不能很好地共存，IPsec AH使用加密哈希覆盖整个数据包。因此，如果需要加密身份验证机制与部分校验和共存，则必须在应用程序数据中进行身份验证。一种可能的使用模式似乎类似于安全RTP。但是，这种“应用程序级”身份验证不能保护DCCP选项协商和状态机不受伪造数据包的影响。另一种方法是使用IPsec ESP，并使用加密来保护DCCP头免受攻击，同时使用DCCP头有效性检查来验证头是否来自拥有正确密钥的人。虽然这可以抵抗重播（由于DCCP序列号），但它本身不能抵抗某些形式的中间人攻击，因为应用程序数据没有紧密耦合到数据包报头。因此，应用程序级身份验证可能需要与IPsec ESP或类似机制结合，以提供合理完整的安全解决方案。对于某些希望使用部分校验和的应用程序来说，这种解决方案的开销可能是不可接受的。
On balance, the authors believe that DCCP partial checksums have the potential to enable some future uses that would otherwise be difficult. As the cost and complexity of supporting them is small, it seems worth including them at this time. It remains to be seen whether they are useful in practice.
总的来说，作者认为DCCP部分校验和有可能在未来实现一些难以实现的用途。由于支持它们的成本和复杂性都很小，因此目前似乎值得将它们包括在内。它们在实践中是否有用还有待观察。
Normative References
规范性引用文件
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309]Stone，J.，Stewart，R.，和D.Otis，“流控制传输协议（SCTP）校验和更改”，RFC 33092002年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，和G.Fairhurst，“轻量级用户数据报协议（UDP Lite）”，RFC 38282004年7月。
Informative References
资料性引用
[B98] Bellovin, S.M., "Cryptography and the Internet", CRYPTO '98 (LNCS 1462), pp 46-55, August 1988.
[B98]Bellovin，S.M.，“密码学与互联网”，CRYPTO'98（LNCS 1462），第46-55页，1988年8月。
[BB01] Bellovin, S.M. and M. Blaze, "Cryptographic Modes of Operation for the Internet", 2nd NIST Workshop on Modes of Operation, August 2001.
[BB01]Bellovin，S.M.和M.Blaze，“互联网的加密操作模式”，第二届NIST操作模式研讨会，2001年8月。
[M85] Morris, R.T., "A Weakness in the 4.2BSD Unix TCP/IP Software", Computer Science Technical Report 117, AT&T Bell Laboratories, Murray Hill, NJ, February 1985.
[M85]Morris，R.T.，“4.2BSD Unix TCP/IP软件的弱点”，计算机科学技术报告117，美国电话电报公司贝尔实验室，新泽西州默里山，1985年2月。
[PMTUD] Mathis, M. and J. Heffner, "Path MTU Discovery", Work in Progress, March 2006.
[PMTUD]Mathis，M.和J.Heffner，“路径MTU发现”，正在进行的工作，2006年3月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，1996年8月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[RFC2463]Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC2463，1998年12月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124]Balakrishnan，H.和S.Seshan，“拥堵管理者”，RFC31242001年6月。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]Floyd，S.，“不适当的TCP重置被认为是有害的”，BCP 60，RFC 3360，2002年8月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]Spring，N.，Weterral，D.，和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC 35402003年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]Karn，P.，Bormann，C.，Fairhurst，G.，Grossman，D.，路德维希，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341]Floyd，S.和E.Kohler，“数据报拥塞控制协议（DCCP）拥塞控制ID 2的配置文件：类似TCP的拥塞控制”，RFC 43412006年3月。
[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, March 2006.
[RFC4342]Floyd，S.，Kohler，E.，和J.Padhye，“数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）”，RFC 43422006年3月。
[SHHP00] Spatscheck, O., Hansen, J.S., Hartman, J.H., and L.L. Peterson, "Optimizing TCP Forwarder Performance", IEEE/ACM Transactions on Networking 8(2):146-157, April 2000.
[SHHP00]Spatscheck，O.，Hansen，J.S.，Hartman，J.H.，和L.L.Peterson，“优化TCP转发器性能”，IEEE/ACM网络事务8（2）：146-157，2000年4月。
[SYNCOOKIES] Bernstein, D.J., "SYN Cookies", http://cr.yp.to/syncookies.html, as of March 2006.
[SYNCOOKIES]Bernstein，D.J.，“SYN Cookies”，http://cr.yp.to/syncookies.html，截至2006年3月。
[VBK05] Vanit-Anunchai, S., Billington, J., and T. Kongprakaiwoot, "Discovering Chatter and Incompleteness in the Datagram Congestion Control Protocol", FORTE 2005, pp 143-158, October 2005.
[VBK05]Vanit Anunchai，S.，Billington，J.，和T.Kongprakaiwoot，“发现数据报拥塞控制协议中的抖动和不完整性”，FORTE 2005，第143-158页，2005年10月。
Authors' Addresses
作者地址
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
Eddie Kohler 4531C Boelter Hall加州大学洛杉矶分校计算机科学系美国加利福尼亚州洛杉矶90095
EMail: kohler@cs.ucla.edu
EMail: kohler@cs.ucla.edu
Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT UK
马克·汉德利英国伦敦高尔街大学学院计算机科学系伦敦WC1E 6BT
EMail: M.Handley@cs.ucl.ac.uk
EMail: M.Handley@cs.ucl.ac.uk
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
Sally Floyd ICSI互联网研究中心美国加利福尼亚州伯克利中心街1947号600室，邮编94704
EMail: floyd@icir.org
EMail: floyd@icir.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。