RFC 8516 | Код ответа «слишком много запросов» для протокола ограниченного применения

RFC 8516 | Код ответа «слишком много запросов» для протокола ограниченного применения

Аннотация

Сервер протокола ограниченных приложений (Constrained Application ProtocolCoAP) может испытывать временную перегрузку, поскольку один или несколько клиентов отправляют запросы на сервер с более высокой скоростью, чем сервер способен или желает обработать. Этот документ определяет новый код ответа CoAP для сервера, чтобы указать, что клиент должен уменьшить частоту запросов.

Скачать оригинальный документ на английском языке RFC 8516 PDF

 

Оглавление

1. Введение
2. Терминология
3. Поведение CoAP-сервера
4. Поведение клиента CoAP
5. Вопросы безопасности
6. Соображения IANA
7. Ссылки
7.1. Нормативные ссылки
7.2. Информационные ссылки
Благодарности
Адрес автора

 

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 7841.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу https://www.rfc-editor.org/info/rfc8516.

 

Уведомление об авторских правах

Copyright (c) 2019 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ППГ 78 и Правовые положения IETF Trust в отношении документов IETF (https://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

 

1. Введение

Коды ответа Ограниченного прикладного протокола (CoAP) [RFC7252] используются сервером CoAP для указания результата попытки понять и удовлетворить запрос, отправленный клиентом.

Коды ответов CoAP аналогичны кодам состояния HTTP [RFC7230], и многие коды совместно используют с похожей семантикой как CoAP, так и HTTP. HTTP имеет код «429», зарегистрированный для «Too Many Requests» [RFC6585]. Этот документ регистрирует код ответа CoAP «4.29» для аналогичных целей и использует параметр Max-Age (см. Раздел 5.10.5 [RFC7252]), чтобы указать период задержки, после которого клиент может повторить запрос.

Хотя сервер может быть не в состоянии ответить на один вид запроса, он может быть в состоянии ответить на запрос другого типа, даже от одного и того же клиента. Поэтому период отсрочки применяется только к аналогичным запросам. Для целей этого кода ответа запрос аналогичен, если он имеет тот же метод и Request-URI. Кроме того, если клиент отправляет последовательность запросов, которые являются частью одной и той же серии (например, набор измерений, которые должны обрабатываться сервером), они могут считаться аналогичными, даже если URI запроса различны. Поскольку сходство запросов зависит от контекста, решение о том, как следует оценивать сходство запросов, зависит от логики приложения.

Код 4.29 аналогичен коду 5.03 «Служба недоступна» [RFC7252] в том, что код 5.03 также может использоваться сервером для сигнализации ситуации перегрузки. Код 5.03 также использует параметр Max-Age, чтобы указать время, после которого клиент может повторить попытку. Однако код 4.29 указывает, что причиной перегрузки являются слишком частые запросы от запрашивающего клиента.

 

2. Терминология

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

Читатели также должны быть знакомы с терминами и концепциями, обсуждаемыми в [RFC7252].

 

3. Поведение CoAP-сервера

Если сервер CoAP не может обслуживать клиента, который отправляет сообщения запроса CoAP чаще, чем сервер способен или хочет обработать, сервер ДОЛЖЕН ответить на запрос (запросы) с кодом ответа 4.29 «Слишком много запросов». Параметр Max-Age используется для указания количества секунд, по истечении которых сервер предполагает, что клиент может повторить запрос.

Полезная нагрузка результата действия (см. Раздел 5.5.1 [RFC7252]) может быть отправлена ​​сервером, чтобы дать клиенту дополнительные указания, например подробности ситуации перегрузки.

Код ответа 4.29 возвращается только клиенту (-ам), отправляющим запросы слишком часто; если другие клиенты отправляют запросы, которые не могут быть обслужены из-за перегрузки сервера, лучше использовать код ответа 5.03.

Если клиент повторяет запрос с ответом 4.29 до истечения времени Max-Age, возможно, клиент отправил несколько запросов до получения первого ответа или клиент не распознал код ответа. Чтобы замедлить работу клиентов, которые не распознают код 4.29, сервер МОЖЕТ ответить более общим кодом ошибки (например, 5.03). Сервер ДОЛЖЕН ответить на ограничение скорости 4.29 с учетом своих обычных политик сброса нагрузки. Тем не менее, любой такой метод, который добавляет состояние каждого клиента к серверу, может привести к снижению нагрузки.

 

4. Поведение клиента CoAP

Если клиент получает код ответа 4.29 от сервера CoAP на запрос, он НЕ ДОЛЖЕН отправлять аналогичный запрос на сервер до истечения времени, указанного в параметре Max-Age. Если ответ 4.29 не содержит параметр Max-Age, предполагается значение по умолчанию (60 секунд, как определено в Разделе 5.10.5 [RFC7252]).

Обратите внимание, что клиент может получить код ответа 4.29 при первом запросе к серверу. Это может произойти, например, если на пути есть прокси-сервер и сервер отвечает на основании нагрузки от нескольких клиентов, агрегированных прокси-сервером, или если клиент недавно перезапустился и не запомнил свои последние запросы.

Клиент не должен полагаться на то, что сервер может отправлять код ответа 4.29 в ситуации перегрузки, поскольку перегруженный сервер может вообще не иметь возможности отвечать на некоторые запросы.

 

5. Вопросы безопасности

Соображения безопасности [RFC7252] применимы и к этому коду ответа.

Ответ на запросы CoAP с кодом ответа потребляет ресурсы с сервера. Для атакующего сервера может быть целесообразнее просто отбросить запросы, не отвечая вообще. Тем не менее, отбрасывание запросов также может привести к тому, что клиенты с хорошим поведением просто повторят запросы.

Как и в случае любого другого ответа CoAP, клиент должен доверять этому коду ответа только в той степени, в которой он доверяет базовым механизмам безопасности (например, DTLS [RFC6347]) для аутентификации и свежести. Если ответ CoAP с кодом ответа «Too Many Requests» не аутентифицирован и не защищен целостностью, злоумышленник может попытаться подделать ответ и заставить клиента ждать в течение длительного периода времени, прежде чем предпринимать повторную попытку.

Если код ответа отправляется без шифрования, это может привести к утечке информации о ситуации перегрузки сервера и моделях трафика клиента.

 

6. Соображения IANA

IANA зарегистрировала следующий код ответа в субрегионе «Коды ответов CoAP» в реестре «Ограниченные параметры среды RESTful (CoRE)»:

  • Код ответа: 4.29
  • Описание: слишком много запросов
  • Ссылка: RFC 8516

IANA добавила этот документ в качестве дополнительной ссылки для параметра «Максимальный возраст» в субрегионе «Номера вариантов CoAP».

 

7. Ссылки

7.1. Нормативные ссылки

[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>.

[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>.

[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>.

7.2. Информационные ссылки

[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.

[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>.

[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>.

[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>.

Подтверждения

Это определение кода ответа первоначально было частью документа «Брокер публикации-подписки для CoAP» [CoAP-BROKER]. Автор хотел бы поблагодарить Абхиджана Бхаттачарью, Карстена Бормана, Даниэля Миго, Дьорги Ретти, Яну Айенгара, Джима Шаада, Клауса Хартке, Мохита Сетхи и Сандора Катону за их вклад и отзывы.

Адрес автора

Ari Keranen
Ericsson
Hirsalantie 11
02420 Jorvas
Finland

Email: ari.keranen@ericsson.com