Internet Engineering Task Force (IETF) A. Keranen
Request for Comments: 8516 Ericsson
Category: Standards Track January 2019
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Keranen
Request for Comments: 8516 Ericsson
Category: Standards Track January 2019
ISSN: 2070-1721
"Too Many Requests" Response Code for the Constrained Application Protocol
受约束应用程序协议的“太多请求”响应代码
Abstract
摘要
A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP response code for a server to indicate that a client should reduce the rate of requests.
受限应用程序协议（CoAP）服务器可能会遇到临时过载，因为一个或多个客户端向服务器发送请求的速率高于服务器能够或愿意处理的速率。本文档为服务器定义了一个新的CoAP响应代码，以指示客户端应降低请求速率。
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 https://www.rfc-editor.org/info/rfc8516.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8516.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. CoAP Server Behavior . . . . . . . . . . . . . . . . . . . . 3
4. CoAP Client Behavior . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. CoAP Server Behavior . . . . . . . . . . . . . . . . . . . . 3
4. CoAP Client Behavior . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
The Constrained Application Protocol (CoAP) [RFC7252] response codes are used by a CoAP server to indicate the result of an attempt to understand and satisfy a request sent by a client.
CoAP服务器使用受限应用程序协议（CoAP）[RFC7252]响应代码来指示试图理解和满足客户端发送的请求的结果。
CoAP response codes are similar to the HTTP [RFC7230] status codes, and many codes are shared with similar semantics by both CoAP and HTTP. HTTP has the code "429" registered for "Too Many Requests" [RFC6585]. This document registers a CoAP response code "4.29" for similar purposes and uses the Max-Age option (see Section 5.10.5 of [RFC7252]) to indicate a back-off period after which a client can try the request again.
CoAP响应代码类似于HTTP[RFC7230]状态代码，许多代码由CoAP和HTTP以类似的语义共享。HTTP注册了代码“429”，用于“太多请求”[RFC6585]。出于类似目的，本文件注册了CoAP响应代码“4.29”，并使用最大期限选项（见[RFC7252]第5.10.5节）指示客户可以再次尝试请求的退避期。
While a server may not be able to respond to one kind of request, it may be able to respond to a request of a different kind, even from the same client. Therefore, the back-off period applies only to similar requests. For the purpose of this response code, a request is similar if it has the same method and Request-URI. Also, if a client is sending a sequence of requests that are part of the same series (e.g., a set of measurements to be processed by the server), they can be considered similar even if request URIs are different. Because request similarity is context-dependent, it is up to the application logic to decide how the similarity of the requests should be evaluated.
虽然服务器可能无法响应一种请求，但它可能能够响应不同类型的请求，即使来自同一客户机。因此，退避期仅适用于类似的请求。对于此响应代码，如果请求具有相同的方法和请求URI，则请求是类似的。此外，如果客户机正在发送属于同一系列的一系列请求（例如，由服务器处理的一组度量），则即使请求uri不同，也可以认为它们是相似的。由于请求的相似性依赖于上下文，因此应由应用程序逻辑决定如何评估请求的相似性。
The 4.29 code is similar to the 5.03 "Service Unavailable" [RFC7252] code in that the 5.03 code can also be used by a server to signal an overload situation. The 5.03 code also uses the Max-Age option to indicate the time after which a client can retry. However, the 4.29 code indicates that the too-frequent requests from the requesting client are the reason for the overload.
4.29代码与5.03“服务不可用”[RFC7252]代码类似，因为服务器也可以使用5.03代码来表示过载情况。5.03代码还使用Max Age选项指示客户端可以重试的时间。但是，4.29代码表明，来自请求客户端的请求过于频繁是导致过载的原因。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Readers should also be familiar with the terms and concepts discussed in [RFC7252].
读者还应熟悉[RFC7252]中讨论的术语和概念。
If a CoAP server is unable to serve a client that is sending CoAP request messages more often than the server is capable or willing to handle, the server SHOULD respond to the request(s) with the response code 4.29, "Too Many Requests". The Max-Age option is used to indicate the number of seconds after which the server assumes it is OK for the client to retry the request.
如果CoAP服务器无法为发送CoAP请求消息的频率超过服务器能力或愿意处理的频率的客户端提供服务，则服务器应使用响应代码4.29“太多请求”响应请求。Max Age选项用于指示服务器认为客户端可以重试请求的秒数。
An action result payload (see Section 5.5.1 of [RFC7252]) can be sent by the server to give more guidance to the client, e.g., details of the overload situation.
服务器可以发送操作结果有效负载（见[RFC7252]第5.5.1节），以向客户端提供更多指导，例如过载情况的详细信息。
The 4.29 response code is only returned to the client(s) sending requests too frequently; if other clients are sending requests that cannot be served due to server overload, the 5.03 response code is more appropriate.
4.29响应代码仅返回给发送请求过于频繁的客户机；如果其他客户端发送的请求由于服务器过载而无法提供服务，则5.03响应代码更合适。
If a client repeats a request that was answered with 4.29 before Max-Age time has passed, it is possible that the client sent multiple requests before receiving the first answer or that the client did not recognize the response code. To slow down clients that do not recognize the 4.29 code, the server MAY respond with a more generic error code (e.g., 5.03). The server SHOULD rate-limit 4.29 replies taking into account its usual load-shedding policies. However, any such method that adds per-client state to the server may be counterproductive to reducing the load.
如果客户机重复在最长使用期限之前用4.29回答的请求，则可能是客户机在收到第一个回答之前发送了多个请求，或者客户机无法识别响应代码。为了降低无法识别4.29代码的客户端的速度，服务器可能会使用更通用的错误代码（例如5.03）进行响应。考虑到其通常的减载策略，服务器应限制4.29个回复的速率。但是，向服务器添加每个客户端状态的任何此类方法都可能会对降低负载产生反作用。
If a client receives the 4.29 response code from a CoAP server to a request, it SHOULD NOT send a similar request to the server before the time indicated in the Max-Age option has passed. If the 4.29 response does not contain a Max-Age option, the default value (60 seconds, as defined in Section 5.10.5 of [RFC7252]) is assumed.
如果客户机从CoAP服务器接收到请求的4.29响应代码，则在“最大年龄”选项中指示的时间过去之前，不应向服务器发送类似的请求。如果4.29响应不包含“最大寿命”选项，则假定默认值（60秒，如[RFC7252]第5.10.5节所定义）。
Note that a client may receive a 4.29 response code on a first request to a server. This can happen, for example, if there is a proxy on the path and the server replies based on the load from multiple clients aggregated by the proxy, or if a client has restarted recently and does not remember its recent requests.
请注意，客户机可能会在向服务器发出第一个请求时收到4.29响应代码。例如，如果路径上有一个代理，并且服务器根据代理聚合的多个客户端的负载进行响应，或者如果客户端最近重新启动并且不记得其最近的请求，则可能会发生这种情况。
A client should not rely on a server being able to send the 4.29 response code in an overload situation because an overloaded server may not be able to reply at all to some requests.
客户端不应依赖服务器在过载情况下发送4.29响应代码，因为过载的服务器可能根本无法响应某些请求。
Security considerations of [RFC7252] apply to this response code also.
[RFC7252]的安全注意事项也适用于此响应代码。
Replying to CoAP requests with a response code consumes resources from a server. For a server under attack, it may be more appropriate to simply drop requests without responding at all. However, dropping requests is also likely to cause well-behaving clients to simply retry the requests.
用响应代码响应CoAP请求会消耗服务器的资源。对于受到攻击的服务器，可能更适合直接丢弃请求而不进行任何响应。但是，丢弃请求也可能导致行为良好的客户端只需重试请求。
As with any other CoAP reply, a client should trust this response code only to the extent that it trusts the underlying security mechanisms (e.g., DTLS [RFC6347]) for authentication and freshness. If a CoAP reply with the "Too Many Requests" response code is not authenticated and integrity protected, an attacker can attempt to spoof a reply and make the client wait for an extended period of time before trying again.
与任何其他CoAP回复一样，客户机只应在其信任底层安全机制（例如DTLS[RFC6347]）进行身份验证和刷新的情况下才信任此响应代码。如果带有“太多请求”响应代码的CoAP回复未经身份验证且完整性未得到保护，则攻击者可尝试欺骗回复，并使客户端在重试之前等待较长时间。
If the response code is sent without encryption, it may leak information about the server overload situation and client traffic patterns.
如果响应代码未经加密发送，则可能会泄漏有关服务器过载情况和客户端流量模式的信息。
IANA has registered the following response code in the "CoAP Response Codes" subregistry within the "Constrained RESTful Environments (CoRE) Parameters" registry:
IANA已在“受限RESTful环境（核心）参数”注册表中的“CoAP响应代码”子区域中注册了以下响应代码：
o Response Code: 4.29
o 答复代码：4.29
o Description: Too Many Requests
o 描述：请求太多
o Reference: RFC 8516
o 参考：RFC 8516
IANA has added this document as an additional reference for the Max-Age option in the "CoAP Option Numbers" subregistry.
IANA已将本文件添加为“CoAP选项编号”子区域中最大年龄选项的附加参考。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<https://www.rfc-editor.org/info/rfc7252>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[CoAP-BROKER] Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Work in Progress, draft-ietf-core-coap-pubsub-06, January 2019.
[CoAP代理]Koster，M.，Keranen，A.，和J.Jimenez，“受限应用程序协议（CoAP）的发布-订阅代理”，正在进行的工作，草稿-ietf-core-CoAP-pubsub-062019年1月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, <https://www.rfc-editor.org/info/rfc6585>.
[RFC6585]诺丁汉，M.和R.菲尔丁，“附加HTTP状态代码”，RFC 6585，DOI 10.17487/RFC6585，2012年4月<https://www.rfc-editor.org/info/rfc6585>.
[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, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
Acknowledgements
致谢
This response code definition was originally part of the "Publish-Subscribe Broker for CoAP" document [CoAP-BROKER]. The author would like to thank Abhijan Bhattacharyya, Carsten Bormann, Daniel Migault, Gyorgy Rethy, Jana Iyengar, Jim Schaad, Klaus Hartke, Mohit Sethi, and Sandor Katona for their contributions and reviews.
此响应代码定义最初是“CoAP发布-订阅代理”文档[CoAP代理]的一部分。作者要感谢Abhijan Bhattacharyya、Carsten Bormann、Daniel Migault、Gyorgy Rethy、Jana Iyengar、Jim Schaad、Klaus Hartke、Mohit Sethi和Sandor Katona的贡献和评论。
Author's Address
作者地址
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
Email: ari.keranen@ericsson.com
Email: ari.keranen@ericsson.com