Internet Engineering Task Force (IETF) A. Bakker
Request for Comments: 7574 Vrije Universiteit Amsterdam
Category: Standards Track R. Petrocco
ISSN: 2070-1721 V. Grishchenko
Technische Universiteit Delft
July 2015
Internet Engineering Task Force (IETF) A. Bakker
Request for Comments: 7574 Vrije Universiteit Amsterdam
Category: Standards Track R. Petrocco
ISSN: 2070-1721 V. Grishchenko
Technische Universiteit Delft
July 2015
Peer-to-Peer Streaming Peer Protocol (PPSPP)
对等流媒体对等协议（PPSPP）
Abstract
摘要
The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both prerecorded (on-demand) and live audio/video content. It is based on the peer-to-peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth. It has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers. PPSPP has also been designed to be flexible and extensible. It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). It supports multiple methods for content integrity protection and chunk addressing. Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP using Low Extra Delay Background Transport (LEDBAT) for congestion control.
对等流媒体对等协议（PPSPP）是一种用于以流媒体方式向一组感兴趣方传播相同内容的协议。PPSP支持预录（按需）和实时音频/视频内容的流式传输。它基于点对点模式，即消费内容的客户端与最初提供内容的服务器处于同等地位，以创建一个每个人都可以提供上传带宽的系统。它的设计目的是为最终用户提供短时间播放，并防止恶意对等方中断流。PPSPP也被设计为灵活和可扩展的。它可以使用不同的机制来优化对等上载，防止搭便车，并使用不同的对等发现方案（集中式跟踪器或分布式哈希表）。它支持多种内容完整性保护和区块寻址方法。它被设计为一种通用协议，可以在各种传输协议之上运行，目前它在UDP之上运行，使用低额外延迟后台传输（LEDBAT）进行拥塞控制。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7574.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7574.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................5
1.1. Purpose ....................................................5
1.2. Requirements Language ......................................6
1.3. Terminology ................................................6
2. Overall Operation ...............................................9
2.1. Example: Joining a Swarm ...................................9
2.2. Example: Exchanging Chunks ................................10
2.3. Example: Leaving a Swarm ..................................10
3. Messages .......................................................11
3.1. HANDSHAKE .................................................11
3.1.1. Handshake Procedure ................................12
3.2. HAVE ......................................................14
3.3. DATA ......................................................15
3.4. ACK .......................................................15
3.5. INTEGRITY .................................................15
3.6. SIGNED_INTEGRITY ..........................................16
3.7. REQUEST ...................................................16
3.8. CANCEL ....................................................16
3.9. CHOKE and UNCHOKE .........................................17
3.10. Peer Address Exchange ....................................17
3.10.1. PEX_REQ and PEX_RES Messages ......................17
3.11. Channels .................................................19
3.12. Keep Alive Signaling .....................................20
4. Chunk Addressing Schemes .......................................21
4.1. Start-End Ranges ..........................................21
4.1.1. Chunk Ranges .......................................21
4.1.2. Byte Ranges ........................................21
4.2. Bin Numbers ...............................................22
4.3. In Messages ...............................................23
4.3.1. In HAVE Messages ...................................23
4.3.2. In ACK Messages ....................................24
1. Introduction ....................................................5
1.1. Purpose ....................................................5
1.2. Requirements Language ......................................6
1.3. Terminology ................................................6
2. Overall Operation ...............................................9
2.1. Example: Joining a Swarm ...................................9
2.2. Example: Exchanging Chunks ................................10
2.3. Example: Leaving a Swarm ..................................10
3. Messages .......................................................11
3.1. HANDSHAKE .................................................11
3.1.1. Handshake Procedure ................................12
3.2. HAVE ......................................................14
3.3. DATA ......................................................15
3.4. ACK .......................................................15
3.5. INTEGRITY .................................................15
3.6. SIGNED_INTEGRITY ..........................................16
3.7. REQUEST ...................................................16
3.8. CANCEL ....................................................16
3.9. CHOKE and UNCHOKE .........................................17
3.10. Peer Address Exchange ....................................17
3.10.1. PEX_REQ and PEX_RES Messages ......................17
3.11. Channels .................................................19
3.12. Keep Alive Signaling .....................................20
4. Chunk Addressing Schemes .......................................21
4.1. Start-End Ranges ..........................................21
4.1.1. Chunk Ranges .......................................21
4.1.2. Byte Ranges ........................................21
4.2. Bin Numbers ...............................................22
4.3. In Messages ...............................................23
4.3.1. In HAVE Messages ...................................23
4.3.2. In ACK Messages ....................................24
5. Content Integrity Protection ...................................24
5.1. Merkle Hash Tree Scheme ...................................25
5.2. Content Integrity Verification ............................26
5.3. The Atomic Datagram Principle .............................27
5.4. INTEGRITY Messages ........................................28
5.5. Discussion and Overhead ...................................28
5.6. Automatic Detection of Content Size .......................29
5.6.1. Peak Hashes ........................................29
5.6.2. Procedure ..........................................31
6. Live Streaming .................................................32
6.1. Content Authentication ....................................32
6.1.1. Sign All ...........................................33
6.1.2. Unified Merkle Tree ................................33
6.1.2.1. Signed Munro Hashes .......................34
6.1.2.2. Munro Signature Calculation ...............36
6.1.2.3. Procedure .................................37
6.1.2.4. Secure Tune In ............................37
6.2. Forgetting Chunks .........................................38
7. Protocol Options ...............................................38
7.1. End Option ................................................39
7.2. Version ...................................................39
7.3. Minimum Version ...........................................40
7.4. Swarm Identifier ..........................................40
7.5. Content Integrity Protection Method .......................41
7.6. Merkle Tree Hash Function .................................41
7.7. Live Signature Algorithm ..................................42
7.8. Chunk Addressing Method ...................................42
7.9. Live Discard Window .......................................43
7.10. Supported Messages .......................................44
7.11. Chunk Size ...............................................44
8. UDP Encapsulation ..............................................45
8.1. Chunk Size ................................................45
8.2. Datagrams and Messages ....................................46
8.3. Channels ..................................................47
8.4. HANDSHAKE .................................................47
8.5. HAVE ......................................................48
8.6. DATA ......................................................48
8.7. ACK .......................................................49
8.8. INTEGRITY .................................................50
8.9. SIGNED_INTEGRITY ..........................................51
8.10. REQUEST ..................................................52
8.11. CANCEL ...................................................52
8.12. CHOKE and UNCHOKE ........................................53
8.13. PEX_REQ, PEX_RESv4, PEX_RESv6, and PEX_REScert ...........53
8.14. KEEPALIVE ................................................55
8.15. Flow and Congestion Control ..............................56
8.16. Example of Operation .....................................57
9. Extensibility ..................................................61
5. Content Integrity Protection ...................................24
5.1. Merkle Hash Tree Scheme ...................................25
5.2. Content Integrity Verification ............................26
5.3. The Atomic Datagram Principle .............................27
5.4. INTEGRITY Messages ........................................28
5.5. Discussion and Overhead ...................................28
5.6. Automatic Detection of Content Size .......................29
5.6.1. Peak Hashes ........................................29
5.6.2. Procedure ..........................................31
6. Live Streaming .................................................32
6.1. Content Authentication ....................................32
6.1.1. Sign All ...........................................33
6.1.2. Unified Merkle Tree ................................33
6.1.2.1. Signed Munro Hashes .......................34
6.1.2.2. Munro Signature Calculation ...............36
6.1.2.3. Procedure .................................37
6.1.2.4. Secure Tune In ............................37
6.2. Forgetting Chunks .........................................38
7. Protocol Options ...............................................38
7.1. End Option ................................................39
7.2. Version ...................................................39
7.3. Minimum Version ...........................................40
7.4. Swarm Identifier ..........................................40
7.5. Content Integrity Protection Method .......................41
7.6. Merkle Tree Hash Function .................................41
7.7. Live Signature Algorithm ..................................42
7.8. Chunk Addressing Method ...................................42
7.9. Live Discard Window .......................................43
7.10. Supported Messages .......................................44
7.11. Chunk Size ...............................................44
8. UDP Encapsulation ..............................................45
8.1. Chunk Size ................................................45
8.2. Datagrams and Messages ....................................46
8.3. Channels ..................................................47
8.4. HANDSHAKE .................................................47
8.5. HAVE ......................................................48
8.6. DATA ......................................................48
8.7. ACK .......................................................49
8.8. INTEGRITY .................................................50
8.9. SIGNED_INTEGRITY ..........................................51
8.10. REQUEST ..................................................52
8.11. CANCEL ...................................................52
8.12. CHOKE and UNCHOKE ........................................53
8.13. PEX_REQ, PEX_RESv4, PEX_RESv6, and PEX_REScert ...........53
8.14. KEEPALIVE ................................................55
8.15. Flow and Congestion Control ..............................56
8.16. Example of Operation .....................................57
9. Extensibility ..................................................61
9.1. Chunk Picking Algorithms ..................................61
9.2. Reciprocity Algorithms ....................................62
10. IANA Considerations ...........................................62
10.1. PPSPP Message Type Registry ..............................62
10.2. PPSPP Option Registry ....................................62
10.3. PPSPP Version Number Registry ............................62
10.4. PPSPP Content Integrity Protection Method Registry .......62
10.5. PPSPP Merkle Hash Tree Function Registry .................63
10.6. PPSPP Chunk Addressing Method Registry ...................63
11. Manageability Considerations ..................................63
11.1. Operations ...............................................63
11.1.1. Installation and Initial Setup ....................63
11.1.2. Migration Path ....................................64
11.1.3. Requirements on Other Protocols and
Functional Components .............................64
11.1.4. Impact on Network Operation .......................64
11.1.5. Verifying Correct Operation .......................65
11.1.6. Configuration .....................................65
11.2. Management Considerations ................................66
11.2.1. Management Interoperability and Information .......67
11.2.2. Fault Management ..................................67
11.2.3. Configuration Management ..........................67
11.2.4. Accounting Management .............................68
11.2.5. Performance Management ............................68
11.2.6. Security Management ...............................68
12. Security Considerations .......................................68
12.1. Security of the Handshake Procedure ......................68
12.1.1. Protection against Attack 1 .......................69
12.1.2. Protection against Attack 2 .......................70
12.1.3. Protection against Attack 3 .......................70
12.2. Secure Peer Address Exchange .............................71
12.2.1. Protection against the Amplification Attack .......71
12.2.2. Example: Tracker as Certification Authority .......72
12.2.3. Protection against Eclipse Attacks ................73
12.3. Support for Closed Swarms ................................73
12.4. Confidentiality of Streamed Content ......................74
12.5. Strength of the Hash Function for Merkle Hash Trees ......74
12.6. Limit Potential Damage and Resource Exhaustion by
Bad or Broken Peers ......................................74
12.6.1. HANDSHAKE .........................................75
12.6.2. HAVE ..............................................75
12.6.3. DATA ..............................................75
12.6.4. ACK ...............................................75
12.6.5. INTEGRITY and SIGNED_INTEGRITY ....................76
12.6.6. REQUEST ...........................................76
12.6.7. CANCEL ............................................76
12.6.8. CHOKE .............................................77
12.6.9. UNCHOKE ...........................................77
9.1. Chunk Picking Algorithms ..................................61
9.2. Reciprocity Algorithms ....................................62
10. IANA Considerations ...........................................62
10.1. PPSPP Message Type Registry ..............................62
10.2. PPSPP Option Registry ....................................62
10.3. PPSPP Version Number Registry ............................62
10.4. PPSPP Content Integrity Protection Method Registry .......62
10.5. PPSPP Merkle Hash Tree Function Registry .................63
10.6. PPSPP Chunk Addressing Method Registry ...................63
11. Manageability Considerations ..................................63
11.1. Operations ...............................................63
11.1.1. Installation and Initial Setup ....................63
11.1.2. Migration Path ....................................64
11.1.3. Requirements on Other Protocols and
Functional Components .............................64
11.1.4. Impact on Network Operation .......................64
11.1.5. Verifying Correct Operation .......................65
11.1.6. Configuration .....................................65
11.2. Management Considerations ................................66
11.2.1. Management Interoperability and Information .......67
11.2.2. Fault Management ..................................67
11.2.3. Configuration Management ..........................67
11.2.4. Accounting Management .............................68
11.2.5. Performance Management ............................68
11.2.6. Security Management ...............................68
12. Security Considerations .......................................68
12.1. Security of the Handshake Procedure ......................68
12.1.1. Protection against Attack 1 .......................69
12.1.2. Protection against Attack 2 .......................70
12.1.3. Protection against Attack 3 .......................70
12.2. Secure Peer Address Exchange .............................71
12.2.1. Protection against the Amplification Attack .......71
12.2.2. Example: Tracker as Certification Authority .......72
12.2.3. Protection against Eclipse Attacks ................73
12.3. Support for Closed Swarms ................................73
12.4. Confidentiality of Streamed Content ......................74
12.5. Strength of the Hash Function for Merkle Hash Trees ......74
12.6. Limit Potential Damage and Resource Exhaustion by
Bad or Broken Peers ......................................74
12.6.1. HANDSHAKE .........................................75
12.6.2. HAVE ..............................................75
12.6.3. DATA ..............................................75
12.6.4. ACK ...............................................75
12.6.5. INTEGRITY and SIGNED_INTEGRITY ....................76
12.6.6. REQUEST ...........................................76
12.6.7. CANCEL ............................................76
12.6.8. CHOKE .............................................77
12.6.9. UNCHOKE ...........................................77
12.6.10. PEX_RES ..........................................77
12.6.11. Unsolicited Messages in General ..................77
12.7. Exclude Bad or Broken Peers ..............................77
13. References ....................................................78
13.1. Normative References .....................................78
13.2. Informative References ...................................79
Acknowledgements ..................................................84
Authors' Addresses ................................................85
12.6.10. PEX_RES ..........................................77
12.6.11. Unsolicited Messages in General ..................77
12.7. Exclude Bad or Broken Peers ..............................77
13. References ....................................................78
13.1. Normative References .....................................78
13.2. Informative References ...................................79
Acknowledgements ..................................................84
Authors' Addresses ................................................85
This document describes the Peer-to-Peer Streaming Peer Protocol (PPSPP), designed for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both prerecorded (on-demand) and live audio/video content. It is based on the peer-to-peer paradigm where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth.
本文档描述了点对点流媒体对等协议（PPSPP），该协议旨在以流媒体方式将相同内容传播给一组相关方。PPSP支持预录（按需）和实时音频/视频内容的流式传输。它基于点对点模式，即消费内容的客户端与最初提供内容的服务器处于同等地位，以创建一个每个人都可以提供上传带宽的系统。
PPSPP has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers. Central in this design is a simple method of identifying content based on self-certification. In particular, content in PPSPP is identified by a single cryptographic hash that is the root hash in a Merkle hash tree calculated recursively from the content [MERKLE] [ABMRKL]. This self-certifying hash tree allows every peer to directly detect when a malicious peer tries to distribute fake content. The tree can be used for both static and live content. Moreover, it ensures only a small amount of information is needed to start a download and to verify incoming chunks of content, thus ensuring short start-up times.
PPSPP旨在为最终用户提供短时间播放，并防止恶意对等方中断流。该设计的核心是一种基于自我认证识别内容的简单方法。具体而言，PPSPP中的内容由单个加密散列标识，该散列是根据内容[Merkle][ABMRKL]递归计算的Merkle散列树中的根散列。这种自认证哈希树允许每个对等方在恶意对等方试图分发虚假内容时直接检测。该树可用于静态和实时内容。此外，它可以确保启动下载和验证传入的内容块只需要少量信息，从而确保启动时间短。
PPSPP has also been designed to be extensible for different transports and use cases. Hence, PPSPP is a generic protocol that can run directly on top of UDP, TCP, or other protocols. As such, PPSPP defines a common set of messages that make up the protocol, which can have different representations on the wire depending on the lower-level protocol used. When the lower-level transport allows, PPSPP can also use different congestion control algorithms.
PPSPP还被设计为可扩展的，用于不同的传输和用例。因此，PPSP是一种通用协议，可以直接在UDP、TCP或其他协议之上运行。因此，PPSPP定义了组成协议的一组公共消息，根据所使用的较低级别协议，这些消息在线路上可以有不同的表示形式。当较低级别的传输允许时，PPSPP还可以使用不同的拥塞控制算法。
At present, PPSPP is set to run on top of UDP using LEDBAT for congestion control [RFC6817]. Using LEDBAT enables PPSPP to serve the content after playback (seeding) without disrupting the user who may have moved to different tasks that use its network connection.
目前，PPSPP设置为在UDP之上运行，使用LEDBAT进行拥塞控制[RFC6817]。使用LEDBAT可使PPSPP在播放（种子设定）后提供内容，而不会中断可能已转移到使用其网络连接的不同任务的用户。
PPSPP is also flexible and extensible in the mechanisms it uses to promote client contribution and prevent freeriding, that is, how to deal with peers that only download content but never upload to others. It also allows different schemes for chunk addressing and content integrity protection, if the defaults are not fit for a particular use case. In addition, it can work with different peer discovery schemes, such as centralized trackers or fast Distributed Hash Tables [JIM11]. Finally, in this default setup, PPSPP maintains only a small amount of state per peer. A reference implementation of PPSPP over UDP is available [SWIFTIMPL].
PPSPP还具有灵活性和可扩展性，其机制用于促进客户贡献和防止搭便车，即如何处理只下载内容而从不上传给他人的对等方。如果默认设置不适合特定的用例，它还允许使用不同的方案来进行区块寻址和内容完整性保护。此外，它还可以使用不同的对等发现方案，如集中式跟踪器或快速分布式哈希表[JIM11]。最后，在这个默认设置中，PPSPP只维护每个对等点的少量状态。在UDP上提供PPSPP的参考实现[SWIFTIMPL]。
The protocol defined in this document assumes that a peer has already discovered a list of (initial) peers using, for example, a centralized tracker [PPSP-TP]. Once a peer has this list of peers, PPSPP allows the peer to connect to other peers, request chunks of content, and discover other peers disseminating the same content.
本文档中定义的协议假设对等方已经使用（例如）集中式跟踪器[PPSP-TP]发现（初始）对等方列表。一旦一个对等方拥有该对等方列表，PPSP允许该对等方连接到其他对等方，请求内容块，并发现传播相同内容的其他对等方。
The design of PPSPP is based on our research into making BitTorrent [BITTORRENT] suitable for streaming content [P2PWIKI]. Most PPSPP messages have corresponding BitTorrent messages and vice versa. However, PPSPP is specifically targeted towards streaming audio/video content and optimizes time-till-playback. It was also designed to be more flexible and extensible.
PPSPP的设计基于我们对使BitTorrent[BitTorrent]适合流媒体内容[P2PWIKI]的研究。大多数PPSP消息都有相应的BitTorrent消息，反之亦然。但是，PPSPP专门针对流式音频/视频内容，并优化播放时间。它的设计也更加灵活和可扩展。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
message The basic unit of PPSPP communication. A message will have different representations on the wire depending on the transport protocol used. Messages are typically multiplexed into a datagram for transmission.
消息是PPSP通信的基本单元。根据所使用的传输协议，消息在线路上具有不同的表示形式。消息通常被多路复用成数据报进行传输。
datagram A sequence of messages that is offered as a unit to the underlying transport protocol (UDP, etc.). The datagram is PPSPP's Protocol Data Unit (PDU).
数据报作为一个单元提供给底层传输协议（UDP等）的一系列消息。数据报是PPSP的协议数据单元（PDU）。
content Either a live transmission or a prerecorded multimedia file.
内容可以是实时传输，也可以是预先录制的多媒体文件。
chunk The basic unit in which the content is divided. For example, a block of N kilobytes. A chunk may be of variable size.
分块：划分内容的基本单位。例如，一个N KB的块。块的大小可能不同。
chunk ID Unique identifier for a chunk of content (e.g., an integer). Its type depends on the chunk addressing scheme used.
区块ID内容区块的唯一标识符（例如，整数）。其类型取决于所使用的块寻址方案。
chunk specification An expression that denotes one or more chunk IDs.
区块规范表示一个或多个区块ID的表达式。
chunk addressing scheme Scheme for identifying chunks and expressing the chunk availability map of a peer in a compact fashion.
块寻址方案用于识别块并以紧凑的方式表示对等方的块可用性映射的方案。
chunk availability map The set of chunks a peer has successfully downloaded and checked the integrity of.
区块可用性映射对等方已成功下载并检查其完整性的区块集。
bin A number denoting a specific binary interval of the content (i.e., one or more consecutive chunks) in the bin numbers chunk addressing scheme (see Section 4).
bin一个数字，表示在bin数字区块寻址方案中内容的特定二进制间隔（即一个或多个连续区块）（参见第4节）。
content integrity protection scheme Scheme for protecting the integrity of the content while it is being distributed via the peer-to-peer network. That is, methods for receiving peers to detect whether a requested chunk has been modified, either maliciously by the sending peer or accidentally in transit.
内容完整性保护方案用于在通过对等网络分发内容时保护内容完整性的方案。也就是说，用于接收对等方的方法，用于检测请求的区块是否已被修改，或者是被发送对等方恶意修改，或者是在传输过程中意外修改。
hash The result of applying a cryptographic hash function, more specifically a Modification Detection Code (MDC) [HAC01], such as SHA-256 [FIPS180-4], to a piece of data.
散列将加密散列函数，更具体地说，修改检测码（MDC）[HAC01]，如SHA-256[FIPS180-4]应用于数据段的结果。
Merkle hash tree A tree of hashes whose base is formed by the hashes of the chunks of content, and its higher nodes are calculated by recursively computing the hash of the concatenation of the two child hashes (see Section 5.1).
Merkle散列树一种散列树，其基由内容块的散列组成，其较高节点通过递归计算两个子散列串联的散列来计算（见第5.1节）。
root hash The root in a Merkle hash tree calculated recursively from the content (see Section 5.1).
根哈希从内容递归计算的Merkle哈希树中的根（参见第5.1节）。
munro hash The hash of a subtree that is the unit of signing in the Unified Merkle Tree content authentication scheme for live streaming (see Section 6.1.2.1).
munro散列-子树的散列，该子树是直播的统一Merkle树内容认证方案中的签名单元（见第6.1.2.1节）。
swarm A group of peers participating in the distribution of the same content.
群集一组参与相同内容分发的对等方。
swarm ID Unique identifier for a swarm of peers, in PPSPP a sequence of bytes. For video on demand with content integrity protection enabled, the identifier is the so-called root hash of a Merkle hash tree over the content. For live streaming, the swarm ID is a public key.
swarm ID对等群的唯一标识符，以字节序列表示。对于启用内容完整性保护的视频点播，标识符是内容上Merkle哈希树的所谓根哈希。对于直播，swarm ID是一个公钥。
tracker An entity that records the addresses of peers participating in a swarm, usually for a set of swarms, and makes this membership information available to other peers on request.
跟踪器一种实体，它记录参与群的对等方的地址，通常用于一组群，并根据请求将此成员信息提供给其他对等方。
choking When Peer A is choking Peer B, it means that A is currently not willing to accept requests for content from B.
阻塞当对等方A阻塞对等方B时，意味着A当前不愿意接受来自B的内容请求。
seeding Peer A is said to be seeding when A has downloaded a static content file completely and is now offering it for others to download.
当A完全下载了一个静态内容文件，并且现在提供给其他人下载时，种子设定对等方A被称为种子设定。
leeching Peer A is said to be leeching when A has not completely downloaded a static content file yet or is not offering to upload it to others.
当A还没有完全下载一个静态内容文件，或者没有提供将其上传给其他人时，leeching Peer A被认为是在偷窥。
channel A logical connection between two peers. The channel concept allows peers to use the same transport address for communicating with different peers.
通道两个对等方之间的逻辑连接。信道概念允许对等方使用相同的传输地址与不同的对等方通信。
channel ID Unique, randomly chosen identifier for a channel, local to each peer. So the two peers logically connected by a channel each have a different channel ID for that channel.
通道ID为通道随机选择的唯一标识符，位于每个对等方的本地。因此，由一个通道逻辑连接的两个对等方各自具有该通道的不同通道ID。
heavy payload A datagram has a heavy payload when it contains DATA messages, SIGNED_INTEGRITY messages, or a large number of smaller messages.
重负载当数据报包含数据消息、签名完整性消息或大量较小消息时，数据报具有重负载。
In this document the prefixes kilo-, mega-, etc., denote base 1024.
在本文档中，前缀kilo-、mega-等表示基数1024。
The basic unit of communication in PPSPP is the message. Multiple messages are multiplexed into a single datagram for transmission. A datagram (and hence the messages it contains) will have different representations on the wire depending on the transport protocol used (see Section 8).
PPSP中的基本通信单元是消息。多个消息被多路复用成一个数据报进行传输。根据所使用的传输协议，数据报（及其包含的消息）在线路上具有不同的表示形式（见第8节）。
The overall operation of PPSPP is illustrated in the following examples. The examples assume that the content distributed is static, UDP is used for transport, the Merkle Hash Tree scheme is used for content integrity protection, and that a specific policy is used for selecting which chunks to download.
PPSPP的整体操作如以下示例所示。这些示例假设分发的内容是静态的，UDP用于传输，Merkle哈希树方案用于内容完整性保护，并且使用特定策略选择要下载的块。
Consider a user who wants to watch a video. To play the video, the user clicks on the play button of a HTML5 <video> element shown in his PPSPP-enabled browser. Imagine this element has a PPSPP URL (to be defined elsewhere) identifying the video as its source. The browser passes this URL to its peer-to-peer streaming protocol handler. Let's call this protocol handler Peer A. Peer A parses the URL to retrieve the transport address of a peer-to-peer streaming protocol tracker and swarm metadata of the content. The tracker address may be optional in the presence of a decentralized tracking mechanism. The mechanisms for tracking peers are outside of the scope of this document.
考虑一个想看视频的用户。要播放视频，用户单击其支持PPSP的浏览器中显示的HTML5<video>元素的播放按钮。假设此元素有一个PPSPURL（在别处定义），将视频标识为其源。浏览器将此URL传递给其对等流协议处理程序。让我们将此协议处理程序称为Peer A。Peer A解析URL以检索对等流协议跟踪器的传输地址和内容的swarm元数据。在存在分散跟踪机制的情况下，跟踪器地址可能是可选的。跟踪对等点的机制不在本文档的范围内。
Peer A now registers with the tracker following the peer-to-peer streaming protocol tracker specification [PPSP-TP] and receives the IP address and port of peers already in the swarm, say, Peers B, C, and D. At this point, the PPSPP starts operating. Peer A now sends a datagram containing a PPSPP HANDSHAKE message to Peers B, C, and D. This message conveys protocol options. In particular, Peer A includes the ID of the swarm (part of the swarm metadata) as a protocol option because the destination peers can listen for multiple swarms on the same transport address.
对等点A现在按照对等流协议跟踪器规范[PPSP-TP]向跟踪器注册，并接收群中已经存在的对等点（例如对等点B、C和D）的IP地址和端口。此时，PPSP开始运行。对等方A现在向对等方B、C和D发送包含PPSP握手消息的数据报。该消息传递协议选项。特别是，对等方A将群的ID（群元数据的一部分）作为协议选项，因为目标对等方可以侦听同一传输地址上的多个群。
Peers B and C respond with datagrams containing a PPSPP HANDSHAKE message and one or more HAVE messages. A HAVE message conveys (part of) the chunk availability of a peer; thus, it contains a chunk specification that denotes what chunks of the content Peers B and C have, respectively. Peer D sends a datagram with a HANDSHAKE and HAVE messages, but also with a CHOKE message. The latter indicates that Peer D is not willing to upload chunks to Peer A at present.
对等点B和C使用包含PPSP握手消息和一个或多个HAVE消息的数据报进行响应。HAVE消息传递对等方的块可用性（部分）；因此，它包含一个块规范，该规范分别表示对等方B和C的内容块。对等点D通过握手发送数据报，并有消息，但也有阻塞消息。后者表示对等方D目前不愿意将块上传到对等方A。
In response to Peers B and C, Peer A sends new datagrams to Peers B and C containing REQUEST messages. A REQUEST message indicates the chunks that a peer wants to download; thus, it contains a chunk specification. The REQUEST messages to Peers B and C refer to disjoint sets of chunks. Peers B and C respond with datagrams containing HAVE, DATA, and, in this example, INTEGRITY messages. In the Merkle hash tree content protection scheme (see Section 5.1), the INTEGRITY messages contain all cryptographic hashes that Peer A needs to verify the integrity of the content chunk sent in the DATA message. Using these hashes, Peer A verifies that the chunks received from Peers B and C are correct against the trusted swarm ID. Peer A also updates the chunk availability of Peers B and C using the information in the received HAVE messages. In addition, it passes the chunks of video to the user's browser for rendering.
作为对对等点B和C的响应，对等点A向对等点B和C发送包含请求消息的新数据报。请求消息指示对等方想要下载的块；因此，它包含一个块规范。对对等方B和C的请求消息指的是不相交的块集。对等点B和C使用包含HAVE、DATA和完整性消息（在本例中）的数据报进行响应。在Merkle哈希树内容保护方案中（参见第5.1节），完整性消息包含对等方A验证数据消息中发送的内容块完整性所需的所有加密哈希。使用这些散列，对等方A验证从对等方B和C接收的区块是否与受信任的swarm ID相符。对等方A还使用接收到的HAVE消息中的信息更新对等方B和C的区块可用性。此外，它将视频块传递到用户的浏览器进行渲染。
After processing, Peer A sends a datagram containing HAVE messages for the chunks it just received to all its peers. In the datagram to Peers B and C, it includes an ACK message acknowledging the receipt of the chunks and adds REQUEST messages for new chunks. ACK messages are not used when a reliable transport protocol is used. When, for example, Peer C finds that Peer A obtained a chunk (from Peer B) that Peer C did not yet have, Peer C's next datagram includes a REQUEST for that chunk.
经过处理后，对等方A向其所有对等方发送一个数据报，其中包含它刚刚收到的数据块的HAVE消息。在发送给对等方B和C的数据报中，它包括确认接收到块的ACK消息，并添加新块的请求消息。使用可靠传输协议时不使用ACK消息。例如，当对等方C发现对等方A（从对等方B）获得了对等方C尚未拥有的区块时，对等方C的下一个数据报包括对该区块的请求。
Peer D also sends HAVE messages to Peer A when it downloads chunks from other peers. When Peer D is willing to accept REQUESTs from Peer A, Peer D sends a datagram with an UNCHOKE message to inform Peer A. If Peer B or C decides to choke Peer A, they send a CHOKE message and Peer A should then re-request from other peers. Peers B and C may continue to send HAVE, REQUEST, or periodic keep-alive messages such that Peer A keeps sending them HAVE messages.
当对等方D从其他对等方下载块时，它还会向对等方A发送HAVE消息。当对等方D愿意接受来自对等方A的请求时，对等方D发送一个带有未锁定消息的数据报，以通知对等方A。如果对等方B或C决定阻塞对等方A，他们将发送阻塞消息，对等方A随后应重新请求其他对等方。对等方B和C可以继续发送HAVE、REQUEST或定期保持活动的消息，以便对等方A继续发送HAVE消息。
Once Peer A has received all content (video-on-demand use case), it stops sending messages to all other peers that have all content (a.k.a. seeders). Peer A can also contact the tracker or another source again to obtain more peer addresses.
一旦对等方A接收到所有内容（视频点播用例），它将停止向拥有所有内容的所有其他对等方发送消息（也称为播种机）。对等方A还可以再次联系跟踪器或其他来源以获取更多对等方地址。
To leave a swarm in a graceful way, Peer A sends a specific HANDSHAKE message to all its peers (see Section 8.4) and deregisters from the tracker following the tracker specification [PPSP-TP]. Peers receiving the datagram should remove Peer A from their current peer list. If Peer A crashes ungracefully, peers should remove Peer A from their peer list when they detect it no longer sends messages (see Section 3.12).
为了以优雅的方式离开蜂群，对等方a向其所有对等方发送特定的握手消息（见第8.4节），并根据跟踪器规范[PPSP-TP]从跟踪器注销。接收数据报的对等方应从其当前对等方列表中删除对等方A。如果对等机A意外崩溃，对等机应在检测到对等机A不再发送消息时将其从对等机列表中删除（见第3.12节）。
No error codes or responses are used in the protocol; absence of any response indicates an error. Invalid messages are discarded, and further communication with the peer SHOULD be stopped. The rationale is that it is sufficient to classify peers as either good or bad and only use the good ones. A good peer is a peer that responds with chunks; a peer that does not respond, or does not respond in time is classified as bad. The idea is that, in PPSPP, the content is available from multiple sources (unlike HTTP), so a peer should not invest too much effort in trying to obtain it from a particular source. This classification in good or bad allows a peer to deal with slow, crashed, and (silent) malicious peers.
协议中未使用错误代码或响应；没有任何响应表明存在错误。将丢弃无效消息，并应停止与对等方的进一步通信。其基本原理是，将对等点分为好的或坏的，只使用好的就足够了。一个好的同伴是一个用语块回应的同伴；未响应或未及时响应的对等方被归类为坏。其想法是，在PPSPP中，内容可以从多个来源获得（与HTTP不同），因此对等方不应该投入太多精力试图从特定来源获得内容。这种良好或不好的分类允许对等机处理缓慢、崩溃和（静默的）恶意对等机。
Multiple messages MUST be multiplexed into a single datagram for transmission. Messages in a single datagram MUST be processed in the strict order in which they appear in the datagram. If an invalid message is found in a datagram, the remaining messages MUST be discarded.
必须将多条消息多路复用到单个数据报中进行传输。单个数据报中的消息必须按照它们在数据报中出现的严格顺序进行处理。如果在数据报中发现无效消息，则必须丢弃其余消息。
For the sake of simplicity, one swarm of peers deals with one content file or stream only. There is a single division of the content into chunks that all peers in the swarm adhere to, determined by the content publisher. Distribution of a collection of files can be done either by using multiple swarms or by using an external storage mapping from the linear byte space of a single swarm to different files, transparent to the protocol. In other words, the audio/video container format used is outside the scope of this document.
为了简单起见，一组对等方只处理一个内容文件或流。由内容发布者决定，将内容划分为群中所有对等方都遵守的块。文件集合的分发可以通过使用多个群集来完成，也可以通过使用外部存储映射来完成，从单个群集的线性字节空间映射到不同的文件，这对协议是透明的。换句话说，所使用的音频/视频容器格式不在本文档范围内。
For Peer P to establish communication with Peer Q in Swarm S, the peers must first exchange HANDSHAKE messages by means of a handshake procedure. The initiating Peer P needs to know the metadata of Swarm S, which consists of:
为了使对等方P与Swarm S中的对等方Q建立通信，对等方必须首先通过握手过程交换握手消息。发起方P需要知道Swarm S的元数据，包括：
(a) the swarm ID of the content (see Sections 5.1 and 6),
(a) 内容的群集ID（见第5.1节和第6节），
(b) the chunk size used,
(b) 使用的块大小，
(c) the chunk addressing method used,
(c) 使用的块寻址方法，
(d) the content integrity protection method used, and
(d) 使用的内容完整性保护方法，以及
(e) the Merkle hash tree function used (if applicable).
(e) 使用的Merkle哈希树函数（如果适用）。
(f) If automatic content size detection (see Section 5.6) is not used, the content length is also part of the metadata (for static content.)
(f) 如果未使用自动内容大小检测（参见第5.6节），则内容长度也是元数据的一部分（对于静态内容）
This document assumes the swarm metadata is obtained from a trusted source. In addition, Peer P needs to know a transport address for Peer Q, obtained from a peer discovery/tracking protocol.
本文档假设swarm元数据是从可信来源获得的。此外，Peer P需要知道Peer Q的传输地址，该地址是从Peer发现/跟踪协议获得的。
The payload of the HANDSHAKE message contains a sequence of protocol options. The protocol options encode the swarm metadata just described to enable an end-to-end check to see whether the peers are in the right swarm. Additionally, the options encode a number of per-peer configuration parameters. The complete set of protocol options are specified in Section 7. The HANDSHAKE message also contains a channel ID for multiplexing communication and security (see Sections 3.11 and 12.1). A HANDSHAKE message MUST always be the first message in a datagram.
握手消息的有效负载包含一系列协议选项。协议选项对刚才描述的swarm元数据进行编码，以支持端到端检查，查看对等方是否在正确的swarm中。此外，这些选项对每个对等配置参数进行编码。第7节规定了整套协议选项。握手信息还包含用于多路通信和安全的信道ID（见第3.11节和第12.1节）。握手消息必须始终是数据报中的第一条消息。
The handshake procedure for a peer, Peer P, to start communication with another peer, Peer Q, in Swarm S is now as follows.
在Swarm S中，对等点P开始与另一对等点Q通信的握手过程如下。
1. The first datagram the initiating Peer P sends to Peer Q MUST start with a HANDSHAKE message. This HANDSHAKE message MUST contain:
1. 发起对等方P发送给对等方Q的第一个数据报必须以握手消息开始。此握手消息必须包含：
* A channel ID, chanP, randomly chosen as specified in Section 12.1.
* 根据第12.1节的规定，随机选择信道ID chanP。
* The metadata of Swarm S, encoded as protocol options, as specified in Section 7. In particular, the initiating Peer P MUST include the swarm ID.
* Swarm S的元数据，编码为协议选项，如第7节所述。特别是，发起对等点P必须包括群ID。
* The capabilities of Peer P, in particular, its supported protocol versions, "Live Discard Window" (in case of a live swarm) and "Supported Messages", encoded as protocol options.
* Peer P的功能，尤其是其支持的协议版本，“实时丢弃窗口”（如果是实时群集）和“支持的消息”，编码为协议选项。
This first datagram MUST be prefixed with the (destination) channel ID 0; see Section 3.11. Hence, the datagram contains two channel IDs: the destination channel ID prefixed to the datagram and the channel ID chanP included in the HANDSHAKE message inside the datagram. This datagram MAY also contain some minor additional payload, e.g., HAVE messages to indicate Peer P's current progress, but it MUST NOT include any heavy payload (defined in Section 1.3), such as a DATA message. Allowing minor
第一个数据报必须以（目的地）通道ID 0作为前缀；见第3.11节。因此，数据报包含两个信道ID：作为数据报前缀的目标信道ID和数据报内握手消息中包含的信道ID chanP。该数据报还可能包含一些次要的额外有效载荷，例如，具有指示对等方P当前进度的消息，但不得包括任何重有效载荷（在第1.3节中定义），例如数据消息。允许未成年人
payload minimizes the number of initialization round trips, thus improving time-till-playback. Forbidding heavy payload prevents an amplification attack (see Section 12.1).
有效负载将初始化往返次数降至最低，从而缩短播放时间。禁止重型有效载荷可防止放大攻击（见第12.1节）。
2. The receiving Peer Q checks the HANDSHAKE message from Peer P. If any check by Peer Q fails, or if Peers P and Q are not in the same swarm, Peer Q MUST NOT send a HANDSHAKE (or any other) message back, as the message from Peer P may have been spoofed (see Section 12.1). Otherwise, if Peer Q is interested in communicating with Peer P, Peer Q MUST send a datagram to Peer P that starts with a HANDSHAKE message. This reply HANDSHAKE MUST contain:
2. 接收的对等方Q检查来自对等方P的握手消息。如果对等方Q的任何检查失败，或者对等方P和Q不在同一群中，对等方Q不得发回握手（或任何其他）消息，因为来自对等方P的消息可能被欺骗（见第12.1节）。否则，如果Peer Q对与Peer P通信感兴趣，那么Peer Q必须向Peer P发送以握手消息开始的数据报。此应答握手必须包含：
* A channel ID, chanQ, randomly chosen as specified in Section 12.1.
* 按照第12.1节的规定随机选择信道ID chanQ。
* The metadata of Swarm S, encoded as protocol options, as specified in Section 7. In particular, the responding Peer Q MAY include the swarm ID.
* Swarm S的元数据，编码为协议选项，如第7节所述。具体地，响应的对等方Q可以包括群ID。
* The capabilities of Peer Q, in particular, its supported protocol versions, its "Live Discard Window" (in case of a live swarm) and "Supported Messages", encoded as protocol options.
* Peer Q的功能，特别是其支持的协议版本、其“实时丢弃窗口”（如果是Live swarm）和“支持的消息”，编码为协议选项。
This reply datagram MUST be prefixed with the channel ID chanP sent by Peer P in the first HANDSHAKE message (see Section 3.11). This reply datagram MAY also contain some minor additional payload, e.g., HAVE messages to indicate Peer Q's current progress, or REQUEST messages (see Section 3.7), but it MUST NOT include any heavy payload.
此应答数据报必须以对等方P在第一次握手消息中发送的信道ID chanP作为前缀（见第3.11节）。该应答数据报还可能包含一些次要的额外负载，例如，具有指示对等Q当前进度的消息，或请求消息（参见第3.7节），但它不得包括任何重负载。
3. The initiating Peer P checks the reply datagram from Peer Q. If the reply datagram is not prefixed with (destination) channel ID chanP, Peer P MUST discard the datagram. Peer P SHOULD continue to process datagrams from Peer Q that do meet this requirement. This check prevents interference by spoofing, see Section 12.1. If Peer P's channel ID is echoed correctly, the initiator Peer P knows that the addressed Peer Q really responds.
3. 发起的对等方P检查来自对等方Q的应答数据报。如果应答数据报没有前缀（目的地）信道ID chanP，对等方P必须丢弃该数据报。对等点P应继续处理来自对等点Q的数据报，这些数据报确实满足此要求。该检查通过欺骗防止干扰，见第12.1节。如果对等方P的信道ID被正确地回显，则发起方对等方P知道寻址的对等方Q确实响应。
4. Next, Peer P checks the HANDSHAKE message in the datagram from Peer Q. If any check by Peer P fails, or Peer P is no longer interested in communicating with Peer Q, Peer P MAY send a HANDSHAKE message to inform Peer Q it will cease communication. This closing HANDSHAKE message MUST contain an all zeros channel ID and a list of protocol options. The list MUST either be empty or contain the maximum version number Peer P supports, following the min/max versioning scheme defined in [RFC6709], Section 4.1.
4. 接下来，Peer P检查来自Peer Q的数据报中的握手消息。如果Peer P的任何检查失败，或者Peer P不再对与Peer Q通信感兴趣，Peer P可以发送握手消息来通知Peer Q它将停止通信。此结束握手消息必须包含全零通道ID和协议选项列表。根据[RFC6709]第4.1节中定义的最小/最大版本控制方案，列表必须为空或包含对等支持的最大版本号。
The datagram containing this closing HANDSHAKE message MUST be prefixed with the (destination) channel ID chanQ. Peer P MAY also simply cease communication.
包含此结束握手消息的数据报必须以（目标）通道ID chanQ作为前缀。对等点P也可以简单地停止通信。
5. If the addressed peer, Peer Q, does not respond to initiating Peer P's first datagram, Peer P MAY resend that datagram until Peer Q is considered dead, according to the rules specified in Section 3.12.
5. 根据第3.12节规定的规则，如果寻址的对等方（对等方Q）没有响应发起对等方P的第一个数据报，对等方P可以重新发送该数据报，直到对等方Q被视为死亡。
6. If the reply datagram by Peer Q does pass the checks by Peer P, and Peer P wants to continue interacting with Peer Q, Peer P can now send REQUEST, PEX_REQ, and other messages to Peer Q. Datagrams carrying these messages MUST be prefixed with the channel ID chanQ sent by Peer Q. More specifically, because Peer P knows that Peer Q really responds, Peer P MAY start sending Peer Q messages with heavy payload. That means that Peer P MAY start responding to any REQUEST messages that Peer Q may have sent in this first reply datagram with DATA messages. Hence, transfer of chunks can start soon in PPSPP.
6. 如果Peer Q的回复数据报确实通过了Peer P的检查，并且Peer P希望继续与Peer Q交互，Peer P现在可以向Peer Q发送请求、PEX_REQ和其他消息。携带这些消息的数据报必须以Peer Q发送的通道ID chanQ作为前缀。更具体地说，因为Peer P知道Peer Q确实响应，Peer P可能开始发送具有重负载的Peer Q消息。这意味着Peer P可以开始响应Peer Q在第一个应答数据报中发送的任何请求消息，其中包含数据消息。因此，在PPSPP中块的传输很快就可以开始了。
7. If Peer Q receives any datagram (apparently) from Peer P that does not contain channel ID chanQ, Peer Q MUST discard the datagram but SHOULD continue to process datagrams from Peer P that do meet this requirement. Once Peer Q receives a datagram from Peer P that does contain the channel ID chanQ, Peer Q knows that Peer P really received its reply datagram, and the three-way handshake and channel establishment is complete. Peer Q MAY now also start sending messages with heavy payload to Peer P.
7. 如果对等方Q从对等方P接收到任何（显然）不包含信道ID chanQ的数据报，对等方Q必须丢弃该数据报，但应继续处理来自对等方P且满足该要求的数据报。一旦Peer Q从Peer P接收到包含信道ID chanQ的数据报，Peer Q知道Peer P确实接收到了其应答数据报，并且三方握手和信道建立完成。对等方Q现在也可以开始向对等方P发送具有重负载的消息。
8. If Peer P decides it no longer wants to communicate with Peer Q, or vice versa, the peer SHOULD send a closing HANDSHAKE message to the other, as described above.
8. 如果对等方P决定不再与对等方Q通信，或者反之亦然，则对等方应向另一方发送结束握手消息，如上所述。
The HAVE message is used to convey which chunks a peer has available for download. The set of chunks it has available may be expressed using different chunk addressing and availability map compression schemes, described in Section 4. HAVE messages can be used both for sending a complete overview of a peer's chunk availability as well as for updates to that set.
HAVE消息用于传达对等方可下载的块。它可用的块集可以使用不同的块寻址和可用性映射压缩方案来表示，如第4节所述。HAVE消息既可用于发送对等块可用性的完整概述，也可用于更新该集。
In particular, whenever a receiving Peer P has successfully checked the integrity of a chunk, or interval of chunks, it MUST send a HAVE message to all peers Q1..Qn it wants to allow to download those chunks. A policy in Peer P determines when the HAVE is sent. Peer P may send it directly, or Peer P may wait either until it has other data to send to Peer Qi or until it has received and checked multiple
特别是，每当接收对等方P成功检查块的完整性或块的间隔时，它必须向所有对等方发送HAVE消息Q1..Qn，以允许下载这些块。Peer P中的策略确定何时发送HAVE。对等方P可以直接发送，或者对等方P可以等待，直到它有其他数据发送给对等方Qi，或者直到它接收并检查了多个数据
chunks. The policy will depend on how urgent it is to distribute this information to the other peers. This urgency is generally determined in turn by the chunk picking policy (see Section 9.1). In general, the HAVE messages can be piggybacked onto other messages. Peers that do not receive HAVE messages are effectively prevented from downloading the newly available chunks; hence, the HAVE message can be used as a method of choking.
大块。该策略将取决于将该信息分发给其他对等方的紧迫程度。这种紧迫性通常依次由区块选取政策决定（见第9.1节）。一般来说，HAVE消息可以搭载到其他消息上。有效地防止未接收HAVE消息的对等方下载新的可用块；因此，HAVE消息可以用作阻塞方法。
The HAVE message MUST contain the chunk specification of the received and verified chunks. A receiving peer MUST NOT send a HAVE message to peers for which the handshake procedure is still incomplete, see Section 12.1. A peer SHOULD NOT send a HAVE message to peers that have the complete content already (e.g., in video-on-demand scenarios).
HAVE消息必须包含已接收和已验证区块的区块规范。接收对等方不得向握手过程尚未完成的对等方发送HAVE消息，参见第12.1节。对等方不应向已经拥有完整内容的对等方发送HAVE消息（例如，在视频点播场景中）。
The DATA message is used to transfer chunks of content. The DATA message MUST contain the chunk ID of the chunk and chunk itself. A peer MAY send the DATA messages for multiple chunks in the same datagram. The DATA message MAY contain additional information if needed by the specific congestion control mechanism used. At present, PPSPP uses LEDBAT [RFC6817] for congestion control, which requires the current system time to be sent along with the DATA message, so the current system time MUST be included.
数据消息用于传输内容块。数据消息必须包含区块的区块ID和区块本身。对等方可以为同一数据报中的多个数据块发送数据消息。如果所使用的特定拥塞控制机制需要，数据消息可以包含附加信息。目前，PPSPP使用LEDBAT[RFC6817]进行拥塞控制，这要求当前系统时间与数据消息一起发送，因此必须包括当前系统时间。
ACK messages MUST be sent to acknowledge received chunks if PPSPP is run over an unreliable transport protocol. ACK messages MAY be sent if a reliable transport protocol is used. In the former case, a receiving peer that has successfully checked the integrity of a chunk, or interval of chunks C, MUST send an ACK message containing a chunk specification for C. As LEDBAT is used, an ACK message MUST contain the one-way delay, computed from the peer's current system time received in the DATA message. A peer MAY delay sending ACK messages as defined in the LEDBAT specification [RFC6817].
如果PPSP通过不可靠的传输协议运行，则必须发送ACK消息以确认收到的数据块。如果使用可靠的传输协议，则可以发送ACK消息。在前一种情况下，成功检查区块完整性或区块间隔C的接收对等方必须发送包含C区块规范的ACK消息。使用LEDBAT时，ACK消息必须包含单向延迟，该延迟是根据对等方在数据消息中接收的当前系统时间计算得出的。对等方可以延迟发送LEDBAT规范[RFC6817]中定义的ACK消息。
The INTEGRITY message carries information required by the receiver to verify the integrity of a chunk. Its payload depends on the content integrity protection scheme used. When the Merkle Hash Tree scheme is used, an INTEGRITY message MUST contain a cryptographic hash of a subtree of the Merkle hash tree and the chunk specification that identifies the subtree.
完整性消息包含接收方验证数据块完整性所需的信息。其有效负载取决于所使用的内容完整性保护方案。使用Merkle哈希树方案时，完整性消息必须包含Merkle哈希树子树的加密哈希以及标识子树的区块规范。
As a typical example, when a peer wants to send a chunk and Merkle hash trees are used, it creates a datagram that consists of several INTEGRITY messages containing the hashes the receiver needs to verify the chunk and the actual chunk itself encoded in a DATA message. What are the necessary hashes and the exact rules for encoding them into datagrams is specified in Sections 5.3, and 5.4, respectively.
作为一个典型的例子，当一个对等方想要发送一个区块并且使用Merkle哈希树时，它会创建一个数据报，该数据报由多个完整性消息组成，其中包含接收方需要验证区块和数据消息中编码的实际区块本身的哈希。第5.3节和第5.4节分别规定了必要的哈希以及将其编码为数据报的确切规则。
The SIGNED_INTEGRITY message carries digitally signed information required by the receiver to verify the integrity of a chunk in live streaming. It logically contains a chunk specification, a timestamp, and a digital signature. Its exact payload depends on the live content integrity protection scheme used, see Section 6.1.
签名的_INTEGRITY消息包含接收方验证实时流媒体中数据块完整性所需的数字签名信息。它在逻辑上包含块规范、时间戳和数字签名。其确切有效负载取决于所使用的直播内容完整性保护方案，请参见第6.1节。
While bulk download protocols normally do explicit requests for certain ranges of data (i.e., use a pull model, for example, BitTorrent [BITTORRENT]), live streaming protocols quite often use a push model without requests to save round trips. PPSPP supports both models of operation.
虽然大容量下载协议通常对特定范围的数据进行显式请求（即，使用pull模型，例如BitTorrent[BitTorrent]），但实时流媒体协议通常使用push模型而不请求保存往返。PPSP支持两种操作模式。
The REQUEST message is used to request one or more chunks from another peer. A REQUEST message MUST contain the specification of the chunks the requester wants to download. A peer receiving a REQUEST message MAY send out the requested chunks (by means of DATA messages). When Peer Q receives multiple REQUESTs from the same Peer P, Peer Q SHOULD process the REQUESTs in the order received. Multiple REQUEST messages MAY be sent in one datagram, for example, when a peer wants to request several rare chunks at once.
请求消息用于从另一个对等方请求一个或多个块。请求消息必须包含请求者想要下载的块的规范。接收请求消息的对等方可以（通过数据消息）发送所请求的块。当对等Q收到来自同一对等P的多个请求时，对等Q应按照收到的顺序处理这些请求。多个请求消息可以在一个数据报中发送，例如，当一个对等方想要同时请求几个罕见的数据块时。
When live streaming via a push model, a peer receiving REQUESTs also MAY send some other chunks in case it runs out of requests or for some other reason. In that case, the only purpose of REQUEST messages is to provide hints and coordinate peers to avoid unnecessary data retransmission.
当通过推送模式进行实时流媒体传输时，接收请求的对等方还可能发送一些其他数据块，以防请求用尽或出于其他原因。在这种情况下，请求消息的唯一目的是提供提示并协调对等方以避免不必要的数据重新传输。
When downloading on-demand or live streaming content, a peer can request urgent data from multiple peers to increase the probability of it being delivered on time. In particular, when the specific chunk picking algorithm (see Section 9.1), detects that a request for urgent data might not be served on time, a request for the same data can be sent to a different peer. When a Peer P decides to request urgent data from a Peer Q, Peer P SHOULD send a CANCEL message to all the peers to which the data has been previously requested. The
当下载点播或流媒体直播内容时，一个对等方可以从多个对等方请求紧急数据，以提高其按时交付的概率。特别是，当特定区块选取算法（见第9.1节）检测到紧急数据请求可能无法按时送达时，相同数据的请求可以发送到不同的对等方。当对等方P决定从对等方Q请求紧急数据时，对等方P应向先前请求数据的所有对等方发送取消消息。这个
CANCEL message contains the specification of the chunks Peer P no longer wants to request. In addition, when Peer Q receives a HAVE message for the urgent data from Peer P, Peer Q MUST also cancel the previous REQUEST(s) from Peer P. In other words, the HAVE message acts as an implicit CANCEL.
CANCEL消息包含对等方P不再希望请求的块的规范。此外，当对等方Q收到来自对等方P的紧急数据HAVE消息时，对等方Q还必须取消来自对等方P的先前请求。换句话说，HAVE消息充当隐式取消。
Peer A can send a CHOKE message to Peer B to signal it will no longer be responding to REQUEST messages from Peer B, for example, because Peer A's upload capacity is exhausted. Peer A MAY send a subsequent UNCHOKE message to signal that it will respond to new REQUESTs from Peer B again (Peer A SHOULD discard old requests). When Peer B receives a CHOKE message from Peer A, it MUST NOT send new REQUEST messages and it cannot expect answers to any outstanding ones, as the transfer of chunks is choked. When Peer B is choked but receives a HAVE message from Peer A, it is not automatically unchoked and MUST NOT send any new REQUEST messages. The CHOKE and UNCHOKE messages are informational as responding to REQUESTs is OPTIONAL, see Section 3.7.
对等方A可以向对等方B发送阻塞消息，以表明它将不再响应来自对等方B的请求消息，例如，因为对等方A的上载容量已耗尽。对等方A可能会发送后续取消勾选的消息，以表示它将再次响应来自对等方B的新请求（对等方A应丢弃旧请求）。当对等方B接收到来自对等方a的阻塞消息时，它不得发送新的请求消息，也不能期望对任何未完成的请求消息做出响应，因为区块的传输被阻塞。当对等方B阻塞但从对等方a收到HAVE消息时，它不会自动取消勾选，并且不得发送任何新的请求消息。阻塞和取消阻塞消息是信息性的，因为响应请求是可选的，请参见第3.7节。
Peer Exchange (PEX) messages are common in many peer-to-peer protocols. They allow peers to exchange the transport addresses of the peers they are currently interacting with, thereby reducing the need to contact a central tracker (or Distributed Hash Table) to discovery new peers. The strength of this mechanism is therefore that it enables decentralized peer discovery: after an initial bootstrap, a central tracker is no longer needed. Its weakness is that it enables a number of attacks, so it should not be used on the Internet unless extra security measures are in place.
对等交换（PEX）消息在许多对等协议中很常见。它们允许对等方交换当前与之交互的对等方的传输地址，从而减少了联系中央跟踪器（或分布式哈希表）以发现新对等方的需要。因此，这种机制的优势在于它支持分散的对等发现：在初始引导之后，不再需要中央跟踪器。它的弱点是，它可以发起许多攻击，因此除非有额外的安全措施，否则不应在互联网上使用它。
PPSPP supports peer-address exchange on the Internet and in benign private networks as an OPTIONAL feature (not mandatory to implement) under certain conditions. The general mechanism works as follows. To obtain some peer addresses, a Peer A MAY send a PEX_REQ message to Peer B. Peer B MAY respond with one or more PEX_REScert messages. Logically, a PEX_REScert reply message contains the address of a single peer Ci. Peer B MUST have exchanged messages with Peer Ci in the last 60 seconds to guarantee liveliness. Upon receipt, Peer A may contact any or none of the returned peers Ci. Alternatively, peers MAY ignore PEX_REQ and PEX_REScert messages if uninterested in obtaining new peers or because of security considerations (rate limiting) or any other reason. The PEX messages can be used to construct a dedicated tracker peer.
PPSPP在某些条件下作为可选功能（非强制实施）支持Internet和良性专用网络中的对等地址交换。一般机制的工作原理如下。为了获得一些对等地址，对等方a可以向对等方B发送PEX_REQ消息。对等方B可以使用一个或多个PEX_重新插入消息进行响应。从逻辑上讲，PEX_REScert回复消息包含单个对等Ci的地址。对等方B必须在过去60秒内与对等方Ci交换消息，以保证生动性。收到后，对等方A可联系任何或任何返回的对等方Ci。或者，如果对获取新的对等方不感兴趣，或者出于安全考虑（速率限制）或任何其他原因，对等方可以忽略PEX_REQ和PEX_RESERT消息。PEX消息可用于构建专用的对等跟踪器。
To use PEX in PPSPP on the Internet, two conditions must be met:
要在互联网上的PPSPP中使用PEX，必须满足两个条件：
1. Peer transport addresses must be relatively stable.
1. 对等传输地址必须相对稳定。
2. A peer must not obtain all its peer addresses through PEX.
2. 对等方不得通过PEX获取其所有对等地址。
The full security analysis for PEX messages can be found in Section 12.2. Physically, a PEX_REScert message carries a swarm-membership certificate rather than an IP address and port. A membership certificate for Peer C states that Peer C at address (ipC,portC) is part of Swarm S at Time T and is cryptographically signed by an issuer. The receiver Peer A can check the certificate for a valid signature by a trusted issuer, the right swarm, and liveliness and only then consider contacting C. These swarm-membership certificates correspond to signed node descriptors in secure decentralized peer sampling services [SPS].
PEX消息的完整安全性分析见第12.2节。物理上，PEX_Resert消息携带的是swarm成员资格证书，而不是IP地址和端口。对等方C的成员资格证书声明，地址（ipC，portC）处的对等方C在时间T是Swarm S的一部分，并由发卡机构进行加密签名。接收者对等体A可以通过可信发行者、正确群体和活跃性来检查证书以获得有效签名，然后才考虑联系C。这些群成员证书对应于安全分散的对等采样服务[SSP]中的签名节点描述符。
Several designs are possible for the security environment for these membership certificates. That is, there are different designs possible for who signs the membership certificates and how public keys are distributed. Section 12.2.2 describes an example where a central tracker acts as the Certification Authority.
这些成员资格证书的安全环境有多种设计。也就是说，对于谁签署会员证书以及如何分发公钥，可能有不同的设计。第12.2.2节描述了中央跟踪器充当认证机构的示例。
In a hostile environment, such as the Internet, peers must also ensure that they do not end up interacting only with malicious peers when using the peer-address exchange feature. To this extent, peers MUST ensure that part of their connections are to peers whose addresses came from a trusted and secured tracker (see Section 12.2.3).
在敌对环境（如互联网）中，对等方还必须确保在使用对等方地址交换功能时，不会只与恶意对等方进行交互。在这种情况下，对等方必须确保其部分连接到其地址来自可信和安全追踪器的对等方（见第12.2.3节）。
In addition to the PEX_REScert, there are two other PEX reply messages. The PEX_RESv4 message contains a single IPv4 address and port. The PEX_RESv6 message contains a single IPv6 address and port. They MUST only be used in a benign environment, such as a private network, as they provide no guarantees that the host addressed actually participates in a PPSPP swarm.
除PEX_Resert外，还有另外两条PEX回复消息。PEX_RESv4消息包含单个IPv4地址和端口。PEX_RESv6消息包含单个IPv6地址和端口。它们只能在良性环境中使用，如专用网络，因为它们不能保证所寻址的主机实际参与PPSPSwarm。
Once a PPSPP implementation has obtained a list of peers (either via PEX, from a central tracker, or via a Distributed Hash Table (DHT)), it has to determine which peers to actually contact. In this process, a PPSPP implementation can benefit from information by network or content providers to help improve network usage and boost PPSPP performance. How a peer-to-peer (P2P) system like PPSPP can perform these optimizations using the Application-Layer Traffic Optimization (ALTO) protocol is described in detail in [RFC7285], Section 7.
一旦PPSP实现获得了对等点列表（通过PEX、从中央跟踪器或通过分布式哈希表（DHT）），它就必须确定实际联系的对等点。在此过程中，PPSPP实施可以受益于网络或内容提供商提供的信息，以帮助提高网络使用率和PPSPP性能。[RFC7285]第7节详细描述了像PPSPP这样的对等（P2P）系统如何使用应用层流量优化（ALTO）协议执行这些优化。
It is increasingly complex for peers to enable communication between each other due to NATs and firewalls. Therefore, PPSPP uses a multiplexing scheme, called channels, to allow multiple swarms to use the same transport address. Channels loosely correspond to TCP connections and each channel belongs to a single swarm, as illustrated in Figure 1. As with TCP connections, a channel is identified by a unique identifier local to the peer at each end of the connection (cf. TCP port), which MUST be randomly chosen. In other words, the two peers connected by a channel use different IDs to denote the same channel. The IDs are different and random for security reasons, see Section 12.1.
由于NAT和防火墙，对等点之间的通信变得越来越复杂。因此，PPSP使用一种称为通道的多路复用方案，允许多个群集使用相同的传输地址。通道松散地对应于TCP连接，每个通道属于一个群集，如图1所示。与TCP连接一样，通道由连接两端的对等方本地唯一标识符（参见TCP端口）标识，必须随机选择。换句话说，由一个信道连接的两个对等方使用不同的id来表示相同的信道。出于安全原因，ID不同且随机，见第12.1节。
In the PPSP-over-UDP encapsulation (Section 8.3), when a Channel C has been established between Peer A and Peer B, the datagrams containing messages from Peer A to Peer B are prefixed with the four-byte channel ID allocated by Peer B, and vice versa for datagrams from Peer B to A. The channel IDs used are exchanged as part of the handshake procedure, see Section 8.4. In that procedure, the channel ID with value 0 is used for the datagram that initiates the handshake. PPSPP can be used in combination with Session Traversal Utilities for NAT (STUN) [RFC5389].
在PPSP over UDP封装（第8.3节）中，当在对等a和对等B之间建立通道C时，包含对等a到对等B消息的数据报以对等B分配的四字节通道ID作为前缀，从对等B到A的数据报也是如此。使用的信道ID作为握手过程的一部分进行交换，见第8.4节。在该过程中，值为0的通道ID用于发起握手的数据报。PPSPP可以与NAT（STUN）的会话遍历实用程序结合使用[RFC5389]。
_________ _________ _________
| | | | | |
| Swarm | | Swarm | | Swarm |
| Mgr | | A | | B |
|_______| |_______| |_______|
| | / \
| | / \
____|____ ____|____ ______/__ _\_______
| | | | | | | |
| Chan | | Chan | | Chan | | Chan |
| 0 | | 481 | | 836 | | 372 |
|_______| |_______| |_______| |_______|
| | | |
| | | |
____|____________|____________|____________|____
| |
| UDP |
| port 6778 |
|______________________________________________|
_________ _________ _________
| | | | | |
| Swarm | | Swarm | | Swarm |
| Mgr | | A | | B |
|_______| |_______| |_______|
| | / \
| | / \
____|____ ____|____ ______/__ _\_______
| | | | | | | |
| Chan | | Chan | | Chan | | Chan |
| 0 | | 481 | | 836 | | 372 |
|_______| |_______| |_______| |_______|
| | | |
| | | |
____|____________|____________|____________|____
| |
| UDP |
| port 6778 |
|______________________________________________|
Network stack of a PPSPP peer that is reachable on UDP port 6778 and is connected via channel 481 to one peer in Swarm A and two peers in Swarm B via channels 836 and 372, respectively. Channel ID 0 is special and is used for handshaking.
可在UDP端口6778上访问并通过通道481分别连接到群a中的一个对等方和群B中的两个对等方（通过通道836和372）的PPSP对等方的网络堆栈。通道ID 0是特殊的，用于握手。
Figure 1
图1
A peer SHOULD send a "keep alive" message periodically to each peer it is interested in, but has no other messages to send to them at present. The goal of the keep alives is to keep a signaling channel open to peers that are of interest. Which peers those are is determined by a policy that decides which peers are of interest now and in the near future. This document does not prescribe a policy, but examples of interesting peers are (a) peers that have chunks on offer that this client needs or (b) peers that currently do not have interesting chunks on offer (because they are still downloading themselves, or in live streaming) but gave good performance in the past. When these peers have new chunks to offer, the peer that kept a signaling channel open can use them again. Periodically sending "keep alive" messages prevents other peers declaring the peer dead. A guideline for declaring a peer dead when using UDP consists of a three minute delay since that last packet has been received from that peer and at least three datagrams having been sent to that peer during the same period. When a peer is declared dead, the channel to it is closed, no more messages will be sent to that peer and the
对等方应定期向其感兴趣的每个对等方发送“保持活动”消息，但目前没有其他消息可发送给它们。keep alives的目标是保持一个信号通道对感兴趣的对等方开放。哪些对等点是由一项政策决定的，该政策决定哪些对等点是现在和不久的将来感兴趣的。本文档未规定政策，但感兴趣的对等点的示例包括：（a）具有该客户端所需的可用块的对等点，或（b）当前没有提供感兴趣的可用块的对等点（因为他们仍在下载自己的内容，或在流媒体直播中），但在过去表现良好。当这些对等方有新的块提供时，保持信令通道开放的对等方可以再次使用它们。定期发送“保持活动”消息可防止其他对等方声明该对等方已死亡。当使用UDP时，用于声明对等方已死亡的准则包括三分钟的延迟，因为已从该对等方接收到最后一个数据包，并且在同一时间段内已向该对等方发送了至少三个数据报。当一个对等方被声明为死亡时，到它的通道关闭，不再向该对等方发送消息，并且
local administration about the peer is discarded. Busy servers can force idle clients to disconnect by not sending keep alives. PPSPP does not define an explicit message type for "keep alive" messages. In the PPSP-over-UDP encapsulation they are implemented as simple datagrams consisting of a four-byte channel ID only, see Sections 8.3 and 8.4.
放弃对对等方的本地管理。繁忙的服务器可以通过不发送keep-alives来强制空闲客户端断开连接。PPSPP没有为“保持活动”消息定义显式消息类型。在PPSP over UDP封装中，它们被实现为仅由四字节通道ID组成的简单数据报，请参见第8.3节和第8.4节。
PPSPP can use different methods of chunk addressing, that is, support different ways of identifying chunks and different ways of expressing the chunk availability map of a peer in a compact fashion.
PPSPP可以使用不同的区块寻址方法，即支持不同的区块识别方法和以紧凑方式表示对等方区块可用性映射的不同方法。
All peers in a swarm MUST use the same chunk addressing method.
群中的所有对等方必须使用相同的块寻址方法。
A chunk specification consists of a single (start specification,end specification) pair that identifies a range of chunks (end inclusive). The start and end specifications can use one of multiple addressing schemes. Two schemes are currently defined: chunk ranges and byte ranges.
块规范由单个（开始规范、结束规范）对组成，用于标识一系列块（包括结束）。起始和结束规范可以使用多个寻址方案之一。目前定义了两种方案：块范围和字节范围。
The start and end specification are both chunk identifiers. Chunk identifiers are 32-bit or 64-bit unsigned integers. A PPSPP peer MUST support this scheme.
开始和结束规范都是块标识符。块标识符是32位或64位无符号整数。PPSP对等方必须支持此方案。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Start chunk (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ End chunk (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Start chunk (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ End chunk (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The start and end specification are 64-bit byte offsets in the content. The support for this scheme is OPTIONAL.
开始和结束规范是内容中的64位字节偏移量。对该方案的支持是可选的。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start byte offset (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End byte offset (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start byte offset (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End byte offset (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PPSPP introduces a novel method of addressing chunks of content called "bin numbers" (or "bins" for short). Bin numbers allow the addressing of a binary interval of data using a single integer. This reduces the amount of state that needs to be recorded per peer and the space needed to denote intervals on the wire, making the protocol lightweight. In general, this numbering system allows PPSPP to work with simpler data structures, e.g., to use arrays instead of binary trees, thus reducing complexity. The support for this scheme is OPTIONAL.
PPSPP引入了一种新的寻址内容块的方法，称为“bin number”（简称“bin”）。Bin编号允许使用单个整数对二进制数据间隔进行寻址。这减少了每个对等方需要记录的状态量以及表示线路上的间隔所需的空间，从而使协议变得轻量级。通常，这种编号系统允许PPSPP使用更简单的数据结构，例如使用数组而不是二叉树，从而降低复杂性。对该方案的支持是可选的。
In bin addressing, the smallest binary interval is a single chunk (e.g., a block of bytes that may be of variable size), the largest interval is a complete range of 2**63 chunks. In a novel addition to the classical scheme, these intervals are numbered in a way that lays them out into a vector nicely, which is called bin numbering, as follows. Consider a chunk interval of width W. To derive the bin numbers of the complete interval and the subintervals, a minimal balanced binary tree is built that is at least W chunks wide at the base. The leaves from left-to-right correspond to the chunks 0..W-1 in the interval, and have bin number I*2 where I is the index of the chunk (counting beyond W-1 to balance the tree). The bin number of higher-level node P in the tree is calculated as follows:
在bin寻址中，最小的二进制间隔是单个块（例如，大小可变的字节块），最大间隔是2**63块的完整范围。在经典方案的一个新的补充中，这些间隔以一种将它们巧妙地排列成向量的方式进行编号，称为bin编号，如下所示。考虑宽度W的块区间，导出完整区间和子区间的bin数，建立最小平衡二叉树，该最小平衡二叉树至少在基部宽。从左到右的叶子对应于间隔中的块0..W-1，并且具有仓位号I*2，其中I是块的索引（计数超过W-1以平衡树）。树中更高级别节点P的bin编号计算如下：
binP = (binL + binR) / 2
binP = (binL + binR) / 2
where binL is the bin of node P's left-hand child and binR is the bin of node P's right-hand child. Given that each node in the tree represents a subinterval of the original interval, each such subinterval now is addressable by a bin number, a single integer. The bin number tree of an interval of width W=8 looks like this:
其中binL是节点P左侧子节点的bin，binR是节点P右侧子节点的bin。假设树中的每个节点表示原始间隔的一个子间隔，那么每个这样的子间隔现在都可以通过一个bin编号（一个整数）进行寻址。宽度为W=8的间隔的箱号树如下所示：
7
/ \
/ \
/ \
/ \
3 11
/ \ / \
/ \ / \
/ \ / \
1 5 9 13
/ \ / \ / \ / \
0 2 4 6 8 10 12 14
7
/ \
/ \
/ \
/ \
3 11
/ \ / \
/ \ / \
/ \ / \
1 5 9 13
/ \ / \ / \ / \
0 2 4 6 8 10 12 14
C0 C1 C2 C3 C4 C5 C6 C7
C0 C1 C2 C3 C4 C5 C6 C7
The bin number tree of an interval of width W=8
宽度为W=8的区间的箱号树
Figure 2
图2
So bin 7 represents the complete interval, bin 3 represents the interval of chunk C0..C3, bin 1 represents the interval of chunks C0 and C1, and bin 2 represents chunk C1. The special numbers 0xFFFFFFFF (32-bit) or 0xFFFFFFFFFFFFFFFF (64-bit) stands for an empty interval, and 0x7FFF...FFF stands for "everything".
因此，bin 7表示完整间隔，bin 3表示块C0..C3的间隔，bin 1表示块C0和C1的间隔，bin 2表示块C1。特殊数字0xFFFFFF（32位）或0xFFFFFFFFFFFF（64位）表示空间隔，0x7FFF…FFF表示“所有”。
When bin numbering is used, the ID of a chunk is its corresponding (leaf) bin number in the tree, and the chunk specification in HAVE and ACK messages is equal to a single bin number (32-bit or 64-bit), as follows.
当使用仓位编号时，区块的ID是树中对应的（叶）仓位编号，HAVE和ACK消息中的区块规范等于单个仓位编号（32位或64位），如下所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bin number (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bin number (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a receiving peer has successfully checked the integrity of a chunk or interval of chunks, it MUST send a HAVE message to all peers it wants to allow download of those chunk(s) from. The ability to withhold HAVE messages allows them to be used as a method of choking. The HAVE message MUST contain the chunk specification of the biggest complete interval of all chunks the receiver has received and checked so far that fully includes the interval of chunks just received. So
当接收端成功地检查了区块或区块间隔的完整性时，它必须向它希望允许从中下载这些区块的所有对等方发送HAVE消息。保留HAVE消息的能力允许它们被用作阻塞的方法。HAVE消息必须包含接收方迄今为止已接收并检查的所有区块中最大完整间隔的区块规范，该规范完全包括刚刚接收的区块间隔。所以
the chunk specification MUST denote at least the interval received, but the receiver is supposed to aggregate and acknowledge bigger intervals, when possible.
区块规范必须至少表示接收到的间隔，但是如果可能的话，接收方应该聚合并确认更大的间隔。
As a result, every single chunk is acknowledged a logarithmic number of times. That provides some necessary redundancy of acknowledgements and sufficiently compensates for unreliable transport protocols.
因此，每个块都会被对数次数的确认。这提供了一些必要的确认冗余，并充分补偿了不可靠的传输协议。
Implementation note:
实施说明：
To record which chunks a peer has in the state that an implementation keeps for each peer, an implementation MAY use the efficient "binmap" data structure, which is a hybrid of a bitmap and a binary tree, discussed in detail in [BINMAP].
为了记录对等体在实现为每个对等体保留的状态下拥有的块，实现可以使用高效的“binmap”数据结构，该数据结构是位图和二叉树的混合体，在[binmap]中详细讨论。
PPSPP peers MUST use ACK messages to acknowledge received chunks if an unreliable transport protocol is used. When a receiving peer has successfully checked the integrity of a chunk or interval of chunks C, it MUST send an ACK message containing the chunk specification of its biggest, complete interval covering C to the sending peer (see HAVE).
如果使用了不可靠的传输协议，PPSPP对等方必须使用ACK消息来确认接收到的数据块。当接收端已成功检查块或块间隔C的完整性时，它必须向发送端发送一条ACK消息，其中包含覆盖C的最大完整间隔的块规范（参见HAVE）。
PPSPP can use different methods for protecting the integrity of the content while it is being distributed via the peer-to-peer network. More specifically, PPSPP can use different methods for receiving peers to detect whether a requested chunk has been maliciously modified by the sending peer. In benign environments, content integrity protection can be disabled.
PPSP可以使用不同的方法在通过对等网络分发内容时保护内容的完整性。更具体地说，PPSP可以使用不同的方法来接收对等方，以检测请求的块是否被发送对等方恶意修改。在良好的环境中，可以禁用内容完整性保护。
For static content, PPSPP currently defines one method for protecting integrity, called the Merkle Hash Tree scheme. If PPSPP operates over the Internet, this scheme MUST be used. If PPSPP operates in a benign environment, this scheme MAY be used. So the scheme is mandatory to implement, to satisfy the requirement of strong security for an IETF protocol [RFC3365]. An extended version of the scheme is used to efficiently protect dynamically generated content (live streams), as explained below and in Section 6.1.
对于静态内容，PPSPP目前定义了一种保护完整性的方法，称为Merkle哈希树方案。如果PPSP在互联网上运行，则必须使用此方案。如果PPSP在良性环境中运行，则可使用此方案。因此，必须实施该方案，以满足IETF协议[RFC3365]的强安全性要求。该方案的扩展版本用于有效保护动态生成的内容（实时流），如下文和第6.1节所述。
The Merkle Hash Tree scheme can work with different chunk addressing schemes. All it requires is the ability to address a range of chunks. In the following description abstract node IDs are used to identify nodes in the tree. On the wire, these are translated to the corresponding range of chunks in the chosen chunk addressing scheme.
Merkle哈希树方案可以使用不同的块寻址方案。它所需要的只是处理一系列块的能力。在以下描述中，抽象节点ID用于标识树中的节点。在线路上，这些被转换为所选块寻址方案中的相应块范围。
PPSPP uses a method of naming content based on self-certification. In particular, content in PPSPP is identified by a single cryptographic hash that is the root hash in a Merkle hash tree calculated recursively from the content [ABMRKL]. This self-certifying hash tree allows every peer to directly detect when a malicious peer tries to distribute fake content. It also ensures only a small the amount of information is needed to start a download (the root hash and some peer addresses). For live streaming, a dynamic tree and a public key are used, see below.
PPSP使用基于自我认证的内容命名方法。具体而言，PPSPP中的内容由单个加密哈希标识，该哈希是根据内容[ABMRKL]递归计算的Merkle哈希树中的根哈希。这种自认证哈希树允许每个对等方在恶意对等方试图分发虚假内容时直接检测。它还确保启动下载只需要少量信息（根哈希和一些对等地址）。对于实时流媒体，使用动态树和公钥，请参见下文。
The Merkle hash tree of a content file that is divided into N chunks is constructed as follows. Note the construction does not assume chunks of content to be of a fixed size. Given a cryptographic hash function, more specifically an MDC [HAC01], such as SHA-256, the hashes of all the chunks of the content are calculated. Next, a binary tree of sufficient height is created. Sufficient height means that the lowest level in the tree has enough nodes to hold all chunk hashes in the set, as with bin numbering. The figure below shows the tree for a content file consisting of 7 chunks. As with the content addressing scheme, the leaves of the tree correspond to a chunk and, in this case, are assigned the hash of that chunk, starting at the leftmost leaf. As the base of the tree may be wider than the number of chunks, any remaining leaves in the tree are assigned an empty hash value of all zeros. Finally, the hash values of the higher levels in the tree are calculated, by concatenating the hash values of the two children (again left to right) and computing the hash of that aggregate. If the two children are empty hashes, the parent is an empty all-zeros hash as well (to save computation). This process ends in a hash value for the root node, which is called the "root hash". Note the root hash only depends on the content and any modification of the content will result in a different root hash.
被划分为N个块的内容文件的Merkle哈希树构造如下。注意，这种构造并不假定内容块的大小是固定的。给定加密散列函数，更具体地说是MDC[HAC01]，例如SHA-256，计算内容的所有块的散列。接下来，创建一个足够高的二叉树。足够的高度意味着树中的最低级别有足够的节点来容纳集合中的所有区块哈希，就像bin编号一样。下图显示了由7个块组成的内容文件的树。与内容寻址方案一样，树的叶子对应一个块，在本例中，从最左边的叶子开始分配该块的哈希。由于树的底部可能比块的数量更宽，因此树中的任何剩余叶子都被分配一个全为零的空哈希值。最后，通过连接两个子项的哈希值（再次从左到右）并计算该聚合的哈希值，计算树中较高级别的哈希值。如果两个子项是空哈希，则父项也是空的全零哈希（以节省计算）。此过程以根节点的哈希值结束，该值称为“根哈希”。注意，根哈希仅取决于内容，对内容的任何修改都将导致不同的根哈希。
7 = root hash
/ \
/ \
/ \
/ \
3* 11
/ \ / \
/ \ / \
/ \ / \
1 5 9 13* = uncle hash
/ \ / \ / \ / \
0 2 4 6 8 10* 12 14
7 = root hash
/ \
/ \
/ \
/ \
3* 11
/ \ / \
/ \ / \
/ \ / \
1 5 9 13* = uncle hash
/ \ / \ / \ / \
0 2 4 6 8 10* 12 14
C0 C1 C2 C3 C4 C5 C6 E
=chunk index ^^ = empty hash
C0 C1 C2 C3 C4 C5 C6 E
=chunk index ^^ = empty hash
Merkle hash tree of a content file with N=7 chunks
具有N=7个块的内容文件的Merkle哈希树
Figure 3
图3
Assuming a peer receives the root hash of the content it wants to download from a trusted source, it can check the integrity of any chunk of that content it receives as follows. It first calculates the hash of the chunk it received, for example, chunk C4 in the previous figure. Along with this chunk, it MUST receive the hashes required to check the integrity of that chunk. In principle, these are the hash of the chunk's sibling (C5) and that of its "uncles". A chunk's uncles are the sibling Y of its parent X, and the uncle of that Y, recursively until the root is reached. For chunk C4, the uncles are nodes 13 and 3 and the sibling is 10; all marked with a * in the figure. Using this information, the peer recalculates the root hash of the tree and compares it to the root hash it received from the trusted source. If they match, the chunk of content has been positively verified to be the requested part of the content. Otherwise, the sending peer sent either the wrong content or the wrong sibling or uncle hashes. For simplicity, the set of sibling and uncle hashes is collectively referred to as the "uncle hashes".
假设对等方从可信源接收到它想要下载的内容的根哈希，它可以按如下方式检查它接收到的任何内容块的完整性。它首先计算它接收到的块的哈希值，例如上图中的块C4。它必须与此块一起接收检查该块完整性所需的哈希值。原则上，这些是块的兄弟（C5）及其“叔叔”的散列。块的叔叔是其父X的兄弟Y，并且递归地是该Y的叔叔，直到到达根为止。对于块C4，UNBLE是节点13和3，兄弟节点是10；图中所有标记为*的。使用此信息，对等方重新计算树的根哈希，并将其与从受信任源接收的根哈希进行比较。如果它们匹配，则内容块已被确认为内容的请求部分。否则，发送对等方发送了错误的内容或错误的兄弟姐妹或叔叔散列。为简单起见，兄弟和叔叔散列集合统称为“叔叔散列”。
In the case of live streaming, the tree of chunks grows dynamically and the root hash is undefined or, more precisely, transient, as long as new data is generated by the live source. Section 6.1.2 defines a method for content integrity verification for live streams that works with such a dynamic tree. Although the tree is dynamic, content verification works the same for both live and predefined content, resulting in a unified method for both types of streaming.
在实时流媒体的情况下，只要实时源生成新数据，数据块树就会动态增长，并且根哈希是未定义的，或者更准确地说，是暂时的。第6.1.2节定义了一种对使用这种动态树的实时流进行内容完整性验证的方法。尽管树是动态的，但内容验证对实时内容和预定义内容的效果相同，从而为这两种类型的流媒体提供了统一的方法。
As explained above, a datagram consists of a sequence of messages. Ideally, every datagram sent must be independent of other datagrams: each datagram SHOULD be processed separately, and a loss of one datagram must not disrupt the flow of datagrams between two peers. Thus, as a datagram carries zero or more messages, both messages and message interdependencies SHOULD NOT span over multiple datagrams.
如上所述，数据报由一系列消息组成。理想情况下，发送的每个数据报必须独立于其他数据报：每个数据报应单独处理，一个数据报的丢失不得中断两个对等方之间的数据报流。因此，由于数据报携带零条或多条消息，因此消息和消息相互依赖性不应跨越多个数据报。
This principle implies that as any chunk is verified using its uncle hashes, the necessary hashes SHOULD be put into the same datagram as the chunk's data. If this is not possible because of a limitation on datagram size, the necessary hashes MUST be sent first in one or more datagrams. As a general rule, if some additional data is still missing to process a message within a datagram, the message SHOULD be dropped.
这一原则意味着，当任何区块都是使用其叔叔散列进行验证时，必要的散列应该与区块的数据放在同一个数据报中。如果由于数据报大小的限制而无法实现，则必须首先在一个或多个数据报中发送必要的哈希。作为一般规则，如果在处理数据报中的消息时仍缺少一些附加数据，则应删除该消息。
The hashes necessary to verify a chunk are, in principle, its sibling's hash and all its uncle hashes, but the set of hashes to send can be optimized. Before sending a packet of data to the receiver, the sender inspects the receiver's previous acknowledgements (HAVE or ACK) to derive which hashes the receiver already has for sure. Suppose the receiver had acknowledged chunks C0 and C1 (the first two chunks of the file), then it must already have uncle hashes 5, 11, and so on. That is because those hashes are necessary to check C0 and C1 against the root hash. Then, hashes 3, 7, and so on must also be known as they are calculated in the process of checking the uncle hash chain. Hence, to send chunk C7, the sender needs to include just the hashes for nodes 14 and 9, which let the data be checked against hash 11, which is already known to the receiver.
原则上，验证区块所需的散列是其同级散列和所有同级散列，但要发送的散列集可以优化。在向接收方发送数据包之前，发送方检查接收方之前的确认（HAVE或ACK），以确定接收方已经拥有哪些散列。假设接收者已经确认了块C0和C1（文件的前两个块），那么它一定已经有了叔叔散列5、11等等。这是因为这些散列是根据根散列检查C0和C1所必需的。然后，还必须知道散列3、7等，因为它们是在检查散列链的过程中计算的。因此，为了发送区块C7，发送方需要仅包括节点14和9的散列，这使得数据可以根据接收方已知的散列11进行检查。
The sender MAY optimistically skip hashes that were sent out in previous, still-unacknowledged datagrams. It is an optimization trade-off between redundant hash transmission and the possibility of collateral data loss in the case in which some necessary hashes were lost in the network so some delivered data cannot be verified and thus had to be dropped. In either case, the receiver builds the Merkle hash tree on-demand, incrementally, starting from the root hash, and uses it for data validation.
发送方可以乐观地跳过在先前的、仍然未确认的数据报中发送的散列。这是冗余散列传输和并行数据丢失的可能性之间的优化折衷，在这种情况下，一些必要的散列在网络中丢失，因此一些传递的数据无法验证，因此必须丢弃。在任何一种情况下，接收方都从根散列开始按需递增地构建Merkle散列树，并将其用于数据验证。
In short, the sender MUST put into the datagram the hashes he believes are necessary for the receiver to verify the chunk. The receiver MUST remember all the hashes it needs to verify missing chunks that it still wants to download. Note that the latter implies that a hardware-limited receiver MAY forget some hashes if it does not plan to announce possession of these chunks to others (i.e., does not plan to send HAVE messages.)
简言之，发送方必须在数据报中输入他认为接收方验证数据块所必需的哈希值。接收者必须记住它需要的所有哈希值，以验证它仍然想要下载的丢失的块。注意，后者意味着，如果硬件有限的接收器不打算向其他人宣布拥有这些数据块（即，不打算发送HAVE消息），那么它可能会忘记一些散列
Concretely, a peer that wants to send a chunk of content creates a datagram that MUST consist of a list of INTEGRITY messages followed by a DATA message. If the INTEGRITY messages and DATA message cannot be put into a single datagram because of a limitation on datagram size, the INTEGRITY messages MUST be sent first in one or more datagrams. The list of INTEGRITY messages sent MUST contain an INTEGRITY message for each hash the receiver misses for integrity checking. An INTEGRITY message for a hash MUST contain the chunk specification corresponding to the node ID of the hash and the hash data itself. The chunk specification corresponding to a node ID is defined as the range of chunks formed by the leaves of the subtree rooted at the node. For example, node 3 in Figure 3 denotes chunks 0, 2, 4, and 6, so the chunk specification should denote that interval. The list of INTEGRITY messages MUST be sorted in order of the tree height of the nodes, descending (the leaves are at height 0). The DATA message MUST contain the chunk specification of the chunk and the chunk itself. A peer MAY send the required messages for multiple chunks in the same datagram, depending on the encapsulation.
具体地说，想要发送内容块的对等方创建的数据报必须由完整性消息列表和数据消息组成。如果由于数据报大小的限制，完整性消息和数据消息无法放入单个数据报，则必须首先在一个或多个数据报中发送完整性消息。发送的完整性消息列表必须包含接收方未命中的每个哈希的完整性消息，以进行完整性检查。哈希的完整性消息必须包含与哈希的节点ID和哈希数据本身相对应的区块规范。与节点ID相对应的区块规范定义为由根在节点上的子树叶形成的区块范围。例如，图3中的节点3表示块0、2、4和6，因此块规范应该表示该间隔。完整性消息列表必须按节点的树高降序排列（叶子高度为0）。数据消息必须包含区块和区块本身的区块规范。根据封装情况，对等方可以为同一数据报中的多个数据块发送所需的消息。
The current method for protecting content integrity in BitTorrent [BITTORRENT] is not suited for streaming. It involves providing clients with the hashes of the content's chunks before the download commences by means of metadata files (called .torrent files in BitTorrent.) However, when chunks are small, as in the current UDP encapsulation of PPSPP, this implies having to download a large number of hashes before content download can begin. This, in turn, increases time-till-playback for end users, making this method unsuited for streaming.
当前用于保护BitTorrent[BitTorrent]中内容完整性的方法不适用于流媒体。它包括在下载开始之前通过元数据文件（在BitTorrent中称为.torrent文件）向客户端提供内容块的散列。但是，当块很小时，如当前PPSP的UDP封装，这意味着在开始内容下载之前必须下载大量散列。这反过来又增加了最终用户播放之前的时间，使得这种方法不适合流媒体。
The overhead of using Merkle hash trees is limited. The size of the hash tree expressed as the total number of nodes depends on the number of chunks the content is divided (and hence the size of chunks) following this formula:
使用Merkle哈希树的开销是有限的。表示为节点总数的哈希树的大小取决于内容按以下公式划分的块数（以及块的大小）：
nnodes = math.pow(2,math.log(nchunks,2)+1)
nnodes = math.pow(2,math.log(nchunks,2)+1)
In principle, the hash values of all these nodes will have to be sent to a peer once for it to verify all of the chunks. Hence, the maximum on-the-wire overhead is hashsize * nnodes. However, the actual number of hashes transmitted can be optimized as described in Section 5.3.
原则上，所有这些节点的散列值必须发送给对等方一次，以便对等方验证所有块。因此，线路开销的最大值是hashsize*nnodes。但是，可以按照第5.3节所述优化传输的实际散列数。
To see a peer can verify all chunks whilst receiving not all hashes, consider the example tree in Section 5.1. In the case of a simple progressive download, of chunks 0, 2, 4, 6, etc., the sending peer will send the following hashes:
要查看对等体可以在接收所有散列时验证所有块，请考虑第5.1节中的示例树。在简单渐进下载的情况下，块0、2、4、6等，发送对等方将发送以下哈希：
+-------+---------------------------------------------+
| Chunk | Node IDs of hashes sent |
+-------+---------------------------------------------+
| 0 | 2,5,11 |
| 2 | - (receiver already knows all) |
| 4 | 6 |
| 6 | - |
| 8 | 10,13 (hash 3 can be calculated from 0,2,5) |
| 10 | - |
| 12 | 14 |
| 14 | - |
| Total | # hashes 7 |
+-------+---------------------------------------------+
+-------+---------------------------------------------+
| Chunk | Node IDs of hashes sent |
+-------+---------------------------------------------+
| 0 | 2,5,11 |
| 2 | - (receiver already knows all) |
| 4 | 6 |
| 6 | - |
| 8 | 10,13 (hash 3 can be calculated from 0,2,5) |
| 10 | - |
| 12 | 14 |
| 14 | - |
| Total | # hashes 7 |
+-------+---------------------------------------------+
Table 1: Overhead for the Example Tree
表1：示例树的开销
So the number of hashes sent in total (7) is less than the total number of hashes in the tree (16), as a peer does not need to send hashes that are calculated and verified as part of earlier chunks.
因此，总共发送的哈希数（7）小于树（16）中的哈希总数，因为对等方不需要发送作为早期块的一部分计算和验证的哈希。
In PPSPP, the size of a static content file, such as a video file, can be reliably and automatically derived from information received from the network when fixed-size chunks are used. As a result, it is not necessary to include the size of the content file as the metadata of the content for such files. Implementations of PPSPP MAY use this automatic detection feature. Note this feature is the only feature of PPSPP that requires that a fixed-size chunk is used. This feature builds on the Merkle hash tree and the trusted root hash as swarm ID as follows.
在PPSP中，当使用固定大小的块时，静态内容文件（例如视频文件）的大小可以可靠地、自动地从从网络接收的信息中导出。因此，不必将内容文件的大小作为此类文件的内容元数据。PPSPP的实现可以使用此自动检测功能。注意：此功能是PPSPP唯一要求使用固定大小块的功能。此功能基于Merkle哈希树和受信任的根哈希作为swarm ID构建，如下所示。
The ability for a newcomer peer to detect the size of the content depends heavily on the concept of peak hashes. The concept of peak hashes depends on the concepts of filled and incomplete nodes. Recall that when constructing the binary trees for content verification and addressing the base of the tree may have more leaves than the number of chunks in the content. In the Merkle hash tree, these leaves were assigned empty all-zero hashes to be able to calculate the higher-level hashes. A filled node is now defined as a node that corresponds to an interval of leaves that consists only of
新来者检测内容大小的能力在很大程度上取决于峰值哈希的概念。峰值哈希的概念取决于填充节点和不完整节点的概念。回想一下，在构建用于内容验证和寻址的二叉树时，树的基可能比内容中的块数有更多的叶子。在Merkle散列树中，这些叶子被分配为空的所有零散列，以便能够计算更高级别的散列。填充节点现在定义为与仅由以下元素组成的叶间隔相对应的节点
hashes of content chunks, not empty hashes. Reversely, an incomplete (not filled) node corresponds to an interval that also contains empty hashes, typically, an interval that extends past the end of the file. In the following figure, nodes 7, 11, 13, and 14 are incomplete: the rest is filled.
内容块的散列，而不是空散列。相反，不完整（未填充）节点对应于也包含空散列的间隔，通常是延伸到文件末尾的间隔。在下图中，节点7、11、13和14不完整：其余部分已填充。
Formally, a peak hash is the hash of a filled node in the Merkle hash tree, whose sibling is an incomplete node. Practically, suppose a file is 7162 bytes long and a chunk is 1 kilobyte. That file fits into 7 chunks, the tail chunk being 1018 bytes long. The Merkle hash tree for that file is shown in Figure 4. Following the definition, the peak hashes of this file are in nodes 3, 9, and 12, denoted with an *. E denotes an empty hash.
形式上，峰值散列是Merkle散列树中已填充节点的散列，其兄弟节点是不完整节点。实际上，假设一个文件的长度为7162字节，一个块的长度为1KB。该文件可分为7个块，尾部块的长度为1018字节。该文件的Merkle哈希树如图4所示。根据定义，该文件的峰值散列位于节点3、9和12中，用*表示。E表示一个空散列。
7
/ \
/ \
/ \
/ \
3* 11
/ \ / \
/ \ / \
/ \ / \
1 5 9* 13
/ \ / \ / \ / \
0 2 4 6 8 10 12* 14
7
/ \
/ \
/ \
/ \
3* 11
/ \ / \
/ \ / \
/ \ / \
1 5 9* 13
/ \ / \ / \ / \
0 2 4 6 8 10 12* 14
C0 C1 C2 C3 C4 C5 C6 E = 1018 bytes
C0 C1 C2 C3 C4 C5 C6 E=1018字节
Peak hashes in a Merkle hash tree
Merkle哈希树中的峰值哈希
Figure 4
图4
Peak hashes can be explained by the binary representation of the number of chunks the file occupies. The binary representation for 7 is 111. Every "1" in binary representation of the file's packet length corresponds to a peak hash. For this particular file, there are indeed three peaks: nodes 3, 9, and 12. Therefore, the number of peak hashes for a file is also, at most, logarithmic with its size.
峰值哈希可以用文件占用的块数的二进制表示来解释。7的二进制表示是111。文件包长度的二进制表示形式中的每个“1”对应一个峰值散列。对于这个特定的文件，确实有三个峰值：节点3、9和12。因此，一个文件的峰值哈希数最多也是与其大小的对数。
A peer knowing which nodes contain the peak hashes for the file can therefore calculate the number of chunks it consists of; thus, it gets an estimate of the file size (given all chunks but the last are of a fixed size). Which nodes are the peaks can be securely communicated from one (untrusted) peer, Peer A, to another peer, Peer B, by letting Peer A send the peak hashes and their node IDs to Peer
因此，知道哪些节点包含文件的峰值散列的对等方可以计算它包含的块的数量；因此，它可以得到文件大小的估计值（给定所有块，但最后一个块的大小是固定的）。通过让对等方A向对等方发送峰值散列及其节点ID，可以将峰值从一个（不受信任的）对等方A安全地传送到另一个对等方B
B. It can be shown that the root hash that Peer B obtained from a trusted source is sufficient to verify that these are indeed the right peak hashes, as follows.
B.可以证明对等方B从可信源获得的根散列足以验证这些确实是正确的峰值散列，如下所示。
Lemma: Peak hashes can be checked against the root hash.
引理：可以根据根哈希检查峰值哈希。
Proof: (a) Any peak hash is always the left sibling. Otherwise, if it is the right sibling, its left neighbor/sibling must also be a filled node, because of the way chunks are laid out in the leaves, which contradicts the definition of a peak hash. (b) For the rightmost peak hash, its right sibling is zero. (c) For any peak hash, the right sibling might be calculated using peak hashes to the left and zeros for empty nodes. (d) Once the right sibling of the leftmost peak hash is calculated, its parent might be calculated. (e) Once that parent is calculated, we might trivially get to the root hash by concatenating the hash with zeros and hashing it repeatedly.
证明：（a）任何峰值散列总是左同胞。否则，如果它是右同级，则其左邻居/同级也必须是填充节点，因为块在叶中的布局方式与峰值散列的定义相矛盾。（b） 对于最右边的峰值哈希，其右边的同级为零。（c） 对于任何峰值散列，可以使用左侧的峰值散列和空节点的零来计算右同级。（d） 一旦计算了最左侧峰值哈希的右同级，就可以计算其父级。（e） 一旦计算出父级，我们就可以通过将散列与零串联并重复散列来获得根散列。
Informally, the Lemma might be expressed as follows: peak hashes cover all data, so the remaining hashes are either trivial (zeros) or might be calculated from peak hashes and zero hashes.
非正式地说，引理可以表示为：峰值散列覆盖所有数据，因此剩余的散列要么微不足道（零），要么可以从峰值散列和零散列计算。
Finally, once Peer B has obtained the number of chunks in the content, it can determine the exact file size as follows. Given that all chunks except the last are of a fixed size, Peer B just needs to know the size of the last chunk. Knowing the number of chunks, Peer B can calculate the node ID of the last chunk and download it. As always, Peer B verifies the integrity of this chunk against the trusted root hash. As there is only one chunk of data that leads to a successful verification, the size of this chunk must be correct. Peer B can then determine the exact file size as:
最后，一旦对等方B获得了内容中的块数，它就可以按如下方式确定确切的文件大小。考虑到除了最后一个块以外的所有块都是固定大小的，对等方B只需要知道最后一个块的大小。知道区块的数量后，对等方B可以计算最后一个区块的节点ID并下载它。和往常一样，对等方B根据受信任的根哈希验证该块的完整性。由于只有一个数据块导致验证成功，因此该数据块的大小必须正确。然后，对等方B可以确定确切的文件大小，如下所示：
(number of chunks -1) * fixed chunk size + size of last chunk
(number of chunks -1) * fixed chunk size + size of last chunk
A PPSPP implementation that wants to use automatic size detection MUST operate as follows. When Peer A sends a DATA message for the first time to Peer B, Peer A MUST first send all the peak hashes for the content, in INTEGRITY messages, unless Peer B has already signaled that it knows the peak hashes by having acknowledged any chunk. If they are needed, the peak hashes MUST be sent as an extra list of uncle hashes for the chunk, before the list of actual uncle hashes of the chunk as described in Section 5.3. The receiver, Peer B, MUST check the peak hashes against the root hash to determine the approximate content size. To obtain the definite content size, Peer B MUST download the last chunk of the content from any peer that offers it.
想要使用自动大小检测的PPSPP实现必须按如下操作。当对等方A第一次向对等方B发送数据消息时，对等方A必须首先在完整性消息中发送内容的所有峰值散列，除非对等方B已经通过确认任何数据块发出它知道峰值散列的信号。如果需要，峰值散列必须作为区块的额外叔叔散列列表发送，在区块的实际叔叔散列列表之前，如第5.3节所述。接收方对等方B必须对照根哈希检查峰值哈希，以确定大致的内容大小。为了获得确定的内容大小，对等方B必须从提供内容的任何对等方下载最后一块内容。
As an example, let's consider a 7162-byte file, which fits in 7 chunks of 1 kilobyte, distributed by Peer A. Figure 4 shows the relevant Merkle hash tree. Peer B, which only knows the root hash of the file after successfully connecting to Peer A, requests the first chunk of data, C0 in Figure 4. Peer A replies to Peer B by including in the datagram the following messages in this specific order: first, the three peak hashes of this particular file, the hashes of nodes 3, 9, and 12; second, the uncle hashes of C0, followed by the DATA message containing the actual content of C0. Upon receiving the peak hashes, Peer B checks them against the root hash determining that the file is 7 chunks long. To establish the exact size of the file, Peer B needs to request and retrieve the last chunk containing data, C6 in Figure 4. Once the last chunk has been retrieved and verified, Peer B concludes that it is 1018 bytes long, hence determining that the file is exactly 7162 bytes long.
作为一个例子，让我们考虑一个7162字节的文件，它符合7个1千字节的块，由对等体A分发。图4显示了相关的Mhelk哈希树。对等方B在成功连接到对等方A后才知道文件的根哈希，它请求第一个数据块，如图4中的C0。对等方A通过在数据报中按此特定顺序包含以下消息来回复对等方B：首先，此特定文件的三个峰值散列，节点3、9和12的散列；其次，对C0进行哈希，然后是包含C0实际内容的数据消息。在接收到峰值散列后，对等方B将其与根散列进行检查，确定文件的长度为7个块。为了确定文件的确切大小，对等方B需要请求并检索包含数据的最后一个块，如图4中的C6。一旦检索并验证了最后一个区块，对等方B就会得出结论，认为该区块的长度为1018字节，因此确定该文件的长度正好为7162字节。
The set of messages defined above can be used for live streaming as well. In a pull-based model, a live streaming injector can announce the chunks it generates via HAVE messages, and peers can retrieve them via REQUEST messages. Areas that need special attention are content authentication and chunk addressing (to achieve an infinite stream of chunks).
上面定义的消息集也可以用于实时流媒体。在基于pull的模型中，实时流式注入器可以通过HAVE消息宣布它生成的区块，对等方可以通过请求消息检索它们。需要特别注意的领域是内容认证和块寻址（以实现无限的块流）。
For live streaming, PPSPP supports two methods for a peer to authenticate the content it receives from another peer, called "Sign All" and "Unified Merkle Tree".
对于实时流媒体，PPSPP支持两种方法，即“全部签名”和“统一Merkle树”，供对等方对从另一对等方接收的内容进行身份验证。
In the "Sign All" method, the live injector signs each chunk of content using a private key. Upon receiving the chunk, peers check the signature using the corresponding public key obtained from a trusted source. Support for this method is OPTIONAL.
在“全部签名”方法中，live injector使用私钥对每个内容块进行签名。在收到区块后，对等方使用从可信来源获得的相应公钥检查签名。对此方法的支持是可选的。
In the "Unified Merkle Tree" method, PPSPP combines the Merkle Hash Tree scheme for static content with signatures to unify the video-on-demand and live streaming scenarios. The use of Merkle hash trees reduces the number of signing and verification operations, hence providing a similar signature amortization to the approach described in [SIGMCAST]. If PPSPP operates over the Internet, the "Unified Merkle Tree" method MUST be used. If the protocol operates in a benign environment, the "Unified Merkle Tree" method MAY be used. So this method is mandatory to implement.
在“统一Merkle树”方法中，PPSP将静态内容的Merkle哈希树方案与签名相结合，以统一视频点播和直播场景。Merkle哈希树的使用减少了签名和验证操作的数量，因此提供了与[SIGMCAST]中描述的方法类似的签名摊销。如果PPSP在互联网上运行，则必须使用“统一Merkle树”方法。如果协议在良性环境下运行，则可以使用“统一Merkle树”方法。因此，这种方法是必须实现的。
In both methods, the swarm ID consists of a public key encoded as in a DNSSEC DNSKEY resource record without Base64 encoding [RFC4034].
在这两种方法中，swarm ID由一个公钥组成，该公钥在DNSSEC DNSKEY资源记录中编码，没有Base64编码[RFC4034]。
In particular, the swarm ID consists of a 1-byte Algorithm field that identifies the public key's cryptographic algorithm and determines the format of the Public Key field that follows. The value of this Algorithm field is one of the values in the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry [IANADNSSECALGNUM]. The RSASHA1 [RFC4034], RSASHA256 [RFC5702], ECDSAP256SHA256 and ECDSAP384SHA384 [RFC6605] algorithms are mandatory to implement.
特别是，swarm ID由一个1字节算法字段组成，该字段标识公钥的加密算法，并确定随后的公钥字段的格式。此算法字段的值是“域名系统安全性（DNSSEC）算法编号”注册表[IANADNSSECALGNUM]中的值之一。必须实现RSASA1[RFC4034]、RSASA256[RFC5702]、ECDSAP256SHA256和ECDSAP384SHA384[RFC6605]算法。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algo Number(8)| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DNSSEC Public Key (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algo Number(8)| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DNSSEC Public Key (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the "Sign All" method, the live injector signs each chunk of content using a private key and peers, upon receiving the chunk, check the signature using the corresponding public key obtained from a trusted source. In particular, in PPSPP, the swarm ID of the live stream is that public key.
在“全部签名”方法中，live injector使用私钥对内容的每个区块进行签名，对等方在收到区块后，使用从可信源获得的相应公钥检查签名。特别是，在PPSPP中，实时流的swarm ID是该公钥。
A peer that wants to send a chunk of content creates a datagram that MUST contain a SIGNED_INTEGRITY message with the chunk's signature, followed by a DATA message with the actual chunk. If the SIGNED_INTEGRITY message and DATA message cannot be contained into a single datagram, because of a limitation on datagram size, the SIGNED_INTEGRITY message MUST be sent first in a separate datagram. The SIGNED_INTEGRITY message consists of the chunk specification, the timestamp, and the digital signature.
想要发送内容块的对等方创建一个数据报，该数据报必须包含一个带有块签名的完整性消息，然后是一个带有实际块的数据消息。如果由于数据报大小的限制，签名的\u完整性消息和数据消息不能包含在单个数据报中，则必须首先在单独的数据报中发送签名的\u完整性消息。签名的完整性消息由块规范、时间戳和数字签名组成。
The digital signature algorithm that is used, is determined by the Live Signature Algorithm protocol option, see Section 7.7. The signature is computed over a concatenation of the on-the-wire representation of the chunk specification, a 64-bit timestamp in NTP Timestamp format [RFC5905], and the chunk, in that order. The timestamp is the time signature that was made at the injector in UTC.
使用的数字签名算法由实时签名算法协议选项决定，见第7.7节。签名是按照块规范的在线表示、NTP时间戳格式[RFC5905]的64位时间戳和块的顺序串联计算的。时间戳是以UTC为单位在喷油器上进行的时间签名。
In this method, the chunks of content are used as the basis for a Merkle hash tree as for static content. However, because chunks are continuously generated, this tree is not static, but dynamic. As a result, the tree does not have a root hash, or, more precisely, it has a transient root hash. Therefore, a public key serves as swarm
在该方法中，内容块与静态内容一样，被用作Merkle哈希树的基础。但是，由于块是连续生成的，所以此树不是静态的，而是动态的。因此，树没有根哈希，或者更准确地说，它没有一个临时根哈希。因此，公钥充当swarm
ID of the content. It is used to digitally sign updates to the tree allowing peers to expand it based on trusted information using the following process.
内容的ID。它用于对树的更新进行数字签名，允许对等方使用以下过程基于可信信息扩展树。
The live injector generates a number of chunks, denoted NCHUNKS_PER_SIG, corresponding to fixed power of 2 (NCHUNKS_PER_SIG>=2), which are added as new leaves to the existing hash tree. As a result of this expansion, the hash tree contains a new subtree that is NCHUNKS_PER_SIG chunks wide at the base. The root of this new subtree is referred to as the munro of that subtree, and its hash as the munro hash of the subtree, illustrated in Figure 5. In this figure, node 5 is the new munro, labeled with a $ sign.
live injector生成大量块，表示为NCHUNKS_PER_SIG，对应于2的固定幂（NCHUNKS_PER_SIG>=2），这些块作为新叶添加到现有哈希树中。作为此扩展的结果，哈希树包含一个新的子树，该子树的底部为NCHUNKS_PER_SIG chunks宽。这个新子树的根称为该子树的munro，其散列称为子树的munro散列，如图5所示。在此图中，节点5是新的munro，标记为$符号。
3
/ \
/ \
/ \
1 5$
/ \ / \
0 2 4 6
3
/ \
/ \
/ \
1 5$
/ \ / \
0 2 4 6
Expanded live tree. With NCHUNKS_PER_SIG=2, node 5 is the munro for the new subtree spanning 4 and 6. Node 1 is the munro for the subtree spanning chunks 0 and 2, created in the previous iteration.
扩展活树。当NCHUNKS_PER_SIG=2时，节点5是跨越4和6的新子树的munro。节点1是在上一次迭代中创建的跨越块0和块2的子树的munro。
Figure 5
图5
Informally, the process now proceeds as follows. The injector signs only the munro hash of the new subtree using its private key. Next, the injector announces the existence of the new subtree to its peers using HAVE messages. When a peer, in response to the HAVE messages, requests a chunk from the new subtree, the injector first sends the signed munro hash corresponding to the requested chunk. Afterwards, similar to static content, the injector sends the uncle hashes necessary to verify that chunk, as in Section 5.1. In particular, the injector sends the uncle hashes necessary to verify the requested chunk against the munro hash. This differs from static content, where the verification takes places against the root hash. Finally, the injector sends the actual chunk.
非正式地说，这一进程现在进行如下。注入器使用其私钥仅对新子树的munro散列进行签名。接下来，注入器使用HAVE消息向其对等方宣布新子树的存在。当对等方响应HAVE消息，从新子树请求块时，注入器首先发送与请求的块相对应的签名munro散列。之后，与静态内容类似，注入器发送验证该块所需的散列，如第5.1节所示。特别是，注入器发送必要的叔叔散列，以对照munro散列验证请求的块。这与静态内容不同，静态内容根据根散列进行验证。最后，注入器发送实际数据块。
The receiving peer verifies the signature on the signed munro using the swarm ID (a public key) and updates its hash tree. As the peer now knows the munro hash is trusted, it can verify all chunks in the subtree against this munro hash, using the accompanying uncle hashes as in Section 5.1.
接收端使用swarm ID（公钥）验证已签名munro上的签名，并更新其哈希树。由于对等方现在知道munro散列是可信的，因此它可以使用5.1节中附带的叔叔散列，根据该munro散列验证子树中的所有块。
To illustrate this procedure, lets consider the next iteration in the process. The injector has generated the current tree shown in Figure 5, and it is connected to several peers that currently have the same tree and all posses chunks 0, 2, 4, and 6. When the injector generates two new chunks, NCHUNKS_PER_SIG=2, the hash tree expands as shown in Figure 6. The two new chunks, 8 and 10, extend the tree on the right side, and to accommodate them, a new root is created: node 7. As this tree is wider at the base than the actual number of chunks, there are currently two empty leaves. The munro node for the new subtree is 9, labeled with a $ sign.
为了说明这个过程，让我们考虑过程中的下一个迭代。注入器已经生成了如图5所示的当前树，并且它连接到当前具有相同树和所有拥有块0、2、4和6的多个对等方。当注入器生成两个新块时，NCHUNKS_PER_SIG=2，散列树将展开，如图6所示。两个新的块8和10扩展了右侧的树，为了容纳它们，创建了一个新的根：节点7。由于此树的底部比实际的块数宽，因此当前有两片空叶子。新子树的munro节点是9，标有$符号。
7
/ \
/ \
/ \
/ \
3 11
/ \ / \
/ \ / \
/ \ / \
1 5 9$ 13
/ \ / \ / \ / \
0 2 4 6 8 10 E E
7
/ \
/ \
/ \
/ \
3 11
/ \ / \
/ \ / \
/ \ / \
1 5 9$ 13
/ \ / \ / \ / \
0 2 4 6 8 10 E E
Expanded live tree. With NCHUNKS_PER_SIG=2, node 9 is the munro of the newly added subtree spanning chunks 8 and 10.
扩展活树。当NCHUNKS_PER_SIG=2时，节点9是新添加的子树的munro，该子树跨越块8和块10。
Figure 6
图6
The injector now needs to inform its peers of the updated tree, communicating the addition of the new munro hash 9. Hence, it sends a HAVE message with a chunk specification for nodes 8 + 10 to its peers. As a response, Peer P requests the newly created chunk, e.g., chunk 8, from the injector by sending a REQUEST message. In reply, the injector sends the signed munro hash of node 9 as an INTEGRITY message with the hash of node 9, and a SIGNED_INTEGRITY message with the signature of the hash of node 9. These messages are followed by an INTEGRITY message with the hash of node 10 and a DATA message with chunk 8.
注入器现在需要将更新后的树通知其对等方，从而通知添加新的munro散列9。因此，它向其对等方发送具有节点8+10的区块规范的HAVE消息。作为响应，对等P通过发送请求消息从注入器请求新创建的区块，例如区块8。作为响应，注入器将节点9的签名munro散列作为完整性消息发送，其中散列为节点9，签名为节点9的散列。这些消息之后是一条完整性消息，其哈希值为节点10，数据消息为块8。
Upon receipt, Peer P verifies the signature of the munro and expands its view of the tree. Next, the peer computes the hash of chunk 8 and combines it with the received hash of node 10, computing the expected hash of node 9. He can then verify the content of chunk 8 by comparing the computed hash of node 9 with the munro hash of the same node he just received; hence, Peer P has successfully verified the integrity of chunk 8.
收到后，对等方P验证munro的签名并扩展其树视图。接下来，对等方计算区块8的散列，并将其与节点10的接收散列相结合，计算节点9的预期散列。然后，他可以通过将节点9的计算哈希与他刚刚收到的同一节点的munro哈希进行比较来验证区块8的内容；因此，对等方P已成功验证区块8的完整性。
This procedure requires just one signing operation for every NCHUNKS_PER_SIG chunks created, and one verification operation for every NCHUNKS_PER_SIG received, making it much cheaper than "Sign All". A receiving peer does additionally need to check one or more hashes per chunk via the Merkle Hash Tree scheme, but this has less hardware requirements than a signature verification for every chunk. This approach is similar to signature amortization via Merkle Tree Chaining [SIGMCAST]. The downside of this scheme is in an increased latency. A peer cannot download the new chunks until the injector has computed the signature and announced the subtree. A peer MUST check the signature before forwarding the chunks to other peers [POLLIVE].
此过程只需要对创建的每个NCHUNKS_PER_SIG块执行一次签名操作，并对接收到的每个NCHUNKS_PER_SIG执行一次验证操作，这比“全部签名”便宜得多。另外，接收端确实需要通过Merkle哈希树方案检查每个区块的一个或多个哈希，但这比每个区块的签名验证具有更少的硬件要求。这种方法类似于通过Merkle树链接[SIGMCAST]进行的签名摊销。此方案的缺点是延迟增加。在注入器计算签名并宣布子树之前，对等方无法下载新块。对等方必须在将区块转发给其他对等方之前检查签名[POLLIVE]。
The number of chunks per signature NCHUNKS_PER_SIG MUST be a fixed power of 2 for simplicity. NCHUNKS_PER_SIG MUST be larger than 1 for performance reasons. There are two related factors to consider when choosing a value for NCHUNKS_PER_SIG. First, the allowed CPU load on clients due to signature verifications, given the expected bitrate of the stream. To achieve a low CPU load in a high bitrate stream, NCHUNKS_PER_SIG should be high. Second, the effect on latency, which increases when NCHUNKS_PER_SIG gets higher, as just discussed. Note how the procedure does not preclude the use of variable-size chunks.
为了简单起见，每个签名的块数NCHUNKS\u per\u SIG必须是2的固定幂。出于性能原因，NCHUNKS_PER_SIG必须大于1。当选择nCukssPisisig的值时，有两个相关的因素要考虑。首先，给定流的预期比特率，由于签名验证，客户端上允许的CPU负载。要在高比特率流中实现较低的CPU负载，NCHUNKS_PER_SIG应该较高。第二，对延迟的影响，如前所述，当NCHUNKS_PER_SIG变得更高时，延迟会增加。请注意，该过程如何不排除使用可变大小的块。
This method of integrity verification provides an additional benefit. If the system includes some peers that saved the complete broadcast, as soon as the broadcast ends, the content is available as a video-on-demand download using the now stabilized tree and the final root hash as swarm identifier. Peers that saved all the chunks, can now announce the root hash to the tracking infrastructure and instantly seed the content.
这种完整性验证方法提供了额外的好处。如果系统包括一些保存了完整广播的对等方，则一旦广播结束，内容就可以作为视频点播下载，使用现在稳定的树和最终根哈希作为swarm标识符。保存了所有区块的对等方现在可以向跟踪基础设施宣布根哈希，并立即为内容播种。
The digital signature algorithm used is determined by the Live Signature Algorithm protocol option, see Section 7.7. The signature is computed over a concatenation of the on-the-wire representation of the chunk specification of the munro node (see Section 6.1.2.1), a timestamp in 64-bit NTP Timestamp format [RFC5905], and the hash associated with the munro node, in that order. The timestamp is the time signature that was made at the injector in UTC.
使用的数字签名算法由实时签名算法协议选项决定，见第7.7节。签名通过munro节点块规范的在线表示（见第6.1.2.1节）、64位NTP时间戳格式[RFC5905]的时间戳以及与munro节点相关联的散列按该顺序串联计算。时间戳是以UTC为单位在喷油器上进行的时间签名。
Formally, the injector MUST NOT send a HAVE message for chunks in the new subtree until it has computed the signed munro hash for that subtree.
从形式上讲，注入器必须先计算出新子树中的签名munro哈希，然后才能为该子树中的块发送HAVE消息。
When Peer B requests a chunk C from Peer A (either the injector or another peer), and Peer A decides to reply, it must do so as follows. First, Peer A MUST send an INTEGRITY message with the chunk specification for the munro of chunk C and the munro's hash, followed by a SIGNED_INTEGRITY message with the chunk specification for the munro, timestamp, and its signature in a single datagram, unless Peer B indicated earlier in the exchange that it already possess a chunk with the same corresponding munro (by means of HAVE or ACK messages). Following these two messages (if any), Peer A MUST send the necessary missing uncles hashes needed for verifying the chunk against its munro hash, and the chunk itself, as described in Section 5.4, sharing datagrams if possible.
当对等方B从对等方a（注入器或另一个对等方）请求块C，并且对等方a决定答复时，它必须按如下方式进行。首先，对等方A必须发送一条完整性消息，其中包含块C的munro的块规范和munro的散列，然后是一条带签名的完整性消息，其中包含munro的块规范、时间戳及其在单个数据报中的签名，除非对等方B在交换的前面指出它已经拥有具有相同对应munro的块（通过HAVE或ACK消息）。在这两条消息（如果有）之后，对等方A必须发送必要的缺失uncles散列，以根据其munro散列验证区块，并发送区块本身，如第5.4节所述，如果可能，共享数据报。
When a peer tunes in to a live stream, it has to determine what is the last chunk the injector has generated. To facilitate this process in the Unified Merkle Tree scheme, each peer shares its knowledge about the injector's chunks with the others by exchanging their latest signed munro hashes, as follows.
当对等机调到实时流时，它必须确定注入器生成的最后一个区块是什么。为了在统一Merkle树方案中促进此过程，每个对等方通过交换其最新签名的munro散列，与其他方共享其关于注入器块的知识，如下所示。
Recall that, in PPSPP, when Peer A initiates a channel with Peer B, Peer A sends a first datagram with a HANDSHAKE message, and Peer B responds with a second datagram also containing a HANDSHAKE message (see Section 3.1). When Peer A sends a third datagram to Peer B, and it is received by Peer B, both peers know that the other is listening on its stated transport address. Peer B is then allowed to send heavy payload like DATA messages in the fourth datagram. Peer A can already safely do that in the third datagram.
回想一下，在PPSPP中，当对等方A与对等方B发起信道时，对等方A发送带有握手消息的第一个数据报，对等方B使用也包含握手消息的第二个数据报进行响应（参见第3.1节）。当对等方A向对等方B发送第三个数据报，并且对等方B接收到该数据报时，两个对等方都知道另一方正在侦听其声明的传输地址。然后，允许对等方B在第四个数据报中发送重负载数据消息。对等方A已经可以在第三个数据报中安全地执行此操作。
In the Unified Merkle Tree scheme, Peer A MUST send its rightmost signed munro hash to Peer B in the third datagram, and in any subsequent datagrams to Peer B, until Peer B indicates that it possess a chunk with the same corresponding munro or a more recent munro (by means of a HAVE or ACK message). Peer B may already have indicated this fact by means of HAVE messages in the second datagram. Conversely, when Peer B sends the fourth datagram or any subsequent datagram to Peer A, Peer B MUST send its rightmost signed munro hash, unless Peer A indicated knowledge of it or more recent munros. The rightmost signed munro hash of a peer is defined as the munro hash signed by the injector of the rightmost subtree of width NCHUNKS_PER_SIG chunks in the peer's Merkle hash tree. Peer A MUST
在统一Merkle树方案中，对等方A必须向第三个数据报中的对等方B发送其最右边的签名munro哈希，并在任何后续数据报中向对等方B发送，直到对等方B指示其拥有具有相同对应munro或更近munro的区块（通过HAVE或ACK消息）。对等方B可能已经通过第二数据报中的have消息指示了这一事实。相反，当对等方B向对等方A发送第四个数据报或任何后续数据报时，对等方B必须发送其最右边的签名munro哈希，除非对等方A指示知道它或最近的munro。对等方最右边的有符号munro哈希被定义为由对等方Merkle哈希树中最右边的宽度NCHUNKS_PER_SIG块子树的注入器签名的munro哈希。同行是必须的
NOT send the signed munro hash in the first datagram of the HANDSHAKE procedure and Peer B MUST NOT send it in the second datagram as it is considered heavy payload.
不在握手过程的第一个数据报中发送签名的munro哈希，对等方B不得在第二个数据报中发送，因为它被视为重负载。
When a peer receives a SIGNED_INTEGRITY message with a signed munro hash but the timestamp is too old, the peer MUST discard the message. Otherwise, it SHOULD use the signed munro to update its hash tree and pick a tune-in in the live stream. A peer may use the information from multiple peers to pick the tune-in point.
当对等方收到带有签名munro哈希的签名\u完整性消息，但时间戳太旧时，对等方必须丢弃该消息。否则，它应该使用已签名的munro更新其哈希树，并在实时流中选择一个调子。对等方可以使用来自多个对等方的信息来选择接入点。
As a live broadcast progresses, a peer may want to discard the chunks that it already played out. Ideally, other peers should be aware of this fact so that they will not try to request these chunks from this peer. This could happen in scenarios where live streams may be paused by viewers, or viewers are allowed to start late in a live broadcast (e.g., start watching a broadcast at 20:35 when it actually began at 20:30).
随着直播的进行，对等方可能希望丢弃已经播放的块。理想情况下，其他对等方应该知道这一事实，这样他们就不会试图从该对等方请求这些块。这可能发生在观众可能暂停直播流，或允许观众在直播中延迟开始的情况下（例如，在20:35开始观看广播，而实际上是在20:30开始）。
PPSPP provides a simple solution for peers to stay up to date with the chunk availability of a discarding peer. A discarding peer in a live stream MUST enable the Live Discard Window protocol option, specifying how many chunks/bytes it caches before the last chunk/byte it advertised as being available (see Section 7.9). Its peers SHOULD apply this number as a sliding window filter over the peer's chunk availability as conveyed via its HAVE messages.
PPSPP为对等方提供了一个简单的解决方案，使其能够及时了解丢弃对等方的数据块可用性。实时流中的丢弃对等方必须启用“实时丢弃窗口协议”选项，指定在其公布为可用的最后一个块/字节之前，它缓存了多少块/字节（请参阅第7.9节）。其对等方应将此数字作为滑动窗口过滤器应用于通过其HAVE消息传输的对等方区块可用性。
Three factors are important when deciding for an appropriate value for this option: the desired amount of playback buffer for peers, the bitrate of the stream, and the available resources of the peer. Consider the case of a fresh peer joining the stream. The size of the discard window of the peers it connects to influences how much data it can directly download to establish its prebuffer. If the window is smaller than the desired buffer, the fresh peer has to wait until the peers downloaded more of the stream before it can start playback. As media buffers are generally specified in terms of a number of seconds, the size of the discard window is also related to the (average) bitrate of the stream. Finally, if a peer has few resources to store chunks and metadata, it should choose a small discard window.
在决定此选项的适当值时，三个因素很重要：对等点的所需播放缓冲区量、流的比特率和对等点的可用资源。考虑一个新的对等体加入流的情况。它所连接的对等方的丢弃窗口的大小会影响它可以直接下载多少数据以建立其预缓冲区。如果窗口小于所需的缓冲区，则新的对等方必须等到对等方下载了更多的流后才能开始播放。由于媒体缓冲区通常以秒数指定，丢弃窗口的大小也与流的（平均）比特率有关。最后，如果对等方几乎没有资源来存储块和元数据，那么它应该选择一个小的丢弃窗口。
The HANDSHAKE message in PPSPP can contain the following protocol options. Unless stated otherwise, a protocol option consists of an 8-bit code followed by an 8-bit value. Larger values are all encoded
PPSP中的握手消息可以包含以下协议选项。除非另有说明，协议选项由8位代码和8位值组成。较大的值都被编码
big-endian. Each protocol option is explained in the following subsections. The list of protocol options MUST be sorted on code value (ascending) in a HANDSHAKE message.
大恩迪安。每个协议选项将在以下小节中解释。协议选项列表必须按握手消息中的代码值（升序）排序。
+--------+-------------------------------------+
| Code | Description |
+--------+-------------------------------------+
| 0 | Version |
| 1 | Minimum Version |
| 2 | Swarm Identifier |
| 3 | Content Integrity Protection Method |
| 4 | Merkle Hash Tree Function |
| 5 | Live Signature Algorithm |
| 6 | Chunk Addressing Method |
| 7 | Live Discard Window |
| 8 | Supported Messages |
| 9 | Chunk Size |
| 10-254 | Unassigned |
| 255 | End Option |
+--------+-------------------------------------+
+--------+-------------------------------------+
| Code | Description |
+--------+-------------------------------------+
| 0 | Version |
| 1 | Minimum Version |
| 2 | Swarm Identifier |
| 3 | Content Integrity Protection Method |
| 4 | Merkle Hash Tree Function |
| 5 | Live Signature Algorithm |
| 6 | Chunk Addressing Method |
| 7 | Live Discard Window |
| 8 | Supported Messages |
| 9 | Chunk Size |
| 10-254 | Unassigned |
| 255 | End Option |
+--------+-------------------------------------+
Table 2: PPSPP Options
表2:PPSP选项
A peer MUST conclude the list of protocol options with the end option. Subsequent octets should be considered protocol messages. The code for the end option is 255, and unlike others, it has no value octet, so the option's length is 1 octet.
对等方必须以结束选项结束协议选项列表。后续八位字节应视为协议消息。end选项的代码是255，与其他选项不同，它没有值八位字节，因此该选项的长度是1个八位字节。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+
A peer MUST include the maximum version of the PPSPP it supports as the first protocol option in the list. The code for this option is 0. Defined values are listed in Table 3.
对等方必须将其支持的PPSP的最大版本作为列表中的第一个协议选项。此选项的代码为0。表3列出了定义值。
+---------+----------------------------------------+
| Version | Description |
+---------+----------------------------------------+
| 0 | Reserved |
| 1 | Protocol as described in this document |
| 2-255 | Unassigned |
+---------+----------------------------------------+
+---------+----------------------------------------+
| Version | Description |
+---------+----------------------------------------+
| 0 | Reserved |
| 1 | Protocol as described in this document |
| 2-255 | Unassigned |
+---------+----------------------------------------+
Table 3: PPSPP Version Numbers
表3:PPSP版本号
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Version (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Version (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a peer initiates the handshake, it MUST include the minimum version of the PPSPP it supports in the list of protocol options, following the min/max versioning scheme defined in [RFC6709], Section 4.1, strategy 5. The code for this option is 1. Defined values are listed in Table 3.
对等方发起握手时，必须按照[RFC6709]第4.1节策略5中定义的最小/最大版本控制方案，在协议选项列表中包含其支持的PPSP的最低版本。此选项的代码为1。表3列出了定义值。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Min. Ver. (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Min. Ver. (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a peer initiates the handshake, it MUST include a single swarm identifier option. If the peer is not the initiator, it MAY include a swarm identifier option, as an end-to-end check. This option has the following structure:
当一个对等方发起握手时，它必须包含一个swarm标识符选项。如果对等方不是发起方，它可能包括一个swarm标识符选项，作为端到端检查。此选项具有以下结构：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Swarm ID Length (16) | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Swarm Identifier (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Swarm ID Length (16) | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Swarm Identifier (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Swarm ID Length field contains the length of the single Swarm Identifier that follows in bytes. The Length field is 16 bits wide to allow for large public keys as identifiers in live streaming.
Swarm ID Length字段包含单个Swarm标识符的长度，以字节为单位。长度字段为16位宽，允许在实时流媒体中使用大公钥作为标识符。
Each PPSPP peer knows the IDs of the swarms it joins, so this information can be immediately verified upon receipt.
每个PPSP对等方都知道其加入的群集的ID，因此在收到此信息后可以立即验证此信息。
A peer MUST include the content integrity method used by a swarm. The code for this option is 3. Defined values are listed in Table 4.
对等方必须包括swarm使用的内容完整性方法。此选项的代码为3。表4列出了定义值。
+--------+-------------------------+
| Method | Description |
+--------+-------------------------+
| 0 | No integrity protection |
| 1 | Merkle Hash Tree |
| 2 | Sign All |
| 3 | Unified Merkle Tree |
| 4-255 | Unassigned |
+--------+-------------------------+
+--------+-------------------------+
| Method | Description |
+--------+-------------------------+
| 0 | No integrity protection |
| 1 | Merkle Hash Tree |
| 2 | Sign All |
| 3 | Unified Merkle Tree |
| 4-255 | Unassigned |
+--------+-------------------------+
Table 4: PPSPP Content Integrity Protection Methods
表4:PPSP内容完整性保护方法
The "Merkle Hash Tree" method is the default for static content, see Section 5.1. "Sign All", and "Unified Merkle Tree" are for live content, see Section 6.1, with "Unified Merkle Tree" being the default.
“Merkle哈希树”方法是静态内容的默认方法，请参见第5.1节。“全部签名”和“统一Merkle树”用于直播内容，见第6.1节，默认为“统一Merkle树”。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| CIPM (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| CIPM (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the content integrity protection method is "Merkle Hash Tree", this option defining which hash function is used for the tree MUST be included. The code for this option is 4. Defined values are listed in Table 5 (see [FIPS180-4] for the function semantics).
当内容完整性保护方法为“Merkle Hash Tree”时，必须包含此选项，该选项定义用于树的哈希函数。此选项的代码为4。表5列出了定义值（函数语义见[FIPS180-4]）。
+----------+-------------+
| Function | Description |
+----------+-------------+
| 0 | SHA-1 |
| 1 | SHA-224 |
| 2 | SHA-256 |
| 3 | SHA-384 |
| 4 | SHA-512 |
| 5-255 | Unassigned |
+----------+-------------+
+----------+-------------+
| Function | Description |
+----------+-------------+
| 0 | SHA-1 |
| 1 | SHA-224 |
| 2 | SHA-256 |
| 3 | SHA-384 |
| 4 | SHA-512 |
| 5-255 | Unassigned |
+----------+-------------+
Table 5: PPSPP Merkle Hash Functions
表5:PPSPP Merkle哈希函数
Implementations MUST support SHA-1 (see Section 12.5) and SHA-256. SHA-256 is the default.
实施必须支持SHA-1（见第12.5节）和SHA-256。默认为SHA-256。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| MHF (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| MHF (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the content integrity protection method is "Sign All" or "Unified Merkle Tree", this option MUST be defined. The code for this option is 5. The 8-bit value of this option is one of the values listed in the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry [IANADNSSECALGNUM]. The RSASHA1 [RFC4034], RSASHA256 [RFC5702], ECDSAP256SHA256 and ECDSAP384SHA384 [RFC6605] algorithms are mandatory to implement. Default is ECDSAP256SHA256.
当内容完整性保护方法为“全部签名”或“统一Merkle树”时，必须定义此选项。此选项的代码为5。此选项的8位值是“域名系统安全（DNSSEC）算法编号”注册表[IANADNSSECALGNUM]中列出的值之一。必须实现RSASA1[RFC4034]、RSASA256[RFC5702]、ECDSAP256SHA256和ECDSAP384SHA384[RFC6605]算法。默认值为ECDSAP256SHA256。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 1| LSA (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 1| LSA (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer MUST include the chunk addressing method it uses. The code for this option is 6. Defined values are listed in Table 6.
对等方必须包括它使用的块寻址方法。此选项的代码为6。表6列出了定义值。
+--------+---------------------+
| Method | Description |
+--------+---------------------+
| 0 | 32-bit bins |
| 1 | 64-bit byte ranges |
| 2 | 32-bit chunk ranges |
| 3 | 64-bit bins |
| 4 | 64-bit chunk ranges |
| 5-255 | Unassigned |
+--------+---------------------+
+--------+---------------------+
| Method | Description |
+--------+---------------------+
| 0 | 32-bit bins |
| 1 | 64-bit byte ranges |
| 2 | 32-bit chunk ranges |
| 3 | 64-bit bins |
| 4 | 64-bit chunk ranges |
| 5-255 | Unassigned |
+--------+---------------------+
Table 6: PPSPP Chunk Addressing Methods
表6:PPSPP块寻址方法
Implementations MUST support "32-bit chunk ranges" and "64-bit chunk ranges". Default is "32-bit chunk ranges".
实现必须支持“32位区块范围”和“64位区块范围”。默认值为“32位块范围”。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 0| CAM (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 0| CAM (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer in a live swarm MUST include the discard window it uses. The code for this option is 7. The unit of the discard window depends on the chunk addressing method used, see Table 6. For bins and chunk ranges, it is a number of chunks; for byte ranges, it is a number of bytes. Its data type is the same as for a bin, or one value in a range specification. In other words, its value is a 32-bit or 64-bit integer in big-endian format. If this option is used, the Chunk Addressing Method MUST appear before it in the list. This option has the following structure:
活动群中的对等方必须包含其使用的丢弃窗口。此选项的代码为7。discard窗口的单位取决于所使用的区块寻址方法，请参见表6。对于BIN和chunk Range，它是大量的chunk；对于字节范围，它是一个字节数。其数据类型与bin或范围规范中的一个值相同。换句话说，它的值是一个大端格式的32位或64位整数。如果使用此选项，则块寻址方法必须出现在列表中它的前面。此选项具有以下结构：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1| Live Discard Window (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1| Live Discard Window (32 or 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer that does not, under normal circumstances, discard chunks MUST set this option to the special value 0xFFFFFFFF (32-bit) or 0xFFFFFFFFFFFFFFFF (64-bit). For example, peers that record a complete broadcast to offer it directly as a static file after the broadcast ends use these values (see Section 6.1.2). Section 6.2 explains how to determine a value for this option.
在正常情况下，不丢弃块的对等方必须将此选项设置为特殊值0xFFFFFF（32位）或0xFFFFFFFFFFFF（64位）。例如，记录完整广播以在广播结束后直接作为静态文件提供的对等方使用这些值（见第6.1.2节）。第6.2节解释了如何确定该选项的值。
Peers may support just a subset of the PPSPP messages. For example, peers running over TCP may not accept ACK messages or peers used with a centralized tracking infrastructure may not accept PEX messages. For these reasons, peers who support only a proper subset of the PPSPP messages MUST signal which subset they support by means of this protocol option. The code for this option is 8. The value of this option is a length octet (SupMsgLen) indicating the length, in bytes, of the compressed bitmap that follows.
对等方可能只支持PPSP消息的一个子集。例如，通过TCP运行的对等方可能不接受ACK消息，或者与集中跟踪基础设施一起使用的对等方可能不接受PEX消息。出于这些原因，仅支持PPSPP消息的适当子集的对等方必须通过此协议选项指示其支持的子集。此选项的代码为8。此选项的值是一个长度八位字节（SupMsgLen），表示随后压缩位图的长度（以字节为单位）。
The set of messages supported can be derived from the compressed bitmap by padding it with bytes of value 0 until it is 256 bits in length. Then, a 1 bit in the resulting bitmap at position X (numbering left to right) corresponds to support for message type X, see Table 7. In other words, to construct the compressed bitmap, create a bitmap with a 1 for each message type supported and a 0 for a message type that is not, store it as an array of bytes, and truncate it to the last non-zero byte. An example of the first 16 bits of the compressed bitmap for a peer supporting every message except ACKs and PEXs is 11011001 11110000.
通过使用值为0的字节填充压缩位图，直到其长度为256位，可以从压缩位图中导出支持的消息集。然后，结果位图中位置X处的1位（从左到右编号）对应于对消息类型X的支持，见表7。换句话说，要构造压缩位图，请创建一个位图，每个支持的消息类型使用1，不支持的消息类型使用0，将其存储为字节数组，并将其截断为最后一个非零字节。对等方支持除ACK和PEX之外的每条消息的压缩位图的前16位示例为11011001 11110000。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| SupMsgLen (8) | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Supported Messages Bitmap (variable, max 256) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| SupMsgLen (8) | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Supported Messages Bitmap (variable, max 256) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer in a swarm MUST include the chunk size the swarm uses. The code for this option is 9. Its value is a 32-bit integer denoting the size of the chunks in bytes in big-endian format. When variable chunk sizes are used, this option MUST be set to the special value 0xFFFFFFFF. Section 8.1 explains how content publishers can determine a value for this option.
群中的对等方必须包括群使用的块大小。此选项的代码为9。它的值是一个32位整数，表示以字节为单位的big-endian格式的块的大小。使用可变块大小时，此选项必须设置为特殊值0xFFFFFF。第8.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| Chunk Size (32) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| Chunk Size (32) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+
PPSPP implementations MUST use UDP as transport protocol and MUST use LEDBAT for congestion control [RFC6817]. Using LEDBAT enables PPSPP to serve the content after playback (seeding) without disrupting the user who may have moved to different tasks that use its network connection. Future PPSPP versions can also run over other transport protocols or use different congestion control algorithms.
PPSP实现必须使用UDP作为传输协议，并且必须使用LEDBAT进行拥塞控制[RFC6817]。使用LEDBAT可使PPSPP在播放（种子设定）后提供内容，而不会中断可能已转移到使用其网络连接的不同任务的用户。未来的PPSP版本也可以运行在其他传输协议上，或使用不同的拥塞控制算法。
In general, a UDP datagram containing PPSPP messages SHOULD fit inside a single IP packet, so its maximum size depends on the MTU of the network. If the UDP datagram does not fit, its chance of getting lost in the network increases as the loss of a single fragment of the datagram causes the loss of the complete datagram.
通常，包含PPSPP消息的UDP数据报应适合于单个IP数据包，因此其最大大小取决于网络的MTU。如果UDP数据报不适合，则其在网络中丢失的可能性会增加，因为丢失数据报的单个片段会导致丢失完整的数据报。
The largest message in a PPSPP datagram is the DATA message carrying a chunk of content. So the (maximum) size of a chunk to choose for a particular swarm depends primarily on the expected MTU. The chunk size should be chosen such that a chunk and its required INTEGRITY messages can generally be carried inside a single datagram, following the Atomic Datagram Principle (Section 5.3). Other considerations are the hardware capabilities of the peers. Having large chunks and therefore less chunks per megabyte of content reduces processing costs. The chunk addressing schemes can all work with different chunk sizes, see Section 4.
PPSPP数据报中最大的消息是承载内容块的数据消息。因此，为特定群选择的块的（最大）大小主要取决于预期的MTU。应根据原子数据报原则（第5.3节），选择块大小，以便块及其所需的完整性消息通常可以在单个数据报中传输。其他考虑因素是对等方的硬件能力。拥有大数据块，因此每兆字节内容的数据块更少，可以降低处理成本。区块寻址方案都可以使用不同的区块大小，请参见第4节。
The RECOMMENDED approach is to use fixed-size chunks of 1024 bytes, as this size has a high likelihood of traveling end-to-end across the Internet without any fragmentation. In particular, with this size, a UDP datagram with a DATA message can be transmitted as a single IP packet over an Ethernet network with 1500-byte frames.
推荐的方法是使用1024字节的固定大小的块，因为这种大小很可能在互联网上端到端传输而没有任何碎片。特别是，通过这种大小，具有数据消息的UDP数据报可以作为单个IP包在具有1500字节帧的以太网网络上传输。
A PPSPP implementation MAY use a variant of the Packetization Layer Path MTU Discovery (PLPMTUD), described in [RFC4821], for discovering the optimal MTU between sender and destination. As in PLPMTUD, progressively larger probing packets are used to detect the optimal MTU for a given path. However, in PPSPP, probe packets SHOULD contain actual messages, in particular, multiple DATA messages. By using actual DATA messages as probe packets, the returning ACK messages will confirm the probe delivery, effectively updating the MTU estimate on both ends of the link. To be able to scale up probe packets with sensible increments, a minimum chunk size of 512 bytes SHOULD be used. Smaller chunk sizes lead to an inefficient protocol. An implication is that PPSPP supports datagrams over IPv4 of 576 bytes or more only. This variant is not mandatory to implement.
PPSPP实现可以使用[RFC4821]中描述的包化层路径MTU发现（PLPMTUD）的变体来发现发送方和目的地之间的最佳MTU。与PLPMTUD中一样，使用逐渐增大的探测数据包来检测给定路径的最佳MTU。然而，在PPSPP中，探测包应该包含实际消息，特别是多个数据消息。通过使用实际数据消息作为探测数据包，返回的ACK消息将确认探测传递，从而有效地更新链路两端的MTU估计。为了能够以合理的增量放大探测数据包，应使用512字节的最小块大小。较小的块大小会导致协议效率低下。这意味着PPSPP只支持通过IPv4传输576字节或更多的数据报。此变体不是强制实现的。
The chunk size used for a particular swarm, or the fact that it is variable, MUST be part of the swarm's metadata (which then minimally consists of the swarm ID and the chunk nature and size).
用于特定swarm的数据块大小，或者说它是可变的，必须是swarm元数据的一部分（元数据至少由swarm ID和数据块的性质和大小组成）。
When using UDP, the abstract datagram described above corresponds directly to a UDP datagram. Most messages within a datagram have a fixed length, which generally depends on the type of the message. The first byte of a message denotes its type. The currently defined types are:
使用UDP时，上述抽象数据报直接对应于UDP数据报。数据报中的大多数消息都有固定的长度，这通常取决于消息的类型。消息的第一个字节表示其类型。当前定义的类型有：
+----------+------------------+
| Msg Type | Description |
+----------+------------------+
| 0 | HANDSHAKE |
| 1 | DATA |
| 2 | ACK |
| 3 | HAVE |
| 4 | INTEGRITY |
| 5 | PEX_RESv4 |
| 6 | PEX_REQ |
| 7 | SIGNED_INTEGRITY |
| 8 | REQUEST |
| 9 | CANCEL |
| 10 | CHOKE |
| 11 | UNCHOKE |
| 12 | PEX_RESv6 |
| 13 | PEX_REScert |
| 14-254 | Unassigned |
| 255 | Reserved |
+----------+------------------+
+----------+------------------+
| Msg Type | Description |
+----------+------------------+
| 0 | HANDSHAKE |
| 1 | DATA |
| 2 | ACK |
| 3 | HAVE |
| 4 | INTEGRITY |
| 5 | PEX_RESv4 |
| 6 | PEX_REQ |
| 7 | SIGNED_INTEGRITY |
| 8 | REQUEST |
| 9 | CANCEL |
| 10 | CHOKE |
| 11 | UNCHOKE |
| 12 | PEX_RESv6 |
| 13 | PEX_REScert |
| 14-254 | Unassigned |
| 255 | Reserved |
+----------+------------------+
Table 7: PPSPP Message Types
表7:PPSP消息类型
Furthermore, integers are serialized in network (big-endian) byte order. So, consider the example of a HAVE message (Section 3.2) using bin chunk addressing. It has a message type of 0x03 and a payload of a bin number, a 4-byte integer (say, 1); hence, its on-the-wire representation for UDP can be written in hex as "0300000001".
此外，整数以网络（大端）字节顺序序列化。因此，考虑使用bin块寻址的有消息（第3.2节）的示例。它的消息类型为0x03，有效负载为bin编号，即4字节整数（例如，1）；因此，UDP的在线表示可以用十六进制写成“0300000001”。
All messages are idempotent or recognizable as duplicates. Idempotent means that processing a message more than once does not lead to a different state from if it was processed just once. In particular, a peer MAY resend DATA, ACK, HAVE, INTEGRITY, PEX_*, SIGNED_INTEGRITY, REQUEST, CANCEL, CHOKE, and UNCHOKE messages without problems when loss is suspected. When a peer resends a
所有消息都是幂等的或可识别为重复的。幂等意味着多次处理消息不会导致与仅处理一次消息不同的状态。特别地，当怀疑丢失时，对等方可以毫无问题地重新发送数据、ACK、HAVE、INTEGRITY、PEX_*、SIGNED_uintegrity、REQUEST、CANCEL、CHOKE和UNCHOKE消息。当对等方重新发送
HANDSHAKE message, it can be recognized as duplicate by the receiver, because it already recorded the first connection attempt, and be dealt with.
握手消息，接收方可以将其识别为重复消息，因为它已经记录了第一次连接尝试，并将被处理。
As described in Section 3.11, PPSPP uses a multiplexing scheme, called channels, to allow multiple swarms to use the same UDP port. In the UDP encapsulation, each datagram from Peer A to Peer B is prefixed with the channel ID allocated by Peer B. The peers learn about each other's channel ID during the handshake as explained in Section 3.1.1. A channel ID consists of 4 bytes and MUST be generated following the requirements in [RFC4960] (Section 5.1.3).
如第3.11节所述，PPSP使用称为通道的多路复用方案，允许多个群集使用同一UDP端口。在UDP封装中，从对等方A到对等方B的每个数据报都以对等方B分配的信道ID作为前缀。对等方在握手过程中了解彼此的信道ID，如第3.1.1节所述。通道ID由4个字节组成，必须按照[RFC4960]（第5.1.3节）中的要求生成。
A channel is established with a handshake. To start a handshake, the initiating peer needs to know the swarm metadata, defined in Section 3.1 and the IP address and UDP port of a peer. A datagram containing a HANDSHAKE message then looks as follows:
通过握手建立信道。要开始握手，发起的对等方需要知道第3.1节中定义的swarm元数据以及对等方的IP地址和UDP端口。包含握手消息的数据报如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Channel ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Source Channel ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Protocol Options ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Channel ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Source Channel ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Protocol Options ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
哪里：
Destination Channel ID:
目标频道ID：
If the datagram is sent by the initiating peer, then it MUST be an all-zeros channel ID.
如果数据报是由发起的对等方发送的，那么它必须是一个全零通道ID。
If the datagram is sent by the responding peer, then it MUST consist of the Source Channel ID from the sender's HANDSHAKE message.
如果数据报是由响应的对等方发送的，那么它必须包含来自发送方握手消息的源通道ID。
The octet 0x00: The HANDSHAKE message type
八位字节0x00：握手消息类型
Source Channel ID: A locally unused channel ID
源通道ID：本地未使用的通道ID
Protocol Options: A list of protocol options encoding the swarm's metadata, as defined in Section 7.
协议选项：编码swarm元数据的协议选项列表，如第7节所定义。
A peer SHOULD explicitly close a channel by sending a HANDSHAKE message that MUST contain an all zeros Source Channel ID and a list of protocol options. The list MUST either be empty or contain the maximum version number the sender supports, following the min/max versioning scheme defined in [RFC6709], Section 4.1.
对等方应通过发送握手消息明确关闭通道，握手消息必须包含全零源通道ID和协议选项列表。根据[RFC6709]第4.1节中定义的最小/最大版本控制方案，列表必须为空或包含发送方支持的最大版本号。
A HAVE message (type 0x03) consists of a single chunk specification that states that the sending peer has those chunks and successfully checked their integrity. The single chunk specification represents a consecutive range of verified chunks. A bin consists of a single integer, and a chunk or byte range of two integers, of the width specified by the Chunk Addressing protocol options, encoded big-endian.
HAVE消息（类型0x03）由单个区块规范组成，该规范说明发送对等方拥有这些区块并成功检查了它们的完整性。single chunk规范表示一系列连续的已验证区块。bin由单个整数和两个整数的块或字节范围组成，其宽度由块寻址协议选项指定，编码为big-endian。
A HAVE message using 32-bit chunk ranges as Chunk Addressing method:
使用32位区块范围作为区块寻址方法的HAVE消息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
where the first octet is the HAVE message (0x03) followed by the start chunk and the end chunk describing the chunk range. Note this diagram shows a message and not a datagram, so it is not prefixed by the destination Channel ID. This holds for all subsequent message diagrams.
其中，第一个八位组是HAVE消息（0x03），后跟描述区块范围的开始区块和结束区块。注意：此图显示的是一条消息而不是数据报，因此它不以目标通道ID作为前缀。这适用于所有后续的消息图。
A DATA message (type 0x01) consists of a chunk specification, a timestamp, and the actual chunk. In case a datagram contains one DATA message, a sender MUST always put the DATA message in the tail of the datagram. A datagram MAY contain multiple DATA messages when the chunk size is fixed and when none of the DATA messages carry the last chunk, if that is smaller than the chunk size. As LEDBAT congestion control is used, a sender MUST include a timestamp, in
数据消息（类型0x01）由块规范、时间戳和实际块组成。如果数据报包含一条数据消息，发送方必须始终将数据消息放在数据报的尾部。当数据块大小固定且没有数据消息携带最后一个数据块（如果该数据块小于数据块大小）时，数据报可能包含多个数据消息。使用LEDBAT拥塞控制时，发送方必须在
particular, a 64-bit integer representing the current system time with microsecond accuracy. The timestamp MUST be included between chunk specification and the actual chunk.
特别是一个64位整数，表示当前系统时间，精度为微秒。时间戳必须包含在块规范和实际块之间。
A DATA message using 32-bit chunk ranges as Chunk Addressing method:
使用32位区块范围作为区块寻址方法的数据消息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the first octet is the DATA message (0x01) followed by the start chunk and the end chunk describing the single chunk, the timestamp, and the actual data.
其中，第一个八位字节是数据消息（0x01），后跟描述单个块、时间戳和实际数据的开始块和结束块。
An ACK message (type 0x02) acknowledges data that was received from its addressee; to comply with the LEDBAT delay-based congestion control, an ACK message consists of a chunk specification and a timestamp representing a one-way delay sample. The one-way delay sample is a 64-bit integer with microsecond accuracy, and it is computed from the timestamp received from the previous DATA message containing the chunk being acknowledged following the LEDBAT specification.
ACK消息（类型0x02）确认从其收件人接收的数据；为了遵守基于LEDBAT延迟的拥塞控制，ACK消息由块规范和表示单向延迟样本的时间戳组成。单向延迟样本是一个精度为微秒的64位整数，它是根据从先前数据消息接收到的时间戳计算的，该数据消息包含遵循LEDBAT规范确认的区块。
An ACK message using 32-bit chunk ranges as Chunk Addressing method:
使用32位区块范围作为区块寻址方法的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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One-way delay sample (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One-way delay sample (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
where the first octet is the ACK message (0x02) followed by the start chunk and the end chunk describing the chunk range and the one-way delay sample.
其中，第一个八位组是ACK消息（0x02），后面是描述块范围和单向延迟样本的开始块和结束块。
An INTEGRITY message (type 0x04) consists of a chunk specification and the cryptographic hash for the specified chunk or node. The type and format of the hash depends on the protocol options.
完整性消息（类型0x04）由块规范和指定块或节点的加密哈希组成。散列的类型和格式取决于协议选项。
An INTEGRITY message using 32-bit chunk ranges as Chunk Addressing method and a SHA-256 hash:
使用32位区块范围作为区块寻址方法和SHA-256哈希的完整性消息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Hash (256) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Hash (256) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
where the first octet is the INTEGRITY message (0x04) followed by the start chunk and the end chunk describing the chunk range and the hash.
其中，第一个八位组是完整性消息（0x04），后跟描述区块范围和散列的开始区块和结束区块。
A SIGNED_INTEGRITY message (type 0x07) consists of a chunk specification, a 64-bit timestamp in NTP Timestamp format [RFC5905] and a digital signature encoded as a Signature field would be in an RRSIG record in DNSSEC without the Base64 encoding [RFC4034]. The signature algorithm is defined by the Live Signature Algorithm protocol option, see Section 7.7. The plaintext over which the signature is taken depends on the content integrity protection method used, see Section 6.1.
签名的完整性消息（类型0x07）由块规范、NTP时间戳格式的64位时间戳[RFC5905]和编码为签名字段的数字签名组成，该数字签名将在DNSSEC中的RRSIG记录中，而不使用Base64编码[RFC4034]。签名算法由实时签名算法协议选项定义，见第7.7节。签名所使用的明文取决于所使用的内容完整性保护方法，见第6.1节。
A SIGNED_INTEGRITY message using 32-bit chunk ranges as Chunk Addressing method:
使用32位区块范围作为区块寻址方法的签名\u完整性消息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the first octet is the SIGNED_INTEGRITY message (0x07) followed by the start chunk and the end chunk describing the chunk range, the timestamp, and the Signature.
其中，第一个八位组是有符号的_完整性消息（0x07），后跟描述区块范围、时间戳和签名的开始区块和结束区块。
The length of the digital signature can be derived from the Live Signature Algorithm protocol option and the swarm ID as follows. The first mandatory algorithms are RSASHA1 and RSASHA256. For those algorithms, the swarm ID consists of a 1-byte Algorithm field followed by an RSA public key stored as a tuple (exponent length, exponent, modulus) [RFC3110]. Given the exponent length and the length of the public key tuple in the swarm ID, the length of the modulus in bytes can be calculated. This yields the length of the
数字签名的长度可以从Live signature Algorithm协议选项和swarm ID中导出，如下所示。第一个强制算法是RSASHA1和RSASHA256。对于这些算法，swarm ID由一个1字节的算法字段和一个存储为元组（指数长度、指数、模数）的RSA公钥组成[RFC3110]。给定swarm ID中公钥元组的指数长度和长度，可以计算以字节为单位的模的长度。这就产生了
signature, as in RSA this is the length of the modulus [HAC01]. The other mandatory algorithms are ECDSAP256SHA256 and ECDSAP384SHA384 [RFC6605]. For these algorithms, the length of the digital signature is 64 and 96 bytes, respectively.
签名，在RSA中，这是模[HAC01]的长度。其他强制算法是ECDSAP256SHA256和ECDSAP384SHA384[RFC6605]。对于这些算法，数字签名的长度分别为64和96字节。
A REQUEST message (type 0x08) consists of a chunk specification for the chunks the requester wants to download.
请求消息（类型0x08）由请求者想要下载的块的块规范组成。
A REQUEST message using 32-bit chunk ranges as Chunk Addressing method:
使用32位区块范围作为区块寻址方法的请求消息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
where the first octet is the REQUEST message (0x08) followed by the start chunk and the end chunk describing the chunk range.
其中，第一个八位组是请求消息（0x08），后跟描述区块范围的开始区块和结束区块。
A CANCEL message (type 0x09) consists of a chunk specification for the chunks the requester no longer is interested in.
取消消息（类型0x09）由请求者不再感兴趣的块的块规范组成。
A CANCEL message using 32-bit chunk ranges as Chunk Addressing method:
使用32位区块范围作为区块寻址方法的取消消息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| Start chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | End chunk (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
where the first octet is the CANCEL message (0x09) followed by the start chunk and the end chunk describing the chunk range.
其中，第一个八位组是取消消息（0x09），后面是描述区块范围的开始区块和结束区块。
Both CHOKE and UNCHOKE messages (types 0x0a and 0x0b, respectively) carry no payload.
阻塞和取消阻塞消息（分别为0x0a和0x0b类型）均不携带有效负载。
A CHOKE message:
令人窒息的信息：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
where the first octet is the CHOKE message (0x0a).
其中，第一个八位组是阻塞消息（0x0a）。
An UNCHOKE message:
未点击的信息：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 1|
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 1|
+-+-+-+-+-+-+-+-+
where the first octet is the UNCHOKE message (0x0b).
其中，第一个八位组是取消勾选的消息（0x0b）。
A PEX_REQ (0x06) message has no payload. A PEX_RESv4 (0x05) message consists of an IPv4 address in big-endian format followed by a UDP port number in big-endian format. A PEX_RESv6 (0x0c) message contains a 128-bit IPv6 address instead of an IPv4 one. If a PEX_REQ message does not originate from a private, unique-local, link-local, or multicast address [RFC1918] [RFC4193] [RFC4291], then the PEX_RES* messages sent in reply MUST NOT contain such addresses. This is to prevent leaking of internal addresses to external peers.
PEX_REQ（0x06）消息没有有效负载。PEX_RESv4（0x05）消息由一个big-endian格式的IPv4地址和一个big-endian格式的UDP端口号组成。PEX_RESv6（0x0c）消息包含128位IPv6地址，而不是IPv4地址。如果PEX_REQ消息并非源自专用、唯一本地、链路本地或多播地址[RFC1918][RFC4193][RFC4291]，则作为回复发送的PEX_RES*消息不得包含此类地址。这是为了防止内部地址泄漏到外部对等方。
A PEX_REQ message:
PEX_REQ消息：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+
where the first octet is the PEX_REQ message (0x06).
其中，第一个八位组是PEX_REQ消息（0x06）。
A PEX_RESv4 message:
PEX_RESv4消息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 1| IPv4 Address (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Port (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 1| IPv4 Address (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Port (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the first octet is the PEX_RESv4 message (0x05) followed by the IPv4 address and the port number.
其中，第一个八位组是PEX_RESv4消息（0x05），后跟IPv4地址和端口号。
A PEX_RESv6 message:
PEX_RESv6消息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0 0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (128) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Port (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0 0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (128) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Port (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the first octet is the PEX_RESv6 message (0x0c), followed by the IPv6 address and the port number.
其中，第一个八位组是PEX_RESv6消息（0x0c），后跟IPv6地址和端口号。
A PEX_REScert (0x0d) message consists of a 16-bit integer in big-endian specifying the size of the membership certificate that follows, see Section 12.2.1. This membership certificate states that Peer P at Time T is a member of Swarm S and is a X.509v3 certificate [RFC5280] that is encoded using the ASN.1 distinguished encoding rules (DER) [CCITT.X690.2002]. The certificate MUST contain a "Subject Alternative Name" extension, marked as critical, of type uniformResourceIdentifier.
PEX_Resert（0x0d）消息由一个16位的大端整数组成，用于指定随后的成员资格证书的大小，请参见第12.2.1节。此成员资格证书声明，时间T时的对等方P是Swarm S的成员，是使用ASN.1可分辨编码规则（DER）[CCITT.X690.2002]编码的X.509v3证书[RFC5280]。证书必须包含类型为uniformResourceIdentifier的“Subject Alternative Name”扩展名（标记为critical）。
A PEX_REScert message:
PEX_重新插入消息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0 1| Size of Memb. Cert. (16) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Membership Certificate ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0 1| Size of Memb. Cert. (16) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Membership Certificate ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the first octet is the PEX_REScert message (0x0d) followed by the size of the membership certificate and the membership certificate.
其中，第一个八位组是PEX_Resert消息（0x0d），后跟成员证书和成员证书的大小。
The URL contained in the name extension MUST follow the generic syntax for URLs [RFC3986], where its scheme component is "file", the host in the authority component is the DNS name or IP address of Peer P, the port in the authority component is the port of Peer P, and the path contains the swarm identifier for Swarm S, in hexadecimal form. In particular, the preferred form of the swarm identifier is xxyyzz..., where the 'x's, 'y's, and 'z's are 2 hexadecimal digits of the 8-bit pieces of the identifier. The validity time of the certificate is set with notBefore UTCTime set to T and notAfter UTCTime set to T plus some expiry time defined by the issuer. An example URL:
名称扩展名中包含的URL必须遵循URL的通用语法[RFC3986]，其中其方案组件为“文件”，授权组件中的主机为对等方P的DNS名称或IP地址，授权组件中的端口为对等方P的端口，路径包含以十六进制形式表示的swarm S的swarm标识符。特别是，swarm标识符的首选形式是xxyyz…，其中“x”、“y”和“z”是标识符8位片段的2个十六进制数字。证书的有效期设置为notBefore UTCTime设置为T，notAfter UTCTime设置为T加上发卡机构定义的一些到期时间。示例URL：
file://192.0.2.0:6778/e5a12c7ad2d8fab33c699d1e198d66f79fa610c3
file://192.0.2.0:6778/e5a12c7ad2d8fab33c699d1e198d66f79fa610c3
Keep alives do not have a message type on UDP. They are just simple datagrams consisting of the 4-byte channel ID of the destination only.
Keep alives在UDP上没有消息类型。它们只是简单的数据报，只包含目标的4字节通道ID。
A keep-alive datagram:
保持活动的数据报：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Explicit flow control is not required for PPSPP over UDP. In the case of video on demand, the receiver explicitly requests the content from peers, and is therefore in control of how much data is coming towards it. In the case of live streaming, where a push model may be used, the amount of data incoming is limited to the stream bitrate, which the receiver must be able to process for a continuous playback. Should, for any reason, the receiver get saturated with data, the congestion control at the sender side will detect the situation and adjust the sending rate accordingly.
通过UDP的PPSPP不需要显式流控制。在视频点播的情况下，接收器明确地从对等方请求内容，因此控制有多少数据流向它。在可使用推送模型的实时流的情况下，传入的数据量限于流比特率，接收机必须能够处理该流比特率以进行连续回放。如果出于任何原因，接收方数据饱和，发送方的拥塞控制将检测到这种情况并相应地调整发送速率。
PPSPP over UDP can support different congestion control algorithms. At present, it uses the LEDBAT congestion control algorithm [RFC6817]. LEDBAT is a delay-based congestion control algorithm that is used every day by millions of users as part of the uTP transmission protocol of BitTorrent [LBT] [LCOMPL] and is suitable for P2P streaming [PPSPPERF].
UDP上的PPSPP可以支持不同的拥塞控制算法。目前，它使用LEDBAT拥塞控制算法[RFC6817]。LEDBAT是一种基于延迟的拥塞控制算法，作为BitTorrent[LBT][LCOMPL]uTP传输协议的一部分，每天有数百万用户使用该算法，适用于P2P流媒体[PPSPPERF]。
LEDBAT monitors the delay of the packets on the data path. It uses the one-way delay variations to react early and limit the congestion that the stream may induce in the network [RFC6817]. Using LEDBAT enables PPSPP to serve the content to other interested peers after the playback has finished (seeding), without disrupting the user. After the playback, the user might move to different tasks that use its network link, which are prioritized over PPSPP traffic. Hence, the user does not notice the background PPSPP traffic, which in turn increases the chances of seeding the content for a longer period of time.
LEDBAT监控数据路径上数据包的延迟。它使用单向延迟变化提前作出反应，并限制流可能在网络中引起的拥塞[RFC6817]。使用LEDBAT，PPSPP可以在播放完成（种子设定）后将内容提供给其他感兴趣的对等方，而不会中断用户。回放后，用户可能会转到使用其网络链接的不同任务，这些任务的优先级高于PPSP流量。因此，用户不会注意到背景PPSPP流量，这反过来增加了在更长时间内播种内容的机会。
The property of reacting early is not a problem in a peer-to-peer system where multiple sources offer the content. Considering the case of congestion near the sender, LEDBAT's early reaction impacts the transmission of chunks to the receiver. However, for the receiver, it is actually beneficial to learn early that the transmission from a particular source is impacted. The receiver can then choose to download time-critical chunks from other sources during its chunk picking phase.
在多个源提供内容的对等系统中，提前反应的特性不是问题。考虑到发送方附近的拥塞情况，LEDBAT的早期反应会影响块到接收方的传输。然而，对于接收机来说，尽早了解来自特定源的传输受到影响实际上是有益的。然后，接收者可以选择在区块选取阶段从其他来源下载时间关键区块。
If the bottleneck is near the receiver, the receiver is indeed unlucky that transmissions from any source that runs through this bottleneck will back off quite fast due to LEDBAT. However, for the rest of the network (and the network operator), this is beneficial as the video-streaming system will back off early enough and not contribute too much to the congestion.
如果瓶颈在接收器附近，那么接收器确实很不走运，因为LEDBAT，来自任何通过该瓶颈的源的传输都会很快退却。但是，对于网络的其余部分（以及网络运营商），这是有益的，因为视频流系统将提前退出，不会对拥塞造成太大影响。
The power of LEDBAT is that its behavior can be configured. In the case of live streaming, a PPSPP deployer may want a more aggressive behavior to ensure quality of service. In that case, LEDBAT can be configured to be more aggressive. In particular, LEDBAT's queuing target delay value (TARGET in [RFC6817]) and other parameters can be adjusted such that it acts as aggressive as TCP (or even more). Hence, LEDBAT is an algorithm that works for many scenarios in a peer-to-peer context.
LEDBAT的威力在于其行为可以配置。在流媒体直播的情况下，PPSPP部署人员可能需要更积极的行为来确保服务质量。在这种情况下，可以将LEDBAT配置为更具攻击性。特别是，可以调整LEDBAT的队列目标延迟值（在[RFC6817]中为目标）和其他参数，使其与TCP（甚至更多）一样具有攻击性。因此，LEDBAT算法适用于对等环境中的许多场景。
We present a small example of communication between a leecher and a seeder. The example presents the transmission of the file "Hello World!", which fits within a 1024-byte chunk. For an easy understanding, we use the message description names, as listed in Table 7, and the protocol option names as listed in Table 2, rather than the actual binary value.
我们给出了一个小的例子，一个榨汁机和一个播种机之间的通信。该示例显示了文件“Hello World！”的传输，该文件位于1024字节的块中。为了便于理解，我们使用表7中列出的消息描述名称和表2中列出的协议选项名称，而不是实际的二进制值。
To do the handshake, the initiating peer sends a datagram that MUST start with an all-zeros channel ID (0x00000000); followed by a HANDSHAKE message, whose payload is a locally unused; a random channel ID (in this case 0x00000001); and a list of protocol options. Channel IDs MUST be randomly chosen, as described in Section 12.1.
要进行握手，发起的对等方发送一个数据报，该数据报必须以全零通道ID（0x00000000）开头；然后是握手消息，其有效负载是本地未使用的；随机通道ID（在本例中为0x00000001）；以及协议选项列表。通道ID必须随机选择，如第12.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Version |0 0 0 0 0 0 0 1| Min Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Swarm ID |0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 0 1 0 0 1 1 1 1 1 0 0 1 1 0|
~ ..... ~
|1 0 0 0 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 1 0 0 0 0 0 0 1 1 1 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont. Int. |0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Add. |0 0 0 0 0 0 1 0| Chunk Size |0 0 0 0 0 0 0 0~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Version |0 0 0 0 0 0 0 1| Min Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Swarm ID |0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 0 1 0 0 1 1 1 1 1 0 0 1 1 0|
~ ..... ~
|1 0 0 0 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 1 0 0 0 0 0 0 1 1 1 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont. Int. |0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Add. |0 0 0 0 0 0 1 0| Chunk Size |0 0 0 0 0 0 0 0~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The protocol options are:
协议选项包括：
Version: 1
版本:1
Minimum supported Version: 1
支持的最低版本：1
Swarm Identifier: A 32-byte root hash (47a0...b03b) identifying the content
Swarm标识符：标识内容的32字节根哈希（47a0…b03b）
Content Integrity Protection Method: Merkle Hash Tree
内容完整性保护方法：Merkle哈希树
Merkle Tree Hash Function: SHA-256
Merkle树哈希函数：SHA-256
Chunk Addressing Method: 32-bit chunk ranges
区块寻址方法：32位区块范围
Chunk Size: 1024
区块大小：1024
The receiving peer MAY respond, in which case the returned datagram
MUST consist of the channel ID from the sender's HANDSHAKE message
(0x00000001); a HANDSHAKE message, whose payload is a locally unused;
a random channel ID (0x00000008); and a list of protocol options;
followed by any other messages it wants to send.
The receiving peer MAY respond, in which case the returned datagram
MUST consist of the channel ID from the sender's HANDSHAKE message
(0x00000001); a HANDSHAKE message, whose payload is a locally unused;
a random channel ID (0x00000008); and a list of protocol options;
followed by any other messages it wants to send.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Version |0 0 0 0 0 0 0 1| Cont. Int. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0| Chunk Add. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Chunk Size |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| End | HAVE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Version |0 0 0 0 0 0 0 1| Cont. Int. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0| Chunk Add. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Chunk Size |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| End | HAVE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
With the protocol options, the receiving peer agrees on speaking protocol version 1, on using the Merkle Hash Tree as the Content Integrity Protection Method, SHA-256 hash as the Merkle Tree Hash Function, 32-bit chunk ranges as the Chunk Addressing Method, and
通过协议选项，接收对等方同意使用协议版本1，同意使用Merkle哈希树作为内容完整性保护方法，同意使用SHA-256哈希作为Merkle树哈希函数，同意使用32位块范围作为块寻址方法，以及
Chunk Size 1024. Furthermore, it sends a HAVE message within the same datagram, announcing that it has locally available the first chunk of content.
块大小1024。此外，它在同一数据报中发送HAVE消息，宣布它在本地拥有第一块内容。
At this point, the initiator knows that the peer really responds; for that purpose, channel IDs MUST be random enough to prevent easy guessing. So, the third datagram of a handshake MAY already contain some heavy payload. To minimize the number of initialization round trips, the first two datagrams MAY also contain some minor payload, e.g., the HAVE message.
在这一点上，发起方知道对等方确实做出了响应；为此，通道ID必须足够随机，以防止容易猜测。因此，握手的第三个数据报可能已经包含一些重负载。为了最小化初始化往返次数，前两个数据报还可能包含一些次要有效载荷，例如HAVE消息。
The initiating peer MAY send a request for the chunks of content it wants to retrieve from the receiving peer, e.g., the first chunk announced during the handshake. It always precedes the message with the channel ID of the peer it is communicating with (0x00000008 in our example), as described in Section 3.11. Furthermore, it MAY add additional messages such as a PEX_REQ.
发起对等方可以发送对其想要从接收对等方检索的内容块的请求，例如，握手期间宣布的第一个块。如第3.11节所述，它总是在消息前面加上与其通信的对等方的通道ID（在我们的示例中为0x00000008）。此外，它可以添加额外的消息，例如PEX_REQ。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| REQUEST |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| PEX_REQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| REQUEST |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| PEX_REQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When receiving the third datagram, both peers have proof that they really talk to each other; the three-way handshake is complete. The receiving peer responds to the request by sending a DATA message containing the requested content.
当接收到第三个数据报时，两个对等方都有证据证明他们确实在相互交谈；三方握手已完成。接收端通过发送包含请求内容的数据消息来响应请求。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 1 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 1 0 1 1 0 1 1 1 1 1 0 1 1 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 1 0 0|0 1 0 0 1 0 0 0 0 1 1 0 0 1 0 1 0 1 1 0 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ..... ~
|0 1 1 0 1 1 0 0 0 1 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 1 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 1 0 1 1 0 1 1 1 1 1 0 1 1 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 1 0 0|0 1 0 0 1 0 0 0 0 1 1 0 0 1 0 1 0 1 1 0 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ..... ~
|0 1 1 0 1 1 0 0 0 1 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DATA message consists of:
数据信息包括：
The 32-bit chunk range: 0,0 (the first chunk)
32位区块范围：0,0（第一个区块）
The timestamp value: 0004e94180b7db44
时间戳值：0004e94180b7db44
The data: 48656c6c6f20776f726c6421 (the "Hello world!" file)
数据：48656C6F20776F726C6421（“Hello world！”文件）
Note that the above datagram does not include the INTEGRITY message, as the entire content can fit into a single message; hence, the initiating peer is able to verify it against the root hash. Also, in this example, the peer does not respond to the PEX_REQ as it does not know any third peer participating in the swarm.
注意，上述数据报不包括完整性消息，因为整个内容可以放入单个消息中；因此，发起方能够根据根散列对其进行验证。此外，在本例中，对等方不响应PEX_请求，因为它不知道任何第三方参与swarm。
Upon receiving the requested data, the initiating peer responds with an ACK message for the first chunk, containing a one-way delay sample (100 ms). Furthermore, it also adds a HAVE message for the chunk.
在接收到请求的数据后，发起的对等方响应第一个块的ACK消息，其中包含单向延迟样本（100ms）。此外，它还为区块添加HAVE消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0 0 1 0 0| HAVE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0 0 1 0 0| HAVE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
At this point, the initiating peer has successfully retrieved the entire file. Then, it explicitly closes the connection by sending a HANDSHAKE message that contains an all-zeros Source Channel ID.
此时，发起方已成功检索到整个文件。然后，它通过发送包含全零源通道ID的握手消息来显式关闭连接。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk (or piece) picking entirely depends on the receiving peer. The sending peer is made aware of preferred chunks by the means of REQUEST messages. In some (live) scenarios, it may be beneficial to allow the sender to ignore those hints and send unrequested data.
区块（或片段）拾取完全取决于接收对等方。通过请求消息的方式使发送对等方知道首选块。在某些（实时）场景中，允许发送者忽略这些提示并发送未请求的数据可能是有益的。
The chunk picking algorithm is external to the PPSPP and will generally be a pluggable policy that uses the mechanisms provided by PPSPP. The algorithm will handle the choices made by the user
区块选取算法是PPSPP的外部算法，通常是使用PPSPP提供的机制的可插入策略。该算法将处理用户所做的选择
consuming the content, such as seeking or switching audio tracks or subtitles. Example policies for P2P streaming can be found in [BITOS], and [EPLIVEPERF].
使用内容，例如查找或切换音频曲目或字幕。P2P流媒体的示例策略可以在[BITOS]和[EPLIVEPERF]中找到。
The role of reciprocity algorithms in peer-to-peer systems is to promote client contribution and prevent freeriding. A peer is said to be freeriding if it only downloads content but never uploads to others. Examples of reciprocity algorithms are tit-for-tat as used in BitTorrent [TIT4TAT] and Give-to-Get [GIVE2GET]. In PPSPP, reciprocity enforcement is the sole responsibility of the sending peer.
对等系统中互惠算法的作用是促进客户贡献和防止搭便车。如果一个同伴只下载内容而从不上传给其他人，那么他就被称为搭便车。互惠算法的示例包括BitTorrent[TIT4TAT]和GiveToGet[GIVE2GET]中使用的针锋相对算法。在PPSP中，对等执行是发送对等方的唯一责任。
IANA has created a new top-level registry called "Peer-to-Peer Streaming Peer Protocol (PPSPP)", which hosts the six new sub-registries defined below for the extensibility of the protocol. For all registries, assignments consist of a name and its associated value. Also, for all registries, the "Unassigned" ranges designated are governed by the policy "IETF Review" as described in [RFC5226].
IANA已经创建了一个名为“对等流媒体对等协议（PPSPP）”的新顶级注册表，它托管了下面为协议的可扩展性定义的六个新的子注册表。对于所有注册表，赋值由名称及其关联值组成。此外，对于所有注册中心，指定的“未分配”范围受[RFC5226]中所述的“IETF审查”政策管辖。
The registry name is "PPSPP Message Type Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 7.
注册表名为“PPSPP消息类型注册表”。值是0-255范围内的整数，表7给出了初始赋值和保留。
The registry name is "PPSPP Option Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 2.
注册表名为“PPSPP选项注册表”。值是0-255范围内的整数，表2中给出了初始赋值和保留。
The registry name is "PPSPP Version Number Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 3.
注册表名为“PPSPP版本号注册表”。值是0-255范围内的整数，表3给出了初始赋值和保留。
The registry name is "PPSPP Content Integrity Protection Method Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 4.
注册表名为“PPSPP内容完整性保护方法注册表”。值是0-255范围内的整数，表4给出了初始赋值和保留。
The registry name is "PPSPP Merkle Hash Tree Function Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 5.
注册表名为“PPSPP Merkle哈希树函数注册表”。值是0-255范围内的整数，表5给出了初始赋值和保留。
The registry name is "PPSPP Chunk Addressing Method Registry". Values are integers in the range 0-255, with initial assignments and reservations given in Table 6.
注册表名为“PPSPP区块寻址方法注册表”。值是0-255范围内的整数，表6给出了初始赋值和保留。
This section presents operations and management considerations following the checklist in [RFC5706], Appendix A.
本节介绍了按照附录A[RFC5706]中的检查表进行操作和管理的注意事项。
In this section, "PPSPP client" is defined as a PPSPP peer acting on behalf of an end user which may not yet have a copy of the content, and "PPSPP server" as a PPSPP peer that provides the initial copies of the content to the swarm on behalf of a content provider.
在本节中，“PPSPP客户端”被定义为代表可能尚未拥有内容副本的最终用户的PPSPP对等方，“PPSPP服务器”被定义为代表内容提供商向swarm提供内容初始副本的PPSPP对等方。
A content provider wishing to use PPSPP to distribute content should set up at least one PPSPP server. PPSPP servers need to have access to either some static content or some live audio/video sources. To provide flexibility for implementors, this configuration process is not standardized. The output of this process will be a list of metadata records, one for each swarm. A metadata record consists of the swarm ID, the chunk size used, the chunk addressing method used, the content integrity protection method used, and the Merkle hash tree function used (if applicable). If automatic content size detection (see Section 5.6) is not used, the content length is also part of the metadata record for static content. Note the swarm ID already contains the Live Signature Algorithm used, in case of a live stream.
希望使用PPSP分发内容的内容提供商应至少设置一台PPSP服务器。PPSP服务器需要访问一些静态内容或一些实时音频/视频源。为了为实现者提供灵活性，此配置过程没有标准化。这个过程的输出将是一个元数据记录列表，每个集群一个。元数据记录包括swarm ID、使用的块大小、使用的块寻址方法、使用的内容完整性保护方法和使用的Merkle哈希树函数（如果适用）。如果未使用自动内容大小检测（参见第5.6节），则内容长度也是静态内容元数据记录的一部分。请注意，swarm ID已经包含在实时流中使用的实时签名算法。
In addition, a content provider should set up a tracking facility for the content by configuring, for example, a peer-to-peer streaming protocol tracker [PPSP-TP] or a Distributed Hash Table. The output of the latter process is a list of transport addresses for the tracking facility.
此外，内容提供商应通过配置（例如）对等流协议跟踪器[PPSP-TP]或分布式哈希表来为内容设置跟踪设施。后一个过程的输出是跟踪设施的传输地址列表。
The list of metadata records of available content, and transport address for the tracking facility, can be distributed to users in various ways. Typically, they will be published on a website as links. When a user clicks such a link, the PPSPP client is launched, either as a standalone application or by invoking the browser's internal PPSPP protocol handler, as exemplified in Section 2. The clients use the tracking facility to obtain the transport address of the PPSPP server(s) and other peers from the swarm, executing the peer protocol to retrieve and redistribute the content. The format of the PPSPP URLs should be defined in an extension document. The default protocol options should be exploited to keep the URLs small.
可用内容的元数据记录列表以及跟踪设施的传输地址可以以各种方式分发给用户。通常，它们将作为链接发布在网站上。当用户单击此类链接时，PPSPP客户端将作为独立应用程序或通过调用浏览器的内部PPSPP协议处理程序启动，如第2节所示。客户端使用跟踪功能从swarm获取PPSP服务器和其他对等方的传输地址，执行对等协议以检索和重新分发内容。PPSPP URL的格式应在扩展文档中定义。应利用默认协议选项保持URL较小。
The minimal information a tracking facility must return when queried for a list of peers for a swarm is as follows. Assuming the communication between tracking facility and requester is protected, the facility must at least return for each peer in the list its IP address, transport protocol identifier (i.e., UDP), and transport protocol port number.
当查询swarm的对等方列表时，跟踪设施必须返回的最小信息如下所示。假设跟踪设施和请求者之间的通信受到保护，设施必须至少为列表中的每个对等方返回其IP地址、传输协议标识符（即UDP）和传输协议端口号。
This document does not detail a migration path since there is no previous standard protocol providing similar functionality.
由于以前没有提供类似功能的标准协议，因此本文档没有详细说明迁移路径。
When using the peer-to-peer streaming protocol tracker, PPSPP requires a specific behavior from this protocol for security reasons, as detailed in Section 12.2.
当使用对等流协议跟踪器时，出于安全原因，PPSPP需要该协议的特定行为，详见第12.2节。
PPSPP is a peer-to-peer protocol that takes advantage of the fact that content is available from multiple sources to improve robustness, scalability, and performance. At the same time, poor choices in determining which exact sources to use can lead to bad experience for the end user and high costs for network operators. Hence, PPSPP can benefit from the ALTO protocol to steer peer selection, as described in Section 3.10.1.
PPSPP是一种点对点协议，它利用了内容可从多个来源获得这一事实，以提高健壮性、可伸缩性和性能。与此同时，在确定使用哪些确切来源时选择不当，可能会导致最终用户体验不佳，网络运营商成本高昂。因此，如第3.10.1节所述，PPSPP可以受益于ALTO协议来引导对等选择。
PPSPP is operating correctly when all peers obtain the desired content on time. Therefore, the PPSPP client is the ideal location to verify the protocol's correct operation. However, it is not feasible to mandate logging the behavior of PPSPP peers in all implementations and deployments, for example, due to privacy reasons. There are two alternative options:
当所有对等方按时获得所需内容时，PPSP正常运行。因此，PPSPP客户端是验证协议正确运行的理想位置。但是，由于隐私等原因，在所有实现和部署中强制记录PPSP对等方的行为是不可行的。有两个备选方案：
o Monitoring the PPSPP servers initially providing the content, using standard metrics such as bandwidth usage, peer connections, and activity, can help identify trouble, see next section and [RFC2564].
o 使用带宽使用率、对等连接和活动等标准指标监控最初提供内容的PPSPP服务器，有助于识别故障，请参阅下一节和[RFC2564]。
o The tracker protocol [PPSP-TP] may be used to gather information about all peers in a swarm, to obtain a global view of operation, according to PPSP.OAM.REQ-3 in [RFC6972].
o 根据[RFC6972]中的PPSP.OAM.REQ-3，跟踪协议[PPSP-TP]可用于收集群中所有对等方的信息，以获得操作的全局视图。
Basic operation of the protocol can be easily verified when a tracker and swarm metadata are known by starting a PPSPP download. Deep packet inspection for DATA and ACK messages help to establish that actual content transfer is happening and that the chunk availability signaling and integrity checking are working.
当通过启动PPSP下载已知跟踪程序和swarm元数据时，可以轻松验证协议的基本操作。对数据和ACK消息的深度数据包检查有助于确定实际的内容传输正在发生，并且区块可用性信令和完整性检查正在工作。
Table 8 shows the PPSPP parameters, their defaults, and where the parameter is defined. For parameters that have no default, the table row contains the word "var" and refers to the section discussing the considerations to make when choosing a value.
表8显示了PPSPP参数、它们的默认值以及参数的定义位置。对于没有默认值的参数，表行包含单词“var”，并引用讨论选择值时应注意事项的部分。
+-------------------------+-----------------------+-----------------+
| Name | Default | Definition |
+-------------------------+-----------------------+-----------------+
| Chunk Size | var, 1024 bytes | Section 8.1 |
| | recommended | |
| | | |
| Static Content | 1 (Merkle Hash Tree) | Section 7.5 |
| Integrity Protection | | |
| Method | | |
| | | |
| Live Content Integrity | 3 (Unified Merkle | Section 7.5 |
| Protection Method | Tree) | |
| | | |
| Merkle Hash Tree | 2 (SHA-256) | Section 7.6 |
| Function | | |
| | | |
| Live Signature | 13 (ECDSAP256SHA256) | Section 7.7 |
| Algorithm | | |
| | | |
| Chunk Addressing Method | 2 (32-bit chunk | Section 7.8 |
| | ranges) | |
| | | |
| Live Discard Window | var | Section 6.2, |
| | | Section 7.9 |
| | | |
| NCHUNKS_PER_SIG | var | Section 6.1.2.1 |
| | | |
| Dead peer detection | No reply in 3 minutes | Section 3.12 |
| | + 3 datagrams | |
+-------------------------+-----------------------+-----------------+
+-------------------------+-----------------------+-----------------+
| Name | Default | Definition |
+-------------------------+-----------------------+-----------------+
| Chunk Size | var, 1024 bytes | Section 8.1 |
| | recommended | |
| | | |
| Static Content | 1 (Merkle Hash Tree) | Section 7.5 |
| Integrity Protection | | |
| Method | | |
| | | |
| Live Content Integrity | 3 (Unified Merkle | Section 7.5 |
| Protection Method | Tree) | |
| | | |
| Merkle Hash Tree | 2 (SHA-256) | Section 7.6 |
| Function | | |
| | | |
| Live Signature | 13 (ECDSAP256SHA256) | Section 7.7 |
| Algorithm | | |
| | | |
| Chunk Addressing Method | 2 (32-bit chunk | Section 7.8 |
| | ranges) | |
| | | |
| Live Discard Window | var | Section 6.2, |
| | | Section 7.9 |
| | | |
| NCHUNKS_PER_SIG | var | Section 6.1.2.1 |
| | | |
| Dead peer detection | No reply in 3 minutes | Section 3.12 |
| | + 3 datagrams | |
+-------------------------+-----------------------+-----------------+
Table 8: PPSPP Defaults
表8:PPSP默认值
The management considerations for PPSPP are very similar to other protocols that are used for large-scale content distribution, in particular HTTP. How does one manage large numbers of servers? How does one push new content out to a server farm and allows staged releases? How are faults detected and how are servers and end-user performance measured? As standard solutions to these challenges are still being developed, this section cannot provide a definitive recommendation on how PPSPP should be managed. Hence, it describes the standard solutions available at this time and assumes a future extension document will provide more complete guidelines.
PPSPP的管理考虑事项与用于大规模内容分发的其他协议非常相似，特别是HTTP。如何管理大量服务器？如何将新内容推送到服务器场并允许分阶段发布？如何检测故障，如何衡量服务器和最终用户的性能？由于这些挑战的标准解决方案仍在开发中，本节无法就PPSPP的管理方式提供明确的建议。因此，它描述了目前可用的标准解决方案，并假设未来的扩展文档将提供更完整的指南。
As just stated, PPSPP servers providing initial copies of the content are akin to WWW and FTP servers. They can also be deployed in large numbers and thus can benefit from standard management facilities. Therefore, PPSPP servers may implement an SNMP management interface based on the APPLICATION-MIB [RFC2564], where the file object can be used to report on swarms.
如前所述，提供内容初始副本的PPSPP服务器类似于WWW和FTP服务器。它们也可以大量部署，因此可以受益于标准管理设施。因此，PPSP服务器可以基于APPLICATION-MIB[RFC2564]实现SNMP管理接口，其中文件对象可用于报告群集。
What is missing is the ability to remove or rate limit specific PPSPP swarms on a server. This corresponds to removing or limiting specific virtual servers on a web server. In other words, as multiple pieces of content (swarms, virtual WWW servers) are multiplexed onto a single server process, more fine-grained management of that process is required. This functionality is currently missing.
缺少的是删除或限制服务器上特定PPSP群集的能力。这对应于删除或限制web服务器上的特定虚拟服务器。换句话说，由于多个内容（群集、虚拟WWW服务器）被多路复用到单个服务器进程上，因此需要对该进程进行更细粒度的管理。此功能当前缺失。
Logging is an important functionality for PPSPP servers and, depending on the deployment, PPSPP clients. Logging should be done via syslog [RFC5424].
日志记录是PPSP服务器和PPSP客户端（取决于部署）的一项重要功能。应通过syslog[RFC5424]进行日志记录。
The facilities for verifying correct operation and server management (just discussed) appear sufficient for PPSPP fault monitoring. This can be supplemented with host resource [RFC2790] and UDP/IP network monitoring [RFC4113], as PPSPP server failures can generally be attributed directly to conditions on the host or network.
用于验证正确操作和服务器管理的设施（刚才讨论过）似乎足以用于PPSP故障监控。这可以通过主机资源[RFC2790]和UDP/IP网络监控[RFC4113]进行补充，因为PPSP服务器故障通常可直接归因于主机或网络上的状况。
Since PPSPP has been designed to work in a hostile environment, many benign faults will be handled by the mechanisms used for managing attacks. For example, when a malfunctioning peer starts sending the wrong chunks, this is detected by the content integrity protection mechanism and another source is sought.
由于PPSPP设计用于在敌对环境中工作，因此许多良性故障将由用于管理攻击的机制处理。例如，当出现故障的对等方开始发送错误的块时，内容完整性保护机制会检测到这一点，并寻找另一个源。
Large-scale deployments may benefit from a standard way of replicating a new piece of content on a set of initial PPSPP servers. This functionality may need to include controlled releasing, such that content becomes available only at a specific point in time (e.g., the release of a movie trailer). This functionality could be provided via NETCONF [RFC6241], to enable atomic configuration updates over a set of servers. Uploading the new content could be one configuration change, making the content available for download by the public another.
大规模部署可能受益于在一组初始PPSP服务器上复制新内容的标准方式。此功能可能需要包括受控发布，以便内容仅在特定时间点可用（例如，电影预告片的发布）。可以通过NETCONF[RFC6241]提供此功能，以便在一组服务器上启用原子配置更新。上传新内容可能是一个配置更改，使内容可供公众下载。
Content providers may offer PPSPP hosting for different customers and will want to bill these customers, for example, based on bandwidth usage. This situation is a common accounting scenario, similar to billing per virtual server for web servers. PPSPP can therefore benefit from general standardization efforts in this area [RFC2975] when they come to fruition.
内容提供商可能为不同的客户提供PPSP托管服务，并希望根据带宽使用情况向这些客户收取费用。这种情况是一种常见的计费场景，类似于为web服务器按虚拟服务器计费。因此，PPSPP在取得成果时可受益于该领域的一般标准化工作[RFC2975]。
Depending on the deployment scenarios, the application performance measurement facilities of [RFC3729] and associated [RFC4150] can be used with PPSPP.
根据部署场景，[RFC3729]和相关[RFC4150]的应用程序性能度量工具可与PPSP一起使用。
In addition, when the PPSPP tracker protocol is used, it provides a built-in, application-level, performance measurement infrastructure for different metrics. See PPSP.OAM.REQ-3 in [RFC6972].
此外，当使用PPSPP跟踪协议时，它为不同的度量提供了内置的应用程序级性能度量基础设施。参见[RFC6972]中的PPSP.OAM.REQ-3。
Malicious peers should ideally be locked out long term. This is primarily for performance reasons, as the protocol is robust against attacks (see next section). Section 12.7 describes a procedure for long-term exclusion.
理想情况下，恶意的对等方应该被长期锁定。这主要是出于性能原因，因为该协议对攻击具有鲁棒性（请参阅下一节）。第12.7节描述了长期排除的程序。
As any other network protocol, PPSPP faces a common set of security challenges. An implementation must consider the possibility of buffer overruns, DoS attacks and manipulation (i.e., reflection attacks). Any guarantee of privacy seems unlikely, as the user is exposing its IP address to the peers. A probable exception is the case of the user being hidden behind a public NAT or proxy. This section discusses the protocol's security considerations in detail.
与任何其他网络协议一样，PPSP面临一系列常见的安全挑战。实现必须考虑缓冲区溢出、DoS攻击和操作（即反射攻击）的可能性。任何隐私保证似乎都不太可能，因为用户将其IP地址暴露给对等方。一个可能的例外是用户隐藏在公共NAT或代理后面。本节详细讨论协议的安全注意事项。
Borrowing from the analysis in [RFC5971], the PPSPP may be attacked with three types of denial-of-service attacks:
借用[RFC5971]中的分析，PPSPP可能受到三种类型的拒绝服务攻击：
1. DoS amplification attack: attackers try to use a PPSPP peer to generate more traffic to a victim.
1. DoS放大攻击：攻击者试图使用PPSPP对等点为受害者生成更多流量。
2. DoS flood attack: attackers try to deny service to other peers by allocating lots of state at a PPSPP peer.
2. DoS洪水攻击：攻击者试图通过在PPSPP对等点分配大量状态来拒绝向其他对等点提供服务。
3. Disrupt service to an individual peer: attackers send bogus, e.g., REQUEST and HAVE messages appearing to come from victim Peer A to the Peers B1..Bn serving that peer. This causes Peer A to receive chunks it did not request or to not receive the chunks it requested.
3. 中断对单个对等方的服务：攻击者向为该对等方提供服务的对等方B1..Bn发送虚假请求，并显示来自受害对等方A的消息。这会导致对等方A接收到它没有请求的块或没有接收到它请求的块。
The basic scheme to protect against these attacks is the use of a secure handshake procedure. In the UDP encapsulation, the handshake procedure is secured by the use of randomly chosen channel IDs as follows. The channel IDs must be generated following the requirements in [RFC4960] (Section 5.1.3).
防止这些攻击的基本方案是使用安全握手过程。在UDP封装中，握手过程通过使用随机选择的通道ID进行保护，如下所示。必须按照[RFC4960]（第5.1.3节）中的要求生成通道ID。
When UDP is used, all datagrams carrying PPSPP messages are prefixed with a 4-byte channel ID. These channel IDs are random numbers, established during the handshake phase as follows. Peer A initiates an exchange with Peer B by sending a datagram containing a HANDSHAKE message prefixed with the channel ID consisting of all zeros. Peer A's HANDSHAKE contains a randomly chosen channel ID, chanA:
使用UDP时，所有携带PPSPP消息的数据报都以4字节通道ID作为前缀。这些通道ID是随机数，在握手阶段建立，如下所示。对等方A通过发送包含握手消息的数据报来启动与对等方B的交换，握手消息的前缀为通道ID（由全零组成）。对等方A的握手包含随机选择的通道ID chanA：
A->B: chan0 + HANDSHAKE(chanA) + ...
A->B:chan0+握手（chanA）+。。。
When Peer B receives this datagram, it creates some state for Peer A, that at least contains the channel ID chanA. Next, Peer B sends a response to Peer A, consisting of a datagram containing a HANDSHAKE message prefixed with the chanA channel ID. Peer B's HANDSHAKE contains a randomly chosen channel ID, chanB.
当对等方B接收到此数据报时，它为对等方A创建一些状态，该状态至少包含通道ID chanA。接下来，对等方B向对等方a发送一个响应，该响应由一个数据报组成，其中包含一个以chanA通道ID为前缀的握手消息。对等方B的握手包含一个随机选择的通道ID chanB。
B->A: chanA + HANDSHAKE(chanB) + ...
B->A:chanA+握手（chanB）+。。。
Peer A now knows that Peer B really responds, as it echoed chanA. So the next datagram that Peer A sends may already contain heavy payload, i.e., a chunk. This next datagram to Peer B will be prefixed with the chanB channel ID. When Peer B receives this datagram, both peers have the proof they are really talking to each other, the three-way handshake is complete. In other words, the randomly chosen channel IDs act as tags (cf. [RFC4960] (Section 5.1)).
同伴A现在知道同伴B真的回应了，因为它回应了chanA。因此，对等方A发送的下一个数据报可能已经包含大量有效负载，即块。发送给对等方B的下一个数据报将以chanB通道ID作为前缀。当对等方B收到该数据报时，两个对等方都有证据证明他们确实在相互交谈，三方握手完成。换句话说，随机选择的信道id充当标签（参见[RFC4960]（第5.1节））。
A->B: chanB + HAVE + DATA + ...
A->B:chanB+拥有+数据+。。。
In short, PPSPP does a so-called return routability check before heavy payload is sent. This means that attack 1 is fended off: PPSPP does not send back much more data than it received, unless it knows it is talking to a live peer. Attackers sending a spoofed HANDSHAKE to Peer B pretending to be Peer A now need to intercept the message
简言之，PPSPP在发送重负载之前进行所谓的返回路由性检查。这意味着攻击1被击退：PPSPP发送回的数据不会比接收到的数据多得多，除非它知道它正在与一个活动的对等方通话。攻击者向假装为对等方a的对等方B发送伪造握手，现在需要拦截该消息
from Peer B to Peer A to get Peer B to send heavy payload, and ensure that that heavy payload goes to the victim, something assumed too hard to be a practical attack.
从对等点B到对等点A，让对等点B发送沉重的负载，并确保沉重的负载传递给受害者，这被认为是很难成为实际的攻击。
Note the rule is that no heavy payload may be sent until the third datagram. This has implications for PPSPP implementations that use chunk addressing schemes that are verbose. If a PPSPP implementation uses large bitmaps to convey chunk availability, these may not be sent by Peer B in the second datagram.
注意，规则是在第三个数据报之前，不可能发送任何重负载。这对使用冗长的块寻址方案的PPSP实现有影响。如果PPSPP实现使用大型位图来传递区块可用性，则这些位图可能不会由第二个数据报中的对等方B发送。
On receiving the first datagram Peer B will record some state about Peer A. At present, this state consists of the chanA channel ID, and the results of processing the other messages in the first datagram. In particular, if Peer A included some HAVE messages, Peer B may add a chunk availability map to Peer A's state. In addition, Peer B may request some chunks from Peer A in the second datagram, and Peer B will maintain state about these outgoing requests.
在接收到第一个数据报时，对等方B将记录关于对等方A的一些状态。目前，该状态由chanA通道ID和处理第一个数据报中其他消息的结果组成。特别是，如果对等方A包含一些HAVE消息，则对等方B可以向对等方A的状态添加块可用性映射。此外，对等方B可以在第二个数据报中从对等方A请求一些数据块，对等方B将维护关于这些传出请求的状态。
So presently, PPSPP is somewhat vulnerable to attack 2. An attacker could send many datagrams with HANDSHAKEs and HAVEs and thus allocate state at the PPSPP peer. Therefore, Peer A MUST respond immediately to the second datagram, if it is still interested in Peer B.
因此，目前PPSPP有点容易受到攻击2。攻击者可以通过握手和have发送许多数据报，从而在PPSPP对等点分配状态。因此，如果对等方A仍然对对等方B感兴趣，它必须立即响应第二个数据报。
The reason for using this slightly vulnerable three-way handshake instead of the safer handshake procedure of Stream Control Transmission Protocol (SCTP) [RFC4960] (Section 5.1) is quicker response time for the user. In the SCTP procedure, Peers A and B cannot request chunks until datagrams 3 and 4 respectively, as opposed to 2 and 1 in the proposed procedure. This means that the user has to wait less time in PPSPP between starting the video stream and seeing the first images.
使用这种略微易受攻击的三向握手而不是流控制传输协议（SCTP）[RFC4960]（第5.1节）中更安全的握手过程的原因是用户的响应时间更快。在SCTP过程中，对等方A和B分别在数据报3和4之前不能请求数据块，而在建议的过程中则是2和1。这意味着用户在PPSP中从开始视频流到看到第一幅图像之间的等待时间更短。
In general, channel IDs serve to authenticate a peer. Hence, to attack, a malicious Peer T would need to be able to eavesdrop on conversations between victim A and a benign Peer B to obtain the channel ID Peer B assigned to Peer A, chanB. Furthermore, attacker Peer T would need to be able to spoof, e.g., REQUEST and HAVE messages from Peer A to cause Peer B to send heavy DATA messages to Peer A, or prevent Peer B from sending them, respectively.
通常，通道ID用于对对等方进行身份验证。因此，为了进行攻击，恶意对等方T需要能够窃听受害者a和良性对等方B之间的对话，以获得分配给对等方a、chanB的信道ID对等方B。此外，攻击者Peer T需要能够欺骗，例如，请求并拥有来自Peer A的消息，以导致Peer B向Peer A发送重数据消息，或阻止Peer B分别发送重数据消息。
The capability to eavesdrop is not common, so the protection afforded by channel IDs will be sufficient in most cases. If not, point-to-point encryption of traffic should be used, see below.
窃听功能并不常见，因此在大多数情况下，通道ID提供的保护就足够了。如果不是，则应使用通信量的点对点加密，见下文。
As described in Section 3.10, Peer A can send Peer-Exchange messages PEX_RES to Peer B, which contain the IP address and port of other peers that are supposedly also in the current swarm. The strength of this mechanism is that it allows decentralized tracking: after an initial bootstrap, no central tracker is needed. The vulnerability of this mechanism (and DHTs) is that malicious peers can use it for an Amplification attack.
如第3.10节所述，对等方A可以向对等方B发送对等交换消息PEX_RES，其中包含假定也在当前swarm中的其他对等方的IP地址和端口。这种机制的优势在于它允许分散跟踪：在初始引导后，不需要中央跟踪器。此机制（和DHTs）的漏洞在于恶意对等方可以使用它进行放大攻击。
In particular, a malicious Peer T could send PEX_RES messages to well-behaved Peer A with addresses of Peers B1..Bn; on receipt, Peer A could send a HANDSHAKE to all these peers. So, in the worst case, a single datagram results in N datagrams. The actual damage depends on Peer A's behavior. For example, when Peer A already has sufficient connections, it may not connect to the offered ones at all; but if it is a fresh peer, it may connect to all directly.
特别是，恶意对等方T可以向行为良好的对等方a发送PEX_RES消息，地址为对等方B1..Bn；收到后，对等方A可以向所有这些对等方发送握手。因此，在最坏的情况下，一个数据报产生N个数据报。实际损害取决于同伴A的行为。例如，当对等方A已经有足够的连接时，它可能根本无法连接到提供的连接；但如果它是一个新的对等点，它可能会直接连接到所有节点。
In addition, PEX can be used in Eclipse attacks [ECLIPSE] where malicious peers try to isolate a particular peer such that it only interacts with malicious peers. Let us distinguish two specific attacks:
此外，PEX可用于Eclipse攻击[Eclipse]，恶意对等方试图隔离特定对等方，使其仅与恶意对等方交互。让我们区分两种特定的攻击：
E1. Malicious peers try to eclipse the single injector in live streaming.
E1。恶意对等方试图在实时流媒体中掩盖单个注入器。
E2. Malicious peers try to eclipse a specific consumer peer.
E2。恶意对等方试图超越特定的消费者对等方。
Attack E1 has the most impact on the system as it would disrupt all peers.
攻击E1对系统的影响最大，因为它会破坏所有对等方。
If peer addresses are relatively stable, strong protection against the attack can be provided by using public key cryptography and certification. In particular, a PEX_REScert message will carry swarm-membership certificates rather than IP address and port. A membership certificate for Peer B states that Peer B at address (ipB,portB) is part of Swarm S at Time T and is cryptographically signed. The receiver Peer A can check the certificate for a valid signature, the right swarm and liveliness, and only then consider contacting Peer B. These swarm-membership certificates correspond to signed node descriptors in secure decentralized peer sampling services [SPS].
如果对等地址相对稳定，则可以通过使用公钥加密和认证来提供针对攻击的强大保护。特别是，PEX_REScert消息将携带swarm成员资格证书，而不是IP地址和端口。对等方B的成员资格证书表明，地址（ipB，portB）处的对等方B在时间T是Swarm S的一部分，并且经过加密签名。接收者对等体A可以检查证书的有效签名、正确群体和活跃性，并且只考虑联系对等体B。这些群成员证书对应于安全分散的对等采样服务[SSP]中的签名节点描述符。
Several designs are possible for the security environment for these membership certificates. That is, there are different designs possible for who signs the membership certificates and how public keys are distributed. As an example, we describe a design where the peer-to-peer streaming protocol tracker acts as certification authority.
这些成员资格证书的安全环境有多种设计。也就是说，对于谁签署会员证书以及如何分发公钥，可能有不同的设计。作为一个例子，我们描述了一个设计，其中对等流协议跟踪器充当证书颁发机构。
Peer A wanting to join Swarm S sends a certificate request message to a Tracker X for that swarm. Upon receipt, the tracker creates a membership certificate from the request with Swarm ID S, a Timestamp T, and the external IP and port it received the message from, signed with the tracker's private key. This certificate is returned to Peer A.
想要加入Swarm S的对等方A向该Swarm的跟踪器X发送证书请求消息。收到后，跟踪器将根据请求创建一个成员资格证书，其中包含Swarm ID S、时间戳T以及接收消息的外部IP和端口，并使用跟踪器的私钥进行签名。此证书将返回给对等方A。
Peer A then includes this certificate when it sends a PEX_REScert to Peer B. Receiver Peer B verifies it against the tracker public key. This tracker public key should be part of the swarm's metadata, which Peer B received from a trusted source. Subsequently, Peer B can send the member certificate of Peer A to other peers in PEX_REScert messages.
然后，对等方A在向对等方B发送PEX_重新扫描时包含该证书。接收方对等方B根据跟踪器公钥验证该证书。该跟踪器公钥应该是swarm元数据的一部分，对等方B从可信来源接收元数据。随后，对等方B可以在PEX_Resert消息中将对等方A的成员证书发送给其他对等方。
Peer A can send the certification request when it first contacts the tracker or at a later time. Furthermore, the responses the tracker sends could contain membership certificates instead of plain addresses, such that they can be gossiped securely as well.
对等方A可以在第一次联系跟踪器时或稍后发送认证请求。此外，跟踪器发送的响应可能包含成员资格证书而不是普通地址，因此它们也可以被安全地传播。
We assume the tracker is protected against attacks and does a return routability check. The latter ensures that malicious peers cannot obtain a certificate for a random host, just for hosts where they can eavesdrop on incoming traffic.
我们假设跟踪器受到攻击保护，并进行返回路由性检查。后者可确保恶意对等方无法为随机主机获取证书，仅针对可以窃听传入流量的主机。
The load generated on the tracker depends on churn and the lifetime of a certificate. Certificates can be fairly long lived, given that the main goal of the membership certificates is to prevent that malicious Peer T can cause good Peer A to contact *random* hosts. The freshness of the timestamp just adds extra protection in addition to achieving that goal. It protects against malicious hosts causing a good Peer A to contact hosts that previously participated in the swarm.
跟踪器上生成的负载取决于搅动和证书的生存期。鉴于成员资格证书的主要目标是防止恶意对等方T导致好的对等方A接触*随机*主机，因此证书的寿命可能相当长。时间戳的新鲜度只是在实现这一目标的同时增加了额外的保护。它可以防止恶意主机导致良好的对等方a联系以前参与swarm的主机。
The membership certificate mechanism itself can be used for a kind of amplification attack against good peers. Malicious Peer T can cause Peer A to spend some CPU to verify the signatures on the membership certificates that Peer T sends. To counter this, Peer A SHOULD check a few of the certificates sent and discard the rest if they are defective.
成员资格证书机制本身可以用于针对好的对等方的一种放大攻击。恶意的Peer T会导致Peer A花费一些CPU来验证Peer T发送的成员资格证书上的签名。为了解决这个问题，对等方A应该检查发送的一些证书，如果其余的证书有缺陷，就丢弃它们。
The same membership certificates described above can be registered in a Distributed Hash Table that has been secured against the well-known DHT specific attacks [SECDHTS].
可以在分布式哈希表中注册上述相同的成员资格证书，该哈希表已针对众所周知的DHT特定攻击[SECDHTS]进行了保护。
Note that this scheme does not work for peers behind a symmetric Network Address Translator, but neither does normal tracker registration.
请注意，此方案不适用于对称网络地址转换器后面的对等方，但正常的跟踪器注册也不适用。
Before we can discuss Eclipse attacks, we first need to establish the security properties of the central tracker. A tracker is vulnerable to Amplification attacks, too. A malicious Peer T could register a victim Peer B with the tracker, and many peers joining the swarm will contact Peer B. Trackers can also be used in Eclipse attacks. If many malicious peers register themselves at the tracker, the percentage of bad peers in the returned address list may become high. Leaving the protection of the tracker to the peer-to-peer streaming protocol tracker specification [PPSP-TP], we assume for the following discussion that it returns a true random sample of the actual swarm membership (achieved via Sybil attack protection). This means that if 50% of the peers are bad, you'll still get 50% good addresses from the tracker.
在讨论Eclipse攻击之前，我们首先需要建立中央跟踪器的安全属性。追踪器也容易受到放大攻击。恶意节点T可以向跟踪器注册受害者节点B，许多加入群的节点将联系节点B。跟踪器也可以用于Eclipse攻击。如果许多恶意对等点在跟踪器中注册，则返回的地址列表中的坏对等点的百分比可能会很高。将跟踪器的保护留给对等流协议跟踪器规范[PPSP-TP]，在下面的讨论中，我们假设它返回实际群成员的真实随机样本（通过Sybil攻击保护实现）。这意味着，如果50%的对等方是坏的，您仍然可以从跟踪器中获得50%的好地址。
Attack E1 on PEX can be fended off by letting live injectors disable PEX -- or at least, letting live injectors ensure that part of their connections are to peers whose addresses came from the trusted tracker.
通过让带电注入器禁用PEX，或者至少让带电注入器确保其部分连接到地址来自可信跟踪器的对等方，可以抵御PEX上的E1攻击。
The same measures defend against attack E2 on PEX. They can also be employed dynamically. When the current set of Peers B that Peer A is connected to doesn't provide good quality of service, Peer A can contact the tracker to find new candidates.
同样的措施可以抵御PEX上的E2攻击。它们也可以动态使用。当对等点A连接到的当前对等点B不能提供高质量的服务时，对等点A可以联系跟踪器以查找新的候选点。
Regarding PPSP.SEC.REQ-1 in [RFC6972], the Closed Swarms [CLOSED] and Enhanced Closed Swarms [ECS] mechanisms provide swarm-level access control. The basic idea is that a peer cannot download from another peer unless it shows a Proof-of-Access. Enhanced Closed Swarms improve on the original Closed Swarms by adding on-the-wire encryption against man-in-the-middle attacks and more flexible access control rules.
关于[RFC6972]中的PPSP.SEC.REQ-1，封闭群[Closed]和增强型封闭群[ECS]机制提供群级访问控制。其基本思想是，一个对等方不能从另一个对等方下载，除非它显示访问证明。增强的封闭群通过添加针对中间人攻击的有线加密和更灵活的访问控制规则，改进了原始封闭群。
The exact mapping of ECS to PPSPP is defined in [ECS-protocol].
ECS到PPSP的精确映射在[ECS协议]中定义。
Regarding PPSP.SEC.REQ-1 in [RFC6972], no extra mechanism is needed to support confidentiality in PPSPP. A content publisher wishing confidentiality should just distribute content in ciphertext and/or in a format to which Digital Rights Management (DRM) techniques have been applied. In that case, it is assumed a higher layer handles key management out-of-band. Alternatively, pure point-to-point encryption of content and traffic can be provided by the proposed Closed Swarms access control mechanism, by DTLS [RFC6347], or by IPsec [RFC4301].
关于[RFC6972]中的PPSP.SEC.REQ-1，不需要额外的机制来支持PPSP中的保密性。希望保密的内容发布者应仅以密文和/或应用数字版权管理（DRM）技术的格式发布内容。在这种情况下，假定更高层处理带外密钥管理。或者，内容和通信量的纯点对点加密可以由提议的封闭群集访问控制机制、DTLS[RFC6347]或IPsec[RFC4301]提供。
When transmitting over DTLS, PPSPP can obtain the PMTU estimate maintained by the IP layer to determine how much payload can be put in a single datagram without fragmentation ([RFC6347], Section 4.1.1.1). If PMTU changes and the chunk size becomes too large to fit into a single datagram, PPSPP can choose to allow fragmentation by clearing the Don't Fragment (DF) bit. Alternatively, the content publisher can decide to use smaller chunks and transmit multiple in the same datagram when the MTU allows.
当通过DTLS传输时，PPSPP可以获得由IP层维护的PMTU估计值，以确定在没有碎片的情况下单个数据报中可以放入多少有效负载（[RFC6347]，第4.1.1.1节）。如果PMTU发生变化，块大小变得太大，无法容纳单个数据报，PPSPP可以通过清除不分段（DF）位来选择允许分段。或者，当MTU允许时，内容发布者可以决定使用较小的块并在同一数据报中传输多个块。
Implementations MUST support SHA-1 as the hash function for content integrity protection via Merkle hash trees. SHA-1 may be preferred over stronger hash functions by content providers because it reduces on-the-wire overhead. As such, it presents a trade-off between performance and security. The security considerations for SHA-1 are discussed in [RFC6194].
实现必须支持SHA-1作为通过Merkle哈希树保护内容完整性的哈希函数。内容提供商可能更喜欢SHA-1而不是更强的哈希函数，因为它减少了在线开销。因此，它在性能和安全性之间进行了权衡。[RFC6194]中讨论了SHA-1的安全注意事项。
In general, note that the hash function is used in a hash tree, which makes it more complex to create collisions. In particular, if attackers manage to find a collision for a hash, it can replace just one chunk, so the impact is limited. If fixed-size chunks are used, the collision even has to be of the same size as the original chunk. For hashes higher up in the hash tree, a collision must be a concatenation of two hashes. In sum, finding collisions that fit with the hash tree are generally harder to find than regular collisions.
通常，请注意哈希函数用于哈希树，这使得创建冲突更加复杂。特别是，如果攻击者设法找到散列的冲突，它只能替换一个块，因此影响是有限的。如果使用固定大小的块，冲突甚至必须与原始块大小相同。对于哈希树中较高的哈希，冲突必须是两个哈希的串联。总之，查找符合哈希树的冲突通常比查找常规冲突更难。
12.6. Limit Potential Damage and Resource Exhaustion by Bad or Broken Peers
12.6. 限制坏节点或坏节点造成的潜在损害和资源消耗
Regarding PPSP.SEC.REQ-2 in [RFC6972], this section provides an analysis of the potential damage a malicious peer can do with each message in the protocol, and how it is prevented by the protocol (implementation).
关于[RFC6972]中的PPSP.SEC.REQ-2，本节分析了恶意对等方对协议中每条消息可能造成的潜在损害，以及协议如何防止这种损害（实现）。
o Secured against DoS Amplification attacks as described in Section 12.1.
o 如第12.1节所述，防止DoS放大攻击。
o Threat HS.1: An Eclipse attack where Peers T1..Tn fill all connection slots of Peer A by initiating the connection to Peer A.
o 威胁HS.1：一种Eclipse攻击，其中对等方T1..Tn通过启动与对等方A的连接来填充对等方A的所有连接槽。
Solution: Peer A must not let other peers fill all its available connection slots, i.e., Peer A must initiate connections itself too, to prevent isolation.
解决方案：对等方A不得让其他对等方填满其所有可用的连接插槽，即对等方A也必须自己启动连接，以防止隔离。
o Threat HAVE.1: Malicious Peer T can claim to have content that it does not. Subsequently, Peer T won't respond to requests.
o 威胁。1：恶意对等方T可以声称拥有其不拥有的内容。随后，对等T不会响应请求。
Solution: Peer A will consider Peer T to be a slow peer and not ask it again.
解决方案：Peer-A会认为Peer-T是一个缓慢的对等体，而不是再问它。
o Threat HAVE.2: Malicious Peer T can claim not to have content. Hence, it won't contribute.
o 威胁2：恶意的对等方T可以声称没有内容。因此，它不会起作用。
Solution: Peer and chunk selection algorithms external to the protocol will implement fairness and provide sharing incentives.
解决方案：协议外部的对等和区块选择算法将实现公平性并提供共享激励。
o Threat DATA.1: Peer T sending bogus chunks.
o 威胁数据。1：对等方发送虚假数据块。
Solution: The content integrity protection schemes defend against this.
解决方案：内容完整性保护方案可以防止这种情况。
o Threat DATA.2: Peer T sends Peer A unrequested chunks.
o 威胁数据。2：对等T向对等发送未请求的数据块。
To protect against this threat we need network-level DoS prevention.
为了防止这种威胁，我们需要网络级DoS预防。
o Threat ACK.1: Peer T acknowledges wrong chunks.
o 威胁确认1：对等T确认错误块。
Solution: Peer A will detect inconsistencies with the data it sent to Peer T.
解决方案：对等方A将检测发送给对等方T的数据的不一致性。
o Threat ACK.2: Peer T modifies timestamp in ACK to Peer A used for time-based congestion control.
o 威胁确认。2：对等T修改确认中的时间戳，以对等A用于基于时间的拥塞控制。
Solution: In theory, by decreasing the timestamp, Peer T could fake that there is no congestion when in fact there is, causing Peer A to send more data than it should. [RFC6817] does not list this as a security consideration. Possibly, this attack can be detected by the large resulting asymmetry between round-trip time and measured one-way delay.
解决方案：从理论上讲，通过减少时间戳，对等方T可以假装没有拥塞，而实际上没有，从而导致对等方A发送的数据比它应该发送的更多。[RFC6817]未将此列为安全考虑因素。很可能，这种攻击可以通过往返时间和测量的单向延迟之间的巨大不对称性来检测。
o Threat INTEGRITY.1: An amplification attack where Peer T sends bogus INTEGRITY or SIGNED_INTEGRITY messages, causing Peer A to checks hashes or signatures, thus spending CPU unnecessarily.
o 威胁完整性。1：一种放大攻击，其中对等方T发送虚假完整性或签名完整性消息，导致对等方A检查哈希或签名，从而不必要地花费CPU。
Solution: If the hashes/signatures don't check out, Peer A will stop asking Peer T because of the atomic datagram principle and the content integrity protection. Subsequent unsolicited traffic from Peer T will be ignored.
解决方案：如果哈希/签名没有签出，由于原子数据报原理和内容完整性保护，对等方A将停止询问对等方t。来自对等T的后续未经请求的流量将被忽略。
o Threat INTEGRITY.2: An attack where Peer T sends old SIGNED_INTEGRITY messages in the Unified Merkle Tree scheme, trying to make Peer A tune in at a past point in the live stream.
o 威胁完整性。2：一种攻击，其中对等方T在统一Merkle树方案中发送旧的签名完整性消息，试图使对等方在实时流中的过去点进行调谐。
Solution: The timestamp in the SIGNED_INTEGRITY message protects against such replays. Subsequent traffic from Peer T will be ignored.
解决方案：签名的完整性消息中的时间戳可防止此类重播。来自对等T的后续流量将被忽略。
o Threat REQUEST.1: Peer T could request lots from Peer A, leaving Peer A without resources for others.
o 威胁请求。1：对等T可以从对等A请求很多，使对等A没有其他资源。
Solution: A limit is imposed on the upload capacity a single peer can consume, for example, by using an upload bandwidth scheduler that takes into account the need of multiple peers. A natural upper limit of this upload quotum is the bitrate of the content, taking into account that this may be variable.
解决方案：对单个对等方可以使用的上载容量施加限制，例如，通过使用考虑多个对等方需要的上载带宽调度器。考虑到内容的比特率可能是可变的，上传quotum的自然上限是内容的比特率。
o Threat CANCEL.1: Peer T sends CANCEL messages for content it never requested to Peer A.
o 威胁取消。1：对等方T向其从未请求过对等方A的内容发送取消消息。
Solution: Peer A will detect the inconsistency of the messages and ignore them. Note that CANCEL messages may be received unexpectedly when a transport is used where REQUEST messages may be lost or reordered with respect to the subsequent CANCELs.
解决方案：对等A将检测消息的不一致性并忽略它们。请注意，当使用传输时，可能会意外地接收到取消消息，其中请求消息可能会丢失或根据后续取消重新排序。
o Threat CHOKE.1: Peer T sends REQUEST messages after Peer A sent Peer B a CHOKE message.
o 威胁阻塞。1：对等方T在对等方A发送对等方B阻塞消息之后发送请求消息。
Solution: Peer A will just discard the unwanted REQUESTs and resend the CHOKE, assuming it got lost.
解决方案：对等A将丢弃不需要的请求，并重新发送阻塞，假设它丢失了。
o Threat UNCHOKE.1: Peer T sends an UNCHOKE message to Peer A without having sent a CHOKE message before.
o 威胁解除锁定。1：对等方T向对等方A发送解除锁定消息，之前未发送阻塞消息。
Solution: Peer A can easily detect this violation of protocol state, and ignore it. Note this can also happen due to loss of a CHOKE message sent by a benign peer.
解决方案：对等方A可以很容易地检测到这种违反协议状态的情况，并忽略它。注意，由于良性对等方发送的阻塞消息丢失，也可能发生这种情况。
o Threat UNCHOKE.2: Peer T sends an UNCHOKE message to Peer A, but subsequently does not respond to its REQUESTs.
o 威胁解除锁定。2：对等T向对等A发送解除锁定消息，但随后不响应其请求。
Solution: Peer A will consider Peer T to be a slow peer and not ask it again.
解决方案：Peer-A会认为Peer-T是一个缓慢的对等体，而不是再问它。
o Secured against amplification and Eclipse attacks as described in Section 12.2.
o 如第12.2节所述，防止放大和Eclipse攻击。
o Threat: Peer T could send a spoofed PEX_REQ or REQUEST from Peer B to Peer A, causing Peer A to send a PEX_RES/DATA to Peer B.
o 威胁：对等方T可能从对等方B向对等方a发送伪造的PEX_请求或请求，导致对等方a向对等方B发送PEX_请求/数据。
Solution: the message from Peer T won't be accepted unless Peer T does a handshake first, in which case the reply goes to Peer T, not victim Peer B.
解决方案：除非对等方T首先进行握手，否则不会接受来自对等方T的消息，在这种情况下，应答将转到对等方T，而不是受害者对等方B。
This section is regarding PPSP.SEC.REQ-2 in [RFC6972]. A receiving peer can detect malicious or faulty senders as just described, which it can then subsequently ignore. However, excluding such a bad peer from the system completely is complex. Random monitoring by trusted peers that would blacklist bad peers as described in [DETMAL] is one option. This mechanism does require extra capacity to run such trusted peers, which must be indistinguishable from regular peers, and requires a solution for the timely distribution of this blacklist to peers in a scalable manner.
本节涉及[RFC6972]中的PPSP.SEC.REQ-2。接收对等方可以检测恶意或有故障的发送方，如前所述，随后可以忽略这些发送方。然而，从系统中完全排除这样一个坏节点是复杂的。如[DETMAL]所述，由可信对等方进行随机监控，将坏对等方列入黑名单是一种选择。此机制确实需要额外的容量来运行此类受信任的对等点，而这些对等点必须与常规对等点无法区分，并且需要一种解决方案，以便以可扩展的方式将此黑名单及时分发给对等点。
[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.
[CCITT.X690.2002]国际电话电报咨询委员会，“ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，CCITT建议X.690，2002年7月。
[FIPS180-4] National Institute of Standards and Technology, Information Technology Laboratory, "Federal Information Processing Standards: Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012.
[FIPS180-4]国家标准与技术研究所，信息技术实验室，“联邦信息处理标准：安全哈希标准（SHS）”，FIPS PUB 180-42012年3月。
[IANADNSSECALGNUM] IANA, "Domain Name System Security (DNSSEC) Algorithm Numbers", March 2014, <http://www.iana.org/assignments/dns-sec-alg-numbers>.
[IANADNSSECALGNUM]IANA，“域名系统安全（DNSSEC）算法编号”，2014年3月<http://www.iana.org/assignments/dns-sec-alg-numbers>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，J.de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, May 2001, <http://www.rfc-editor.org/info/rfc3110>.
[RFC3110]Eastlake 3rd，D.，“域名系统（DNS）中的RSA/SHA-1 SIGs和RSA密钥”，RFC 3110，DOI 10.17487/RFC3110，2001年5月<http://www.rfc-editor.org/info/rfc3110>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<http://www.rfc-editor.org/info/rfc4034>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, DOI 10.17487/RFC5702, October 2009, <http://www.rfc-editor.org/info/rfc5702>.
[RFC5702]Jansen，J.，“在DNSSEC的DNSKEY和RRSIG资源记录中使用带有RSA的SHA-2算法”，RFC 5702，DOI 10.17487/RFC5702，2009年10月<http://www.rfc-editor.org/info/rfc5702>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<http://www.rfc-editor.org/info/rfc5905>.
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012, <http://www.rfc-editor.org/info/rfc6605>.
[RFC6605]Hoffman，P.和W.Wijngaards，“DNSSEC的椭圆曲线数字签名算法（DSA）”，RFC 6605，DOI 10.17487/RFC6605，2012年4月<http://www.rfc-editor.org/info/rfc6605>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://www.rfc-editor.org/info/rfc6817>.
[RFC6817]Shalunov，S.，Hazel，G.，Iyengar，J.，和M.Kuehlewind，“低额外延迟背景传输（LEDBAT）”，RFC 6817，DOI 10.17487/RFC6817，2012年12月<http://www.rfc-editor.org/info/rfc6817>.
[ABMRKL] Bakker, A., "Merkle hash torrent extension", BitTorrent Enhancement Proposal 30, March 2009, <http://bittorrent.org/beps/bep_0030.html>.
[ABMRKL]Bakker，A.，“Merkle hash torrent扩展”，BitTorrent增强提案，2009年3月30日<http://bittorrent.org/beps/bep_0030.html>.
[BINMAP] Grishchenko, V. and J. Pouwelse, "Binmaps: Hybridizing Bitmaps and Binary Trees", Delft University of Technology Parallel and Distributed Systems Report Series, Report number PDS-2011-005, ISSN 1387-2109, April 2009.
Grishchenko，V.和J. Pouwelse，“Binmaps：Hybridizing Bitmaps和二叉树”，代尔夫特理工大学并行和分布式系统报告系列，报告编号PDS2011-05，ISSN 13872109，2009年4月。
[BITOS] Vlavianos, A., Iliofotou, M., Mathieu, F., and M. Faloutsos, "BiToS: Enhancing BitTorrent for Supporting Streaming Applications", IEEE INFOCOM Global Internet Symposium, Barcelona, Spain, April 2006.
[BITOS]Vlavianos，A.，Iliofotou，M.，Mathieu，F.，和M.Falutsos，“BITOS：增强BitTorrent以支持流媒体应用”，IEEE INFOCOM全球互联网研讨会，西班牙巴塞罗那，2006年4月。
[BITTORRENT] Cohen, B., "The BitTorrent Protocol Specification", BitTorrent Enhancement Proposal 3, February 2008, <http://bittorrent.org/beps/bep_0003.html>.
[BITTORRENT]Cohen，B.，“BITTORRENT协议规范”，BITTORRENT增强提案3，2008年2月<http://bittorrent.org/beps/bep_0003.html>.
[CLOSED] Borch, N., Mitchell, K., Arntzen, I., and D. Gabrijelcic, "Access Control to BitTorrent Swarms Using Closed Swarms", ACM workshop on Advanced Video Streaming Techniques for Peer-to-Peer Networks and Social Networking (AVSTP2P '10), Florence, Italy, October 2010, <http://doi.acm.org/10.1145/1877891.1877898>.
[闭门]Borch，N.，Mitchell，K.，Arntzen，I.，和D.Gabrijelcic，“使用闭门群集对BitTorrent群集进行访问控制”，ACM关于点对点网络和社交网络的高级视频流技术研讨会（AVSTP2P'10），意大利佛罗伦萨，2010年10月<http://doi.acm.org/10.1145/1877891.1877898>.
[DETMAL] Shetty, S., Galdames, P., Tavanapong, W., and Ying. Cai, "Detecting Malicious Peers in Overlay Multicast Streaming", IEEE Conference on Local Computer Networks, (LCN'06), Tampa, FL, USA, November 2006.
[细节]谢蒂，S.，盖尔达姆斯，P.，塔瓦纳邦，W.，和英。Cai，“在覆盖多播流中检测恶意对等点”，IEEE本地计算机网络会议，（LCN'06），美国佛罗里达州坦帕，2006年11月。
[ECLIPSE] Sit, E. and R. Morris, "Security Considerations for Peer-to-Peer Distributed Hash Tables", IPTPS '01: Revised Papers from the First International Workshop on Peer-to-Peer Systems, pp. 261-269, Springer-Verlag, 2002.
[ECLIPSE]Sit，E.和R.Morris，“点对点分布式哈希表的安全注意事项”，IPTPS'01：第一届点对点系统国际研讨会的修订论文，第261-269页，Springer Verlag，2002年。
[ECS] Jovanovikj, V., Gabrijelcic, D., and T. Klobucar, "Access Control in BitTorrent P2P Networks Using the Enhanced Closed Swarms Protocol", International Conference on Emerging Security Information, Systems and Technologies (SECURWARE 2011), pp. 97-102, Nice, France, August 2011.
[ECS]Jovanovikj，V.，Gabrijelcic，D.，和T.Klobucar，“使用增强型封闭群协议的BitTorrent P2P网络访问控制”，新兴安全信息、系统和技术国际会议（SECURWARE 2011），第97-102页，法国尼斯，2011年8月。
[ECS-protocol] Gabrijelcic, D., "Enhanced Closed Swarm protocol", Work in Progress, draft-ppsp-gabrijelcic-ecs-01, June 2013.
[ECS协议]Gabrijelcic，D.，“增强型封闭群协议”，正在进行的工作，草稿-ppsp-Gabrijelcic-ECS-012013年6月。
[EPLIVEPERF] Bonald, T., Massoulie, L., Mathieu, F., Perino, D., and A. Twigg, "Epidemic live streaming: optimal performance trade-offs", Proceedings of the 2008 ACM SIGMETRICS International Conference on Measurement and Modeling of Computer Systems, Annapolis, MD, USA, June 2008.
[EPLIVEPERF]Bonald，T.，Massoulie，L.，Mathieu，F.，Perino，D.，和A.Twigg，“流行病直播：最佳性能权衡”，2008年ACM SIGMETRICS国际计算机系统测量和建模会议记录，马里兰州安纳波利斯，美国，2008年6月。
[GIVE2GET] Mol, J., Pouwelse, J., Meulpolder, M., Epema, D., and H. Sips, "Give-to-Get: Free-riding-resilient Video-on-Demand in P2P Systems", Proceedings Multimedia Computing and Networking conference (Proceedings of SPIE, Vol. 6818), San Jose, CA, USA, January 2008.
[GIVE2GET]Mol，J.，Pouwelse，J.，Meulpolder，M.，Epema，D.，和H.Sips，“给予即得：P2P系统中的免费弹性视频点播”，多媒体计算和网络会议论文集（SPIE论文集，第6818卷），美国加利福尼亚州圣何塞，2008年1月。
[HAC01] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, (Fifth Printing, August 2001), October 1996.
[HAC01]Menezes，A.，van Oorschot，P.，和S.Vanstone，“应用密码学手册”，CRC出版社，（第五次印刷，2001年8月），1996年10月。
[JIM11] Jimenez, R., Osmani, F., and B. Knutsson, "Sub-Second Lookups on a Large-Scale Kademlia-Based Overlay", IEEE International Conference on Peer-to-Peer Computing (P2P'11), Kyoto, Japan, August 2011.
[JIM11]Jimenez，R.，Osmani，F.，和B.Knutsson，“基于Kademlia的大规模覆盖的亚秒级查找”，IEEE对等计算国际会议（P2P'11），日本京都，2011年8月。
[LBT] Rossi, D., Testa, C., Valenti, S., and L. Muscariello, "LEDBAT: the new BitTorrent congestion control protocol", Computer Communications and Networks (ICCCN), Zurich, Switzerland, August 2010.
[LBT]Rossi，D.，Testa，C.，Valenti，S.，和L.Muscariello，“LEDBAT：新的BitTorrent拥塞控制协议”，计算机通信和网络（ICCCN），瑞士苏黎世，2010年8月。
[LCOMPL] Testa, C. and D. Rossi, "On the impact of uTP on BitTorrent completion time", IEEE International Conference on Peer-to-Peer Computing (P2P'11), Kyoto, Japan, August 2011.
[LCOMPL]Testa，C.和D.Rossi，“uTP对BitTorrent完成时间的影响”，IEEE对等计算国际会议（P2P'11），日本京都，2011年8月。
[MERKLE] Merkle, R., "Secrecy, Authentication, and Public Key Systems", Ph.D. thesis, Dept. of Electrical Engineering, Stanford University, CA, USA, pp 40-45, 1979.
[MERKLE]MERKLE，R.，“保密、认证和公钥系统”，博士。美国加州斯坦福大学电气工程系论文，第40-451979页。
[P2PWIKI] Bakker, A., Petrocco, R., Dale, M., Gerber, J., Grishchenko, V., Rabaioli, D., and J. Pouwelse, "Online video using BitTorrent and HTML5 applied to Wikipedia", IEEE International Conference on Peer-to-Peer Computing (P2P'10), Delft, The Netherlands, August 2010.
[P2PWIKI]Bakker，A.，Petrocco，R.，Dale，M.，Gerber，J.，Grishchenko，V.，Rabaioli，D.，和J.Pouwelse，“将BitTorrent和HTML5应用于维基百科的在线视频”，IEEE对等计算国际会议（P2P'10），荷兰代尔夫特，2010年8月。
[POLLIVE] Dhungel, P., Hei, Xiaojun., Ross, K., and N. Saxena, "Pollution in P2P Live Video Streaming", International Journal of Computer Networks & Communications (IJCNC) Vol. 1, No. 2, Jul 2009.
[POLLIVE]Dhungel，P.，Hei，Xiaojun.，Ross，K.，和N.Saxena，“P2P实时视频流中的污染”，国际计算机网络与通信杂志（IJCNC）第1卷，第2期，2009年7月。
[PPSP-TP] Cruz, R., Nunes, M., Yingjie, G., Xia, J., Huang, R., Taveira, J., and D. Lingli, "PPSP Tracker Protocol-Base Protocol (PPSP-TP/1.0)", Work in Progress, draft-ietf-ppsp-base-tracker-protocol-09, March 2015.
[PPSP-TP]Cruz，R.，Nunes，M.，Yingjie，G.，Xia，J.，Huang，R.，Taveira，J.，和D.Lingli，“PPSP跟踪器协议基础协议（PPSP-TP/1.0）”，正在进行的工作，草案-ietf-PPSP-Base-Tracker-Protocol-092015年3月。
[PPSPPERF] Petrocco, R., Pouwelse, J., and D. Epema, "Performance Analysis of the Libswift P2P Streaming Protocol", IEEE International Conference on Peer-to-Peer Computing (P2P'12), Tarragona, Spain, September 2012.
[PPSPPERF]Petrocco，R.，Pouwelse，J.，和D.Epema，“Libswift P2P流媒体协议的性能分析”，IEEE对等计算国际会议（P2P'12），西班牙塔拉戈纳，2012年9月。
[RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. Saperia, "Application Management MIB", RFC 2564, DOI 10.17487/RFC2564, May 1999, <http://www.rfc-editor.org/info/rfc2564>.
[RFC2564]Kalbflesch，C.，Krupczak，C.，Presohn，R.，和J.Saperia，“应用程序管理MIB”，RFC 2564，DOI 10.17487/RFC2564，1999年5月<http://www.rfc-editor.org/info/rfc2564>.
[RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, DOI 10.17487/RFC2790, March 2000, <http://www.rfc-editor.org/info/rfc2790>.
[RFC2790]Waldbusser，S.和P.Grillo，“主机资源MIB”，RFC 2790，DOI 10.17487/RFC2790，2000年3月<http://www.rfc-editor.org/info/rfc2790>.
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, DOI 10.17487/RFC2975, October 2000, <http://www.rfc-editor.org/info/rfc2975>.
[RFC2975]Aboba，B.，Arkko，J.，和D.Harrington，“会计管理导论”，RFC 2975，DOI 10.17487/RFC2975，2000年10月<http://www.rfc-editor.org/info/rfc2975>.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <http://www.rfc-editor.org/info/rfc3365>.
[RFC3365]Schiller，J.，“互联网工程任务组标准协议的强大安全要求”，BCP 61，RFC 3365，DOI 10.17487/RFC3365，2002年8月<http://www.rfc-editor.org/info/rfc3365>.
[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, DOI 10.17487/RFC3729, March 2004, <http://www.rfc-editor.org/info/rfc3729>.
[RFC3729]Waldbusser，S.，“应用程序性能度量MIB”，RFC 3729，DOI 10.17487/RFC3729，2004年3月<http://www.rfc-editor.org/info/rfc3729>.
[RFC4113] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", RFC 4113, DOI 10.17487/RFC4113, June 2005, <http://www.rfc-editor.org/info/rfc4113>.
[RFC4113]Fenner，B.和J.Flick，“用户数据报协议（UDP）的管理信息库”，RFC 4113，DOI 10.17487/RFC4113，2005年6月<http://www.rfc-editor.org/info/rfc4113>.
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, DOI 10.17487/RFC4150, August 2005, <http://www.rfc-editor.org/info/rfc4150>.
[RFC4150]Dietz，R.和R.Cole，“运输性能指标MIB”，RFC 4150，DOI 10.17487/RFC4150，2005年8月<http://www.rfc-editor.org/info/rfc4150>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 4193，DOI 10.17487/RFC4193，2005年10月<http://www.rfc-editor.org/info/rfc4193>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 4821，DOI 10.17487/RFC4821，2007年3月<http://www.rfc-editor.org/info/rfc4821>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 4960，DOI 10.17487/RFC4960，2007年9月<http://www.rfc-editor.org/info/rfc4960>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，DOI 10.17487/RFC5389，2008年10月<http://www.rfc-editor.org/info/rfc5389>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 5424DOI 10.17487/RFC54242009年3月<http://www.rfc-editor.org/info/rfc5424>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <http://www.rfc-editor.org/info/rfc5706>.
[RFC5706]Harrington，D.，“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，DOI 10.17487/RFC5706，2009年11月<http://www.rfc-editor.org/info/rfc5706>.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, October 2010, <http://www.rfc-editor.org/info/rfc5971>.
[RFC5971]Schulzrinne，H.和R.Hancock，“要点：通用互联网信号传输”，RFC 5971，DOI 10.17487/RFC597119010年10月<http://www.rfc-editor.org/info/rfc5971>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, <http://www.rfc-editor.org/info/rfc6194>.
[RFC6194]Polk，T.，Chen，L.，Turner，S.，和P.Hoffman，“SHA-0和SHA-1消息摘要算法的安全考虑”，RFC 6194，DOI 10.17487/RFC6194，2011年3月<http://www.rfc-editor.org/info/rfc6194>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<http://www.rfc-editor.org/info/rfc6241>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.
[RFC6709]Carpenter，B.，Aboba，B.，Ed.，和S.Cheshire，“协议扩展的设计考虑”，RFC 6709，DOI 10.17487/RFC6709，2012年9月<http://www.rfc-editor.org/info/rfc6709>.
[RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972, DOI 10.17487/RFC6972, July 2013, <http://www.rfc-editor.org/info/rfc6972>.
[RFC6972]Zhang，Y.和N.Zong，“点对点流协议（PPSP）的问题陈述和要求”，RFC 6972，DOI 10.17487/RFC6972，2013年7月<http://www.rfc-editor.org/info/rfc6972>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>.
[RFC7285]Alimi，R.，Ed.，Penno，R.，Ed.，Yang，Y.，Ed.，Kiesel，S.，Previdi，S.，Room，W.，Shalunov，S.，和R.Woundy，“应用层流量优化（ALTO）协议”，RFC 7285，DOI 10.17487/RFC7285，2014年9月<http://www.rfc-editor.org/info/rfc7285>.
[SECDHTS] Urdaneta, G., Pierre, G., and M. van Steen, "A Survey of DHT Security Techniques", ACM Computing Surveys, vol. 43(2), January 2011.
[SECDHTS]Urdaneta，G.，Pierre，G.，和M.van Steen，“DHT安全技术调查”，ACM计算调查，第43卷（2），2011年1月。
[SIGMCAST] Wong, C. and S. Lam, "Digital Signatures for Flows and Multicasts", IEEE/ACM Transactions on Networking 7(4), pp. 502-513, August 1999.
[SIGMCAST]Wong，C.和S.Lam，“流和多播的数字签名”，IEEE/ACM网络交易7（4），第502-513页，1999年8月。
[SPS] Jesi, G., Montresor, A., and M. van Steen, "Secure Peer Sampling", Computer Networks vol. 54(12), pp. 2086-2098, Elsevier, August 2010.
[SPS]Jesi，G.，Montresor，A.，和M.van Steen，“安全对等抽样”，计算机网络第54卷（12），第2086-2098页，爱思唯尔，2010年8月。
[SWIFTIMPL] Grishchenko, V., Paananen, J., Pronchenkov, A., Bakker, A., and R. Petrocco, "Swift reference implementation", 2015, <https://github.com/libswift/libswift>.
[SWIFTIMPL]Grishchenko，V.，Paananen，J.，Pronchenkov，A.，Bakker，A.，和R.Petrocco，“快速参考实施”，2015年<https://github.com/libswift/libswift>.
[TIT4TAT] Cohen, B., "Incentives Build Robustness in BitTorrent", 1st Workshop on Economics of Peer-to-Peer Systems, Berkeley, CA, USA, May 2003.
[TIT4TAT]Cohen，B.，“激励在BitTorrent中建立稳健性”，第一期对等系统经济学研讨会，加州伯克利，美国，2003年5月。
Acknowledgements
致谢
Arno Bakker, Riccardo Petrocco, and Victor Grishchenko are partially supported by the P2P-Next project <http://www.p2p-next.org/>, a research project supported by the European Community under its 7th Framework Programme (grant agreement no. 216217). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the P2P-Next project or the European Commission.
Arno Bakker、Riccardo Petrocco和Victor Grishchenko得到了P2P下一个项目的部分支持<http://www.p2p-next.org/>，这是一个由欧洲共同体根据其第七个框架计划（第216217号赠款协议）支持的研究项目。本文中包含的观点和结论是作者的观点和结论，不应被解释为必然代表P2P下一个项目或欧盟委员会的官方政策或认可，无论明示或暗示。
PPSPP was designed by Victor Grishchenko at Technische Universiteit Delft under supervision of Johan Pouwelse. The authors would like to thank the following people for their contributions to this document: the chairs (Martin Stiemerling, Yunfei Zhang, Stefano Previdi, and Ning Zong) and members of the IETF PPSP working group, and Mihai Capota, Raul Jimenez, Flutra Osmani, and Raynor Vliegendhart.
PPSP由德尔夫特理工大学的Victor Grishchenko在Johan Pouwelse的监督下设计。作者感谢以下人士对本文件的贡献：IETF PPSP工作组主席（Martin Stieemerling、张云飞、Stefano Previdi和宁宗）和成员，以及Mihai Capota、Raul Jimenez、Flutra Osmani和Raynor Vliegendhart。
Authors' Addresses
作者地址
Arno Bakker Vrije Universiteit Amsterdam De Boelelaan 1081 Amsterdam 1081HV The Netherlands
荷兰阿姆斯特丹博莱兰阿诺·巴克尔·弗里耶大学1081阿姆斯特丹1081HV
Email: arno@cs.vu.nl
Email: arno@cs.vu.nl
Riccardo Petrocco Technische Universiteit Delft Mekelweg 4 Delft 2628CD The Netherlands
荷兰代尔夫特梅克尔韦格4代尔夫特2628CD理工大学里卡多石油公司
Email: r.petrocco@gmail.com
Email: r.petrocco@gmail.com
Victor Grishchenko Technische Universiteit Delft Mekelweg 4 Delft 2628CD The Netherlands
维克多·格里什琴科技术大学代尔夫特梅克尔韦格4代尔夫特2628CD荷兰
Email: victor.grishchenko@gmail.com
Email: victor.grishchenko@gmail.com