Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 7959 Universitaet Bremen TZI
Updates: 7252 Z. Shelby, Ed.
Category: Standards Track ARM
ISSN: 2070-1721 August 2016
Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 7959 Universitaet Bremen TZI
Updates: 7252 Z. Shelby, Ed.
Category: Standards Track ARM
ISSN: 2070-1721 August 2016
Block-Wise Transfers in the Constrained Application Protocol (CoAP)
受限应用程序协议（CoAP）中的分块传输
Abstract
摘要
The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.
受限应用程序协议（CoAP）是一种用于受限节点和网络的RESTful传输协议。对于传感器和执行器的小有效载荷，基本CoAP信息工作良好；然而，应用程序偶尔需要传输更大的有效负载——例如，固件更新。与HTTP不同的是，在HTTP中，TCP执行分段和重新排序的繁重工作，CoAP基于数据报传输，如UDP或数据报传输层安全性（DTLS）。这些传输只提供碎片，这在受约束的节点和网络中更成问题，限制了实际可以传输的资源表示的最大大小。
Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.
本规范不依赖于IP分段，而是使用一对“块”选项扩展了基本CoAP，用于从多个请求-响应对中的资源表示传输多个信息块。在许多重要的情况下，块选项使服务器成为真正的无状态：服务器可以单独处理每个块传输，而不需要连接设置或以前块传输的其他服务器端内存。基本上，块选项提供了以块方式传输较大表示的最小方式。
A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.
不支持这些选项的CoAP实现通常受限于可交换的表示的大小，因此预计块选项将在CoAP实现中广泛使用。因此，本规范更新了RFC 7252。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7959.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7959.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Block-Wise Transfers . . . . . . . . . . . . . . . . . . . . 6
2.1. The Block2 and Block1 Options . . . . . . . . . . . . . . 7
2.2. Structure of a Block Option . . . . . . . . . . . . . . . 8
2.3. Block Options in Requests and Responses . . . . . . . . . 10
2.4. Using the Block2 Option . . . . . . . . . . . . . . . . . 12
2.5. Using the Block1 Option . . . . . . . . . . . . . . . . . 14
2.6. Combining Block-Wise Transfers with the Observe Option . 15
2.7. Combining Block1 and Block2 . . . . . . . . . . . . . . . 16
2.8. Combining Block2 with Multicast . . . . . . . . . . . . . 16
2.9. Response Codes . . . . . . . . . . . . . . . . . . . . . 17
2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 17
2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 17
2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 17
2.10. Caching Considerations . . . . . . . . . . . . . . . . . 18
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 19
3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 23
3.3. Combining Block1 and Block2 . . . . . . . . . . . . . . . 25
3.4. Combining Observe and Block2 . . . . . . . . . . . . . . 26
4. The Size2 and Size1 Options . . . . . . . . . . . . . . . . . 29
5. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . 33
7.2. Mitigating Amplification Attacks . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. Normative References . . . . . . . . . . . . . . . . . . 34
8.2. Informative References . . . . . . . . . . . . . . . . . 35
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Block-Wise Transfers . . . . . . . . . . . . . . . . . . . . 6
2.1. The Block2 and Block1 Options . . . . . . . . . . . . . . 7
2.2. Structure of a Block Option . . . . . . . . . . . . . . . 8
2.3. Block Options in Requests and Responses . . . . . . . . . 10
2.4. Using the Block2 Option . . . . . . . . . . . . . . . . . 12
2.5. Using the Block1 Option . . . . . . . . . . . . . . . . . 14
2.6. Combining Block-Wise Transfers with the Observe Option . 15
2.7. Combining Block1 and Block2 . . . . . . . . . . . . . . . 16
2.8. Combining Block2 with Multicast . . . . . . . . . . . . . 16
2.9. Response Codes . . . . . . . . . . . . . . . . . . . . . 17
2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 17
2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 17
2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 17
2.10. Caching Considerations . . . . . . . . . . . . . . . . . 18
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 19
3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 23
3.3. Combining Block1 and Block2 . . . . . . . . . . . . . . . 25
3.4. Combining Observe and Block2 . . . . . . . . . . . . . . 26
4. The Size2 and Size1 Options . . . . . . . . . . . . . . . . . 29
5. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . 33
7.2. Mitigating Amplification Attacks . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. Normative References . . . . . . . . . . . . . . . . . . 34
8.2. Informative References . . . . . . . . . . . . . . . . . 35
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
The work on Constrained RESTful Environments (CoRE) aims at realizing the Representational State Transfer (REST) architecture in a suitable form for the most constrained nodes (such as microcontrollers with limited RAM and ROM [RFC7228]) and networks (such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC4944]) [RFC7252]. The CoAP protocol is intended to provide RESTful [REST] services not unlike HTTP [RFC7230], while reducing the complexity of implementation as well as the size of packets exchanged in order to make these services useful in a highly constrained network of highly constrained nodes.
关于受限RESTful环境（CoRE）的工作旨在以合适的形式实现最受限节点（如RAM和ROM有限的微控制器[RFC7228]）和网络（如低功耗无线个人区域网络（6LoWPANs）上的IPv6）[RFC4944]）[RFC7252]的代表性状态传输（REST）体系结构。CoAP协议旨在提供与HTTP[RFC7230]不同的RESTful[REST]服务，同时降低实现的复杂性以及交换的数据包的大小，以使这些服务在高度约束的节点的高度约束网络中有用。
This objective requires restraint in a number of sometimes conflicting ways:
这一目标需要在一些有时相互冲突的方面进行克制：
o reducing implementation complexity in order to minimize code size,
o 降低实现复杂性以最小化代码大小，
o reducing message sizes in order to minimize the number of fragments needed for each message (to maximize the probability of delivery of the message), the amount of transmission power needed, and the loading of the limited-bandwidth channel,
o 减少消息大小，以最小化每条消息所需的片段数量（以最大化消息的传递概率）、所需的传输功率和有限带宽信道的负载，
o reducing requirements on the environment such as stable storage, good sources of randomness, or user-interaction capabilities.
o 减少对环境的要求，如稳定的存储、良好的随机性来源或用户交互能力。
Because CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS), the maximum size of resource representations that can be transferred without too much fragmentation is limited. In addition, not all resource representations will fit into a single link-layer packet of a constrained network, which may cause adaptation layer fragmentation even if IP-layer fragmentation is not required. Using fragmentation (either at the adaptation layer or at the IP layer) for the transport of larger representations would be possible up to the maximum size of the underlying datagram protocol (such as UDP), but the fragmentation/reassembly process burdens the lower layers with conversation state that is better managed in the application layer.
由于CoAP基于UDP或数据报传输层安全性（DTLS）等数据报传输，因此可以传输的资源表示的最大大小受到限制，而不会产生太多碎片。此外，并非所有资源表示都适合受限网络的单个链路层分组，即使不需要IP层分段，这也可能导致自适应层分段。使用分段（在适配层或IP层）传输更大的表示可能会达到底层数据报协议（如UDP）的最大大小，但分段/重组过程会给较低层带来会话状态的负担，这些会话状态在应用层中得到更好的管理。
The present specification defines a pair of CoAP options to enable block-wise access to resource representations. The Block options provide a minimal way to transfer larger resource representations in a block-wise fashion. The overriding objective is to avoid the need for creating conversation state at the server for block-wise GET requests. (It is impossible to fully avoid creating conversation state for POST/PUT, if the creation/replacement of resources is to be atomic; where that property is not needed, there is no need to create server conversation state in this case, either.)
本规范定义了一对CoAP选项，以支持对资源表示的分块访问。块选项提供了以块方式传输较大资源表示的最小方式。重写的目标是避免在服务器上为分块GET请求创建会话状态。（如果资源的创建/替换是原子的，则不可能完全避免为POST/PUT创建会话状态；如果不需要该属性，在这种情况下也不需要创建服务器会话状态。）
Block-wise transfers are realized as combinations of exchanges, each of which is performed according to the CoAP base protocol [RFC7252]. Each exchange in such a combination is governed by the specifications in [RFC7252], including the congestion control specifications (Section 4.7 of [RFC7252]) and the security considerations (Section 11 of [RFC7252]; additional security considerations then apply to the transfers as a whole, see Section 7). The present specification minimizes the constraints it adds to those base exchanges; however, not all variants of using CoAP are very useful inside a block-wise transfer (e.g., using Non-confirmable requests within block-wise transfers outside the use case of Section 2.8 would escalate the overall non-delivery probability). To be perfectly clear, the present specification also does not remove any of the constraints posed by the base specification it is strictly layered on top of. For example, back-to-back packets are limited by the congestion control described in Section 4.7 of [RFC7252] (NSTART as a limit for initiating exchanges, PROBING_RATE as a limit for sending with no response); block-wise transfers cannot send/solicit more traffic than a client could be sending to / soliciting from the same server without the block-wise mode.
分块传输作为交换组合实现，每个交换根据CoAP基本协议[RFC7252]执行。这种组合中的每个交换都受[RFC7252]中的规范管辖，包括拥塞控制规范（第[RFC7252]第4.7节）和安全注意事项（第[RFC7252]第11节）；其他安全注意事项则适用于整个传输，见第7节）。本规范将其添加到这些基本交换的约束最小化；然而，并非所有使用CoAP的变体在分块传输中都非常有用（例如，在第2.8节用例之外的分块传输中使用不可确认的请求会增加总体不交付概率）。非常清楚的是，本规范也没有消除基础规范所带来的任何约束，它严格地分层在基础规范之上。例如，背对背数据包受[RFC7252]第4.7节中描述的拥塞控制的限制（NSTART作为发起交换的限制，probling_RATE作为无响应发送的限制）；分块传输发送/请求的流量不能超过客户端在没有分块模式的情况下向同一服务器发送/请求的流量。
In some cases, the present specification will RECOMMEND that a client perform a sequence of block-wise transfers "without undue delay". This cannot be phrased as an interoperability requirement, but is an expectation on implementation quality. Conversely, the expectation is that servers will not have to go out of their way to accommodate clients that take considerable time to finish a block-wise transfer. For example, for a block-wise GET, if the resource changes while this proceeds, the entity-tag (ETag) for a further block obtained may be different. To avoid this happening all the time for a fast-changing resource, a server MAY try to keep a cache around for a specific client for a short amount of time. The expectation here is that the lifetime for such a cache can be kept short, on the order of a few expected round-trip times, counting from the previous block transferred.
在某些情况下，本规范将建议客户机“无不当延迟”地执行分组传输序列。这不能说是互操作性需求，而是对实现质量的期望。相反，我们的期望是，服务器将不必不厌其烦地容纳需要相当长时间才能完成分块传输的客户端。例如，对于逐块GET，如果资源在执行过程中发生变化，则所获得的另一块的实体标记（ETag）可能不同。为了避免在快速变化的资源中始终发生这种情况，服务器可能会尝试在短时间内为特定客户机保留缓存。这里的期望是这样一个缓存的生存期可以保持较短，大约是从先前传输的块开始计算的几个预期往返时间。
In summary, this specification adds a pair of Block options to CoAP that can be used for block-wise transfers. Benefits of using these options include:
总之，本规范向CoAP添加了一对可用于分块传输的块选项。使用这些选项的好处包括：
o Transfers larger than what can be accommodated in constrained-network link-layer packets can be performed in smaller blocks.
o 大于受限网络链路层数据包中可容纳的传输可以在较小的块中执行。
o No hard-to-manage conversation state is created at the adaptation layer or IP layer for fragmentation.
o 在适配层或IP层不会创建难以管理的会话状态以进行分段。
o The transfer of each block is acknowledged, enabling individual retransmission if required.
o 确认每个块的传输，如果需要，允许单独重新传输。
o Both sides have a say in the block size that actually will be used.
o 双方对实际使用的块大小都有发言权。
o The resulting exchanges are easy to understand using packet analyzer tools, and thus quite accessible to debugging.
o 使用数据包分析器工具很容易理解由此产生的交换，因此调试非常容易。
o If needed, the Block options can also be used (without changes) to provide random access to power-of-two sized blocks within a resource representation.
o 如果需要，还可以使用块选项（无需更改）在资源表示中随机访问两个大小的块的功率。
A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, see Section 4.6 of [RFC7252]. Even though the options are Critical, a server may decide to start using them in an unsolicited way in a response. No effort was expended to provide a capability indication mechanism supporting that decision: since the block-wise transfer mechanisms are so fundamental to the use of CoAP for representations larger than about a kilobyte, there is an expectation that they are very widely implemented.
不支持这些选项的CoAP实现通常受到可交换表示大小的限制，参见[RFC7252]第4.6节。即使这些选项很关键，服务器也可能会决定在响应中主动使用它们。没有花费任何精力来提供支持该决策的能力指示机制：由于块式传输机制对于使用CoAP来表示大于约1 KB的数据非常重要，因此人们期望它们能够得到非常广泛的实现。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, BCP 14 [RFC2119] and indicate requirement levels for compliant CoAP implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119、BCP 14[RFC2119]中的描述进行解释，并表示符合CoAP实施的要求级别。
In this document, the term "byte" is used in its now customary sense as a synonym for "octet".
在本文件中，“字节”一词是作为“八位字节”的同义词使用的。
Where bit arithmetic is explained, this document uses the notation familiar from the programming language C, except that the operator "**" stands for exponentiation.
在解释位算术的地方，本文档使用编程语言C中熟悉的符号，除了运算符“**”表示求幂。
As discussed in the introduction, there are good reasons to limit the size of datagrams in constrained networks:
正如引言中所讨论的，有充分的理由限制受限网络中数据报的大小：
o by the maximum datagram size (~ 64 KiB for UDP)
o 按最大数据报大小（UDP约64 KiB）
o by the desire to avoid IP fragmentation (MTU of 1280 for IPv6)
o 希望避免IP碎片（IPv6的MTU为1280）
o by the desire to avoid adaptation-layer fragmentation (60-80 bytes for 6LoWPAN [RFC4919])
o 为了避免适配层碎片（6LoWPAN[RFC4919]为60-80字节）
When a resource representation is larger than can be comfortably transferred in the payload of a single CoAP datagram, a Block option can be used to indicate a block-wise transfer. As payloads can be
当资源表示大于可以在单个CoAP数据报的有效载荷中舒适地传输时，可以使用块选项来指示分块传输。有效载荷可以是
sent both with requests and with responses, this specification provides two separate options for each direction of payload transfer. In naming these options (for block-wise transfers as well as in Section 4), we use the number 1 ("Block1", "Size1") to refer to the transfer of the resource representation that pertains to the request, and the number 2 ("Block2", "Size2") to refer to the transfer of the resource representation for the response.
通过请求和响应发送，该规范为有效负载传输的每个方向提供了两个单独的选项。在命名这些选项时（对于分块传输以及第4节），我们使用数字1（“Block1”、“Size1”）表示与请求相关的资源表示的传输，使用数字2（“Block2”、“Size2”）表示与响应相关的资源表示的传输。
In the following, the term "payload" will be used for the actual content of a single CoAP message, i.e., a single block being transferred, while the term "body" will be used for the entire resource representation that is being transferred in a block-wise fashion. The Content-Format Option applies to the body, not to the payload; in particular, the boundaries between the blocks may be in places that are not separating whole units in terms of the structure, encoding, or content-coding used by the Content-Format. (Similarly, the ETag Option defined in Section 5.10.6 of [RFC7252] applies to the whole representation of the resource, and thus to the body of the response.)
在下文中，术语“有效载荷”将用于单个CoAP消息的实际内容，即正在传输的单个块，而术语“正文”将用于正在以块方式传输的整个资源表示。内容格式选项适用于主体，而不是有效载荷；特别地，块之间的边界可以位于在内容格式使用的结构、编码或内容编码方面不分离整个单元的位置。（类似地，[RFC7252]第5.10.6节中定义的ETag选项适用于资源的整个表示，因此也适用于响应主体。）
In most cases, all blocks being transferred for a body (except for the last one) will be of the same size. (If the first request uses a bigger block size than the receiver prefers, subsequent requests will use the preferred block size.) The block size is not fixed by the protocol. To keep the implementation as simple as possible, the Block options support only a small range of power-of-two block sizes, from 2**4 (16) to 2**10 (1024) bytes. As bodies often will not evenly divide into the power-of-two block size chosen, the size need not be reached in the final block (but even for the final block, the chosen power-of-two size will still be indicated in the block size field of the Block option).
在大多数情况下，为实体传输的所有块（最后一个除外）的大小都相同。（如果第一个请求使用的块大小大于接收方首选的块大小，则后续请求将使用首选的块大小。）协议不会固定块大小。为了使实现尽可能简单，块选项只支持两个块大小的小范围幂，从2**4（16）字节到2**10（1024）字节。由于实体通常不会均匀地划分为所选两个块大小的幂，因此最终块中不需要达到该大小（但即使对于最终块，所选两个大小的幂仍将显示在块选项的块大小字段中）。
+-----+---+---+---+---+--------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+--------+--------+--------+---------+
| 23 | C | U | - | - | Block2 | uint | 0-3 | (none) |
| | | | | | | | | |
| 27 | C | U | - | - | Block1 | uint | 0-3 | (none) |
+-----+---+---+---+---+--------+--------+--------+---------+
+-----+---+---+---+---+--------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+--------+--------+--------+---------+
| 23 | C | U | - | - | Block2 | uint | 0-3 | (none) |
| | | | | | | | | |
| 27 | C | U | - | - | Block1 | uint | 0-3 | (none) |
+-----+---+---+---+---+--------+--------+--------+---------+
Table 1: Block Option Numbers
表1：区块选项编号
Both Block1 and Block2 Options can be present in both the request and response messages. In either case, the Block1 Option pertains to the request payload, and the Block2 Option pertains to the response payload.
Block1和Block2选项都可以出现在请求和响应消息中。无论哪种情况，Block1选项都与请求有效负载相关，而Block2选项与响应有效负载相关。
Hence, for the methods defined in [RFC7252], Block1 is useful with the payload-bearing POST and PUT requests and their responses. Block2 is useful with GET, POST, and PUT requests and their payload-bearing responses (2.01, 2.02, 2.04, and 2.05 -- see Section 5.5 of [RFC7252]).
因此，对于[RFC7252]中定义的方法，Block1对于有效负载承载POST和PUT请求及其响应非常有用。Block2对于GET、POST和PUT请求及其有效负载轴承响应非常有用（2.01、2.02、2.04和2.05——请参见[RFC7252]的第5.5节）。
Where Block1 is present in a request or Block2 in a response (i.e., in that message to the payload of which it pertains) it indicates a block-wise transfer and describes how this specific block-wise payload forms part of the entire body being transferred ("descriptive usage"). Where it is present in the opposite direction, it provides additional control on how that payload will be formed or was processed ("control usage").
当Block1出现在请求中或Block2出现在响应中（即，出现在与之相关的有效载荷的消息中）时，它表示按块传输，并描述该特定的按块有效载荷如何构成被传输的整个主体的一部分（“描述性用法”）。在相反方向上，它提供了关于有效载荷将如何形成或处理的额外控制（“控制使用”）。
Implementation of either Block option is intended to be optional. However, when it is present in a CoAP message, it MUST be processed (or the message rejected); therefore, it is identified as a Critical option. Either Block option MUST NOT occur more than once in a single message.
任何一个块选项的实现都是可选的。但是，当它出现在CoAP消息中时，必须对其进行处理（或拒绝该消息）；因此，它被确定为一个关键选项。任何一个块选项在一条消息中不得出现多次。
Three items of information may need to be transferred in a Block (Block1 or Block2) option:
可能需要在块（块1或块2）选项中传输三项信息：
o the size of the block (SZX);
o 块的大小（SZX）；
o whether more blocks are following (M);
o 是否有更多的块在后面（M）；
o the relative number of the block (NUM) within a sequence of blocks with the given size.
o 给定大小的块序列中块的相对数量（NUM）。
The value of the Block option is a variable-size (0 to 3 byte) unsigned integer (uint, see Section 3.2 of [RFC7252]). This integer value encodes these three fields, see Figure 1. (Due to the CoAP uint-encoding rules, when all of NUM, M, and SZX happen to be zero, a zero-byte integer will be sent.)
块选项的值是一个可变大小（0到3字节）无符号整数（uint，参见[RFC7252]第3.2节）。这个整数值对这三个字段进行编码，见图1。（根据CoAP uint编码规则，当NUM、M和SZX恰好为零时，将发送一个零字节整数。）
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| NUM |M| SZX |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| NUM |M| SZX |
+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUM |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUM |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUM |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUM |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Block Option Value
图1：块选项值
The block size is encoded using a three-bit unsigned integer (0 for 2**4 bytes to 6 for 2**10 bytes), which we call the "SZX" ("size exponent"); the actual block size is then "2**(SZX + 4)". SZX is transferred in the three least significant bits of the option value (i.e., "val & 7" where "val" is the value of the option).
块大小使用三位无符号整数编码（0表示2**4字节，6表示2**10字节），我们称之为“SZX”（“大小指数”）；实际块大小为“2**（SZX+4）”。SZX在期权价值的三个最低有效位中传输（即“val&7”，其中“val”是期权的价值）。
The fourth least significant bit, the M or "more" bit ("val & 8"), indicates whether more blocks are following or if the current block-wise transfer is the last block being transferred.
第四个最低有效位，M或“更多”位（“val&8”），指示是否有更多的块在后面，或者当前按块传输是否是正在传输的最后一个块。
The option value divided by sixteen (the NUM field) is the sequence number of the block currently being transferred, starting from zero. The current transfer is, therefore, about the "size" bytes starting at byte "NUM << (SZX + 4)".
选项值除以十六（NUM字段）是当前正在传输的块的序列号，从零开始。因此，当前传输大约是从字节“NUM<<（SZX+4）”开始的“size”字节。
Implementation note: As an implementation convenience, "(val & ~0xF) << (val & 7)", i.e., the option value with the last 4 bits masked out, shifted to the left by the value of SZX, gives the byte position of the first byte of the block being transferred.
实现说明：为了实现方便，“（val&~0xF）<<（val&7）”，即最后4位被屏蔽的选项值，通过SZX值向左移位，给出被传输块的第一个字节的字节位置。
More specifically, within the option value of a Block1 or Block2 Option, the meaning of the option fields is defined as follows:
更具体地说，在Block1或Block2选项的选项值中，选项字段的含义定义如下：
NUM: Block Number, indicating the block number being requested or provided. Block number 0 indicates the first block of a body (i.e., starting with the first byte of the body).
NUM：块编号，表示请求或提供的块编号。块编号0表示主体的第一个块（即，从主体的第一个字节开始）。
M: More Flag ("not last block"). For descriptive usage, this flag, if unset, indicates that the payload in this message is the last block in the body; when set, it indicates that there are one or more additional blocks available. When a Block2 Option is used in a request to retrieve a specific block number ("control usage"), the M bit MUST be sent as zero and ignored on reception. (In a Block1 Option in a response, the M flag is used to indicate atomicity, see below.)
M：更多标志（“不是最后一个块”）。对于描述性用法，如果未设置此标志，则表示此消息中的有效负载是正文中的最后一个块；设置时，表示有一个或多个附加块可用。当在检索特定块号的请求中使用Block2选项（“控制使用”）时，M位必须作为零发送，并在接收时忽略。（在响应中的Block1选项中，M标志用于指示原子性，见下文。）
SZX: Block Size. The block size is represented as a three-bit unsigned integer indicating the size of a block to the power of two. Thus, block size = 2**(SZX + 4). The allowed values of SZX are 0 to 6, i.e., the minimum block size is 2**(0+4) = 16 and the maximum is 2**(6+4) = 1024. The value 7 for SZX (which would indicate a block size of 2048) is reserved, i.e., MUST NOT be sent and MUST lead to a 4.00 Bad Request response code upon reception in a request.
SZX：块大小。块大小表示为三位无符号整数，表示块大小的二次方。因此，块大小=2**（SZX+4）。SZX的允许值为0到6，即最小块大小为2**（0+4）=16，最大块大小为2**（6+4）=1024。SZX的值7（表示块大小为2048）是保留的，即不得发送，并且在请求中接收时必须导致4.00错误的请求-响应代码。
There is no default value for the Block1 and Block2 Options. Absence of one of these options is equivalent to an option value of 0 with respect to the value of NUM and M that could be given in the option, i.e., it indicates that the current block is the first and only block of the transfer (block number 0, M bit not set). However, in contrast to the explicit value 0, which would indicate an SZX of 0 and thus a size value of 16 bytes, there is no specific explicit size implied by the absence of the option -- the size is left unspecified. (As for any uint, the explicit value 0 is efficiently indicated by a zero-length option; this, therefore, is different in semantics from the absence of the option.)
Block1和Block2选项没有默认值。缺少其中一个选项相当于相对于选项中可能给出的NUM和M值的选项值0，即，它表示当前块是传输的第一个也是唯一的块（块号0，M位未设置）。但是，与显式值0不同，显式值0表示SZX为0，因此大小值为16字节，没有该选项意味着没有特定的显式大小——大小未指定。（对于任何uint，显式值0由零长度选项有效指示；因此，这在语义上与没有该选项不同。）
The Block options are used in one of three roles:
块选项用于以下三种角色之一：
o In descriptive usage, i.e., a Block2 Option in a response (such as a 2.05 response for GET), or a Block1 Option in a request (a PUT or POST):
o 在描述性用法中，即响应中的Block2选项（例如GET的2.05响应）或请求中的Block1选项（PUT或POST）：
* The NUM field in the option value describes what block number is contained in the payload of this message.
* 选项值中的NUM字段描述此消息的有效负载中包含的块编号。
* The M bit indicates whether further blocks need to be transferred to complete the transfer of that body.
* M位指示是否需要传输更多块以完成该实体的传输。
* The block size implied by SZX MUST match the size of the payload in bytes, if the M bit is set. (SZX does not govern the payload size if M is unset). For Block2, if the request suggested a larger value of SZX, the next request MUST move SZX
* 如果设置了M位，则SZX暗示的块大小必须与有效负载的大小（以字节为单位）匹配。（如果M未设置，则SZX不控制有效负载大小）。对于Block2，如果请求建议更大的SZX值，则下一个请求必须移动SZX
down to the size given in the response. (The effect is that, if the server uses the smaller of (1) its preferred block size and (2) the block size requested, all blocks for a body use the same block size.)
减小到响应中给出的大小。（其效果是，如果服务器使用（1）其首选块大小和（2）请求的块大小中的较小者，则主体的所有块都使用相同的块大小。）
o A Block2 Option in control usage in a request (e.g., GET):
o 请求中控制使用的Block2选项（例如GET）：
* The NUM field in the Block2 Option gives the block number of the payload that is being requested to be returned in the response.
* Block2选项中的NUM字段给出请求在响应中返回的有效负载的块号。
* In this case, the M bit has no function and MUST be set to zero.
* 在这种情况下，M位没有功能，必须设置为零。
* The block size given (SZX) suggests a block size (in the case of block number 0) or repeats the block size of previous blocks received (in the case of a non-zero block number).
* 给定的块大小（SZX）表示块大小（在块号为0的情况下）或重复先前接收到的块大小（在块号为非零的情况下）。
o A Block1 Option in control usage in a response (e.g., a 2.xx response for a PUT or POST request):
o 响应中控制使用的Block1选项（例如，PUT或POST请求的2.xx响应）：
* The NUM field of the Block1 Option indicates what block number is being acknowledged.
* Block1选项的NUM字段指示正在确认的块编号。
* If the M bit was set in the request, the server can choose whether to act on each block separately, with no memory, or whether to handle the request for the entire body atomically, or any mix of the two.
* 如果在请求中设置了M位，服务器可以选择是在没有内存的情况下单独处理每个块，还是以原子方式处理整个主体的请求，或者两者的任意组合。
+ If the M bit is also set in the response, it indicates that this response does not carry the final response code to the request, i.e., the server collects further blocks from the same endpoint and plans to implement the request atomically (e.g., acts only upon reception of the last block of payload). In this case, the response MUST NOT carry a Block2 Option.
+ 如果在响应中也设置了M位，则表示该响应不携带请求的最终响应代码，即，服务器从同一端点收集更多块，并计划以原子方式实现请求（例如，仅在接收到最后一块有效负载时才采取行动）。在这种情况下，响应不得带有Block2选项。
+ Conversely, if the M bit is unset even though it was set in the request, it indicates the block-wise request was enacted now specifically for this block, and the response carries the final response to this request (and to any previous ones with the M bit set in the response's Block1 Option in this sequence of block-wise transfers); the client is still expected to continue sending further blocks, the request method for which may or may not also be enacted per-block. (Note that the resource is now in a partially updated state; this approach is only appropriate where exposing such an
+ 相反，如果M位未设置，即使它在请求中被设置，它表示现在专门针对该块执行了分块请求，并且响应携带对此请求的最终响应（以及在此分块传输序列中响应的Block1选项中设置了M位的任何前一个请求）；客户机仍将继续发送更多的块，每个块可能会制定请求方法，也可能不会制定请求方法。（请注意，资源现在处于部分更新状态；此方法仅适用于公开此类资源的情况。）
intermediate state is acceptable. The client can reduce the window by quickly continuing to update the resource, or, in case of failure, restarting the update.)
中间状态是可以接受的。客户端可以通过快速继续更新资源或在出现故障时重新启动更新来缩短窗口。）
* Finally, the SZX block size given in a control Block1 Option indicates the largest block size preferred by the server for transfers toward the resource that is the same or smaller than the one used in the initial exchange; the client SHOULD use this block size or a smaller one in all further requests in the transfer sequence, even if that means changing the block size (and possibly scaling the block number accordingly) from now on.
* 最后，在控制块1选项中给出的SZX块大小指示服务器首选的向资源传输的最大块大小，该块大小与初始交换中使用的块大小相同或更小；客户端应在传输序列中的所有进一步请求中使用此块大小或更小的块大小，即使这意味着从现在起更改块大小（并可能相应地缩放块数）。
Using one or both Block options, a single REST operation can be split into multiple CoAP message exchanges. As specified in [RFC7252], each of these message exchanges uses their own CoAP Message ID.
使用一个或两个块选项，可以将单个REST操作拆分为多个CoAP消息交换。如[RFC7252]所述，这些消息交换中的每一个都使用自己的CoAP消息ID。
The Content-Format Option sent with the requests or responses MUST reflect the Content-Format of the entire body. If blocks of a response body arrive with different Content-Format Options, it is up to the client how to handle this error (it will typically abort any ongoing block-wise transfer). If blocks of a request arrive at a server with mismatching Content-Format Options, the server MUST NOT assemble them into a single request; this usually leads to a 4.08 (Request Entity Incomplete, Section 2.9.2) error response on the mismatching block.
随请求或响应一起发送的内容格式选项必须反映整个正文的内容格式。如果响应主体的块带有不同的内容格式选项，则由客户端决定如何处理此错误（它通常会中止任何正在进行的按块传输）。如果请求块到达的服务器具有不匹配的内容格式选项，则服务器不得将它们组合成单个请求；这通常会导致不匹配块上出现4.08（请求实体不完整，第2.9.2节）错误响应。
When a request is answered with a response carrying a Block2 Option with the M bit set, the requester may retrieve additional blocks of the resource representation by sending further requests with the same options as the initial request and a Block2 Option giving the block number and block size desired. In a request, the client MUST set the M bit of a Block2 Option to zero and the server MUST ignore it on reception.
当使用带有M位集的Block2选项的响应响应响应请求时，请求者可以通过发送与初始请求具有相同选项的进一步请求和给出所需块编号和块大小的Block2选项来检索资源表示的附加块。在请求中，客户端必须将Block2选项的M位设置为零，服务器必须在接收时忽略它。
To influence the block size used in a response, the requester MAY also use the Block2 Option on the initial request, giving the desired size, a block number of zero and an M bit of zero. A server MUST use the block size indicated or a smaller size. Any further block-wise requests for blocks beyond the first one MUST indicate the same block size that was used by the server in the response for the first request that gave a desired size using a Block2 Option.
为了影响响应中使用的块大小，请求者还可以在初始请求上使用Block2选项，给出所需的大小、块数为零和M位为零。服务器必须使用指定的块大小或更小的大小。对于超出第一个块的任何其他块请求，必须指示服务器在响应第一个请求时使用的相同块大小，该请求使用Block2选项提供了所需的大小。
Once the Block2 Option is used by the requester and a first response has been received with a possibly adjusted block size, all further requests in a single block-wise transfer will ultimately converge on
一旦请求者使用Block2选项，并且接收到第一个响应，并且可能调整了块大小，则单个块传输中的所有进一步请求将最终收敛到
using the same size, except that there may not be enough content to fill the last block (the one returned with the M bit not set). (Note that the client may start using the Block2 Option in a second request after a first request without a Block2 Option resulted in a Block2 Option in the response.) The server uses the block size indicated in the request option or a smaller size, but the requester MUST take note of the actual block size used in the response it receives to its initial request and proceed to use it in subsequent requests. The server behavior MUST ensure that this client behavior results in the same block size for all responses in a sequence (except for the last one with the M bit not set, and possibly the first one if the initial request did not contain a Block2 Option).
使用相同的大小，但可能没有足够的内容来填充最后一个块（返回的未设置M位的块）。（请注意，在第一个请求没有Block2选项导致响应中出现Block2选项后，客户端可能会在第二个请求中开始使用Block2选项。）服务器使用请求选项中指示的块大小或更小的大小，但是请求者必须注意它收到的对其初始请求的响应中使用的实际块大小，并继续在后续请求中使用它。服务器行为必须确保此客户端行为导致序列中所有响应的块大小相同（除了未设置M位的最后一个响应，如果初始请求不包含Block2选项，则可能是第一个响应）。
Block-wise transfers can be used to GET resources whose representations are entirely static (not changing over time at all, such as in a schema describing a device), or for dynamically changing resources. In the latter case, the Block2 Option SHOULD be used in conjunction with the ETag Option ([RFC7252], Section 5.10.6), to ensure that the blocks being reassembled are from the same version of the representation: The server SHOULD include an ETag Option in each response. If an ETag Option is available, the client, when reassembling the representation from the blocks being exchanged, MUST compare ETag Options. If the ETag Options do not match in a GET transfer, the requester has the option of attempting to retrieve fresh values for the blocks it retrieved first. To minimize the resulting inefficiency, the server MAY cache the current value of a representation for an ongoing sequence of requests. (The server may identify the sequence by the combination of the requesting endpoint and the URI being the same in each block-wise request.) Note well that this specification makes no requirement for the server to establish any state; however, servers that offer quickly changing resources may thereby make it impossible for a client to ever retrieve a consistent set of blocks. Clients that want to retrieve all blocks of a resource SHOULD strive to do so without undue delay. Servers can fully expect to be free to discard any cached state after a period of EXCHANGE_LIFETIME ([RFC7252], Section 4.8.2) after the last access to the state, however, there is no requirement to always keep the state for as long.
分块传输可用于获取表示完全静态的资源（完全不随时间变化，如在描述设备的模式中），或用于动态更改资源。在后一种情况下，Block2选项应与ETag选项一起使用（[RFC7252]，第5.10.6节），以确保重新组装的块来自相同版本的表示：服务器应在每个响应中包含ETag选项。如果ETag选项可用，则客户机在从正在交换的块重新组装表示时，必须比较ETag选项。如果ETag选项在GET传输中不匹配，请求者可以选择尝试为首先检索到的块检索新值。为了最大限度地降低由此产生的低效率，服务器可以缓存正在进行的请求序列的表示的当前值。（服务器可以通过请求端点的组合来识别序列，并且URI在每个块请求中相同。）请注意，本规范不要求服务器建立任何状态；然而，提供快速变化的资源的服务器可能因此使客户端无法检索到一致的块集。希望检索资源的所有块的客户机应该努力做到这一点，而不应有不适当的延迟。在最后一次访问状态后的一段EXCHANGE_生存期（[RFC7252]，第4.8.2节）后，服务器完全可以自由放弃任何缓存状态，但是，不需要始终保持该状态的时间。
The Block2 Option provides no way for a single endpoint to perform multiple concurrently proceeding block-wise response payload transfer (e.g., GET) operations to the same resource. This is rarely a requirement, but as a workaround, a client may vary the cache key (e.g., by using one of several URIs accessing resources with the same semantics, or by varying a proxy-safe elective option).
Block2选项无法让单个端点执行多个并发进行的块响应有效负载传输（例如GET）操作到同一资源。这很少是一项要求，但作为一种解决办法，客户机可能会改变缓存密钥（例如，通过使用多个URI中的一个访问具有相同语义的资源，或者通过改变代理安全选项）。
In a request with a request payload (e.g., PUT or POST), the Block1 Option refers to the payload in the request (descriptive usage).
在具有请求有效负载（例如，PUT或POST）的请求中，Block1选项指请求中的有效负载（描述性用法）。
In response to a request with a payload (e.g., a PUT or POST transfer), the block size given in the Block1 Option indicates the block size preference of the server for this resource (control usage). Obviously, at this point the first block has already been transferred by the client without benefit of this knowledge. Still, the client SHOULD heed the preference indicated and, for all further blocks, use the block size preferred by the server or a smaller one. Note that any reduction in the block size may mean that the second request starts with a block number larger than one, as the first request already transferred multiple blocks as counted in the smaller size.
为了响应具有有效负载的请求（例如，PUT或POST传输），Block1选项中给出的块大小指示服务器对此资源的块大小偏好（控制使用）。显然，此时第一个块已经被客户机转移，而没有利用这些知识。不过，客户机应该注意指示的首选项，对于所有其他块，使用服务器首选的块大小或更小的块大小。注意，块大小的任何减小都可能意味着第二个请求以大于1的块号开始，因为第一个请求已经传输了多个按较小大小计数的块。
To counter the effects of adaptation-layer fragmentation on packet-delivery probability, a client may want to give up retransmitting a request with a relatively large payload even before MAX_RETRANSMIT has been reached, and try restating the request as a block-wise transfer with a smaller payload. Note that this new attempt is then a new message-layer transaction and requires a new Message ID. (Because of the uncertainty about whether the request or the acknowledgement was lost, this strategy is useful mostly for idempotent requests.)
为了抵消适配层碎片对数据包交付概率的影响，客户机可能希望甚至在达到最大重传之前就放弃重传具有相对较大有效负载的请求，并尝试以具有较小有效负载的分块传输方式重新启动该请求。请注意，这个新尝试是一个新的消息层事务，需要一个新的消息ID。（由于请求或确认是否丢失的不确定性，此策略主要适用于幂等请求。）
In a block-wise transfer of a request payload (e.g., a PUT or POST) that is intended to be implemented in an atomic fashion at the server, the actual creation/replacement takes place at the time the final block, i.e., a block with the M bit unset in the Block1 Option, is received. In this case, all success responses to non-final blocks carry the response code 2.31 (Continue, Section 2.9.1). If not all previous blocks are available at the server at the time of processing the final block, the transfer fails and error code 4.08 (Request Entity Incomplete, Section 2.9.2) MUST be returned. A server MAY also return a 4.08 error code for any (final or non-final) Block1 transfer that is not in sequence; therefore, clients that do not have specific mechanisms to handle this case SHOULD always start with block zero and send the following blocks in order.
在拟在服务器上以原子方式实现的请求有效载荷（例如，PUT或POST）的分块传输中，实际创建/替换发生在接收到最终块时，即，在Block1选项中未设置M位的块。在这种情况下，所有对非最终块的成功响应都带有响应代码2.31（续，第2.9.1节）。如果在处理最后一个数据块时，服务器上并非所有以前的数据块都可用，则传输失败，必须返回错误代码4.08（请求实体不完整，第2.9.2节）。服务器还可以为任何（最终或非最终）不按顺序的Block1传输返回4.08错误代码；因此，没有特定机制来处理这种情况的客户机应始终以块零开始，并按顺序发送以下块。
One reason that a client might encounter a 4.08 error code is that the server has already timed out and discarded the partial request body being assembled. Clients SHOULD strive to send all blocks of a request without undue delay. Servers can fully expect to be free to discard any partial request body when a period of EXCHANGE_LIFETIME
客户机可能会遇到4.08错误代码的一个原因是服务器已超时并放弃正在组装的部分请求主体。客户应努力发送请求的所有数据块，不得无故延迟。在EXCHANGE\u生命周期结束时，服务器完全可以自由丢弃任何部分请求正文
([RFC7252], Section 4.8.2) has elapsed after the most recent block was transferred; however, there is no requirement on a server to always keep the partial request body for as long.
（[RFC7252]，第4.8.2节）在传输最近的数据块后已过；但是，服务器上不需要始终保持部分请求正文的长度。
The error code 4.13 (Request Entity Too Large) can be returned at any time by a server that does not currently have the resources to store blocks for a block-wise request payload transfer that it would intend to implement in an atomic fashion. (Note that a 4.13 response to a request that does not employ Block1 is a hint for the client to try sending Block1, and a 4.13 response with a smaller SZX in its Block1 Option than requested is a hint to try a smaller SZX.)
错误代码4.13（请求实体太大）可由当前没有资源存储块的服务器在任何时候返回，以便以原子方式实现按块请求有效负载传输。（请注意，对不使用Block1的请求的4.13响应是提示客户端尝试发送Block1，而在其Block1选项中具有比请求更小SZX的4.13响应是提示尝试更小的SZX。）
A block-wise transfer of a request payload that is implemented in a stateless fashion at the server is likely to leave the resource being operated on in an inconsistent state while the transfer is still ongoing or when the client does not complete the transfer. This characteristic is closer to that of remote file systems than to that of HTTP, where state is always kept on the server during a transfer. Techniques well known from shared file access (e.g., client-specific temporary resources) can be used to mitigate this difference from HTTP.
在服务器上以无状态方式实现的请求有效负载的分块传输可能会在传输仍在进行或客户端未完成传输时使正在操作的资源处于不一致的状态。此特性更接近于远程文件系统的特性，而不是HTTP的特性，HTTP在传输过程中状态始终保持在服务器上。从共享文件访问（例如，特定于客户端的临时资源）中熟知的技术可用于缓解与HTTP的这种差异。
The Block1 Option provides no way for a single endpoint to perform multiple concurrently proceeding block-wise request payload transfer (e.g., PUT or POST) operations to the same resource. Starting a new block-wise sequence of requests to the same resource (before an old sequence from the same endpoint was finished) simply overwrites the context the server may still be keeping. (This is probably exactly what one wants in this case -- the client may simply have restarted and lost its knowledge of the previous sequence.)
Block1选项不允许单个端点对同一资源执行多个并发进行的分块请求有效负载传输（例如，PUT或POST）操作。对同一资源启动新的按块请求序列（在来自同一端点的旧序列完成之前）只会覆盖服务器可能仍保留的上下文。（在本例中，这可能正是我们想要的——客户端可能只是重新启动并失去了对前一序列的了解。）
The Observe option provides a way for a client to be notified about changes over time of a resource [RFC7641]. Resources observed by clients may be larger than can be comfortably processed or transferred in one CoAP message. The following rules apply to the combination of block-wise transfers with notifications.
“观察”选项提供了一种方法，可以将资源随时间的变化通知客户机[RFC7641]。客户端观察到的资源可能比在一条CoAP消息中轻松处理或传输的资源大。以下规则适用于分块传输与通知的组合。
Observation relationships always apply to an entire resource; the Block2 Option does not provide a way to observe a single block of a resource.
观察关系始终适用于整个资源；Block2选项不提供观察单个资源块的方法。
As with basic GET transfers, the client can indicate its desired block size in a Block2 Option in the GET request establishing or renewing the observation relationship. If the server supports block-wise transfers, it SHOULD take note of the block size and apply it as a maximum size to all notifications/responses resulting from the GET
与基本GET传输一样，客户端可以在GET请求中的Block2选项中指示其所需的块大小，以建立或更新观察关系。如果服务器支持按块传输，则应注意块大小，并将其作为最大大小应用于GET生成的所有通知/响应
request (until the client is removed from the list of observers or the entry in that list is updated by the server receiving a new GET request for the resource from the client).
请求（直到客户机从观察者列表中删除，或者该列表中的条目被从客户机接收到的资源的新GET请求更新为止）。
When sending a 2.05 (Content) notification, the server only sends the first block of the representation. The client retrieves the rest of the representation as if it had caused this first response by a GET request, i.e., by using additional GET requests with Block2 Options containing NUM values greater than zero. (This results in the transfer of the entire representation, even if only some of the blocks have changed with respect to a previous notification.)
发送2.05（内容）通知时，服务器仅发送表示的第一个块。客户端检索表示的其余部分，就好像它是通过GET请求引起第一次响应一样，即，通过使用包含NUM值大于零的Block2选项的附加GET请求。（这将导致整个表示的传输，即使只有部分块相对于以前的通知发生了更改。）
As with other dynamically changing resources, to ensure that the blocks being reassembled are from the same version of the representation, the server SHOULD include an ETag Option in each response, and the reassembling client MUST compare the ETag Options (Section 2.4). Even more so than for the general case of Block2, clients that want to retrieve all blocks of a resource they have been notified about with a first block SHOULD strive to do so without undue delay.
与其他动态变化的资源一样，为了确保重新组装的块来自相同版本的表示，服务器应在每个响应中包含ETag选项，并且重新组装客户端必须比较ETag选项（第2.4节）。与Block2的一般情况相比，更重要的是，希望检索第一个块通知的资源的所有块的客户机应该努力做到不应有的延迟。
See Section 3.4 for examples.
示例见第3.4节。
In PUT and particularly in POST exchanges, both the request body and the response body may be large enough to require the use of block-wise transfers. First, the Block1 transfer of the request body proceeds as usual. In the exchange of the last slice of this block-wise transfer, the response carries the first slice of the Block2 transfer (NUM is zero). To continue this Block2 transfer, the client continues to send requests similar to the requests in the Block1 phase, but leaves out the Block1 Options and includes a Block2 request option with non-zero NUM.
在PUT中，特别是在POST交换中，请求主体和响应主体都可能足够大，需要使用分块传输。首先，请求主体的Block1传输照常进行。在交换此分块传输的最后一个片段时，响应携带Block2传输的第一个片段（NUM为零）。要继续此Block2传输，客户端将继续发送与Block1阶段中的请求类似的请求，但省略了Block1选项，并包括一个非零NUM的Block2请求选项。
Block2 transfers that retrieve the response body for a request that used Block1 MUST be performed in sequential order.
为使用Block1的请求检索响应正文的Block2传输必须按顺序执行。
A client can use the Block2 Option in a multicast GET request with NUM = 0 to aid in limiting the size of the response.
客户端可以在NUM=0的多播GET请求中使用Block2选项来帮助限制响应的大小。
Similarly, a response to a multicast GET request can use a Block2 Option with NUM = 0 if the representation is large, or to further limit the size of the response.
类似地，如果表示较大，对多播GET请求的响应可以使用NUM=0的Block2选项，或者进一步限制响应的大小。
In both cases, the client retrieves any further blocks using unicast exchanges; in the unicast requests, the client SHOULD heed any block size preferences indicated by the server in the response to the multicast request.
在这两种情况下，客户端使用单播交换检索任何进一步的块；在单播请求中，客户端应注意服务器在响应多播请求时指示的任何块大小首选项。
Other uses of the Block options in conjunction with multicast messages are for further study.
块选项与多播消息的其他用途有待进一步研究。
Beyond the response codes defined in [RFC7252], this specification defines two response codes and extends the meaning of one.
除了[RFC7252]中定义的响应代码外，本规范还定义了两个响应代码，并扩展了一个响应代码的含义。
This new success status code indicates that the transfer of this block of the request body was successful and that the server encourages sending further blocks, but that a final outcome of the whole block-wise request cannot yet be determined. No payload is returned with this response code.
此新的成功状态代码表示请求正文的此块的传输已成功，并且服务器鼓励发送更多块，但整个分块请求的最终结果尚无法确定。没有使用此响应代码返回有效负载。
This new client error status code indicates that the server has not received the blocks of the request body that it needs to proceed. The client has not sent all blocks, not sent them in the order required by the server, or has sent them long enough ago that the server has already discarded them.
此新的客户端错误状态代码表示服务器尚未收到需要继续处理的请求正文块。客户端没有发送所有数据块，没有按照服务器要求的顺序发送数据块，或者发送数据块的时间太长，以至于服务器已经丢弃了它们。
(Note that one reason for not having the necessary blocks at hand may be a Content-Format mismatch, see Section 2.3. Implementation note: A server can reject a Block1 transfer with this code when NUM != 0 and a different Content-Format is indicated than expected from the current state of the resource. If it implements the transfer in a stateless fashion, it can match up the Content-Format of the block against that of the existing resource. If it implements the transfer in an atomic fashion, it can match up the block against the partially reassembled piece of representation that is going to replace the state of the resource.)
（请注意，手头没有必要的块的一个原因可能是内容格式不匹配，请参阅第2.3节。实现说明：当NUM！=0时，服务器可以使用此代码拒绝Block1传输，并且从资源的当前状态指示的内容格式与预期的不同。如果服务器以无状态f执行传输例如，它可以将块的内容格式与现有资源的内容格式相匹配。如果它以原子方式实现传输，它可以将块与将替换资源状态的部分重新组装的表示相匹配。）
In Section 5.9.2.9 of [RFC7252], the response code 4.13 (Request Entity Too Large) is defined to be like HTTP 413 "Request Entity Too Large". [RFC7252] also recommends that this response SHOULD include a Size1 Option (Section 4) to indicate the maximum size of request entity the server is able and willing to handle, unless the server is not in a position to make this information available.
在[RFC7252]的第5.9.2.9节中，响应代码4.13（请求实体太大）被定义为类似HTTP 413“请求实体太大”。[RFC7252]还建议此响应应包括Size1选项（第4节），以指示服务器能够并愿意处理的请求实体的最大大小，除非服务器无法提供此信息。
The present specification allows the server to return this response code at any time during a Block1 transfer to indicate that it does not currently have the resources to store blocks for a transfer that it would intend to implement in an atomic fashion. It also allows the server to return a 4.13 response to a request that does not employ Block1 as a hint for the client to try sending Block1. Finally, a 4.13 response to a request with a Block1 Option (control usage, see Section 2.3) where the response carries a smaller SZX in its Block1 Option is a hint to try that smaller SZX.
本规范允许服务器在Block1传输期间的任何时候返回此响应代码，以指示其当前没有资源来存储其打算以原子方式实现的传输的块。它还允许服务器对不使用Block1的请求返回4.13响应，以提示客户端尝试发送Block1。最后，使用Block1选项（控制用法，参见第2.3节）对请求的4.13响应（其中响应在其Block1选项中包含较小的SZX）是尝试较小的SZX的提示。
This specification attempts to leave a variety of implementation strategies open for caches, in particular those in caching proxies. For example, a cache is free to cache blocks individually, but also could wait to obtain the complete representation before it serves parts of it. Partial caching may be more efficient in a cross-proxy (equivalent to a streaming HTTP proxy). A cached block (partial cached response) can be used in place of a complete response to satisfy a block-wise request that is presented to a cache. Note that different blocks can have different Max-Age values, as they are transferred at different times. A response with a block updates the freshness of the complete representation. Individual blocks can be validated, and validating a single block validates the complete representation. A response with a Block1 Option in control usage with the M bit set invalidates cached responses for the target URI.
本规范试图为缓存保留各种实现策略，特别是缓存代理中的实现策略。例如，缓存可以单独缓存块，但也可以在为部分缓存提供服务之前等待获得完整的表示。在跨代理（相当于流式HTTP代理）中，部分缓存可能更有效。可以使用缓存块（部分缓存响应）代替完整响应来满足呈现给缓存的块请求。请注意，不同的块可以具有不同的最大年龄值，因为它们在不同的时间传输。带有块的响应将更新完整表示的新鲜度。可以验证单个块，验证单个块将验证完整的表示。具有M位集的control usage中的Block1选项的响应将使目标URI的缓存响应无效。
A cache or proxy that combines responses (e.g., to split blocks in a request or increase the block size in a response, or a cross-proxy) may need to combine 2.31 and 2.01/2.04 responses; a stateless server may be responding with 2.01 only on the first Block1 block transferred, which dominates any 2.04 responses for later blocks.
组合响应（例如，在请求中分割块或在响应中增加块大小，或交叉代理）的缓存或代理可能需要组合2.31和2.01/2.04响应；无状态服务器可能仅在传输的第一个Block1块上使用2.01进行响应，这主导了后续块的任何2.04响应。
If-None-Match only works correctly on Block1 requests with (NUM=0) and MUST NOT be used on Block1 requests with NUM != 0.
如果“无匹配”仅在具有（NUM=0）的Block1请求上正确工作，并且不得在具有NUM！=0
This section gives a number of short examples with message flows for a block-wise GET, and for a PUT or POST. These examples demonstrate the basic operation, the operation in the presence of retransmissions, and examples for the operation of the block size negotiation.
本节给出了一些简短的示例，其中包含块式GET和PUT或POST的消息流。这些示例演示了基本操作、存在重传时的操作以及块大小协商操作的示例。
In all these examples, a Block option is shown in a decomposed way indicating the kind of Block option (1 or 2) followed by a colon, and then the block number (NUM), more bit (M), and block size exponent (2**(SZX+4)) separated by slashes. For example, a Block2 Option value of 33 would be shown as 2:2/0/32) and a Block1 Option value of 59 would be shown as 1:3/1/128.
在所有这些示例中，块选项以分解的方式显示，指示块选项的类型（1或2），后跟冒号，然后是由斜杠分隔的块编号（NUM）、更多位（M）和块大小指数（2**（SZX+4））。例如，Block2选项值33将显示为2:2/0/32），Block1选项值59将显示为1:3/1/128。
As in [RFC7252], "MID" is used as an abbreviation for "Message ID".
在[RFC7252]中，“MID”用作“消息ID”的缩写。
The first example (Figure 2) shows a GET request that is split into three blocks. The server proposes a block size of 128, and the client agrees. The first two ACKs contain a payload of 128 bytes each, and the third ACK contains a payload between 1 and 128 bytes.
第一个示例（图2）显示了一个GET请求，该请求被分为三个块。服务器建议块大小为128，客户端同意。前两个ACK分别包含128字节的有效负载，第三个ACK包含1到128字节之间的有效负载。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:1/0/128 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/128 |
| |
| CON [MID=1236], GET, /status, 2:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.05 Content, 2:2/0/128 |
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:1/0/128 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/128 |
| |
| CON [MID=1236], GET, /status, 2:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.05 Content, 2:2/0/128 |
Figure 2: Simple Block-Wise GET
图2：简单的分块GET
In the second example (Figure 3), the client anticipates the block-wise transfer (e.g., because of a size indication in the link-format description [RFC6690]) and sends a block size proposal. All ACK messages except for the last carry 64 bytes of payload; the last one carries between 1 and 64 bytes.
在第二个示例（图3）中，客户机预期按块传输（例如，由于链接格式描述[RFC6690]中的大小指示），并发送块大小建议。除最后一个ACK消息外的所有ACK消息都携带64字节的有效负载；最后一个包含1到64个字节。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status, 2:0/0/64 ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/64 |
| |
| CON [MID=1235], GET, /status, 2:1/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:4/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:4/1/64 |
| |
| CON [MID=1239], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1239], 2.05 Content, 2:5/0/64 |
CLIENT SERVER
| |
| CON [MID=1234], GET, /status, 2:0/0/64 ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/64 |
| |
| CON [MID=1235], GET, /status, 2:1/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:4/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:4/1/64 |
| |
| CON [MID=1239], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1239], 2.05 Content, 2:5/0/64 |
Figure 3: Block-Wise GET with Early Negotiation
图3：使用早期协商的分块GET
In the third example (Figure 4), the client is surprised by the need for a block-wise transfer, and unhappy with the size chosen unilaterally by the server. As it did not send a size proposal initially, the negotiation only influences the size from the second message exchange onward. Since the client already obtained both the first and second 64-byte block in the first 128-byte exchange, it goes on requesting the third 64-byte block ("2/0/64"). None of this is (or needs to be) understood by the server, which simply responds to the requests as it best can.
在第三个示例（图4）中，客户机对按块传输的需求感到惊讶，对服务器单方面选择的大小感到不满意。由于最初未发送大小建议，协商仅影响从第二次消息交换开始的大小。由于客户机已经在第一个128字节交换中获得了第一个和第二个64字节块，因此它继续请求第三个64字节块（“2/0/64”）。服务器不理解（或不需要理解）所有这些，它只是尽可能地响应请求。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
| |
| CON [MID=1236], GET, /status, 2:3/0/64 ------> |
| |
| <------ ACK [MID=1236], 2.05 Content, 2:3/1/64 |
| |
| CON [MID=1237], GET, /status, 2:4/0/64 ------> |
| |
| <------ ACK [MID=1237], 2.05 Content, 2:4/1/64 |
| |
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
| |
| CON [MID=1236], GET, /status, 2:3/0/64 ------> |
| |
| <------ ACK [MID=1236], 2.05 Content, 2:3/1/64 |
| |
| CON [MID=1237], GET, /status, 2:4/0/64 ------> |
| |
| <------ ACK [MID=1237], 2.05 Content, 2:4/1/64 |
| |
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
Figure 4: Block-Wise GET with Late Negotiation
图4：延迟协商的分块GET
In all these (and the following) cases, retransmissions are handled by the CoAP message exchange layer, so they don't influence the block operations (Figures 5 and 6).
在所有这些（及以下）情况下，重传由CoAP消息交换层处理，因此它们不会影响块操作（图5和图6）。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GE///////////////////////// |
| |
| (timeout) |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GE///////////////////////// |
| |
| (timeout) |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
Figure 5: Block-Wise GET with Late Negotiation and Lost CON
图5：延迟协商和失败协商的分块GET
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| //////////////////////////////////tent, 2:2/1/64 |
| |
| (timeout) |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| //////////////////////////////////tent, 2:2/1/64 |
| |
| (timeout) |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
Figure 6: Block-Wise GET with Late Negotiation and Lost ACK
图6：延迟协商和丢失ACK的分块GET
The following examples demonstrate a PUT exchange; a POST exchange looks the same, with different requirements on atomicity/idempotence. Note that, similar to GET, the responses to the requests that have a more bit in the request Block1 Option are provisional and carry the response code 2.31 (Continue); only the final response tells the client that the PUT succeeded.
以下示例演示了看跌期权交换；POST交换看起来相同，但对原子性/幂等性的要求不同。注意，与GET类似，对请求Block1选项中具有更多位的请求的响应是临时的，并且带有响应代码2.31（Continue）；只有最后的响应告诉客户端PUT成功。
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
Figure 7: Simple Atomic Block-Wise PUT
图7：简单的原子分块PUT
A stateless server that simply builds/updates the resource in place (statelessly) may indicate this by not setting the more bit in the response (Figure 8); in this case, the response codes are valid separately for each block being updated. This is of course only an acceptable behavior of the server if the potential inconsistency present during the run of the message exchange sequence does not lead to problems, e.g., because the resource being created or changed is not yet or not currently in use.
一个无状态服务器只是就地（无状态地）构建/更新资源，它可以通过不在响应中设置更多位来指示这一点（图8）；在这种情况下，响应代码对于正在更新的每个块分别有效。当然，如果消息交换序列运行期间存在的潜在不一致不会导致问题（例如，因为正在创建或更改的资源尚未使用或当前未使用），则这只是服务器可接受的行为。
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.04 Changed, 1:0/0/128 |
| |
| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.04 Changed, 1:1/0/128 |
| |
| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.04 Changed, 1:0/0/128 |
| |
| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.04 Changed, 1:1/0/128 |
| |
| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
Figure 8: Simple Stateless Block-Wise PUT
图8：简单无状态分块PUT
Finally, a server receiving a block-wise PUT or POST may want to indicate a smaller block size preference (Figure 9). In this case, the client SHOULD continue with a smaller block size; if it does, it MUST adjust the block number to properly count in that smaller size.
最后，接收分块PUT或POST的服务器可能希望指示较小的块大小首选项（图9）。在这种情况下，客户端应继续使用较小的块大小；如果是这样，它必须调整块号，以便在较小的大小中正确计数。
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/32 |
| |
| CON [MID=1235], PUT, /options, 1:4/1/32 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:4/1/32 |
| |
| CON [MID=1236], PUT, /options, 1:5/1/32 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:5/1/32 |
| |
| CON [MID=1237], PUT, /options, 1:6/0/32 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:6/0/32 |
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/32 |
| |
| CON [MID=1235], PUT, /options, 1:4/1/32 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:4/1/32 |
| |
| CON [MID=1236], PUT, /options, 1:5/1/32 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:5/1/32 |
| |
| CON [MID=1237], PUT, /options, 1:6/0/32 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:6/0/32 |
Figure 9: Simple Atomic Block-Wise PUT with Negotiation
图9：带协商的简单原子分块PUT
Block options may be used in both directions of a single exchange. The following example demonstrates a block-wise POST request, resulting in a separate block-wise response.
块选项可以在单个交换的两个方向上使用。下面的示例演示了一个分块POST请求，从而产生一个单独的分块响应。
CLIENT SERVER
| |
| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], POST, /soap, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 2:0/1/128, 1:2/0/128 |
| |
| CON [MID=1237], POST, /soap, 2:1/0/128 ------> |
| (no payload for requests with Block2 with NUM != 0) |
| (could also do late negotiation by requesting, |
| e.g., 2:2/0/64) |
| |
| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/128 |
| |
| CON [MID=1238], POST, /soap, 2:2/0/128 ------> |
| |
| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/128 |
| |
| CON [MID=1239], POST, /soap, 2:3/0/128 ------> |
| |
| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/128 |
CLIENT SERVER
| |
| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], POST, /soap, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 2:0/1/128, 1:2/0/128 |
| |
| CON [MID=1237], POST, /soap, 2:1/0/128 ------> |
| (no payload for requests with Block2 with NUM != 0) |
| (could also do late negotiation by requesting, |
| e.g., 2:2/0/64) |
| |
| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/128 |
| |
| CON [MID=1238], POST, /soap, 2:2/0/128 ------> |
| |
| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/128 |
| |
| CON [MID=1239], POST, /soap, 2:3/0/128 ------> |
| |
| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/128 |
Figure 10: Atomic Block-Wise POST with Block-Wise Response
图10：具有分块响应的原子分块POST
This model does provide for early negotiation input to the Block2 block-wise transfer, as shown below.
该模型确实提供了区块2分块传输的早期协商输入，如下所示。
CLIENT SERVER
| |
| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], POST, /soap, 1:2/0/128, 2:0/0/64 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128, 2:0/1/64 |
| |
| CON [MID=1237], POST, /soap, 2:1/0/64 ------> |
| (no payload for requests with Block2 with NUM != 0) |
| |
| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/64 |
| |
| CON [MID=1238], POST, /soap, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/64 |
| |
| CON [MID=1239], POST, /soap, 2:3/0/64 ------> |
| |
| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/64 |
CLIENT SERVER
| |
| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], POST, /soap, 1:2/0/128, 2:0/0/64 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128, 2:0/1/64 |
| |
| CON [MID=1237], POST, /soap, 2:1/0/64 ------> |
| (no payload for requests with Block2 with NUM != 0) |
| |
| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/64 |
| |
| CON [MID=1238], POST, /soap, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/64 |
| |
| CON [MID=1239], POST, /soap, 2:3/0/64 ------> |
| |
| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/64 |
Figure 11: Atomic Block-Wise POST with Block-Wise Response, Early Negotiation
图11：具有分块响应的原子分块POST，早期协商
In the following example, the server first sends a direct response (Observe sequence number 62350) to the initial GET request (the resulting block-wise transfer is as in Figure 4 and has therefore been left out). The second transfer is started by a 2.05 notification that contains just the first block (Observe sequence number 62354); the client then goes on to obtain the rest of the blocks.
在下面的示例中，服务器首先向初始GET请求发送一个直接响应（观察序列号62350）（生成的分块传输如图4所示，因此被省略）。第二次传输由2.05通知开始，该通知仅包含第一个块（遵守序列号62354）；然后，客户机继续获取其余的块。
CLIENT SERVER
| |
+----->| Header: GET 0x41011636
| GET | Token: 0xfb
| | Uri-Path: status-icon
| | Observe: (empty)
| |
|<-----+ Header: 2.05 0x61451636
| 2.05 | Token: 0xfb
| | Block2: 0/1/128
| | Observe: 62350
| | ETag: 6f00f38e
| | Payload: [128 bytes]
| |
| | (Usual GET transfer left out)
...
| | (Notification of first block)
| |
|<-----+ Header: 2.05 0x4145af9c
| 2.05 | Token: 0xfb
| | Block2: 0/1/128
| | Observe: 62354
| | ETag: 6f00f392
| | Payload: [128 bytes]
| |
+- - ->| Header: 0x6000af9c
| |
| | (Retrieval of remaining blocks)
| |
+----->| Header: GET 0x41011637
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 1/0/128
| |
|<-----+ Header: 2.05 0x61451637
| 2.05 | Token: 0xfc
| | Block2: 1/1/128
| | ETag: 6f00f392
| | Payload: [128 bytes]
| |
+----->| Header: GET 0x41011638
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 2/0/128
| |
CLIENT SERVER
| |
+----->| Header: GET 0x41011636
| GET | Token: 0xfb
| | Uri-Path: status-icon
| | Observe: (empty)
| |
|<-----+ Header: 2.05 0x61451636
| 2.05 | Token: 0xfb
| | Block2: 0/1/128
| | Observe: 62350
| | ETag: 6f00f38e
| | Payload: [128 bytes]
| |
| | (Usual GET transfer left out)
...
| | (Notification of first block)
| |
|<-----+ Header: 2.05 0x4145af9c
| 2.05 | Token: 0xfb
| | Block2: 0/1/128
| | Observe: 62354
| | ETag: 6f00f392
| | Payload: [128 bytes]
| |
+- - ->| Header: 0x6000af9c
| |
| | (Retrieval of remaining blocks)
| |
+----->| Header: GET 0x41011637
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 1/0/128
| |
|<-----+ Header: 2.05 0x61451637
| 2.05 | Token: 0xfc
| | Block2: 1/1/128
| | ETag: 6f00f392
| | Payload: [128 bytes]
| |
+----->| Header: GET 0x41011638
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 2/0/128
| |
|<-----+ Header: 2.05 0x61451638
| 2.05 | Token: 0xfc
| | Block2: 2/0/128
| | ETag: 6f00f392
| | Payload: [53 bytes]
|<-----+ Header: 2.05 0x61451638
| 2.05 | Token: 0xfc
| | Block2: 2/0/128
| | ETag: 6f00f392
| | Payload: [53 bytes]
Figure 12: Observe Sequence with Block-Wise Response
图12：观察分块响应的顺序
(Note that the choice of token 0xfc in this example is arbitrary; tokens are just shown in this example to illustrate that the requests for additional blocks cannot make use of the token of the Observation relationship. As a general comment on tokens, there is no other mention of tokens in this document, as block-wise transfers handle tokens like any other CoAP exchange. As usual, the client is free to choose tokens for each exchange as it likes.)
（请注意，本例中对令牌0xfc的选择是任意的；本例中显示的令牌只是为了说明对附加块的请求不能利用观察关系的令牌。作为对令牌的一般性评论，本文档中没有提及令牌，因为分块传输处理的令牌如下所示任何其他CoAP交换。与往常一样，客户可以根据自己的喜好为每个交换选择代币。）
In the following example, the client also uses early negotiation to limit the block size to 64 bytes.
在下面的示例中，客户端还使用早期协商将块大小限制为64字节。
CLIENT SERVER
| |
+----->| Header: GET 0x41011636
| GET | Token: 0xfb
| | Uri-Path: status-icon
| | Observe: (empty)
| | Block2: 0/0/64
| |
|<-----+ Header: 2.05 0x61451636
| 2.05 | Token: 0xfb
| | Block2: 0/1/64
| | Observe: 62350
| | ETag: 6f00f38e
| | Max-Age: 60
| | Payload: [64 bytes]
| |
| | (Usual GET transfer left out)
...
| | (Notification of first block)
| |
|<-----+ Header: 2.05 0x4145af9c
| 2.05 | Token: 0xfb
| | Block2: 0/1/64
| | Observe: 62354
| | ETag: 6f00f392
| | Payload: [64 bytes]
| |
CLIENT SERVER
| |
+----->| Header: GET 0x41011636
| GET | Token: 0xfb
| | Uri-Path: status-icon
| | Observe: (empty)
| | Block2: 0/0/64
| |
|<-----+ Header: 2.05 0x61451636
| 2.05 | Token: 0xfb
| | Block2: 0/1/64
| | Observe: 62350
| | ETag: 6f00f38e
| | Max-Age: 60
| | Payload: [64 bytes]
| |
| | (Usual GET transfer left out)
...
| | (Notification of first block)
| |
|<-----+ Header: 2.05 0x4145af9c
| 2.05 | Token: 0xfb
| | Block2: 0/1/64
| | Observe: 62354
| | ETag: 6f00f392
| | Payload: [64 bytes]
| |
+- - ->| Header: 0x6000af9c
| |
| | (Retrieval of remaining blocks)
| |
+----->| Header: GET 0x41011637
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 1/0/64
| |
|<-----+ Header: 2.05 0x61451637
| 2.05 | Token: 0xfc
| | Block2: 1/1/64
| | ETag: 6f00f392
| | Payload: [64 bytes]
....
| |
+----->| Header: GET 0x41011638
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 4/0/64
| |
|<-----+ Header: 2.05 0x61451638
| 2.05 | Token: 0xfc
| | Block2: 4/0/64
| | ETag: 6f00f392
| | Payload: [53 bytes]
+- - ->| Header: 0x6000af9c
| |
| | (Retrieval of remaining blocks)
| |
+----->| Header: GET 0x41011637
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 1/0/64
| |
|<-----+ Header: 2.05 0x61451637
| 2.05 | Token: 0xfc
| | Block2: 1/1/64
| | ETag: 6f00f392
| | Payload: [64 bytes]
....
| |
+----->| Header: GET 0x41011638
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 4/0/64
| |
|<-----+ Header: 2.05 0x61451638
| 2.05 | Token: 0xfc
| | Block2: 4/0/64
| | ETag: 6f00f392
| | Payload: [53 bytes]
Figure 13: Observe Sequence with Early Negotiation
图13：遵守早期协商的顺序
In many cases when transferring a large resource representation block by block, it is advantageous to know the total size early in the process. Some indication may be available from the maximum size estimate attribute "sz" provided in a resource description [RFC6690]. However, the size may vary dynamically, so a more up-to-date indication may be useful.
在许多情况下，当逐块传输大型资源表示时，在过程的早期了解总大小是有利的。资源描述[RFC6690]中提供的最大规模估算属性“sz”可能有一些指示。但是，大小可能会动态变化，因此更及时的指示可能会有用。
This specification defines two CoAP options, Size1 for indicating the size of the representation transferred in requests, and Size2 for indicating the size of the representation transferred in responses. (Size1 has already been defined in Section 5.10.9 of [RFC7252] to provide "size information about the resource representation in a request"; however, that section only details the narrow case of indicating in 4.13 responses the maximum size of request payload that the server is able and willing to handle. The present specification provides details about its use as a request option as well.)
本规范定义了两个CoAP选项，Size1用于指示在请求中传输的表示的大小，Size2用于指示在响应中传输的表示的大小。（Size1已在[RFC7252]的第5.10.9节中定义，以提供“请求中资源表示的大小信息”；但是，该部分仅详细说明了在4.13响应中指示服务器能够并愿意处理的请求有效负载的最大大小的狭义情况。本规范还提供了有关其作为请求选项使用的详细信息。）
The Size2 Option may be used for two purposes:
Size2选项可用于两个目的：
o In a request, to ask the server to provide a size estimate along with the usual response ("size request"). For this usage, the value MUST be set to 0.
o 在请求中，要求服务器提供大小估计值以及通常的响应（“大小请求”）。对于此用法，该值必须设置为0。
o In a response carrying a Block2 Option, to indicate the current estimate the server has of the total size of the resource representation, measured in bytes ("size indication").
o 在带有Block2选项的响应中，指示服务器对资源表示的总大小的当前估计，以字节为单位（“大小指示”）。
Similarly, the Size1 Option may be used for two purposes:
同样，Size1选项可用于两个目的：
o In a request carrying a Block1 Option, to indicate the current estimate the client has of the total size of the resource representation, measured in bytes ("size indication").
o 在带有Block1选项的请求中，指示客户端对资源表示的总大小的当前估计，以字节为单位（“大小指示”）。
o In a 4.13 response, to indicate the maximum size that would have been acceptable [RFC7252], measured in bytes.
o 在4.13响应中，指示可接受的最大大小[RFC7252]，以字节为单位。
Apart from conveying/asking for size information, the Size options have no other effect on the processing of the request or response. If the client wants to minimize the size of the payload in the resulting response, it should add a Block2 Option to the request with a small block size (e.g., setting SZX=0).
除了传达/询问尺寸信息外，尺寸选项对请求或响应的处理没有其他影响。如果客户机希望在结果响应中最小化有效负载的大小，则应使用较小的块大小（例如，设置SZX=0）向请求添加Block2选项。
The Size options are "elective", i.e., a client MUST be prepared for the server to ignore the size estimate request. Either Size option MUST NOT occur more than once in a single message.
大小选项是“可选的”，即客户端必须准备好让服务器忽略大小估计请求。任一大小选项在单个消息中不得出现多次。
+-----+---+---+---+---+-------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+-------+--------+--------+---------+
| 60 | | | x | | Size1 | uint | 0-4 | (none) |
| | | | | | | | | |
| 28 | | | x | | Size2 | uint | 0-4 | (none) |
+-----+---+---+---+---+-------+--------+--------+---------+
+-----+---+---+---+---+-------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+-------+--------+--------+---------+
| 60 | | | x | | Size1 | uint | 0-4 | (none) |
| | | | | | | | | |
| 28 | | | x | | Size2 | uint | 0-4 | (none) |
+-----+---+---+---+---+-------+--------+--------+---------+
Table 2: Size Option Numbers
表2：尺寸选项编号
Implementation Notes:
实施说明：
o As a quality of implementation consideration, block-wise transfers for which the total size considerably exceeds the size of one block are expected to include size indications, whenever those can be provided without undue effort (preferably with the first block exchanged). If the size estimate does not change, the indication does not need to be repeated for every block.
o 作为实施质量的考虑因素，总大小大大超过一个块大小的块式传输预期包括大小指示，只要可以在不过度努力的情况下提供这些指示（最好交换第一个块）。如果尺寸估计值不变，则无需对每个块重复指示。
o The end of a block-wise transfer is governed by the M bits in the Block options, _not_ by exhausting the size estimates exchanged.
o 按块传输的结束由块选项中的M位控制，而不是通过耗尽交换的大小估计值。
o As usual for an option of type uint, the value 0 is best expressed as an empty option (0 bytes). There is no default value for either Size option.
o 与uint类型的选项一样，值0最好表示为空选项（0字节）。两个尺寸选项都没有默认值。
o The Size options are neither critical nor unsafe, and are marked as No-Cache-Key.
o 大小选项既不重要也不不安全，并且标记为无缓存密钥。
In this subsection, we give some brief examples of the influence that the Block options might have on intermediaries that map between CoAP and HTTP.
在本小节中，我们将给出一些简短的示例，说明块选项可能对映射到CoAP和HTTP之间的中介体产生的影响。
For mapping CoAP requests to HTTP, the intermediary may want to map the sequence of block-wise transfers into a single HTTP transfer. For example, for a GET request, the intermediary could perform the HTTP request once the first block has been requested and could then fulfill all further block requests out of its cache. A constrained implementation may not be able to cache the entire object and may use a combination of TCP flow control and (in particular if timeouts occur) HTTP range requests to obtain the information necessary for the next block transfer at the right time.
为了将CoAP请求映射到HTTP，中介可能希望将按块传输的序列映射到单个HTTP传输。例如，对于GET请求，中介可以在请求第一个块后执行HTTP请求，然后从缓存中完成所有进一步的块请求。受约束的实现可能无法缓存整个对象，并且可能使用TCP流控制和（特别是在发生超时时）HTTP范围请求的组合来获取在正确时间进行下一次块传输所需的信息。
For PUT or POST requests, historically there was more variation in how HTTP servers might implement ranges; recently, [RFC7233] has defined that Range header fields received with a request method other than GET are not to be interpreted. So, in general, the CoAP-to-HTTP intermediary will have to try sending the payload of all the blocks of a block-wise transfer for these other methods within one HTTP request. If enough buffering is available, this request can be started when the last CoAP block is received. A constrained implementation may want to relieve its buffering by already starting to send the HTTP request at the time the first CoAP block is received; any HTTP 408 status code that indicates that the HTTP server became impatient with the resulting transfer can then be mapped into a CoAP 4.08 response code (similarly, 413 maps to 4.13).
对于PUT或POST请求，历史上HTTP服务器实现范围的方式变化较大；最近，[RFC7233]定义了不解释使用GET以外的请求方法接收的范围标头字段。因此，通常情况下，CoAP-to-HTTP中介必须尝试在一个HTTP请求中发送这些其他方法的块式传输的所有块的有效负载。如果有足够的缓冲可用，则可以在接收到最后一个CoAP块时启动此请求。受约束的实现可能希望通过在接收到第一个CoAP块时已经开始发送HTTP请求来释放其缓冲；指示HTTP服务器对结果传输变得不耐烦的任何HTTP 408状态代码随后可映射为CoAP 4.08响应代码（类似地，413映射为4.13）。
For mapping HTTP to CoAP, the intermediary may want to map a single HTTP transfer into a sequence of block-wise transfers. If the HTTP client is too slow delivering a request body on a PUT or POST, the CoAP server might time out and return a 4.08 response code, which in turn maps well to an HTTP 408 status code (again, 4.13 maps to 413). HTTP range requests received on the HTTP side may be served out of a cache and/or mapped to GET requests that request a sequence of blocks that cover the range.
为了将HTTP映射到CoAP，中介可能希望将单个HTTP传输映射到一系列分块传输。如果HTTP客户端在PUT或POST上传递请求正文的速度太慢，则CoAP服务器可能会超时并返回4.08响应代码，这反过来很好地映射到HTTP 408状态代码（同样，4.13映射到413）。在HTTP端接收的HTTP范围请求可以从缓存中提供和/或映射以获取请求覆盖该范围的块序列的请求。
(Note that, while the semantics of CoAP 4.08 and HTTP 408 differ, this difference is largely due to the different way the two protocols are mapped to transport. HTTP has an underlying TCP connection, which supplies connection state, so an HTTP 408 status code can immediately be used to indicate that a timeout occurred during transmitting a request through that active TCP connection. The CoAP 4.08 response code indicates one or more missing blocks, which may be due to timeouts or resource constraints; as there is no connection state, there is no way to deliver such a response immediately; instead, it is delivered on the next block transfer. Still, HTTP 408 is probably the best mapping back to HTTP, as the timeout is the most likely cause for a CoAP 4.08. Note that there is no way to distinguish a timeout from a missing block for a server without creating additional state, the need for which we want to avoid.)
（注意，虽然CoAP 4.08和HTTP 408的语义不同，但这种差异主要是由于这两个协议映射到传输的方式不同。HTTP具有提供连接状态的底层TCP连接，因此HTTP 408状态代码可立即用于指示在传输请求期间发生超时。）通过该活动TCP连接。CoAP 4.08响应代码指示一个或多个丢失的块，这可能是由于超时或资源限制所致；由于没有连接状态，因此无法立即传递此类响应；相反，它在下一个块传输时传递。不过，HTTP 408可能是最好的映射对于HTTP，超时是最有可能导致CoAP 4.08的原因。请注意，如果不创建额外的状态（我们希望避免这种需要），就无法区分服务器的超时和丢失的块。）
This document adds the following option numbers to the "CoAP Option Numbers" registry defined by [RFC7252]:
本文档将以下选项编号添加到[RFC7252]定义的“CoAP选项编号”注册表中：
+--------+--------+-----------+
| Number | Name | Reference |
+--------+--------+-----------+
| 23 | Block2 | RFC 7959 |
| | | |
| 27 | Block1 | RFC 7959 |
| | | |
| 28 | Size2 | RFC 7959 |
+--------+--------+-----------+
+--------+--------+-----------+
| Number | Name | Reference |
+--------+--------+-----------+
| 23 | Block2 | RFC 7959 |
| | | |
| 27 | Block1 | RFC 7959 |
| | | |
| 28 | Size2 | RFC 7959 |
+--------+--------+-----------+
Table 3: CoAP Option Numbers
表3:CoAP选项编号
This document adds the following response codes to the "CoAP Response Codes" registry defined by [RFC7252]:
本文档将以下响应代码添加到[RFC7252]定义的“CoAP响应代码”注册表中：
+------+---------------------------+-----------+
| Code | Description | Reference |
+------+---------------------------+-----------+
| 2.31 | Continue | RFC 7959 |
| | | |
| 4.08 | Request Entity Incomplete | RFC 7959 |
+------+---------------------------+-----------+
+------+---------------------------+-----------+
| Code | Description | Reference |
+------+---------------------------+-----------+
| 2.31 | Continue | RFC 7959 |
| | | |
| 4.08 | Request Entity Incomplete | RFC 7959 |
+------+---------------------------+-----------+
Table 4: CoAP Response Codes
表4:CoAP响应代码
Providing access to blocks within a resource may lead to surprising vulnerabilities. Where requests are not implemented atomically, an attacker may be able to exploit a race condition or confuse a server by inducing it to use a partially updated resource representation. Partial transfers may also make certain problematic data invisible to Intrusion Detection Systems (IDSs); it is RECOMMENDED that an IDS that analyzes resource representations transferred by CoAP implement the Block options to gain access to entire resource representations. Still, approaches such as transferring even-numbered blocks on one path and odd-numbered blocks on another path, or even transferring blocks multiple times with different content and obtaining a different interpretation of temporal order at the IDS than at the server, may prevent an IDS from seeing the whole picture. These kinds of attacks are well understood from IP fragmentation and TCP segmentation; CoAP does not add fundamentally new considerations.
提供对资源内块的访问可能会导致意外的漏洞。如果请求不是以原子方式实现的，攻击者可能会利用竞争条件，或通过诱导服务器使用部分更新的资源表示来混淆服务器。部分传输还可能使某些有问题的数据对入侵检测系统（IDS）不可见；建议分析CoAP传输的资源表示的IDS实施块选项，以访问整个资源表示。然而，诸如在一条路径上传输偶数编号的块和在另一条路径上传输奇数编号的块，或者在IDS处以不同的内容多次传输块并获得与在服务器处不同的时序解释的方法，可能会阻止IDS看到整个画面。从IP碎片和TCP分段可以很好地理解这些类型的攻击；CoAP并没有从根本上增加新的考虑因素。
Where access to a resource is only granted to clients making use of specific security associations, all blocks of that resource MUST be subject to the same security checks; it MUST NOT be possible for unprotected exchanges to influence blocks of an otherwise protected resource. As a related consideration, where object security is employed, PUT/POST should be implemented in the atomic fashion, unless the object security operation is performed on each access and the creation of unusable resources can be tolerated. Future end-to-end security mechanisms that may be added to CoAP itself may have related security considerations, this includes considerations about caching of blocks in clients and in proxies (see Sections 2.10 and 5 for different strategies in performing this caching); these security considerations will need to be described in the specifications of those mechanisms.
如果仅允许使用特定安全关联的客户端访问资源，则该资源的所有块必须接受相同的安全检查；不受保护的交换不能影响其他受保护资源的块。作为一个相关的考虑因素，在使用对象安全性的情况下，PUT/POST应该以原子方式实现，除非对每个访问执行对象安全性操作，并且可以容忍创建不可用的资源。可能添加到CoAP本身的未来端到端安全机制可能具有相关的安全考虑因素，这包括有关在客户端和代理中缓存块的考虑因素（有关执行此缓存的不同策略，请参见第2.10和5节）；这些安全注意事项需要在这些机制的规范中加以说明。
A stateless server might be susceptible to an attack where the adversary sends a Block1 (e.g., PUT) block with a high block number: A naive implementation might exhaust its resources by creating a huge resource representation.
无状态服务器可能容易受到攻击，对手发送具有高块号的Block1（例如，PUT）块：简单的实现可能会通过创建巨大的资源表示耗尽其资源。
Misleading size indications may be used by an attacker to induce buffer overflows in poor implementations, for which the usual considerations apply.
攻击者可能会使用误导性的大小指示，在较差的实现中导致缓冲区溢出，通常的注意事项适用于此。
Certain block-wise requests may induce the server to create state, e.g., to create a snapshot for the block-wise GET of a fast-changing resource to enable consistent access to the same version of a resource for all blocks, or to create temporary resource
某些分块请求可能会导致服务器创建状态，例如，为快速变化资源的分块获取创建快照，以支持对所有分块的同一版本资源的一致访问，或创建临时资源
representations that are collected until pressed into service by a final PUT or POST with the more bit unset. All mechanisms that induce a server to create state that cannot simply be cleaned up create opportunities for denial-of-service attacks. Servers SHOULD avoid being subject to resource exhaustion based on state created by untrusted sources. But even if this is done, the mitigation may cause a denial-of-service to a legitimate request when it is drowned out by other state-creating requests. Wherever possible, servers should therefore minimize the opportunities to create state for untrusted sources, e.g., by using stateless approaches.
在最后一次PUT或POST（未设置的位较多）将其压入服务之前收集的表示。所有导致服务器创建无法简单清除的状态的机制都会为拒绝服务攻击创造机会。基于不受信任的源创建的状态，服务器应避免资源耗尽。但即使这样做了，当合法请求被其他创建状态的请求淹没时，缓解措施也可能导致拒绝服务。因此，服务器应尽可能减少为不受信任的源创建状态的机会，例如使用无状态方法。
Performing segmentation at the application layer is almost always better in this respect than at the transport layer or lower (IP fragmentation, adaptation-layer fragmentation), for instance, because there are application-layer semantics that can be used for mitigation or because lower layers provide security associations that can prevent attacks. However, it is less common to apply timeouts and keepalive mechanisms at the application layer than at lower layers. Servers MAY want to clean up accumulated state by timing it out (cf. response code 4.08), and clients SHOULD be prepared to run block-wise transfers in an expedient way to minimize the likelihood of running into such a timeout.
例如，在应用层执行分段在这方面几乎总是比在传输层或更低层（IP分段、适配层分段）更好，因为存在可用于缓解的应用程序层语义，或者因为较低层提供可防止攻击的安全关联。但是，在应用程序层应用超时和保持机制的情况要比在较低层的情况少。服务器可能希望通过超时来清除累积状态（参见响应代码4.08），并且客户端应该准备好以一种方便的方式运行分块传输，以最大限度地降低运行到这种超时的可能性。
[RFC7252] discusses the susceptibility of CoAP endpoints for use in amplification attacks.
[RFC7252]讨论了用于放大攻击的CoAP端点的易感性。
A CoAP server can reduce the amount of amplification it provides to an attacker by offering large resource representations only in relatively small blocks. With this, e.g., for a 1000-byte resource, a 10-byte request might result in an 80-byte response (with a 64-byte block) instead of a 1016-byte response, considerably reducing the amplification provided.
CoAP服务器可以通过仅在相对较小的块中提供大型资源表示来减少其提供给攻击者的放大量。这样，例如，对于1000字节的资源，10字节的请求可能会导致80字节的响应（带有64字节的块）而不是1016字节的响应，从而大大减少了提供的放大。
[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>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<http://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <http://www.rfc-editor.org/info/rfc7641>.
[RFC7641]Hartke，K.，“受限应用协议（CoAP）中的观测资源”，RFC 7641，DOI 10.17487/RFC7641，2015年9月<http://www.rfc-editor.org/info/rfc7641>.
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>.
[REST]Fielding，R.，“架构风格和基于网络的软件架构的设计”，博士。学位论文，加利福尼亚大学，尔湾，2000，<http://www.ics.uci.edu/~fielding/pubs/demission/fielding\u demission.pdf>。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <http://www.rfc-editor.org/info/rfc4919>.
[RFC4919]Kushalnagar，N.，黑山，G.和C.Schumacher，“低功率无线个人区域网络（6LoWPANs）上的IPv6：概述，假设，问题陈述和目标”，RFC 4919，DOI 10.17487/RFC4919，2007年8月<http://www.rfc-editor.org/info/rfc4919>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 4944，DOI 10.17487/RFC4944，2007年9月<http://www.rfc-editor.org/info/rfc4944>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>.
[RFC6690]Shelby，Z.“受限RESTful环境（核心）链接格式”，RFC 6690，DOI 10.17487/RFC6690，2012年8月<http://www.rfc-editor.org/info/rfc6690>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，DOI 10.17487/RFC7228，2014年5月<http://www.rfc-editor.org/info/rfc7228>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <http://www.rfc-editor.org/info/rfc7233>.
[RFC7233]Fielding，R.，Ed.，Lafon，Y.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：范围请求”，RFC 7233，DOI 10.17487/RFC7233，2014年6月<http://www.rfc-editor.org/info/rfc7233>.
Acknowledgements
致谢
Much of the content of this document is the result of discussions with the [RFC7252] authors, and via many CoRE WG discussions.
本文档的大部分内容是与[RFC7252]作者讨论的结果，以及通过许多核心工作组讨论的结果。
Charles Palmer provided extensive editorial comments to a previous draft version of this document, some of which have been covered in this document. Esko Dijk reviewed a more recent version, leading to a number of further editorial improvements, a solution to the 4.13 ambiguity problem, and the section about combining Block and multicast (Section 2.8). Markus Becker proposed getting rid of an ill-conceived default value for the Block2 and Block1 Options. Peter Bigot insisted on a more systematic coverage of the options and response code. Qin Wu provided a review for the IETF Operations directorate, and Goeran Selander commented on the security considerations.
查尔斯·帕尔默（Charles Palmer）对本文件的前一个草案版本提供了广泛的编辑评论，其中一些已包含在本文件中。Esko Dijk回顾了一个较新的版本，导致了一些进一步的编辑改进、4.13歧义问题的解决方案，以及关于组合块和多播的部分（第2.8节）。Markus Becker建议取消Block2和Block1期权的错误默认值。Peter Bigot坚持对选项和响应代码进行更系统的覆盖。秦武为IETF作战指挥部提供了审查，Goeran Selander对安全考虑发表了评论。
Kepeng Li, Linyi Tian, and Barry Leiba wrote up an early version of the Size option, which is described in this document. Klaus Hartke wrote some of the text describing the interaction of Block2 with Observe. Matthias Kovatsch provided a number of significant simplifications of the protocol.
李克鹏、田临沂和巴里·雷巴编写了尺寸选项的早期版本，本文对此进行了描述。克劳斯·哈特克写了一些描述Block2与Observe互动的文字。Matthias Kovatsch对该协议进行了许多重大简化。
The IESG reviewers provided very useful comments. Spencer Dawkins even suggested new text. He and Mirja Kuehlewind insisted on more explicit information about the layering of block-wise transfers on top of the base protocol. Ben Campbell helped untangle some MUST/ SHOULD soup. Comments by Alexey Melnikov, as well as the Gen-ART review by Jouni Korhonen, resulted in further improvements to the text.
IESG评审员提供了非常有用的意见。斯宾塞·道金斯甚至提出了新的文本。他和Mirja Kuehlewind坚持在基本协议的基础上提供关于分块传输分层的更明确的信息。本·坎贝尔帮助解开了一些必须/应该喝的汤。Alexey Melnikov的评论以及Jouni Korhonen的Gen ART review进一步改进了文本。
Authors' Addresses
作者地址
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
卡斯滕·鲍曼大学不来梅邮政学院330440不来梅D-28359德国
Phone: +49-421-218-63921
Email: cabo@tzi.org
Phone: +49-421-218-63921
Email: cabo@tzi.org
Zach Shelby (editor) ARM 150 Rose Orchard San Jose, CA 95134 United States of America
Zach Shelby（编辑）ARM 150美国加利福尼亚州圣何塞玫瑰园95134
Phone: +1-408-203-9434
Email: zach.shelby@arm.com
Phone: +1-408-203-9434
Email: zach.shelby@arm.com