Протокол ограниченного приложения
| Набор интернет-протоколов |
|---|
| Прикладной уровень |
| Транспортный уровень |
| Интернет-слой |
| Слой связи |
Протокол ограниченных приложений ( CoAP ) — это специализированный протокол интернет-приложений на основе UDP для ограниченных устройств, как определено в RFC 7252 . Это позволяет этим ограниченным устройствам, называемым «узлами», взаимодействовать с более широким Интернетом, используя аналогичные протоколы. CoAP предназначен для использования между устройствами в одной ограниченной сети (например, сети с низким энергопотреблением и потерями), между устройствами и общими узлами в Интернете, а также между устройствами в разных ограниченных сетях, соединенных Интернетом. CoAP также используется с помощью других механизмов, таких как SMS в сетях мобильной связи.
CoAP — это протокол прикладного уровня, предназначенный для использования в интернет-устройствах с ограниченными ресурсами, таких как беспроводной сенсорной сети узлы . CoAP предназначен для простой трансляции в HTTP для упрощенной интеграции с Интернетом, а также отвечает специальным требованиям, таким как поддержка многоадресной рассылки , очень низкие накладные расходы и простота. [1] [2] Многоадресная рассылка, низкие накладные расходы и простота важны для Интернета вещей (IoT) и межмашинной связи (M2M), которые, как правило, являются встроенными и имеют гораздо меньше памяти и питания, чем традиционные интернет-устройства. Поэтому эффективность очень важна. CoAP может работать на большинстве устройств, поддерживающих UDP или аналог UDP.
) Internet Engineering Task Force ( IETF Рабочая группа по ограниченным средам RESTful ( CoRE ) проделала основную работу по стандартизации этого протокола. Чтобы сделать протокол подходящим для приложений IoT и M2M, были добавлены различные новые функции.
Спецификация
[ редактировать ]Ядро протокола указано в РФК 7252 . Были предложены различные расширения, в частности:
- RFC 7641 (2015) Наблюдение за ресурсами в протоколе ограниченного приложения
- RFC 7959 (2016) Блочная передача в протоколе ограниченных приложений (CoAP)
- RFC 8323 (2018) CoAP (протокол ограниченного приложения) через TCP, TLS и WebSockets
- RFC 8974 (2021) Расширенные токены и клиенты без сохранения состояния в протоколе ограниченных приложений (CoAP)
Форматы сообщений
[ редактировать ]CoAP использует два типа сообщений: запросы и ответы, используя простой формат двоичного заголовка. CoAP по умолчанию привязан к UDP и, при необходимости, к DTLS , обеспечивая высокий уровень безопасности связи. При привязке к UDP все сообщение должно умещаться в одной датаграмме. При использовании с 6LoWPAN , как определено в RFC 4944, сообщения должны умещаться в один кадр IEEE 802.15.4, чтобы минимизировать фрагментацию.
Наименьшее сообщение CoAP имеет длину 4 байта, если поля токена, опций и полезной нагрузки опущены, т. е. если оно состоит только из заголовка CoAP. За заголовком следует значение токена (от 0 до 8 байт), за которым может следовать список опций в оптимизированном формате тип-длина-значение. Любые байты после заголовка, токена и параметров (если таковые имеются) считаются полезными данными сообщения, которым предшествует однобайтовый «маркер полезной нагрузки» (0xFF). Длина полезной нагрузки определяется длиной дейтаграммы.
| октета Смещение | 0 | 1 | 2 | 3 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Битовое смещение | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |
| 4 | 32 | видеть | тип | длина токена | код запроса/ответа | идентификатор сообщения | |||||||||||||||||||||||||||
| 8 | 64 | токен (0–8 байт) | |||||||||||||||||||||||||||||||
| 12 | 96 | ||||||||||||||||||||||||||||||||
| 16 | 128 | опции (если есть) | |||||||||||||||||||||||||||||||
| 20 | 160 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | полезная нагрузка (если имеется) | |||||||||||||||||||||||
Заголовок фиксированного размера CoAP
[ редактировать ]Первые 4 байта являются обязательными во всех датаграммах CoAP и составляют заголовок фиксированного размера.
Эти поля можно извлечь из этих 4 байтов в C с помощью этих макросов:
#define COAP_HEADER_VERSION(data) ( (0xC0 & (data)[0]) >> 6 )
#define COAP_HEADER_TYPE(data) ( (0x30 & (data)[0]) >> 4 )
#define COAP_HEADER_TKL(data) ( (0x0F & (data)[0]) >> 0 )
#define COAP_HEADER_CLASS(data) ( ((data)[1] >> 5) & 0x07 )
#define COAP_HEADER_CODE(data) ( ((data)[1] >> 0) & 0x1F )
#define COAP_HEADER_MID(data) ( ((data)[2] << 8) | (data)[3] )
Версия (вер) (2 бита)
[ редактировать ]- Указывает номер версии CoAP.
Тип (2 бита)
[ редактировать ]- Здесь описывается тип сообщения дейтаграммы для контекста двух типов сообщений: запроса и ответа.
- Запрос
- 0: Подтверждается: Это сообщение ожидает соответствующего сообщения подтверждения.
- 1: Неподтверждаемый: Это сообщение не ожидает подтверждающего сообщения.
- Ответ
- 2: Подтверждение: Это сообщение является ответом, подтверждающим подтверждающее сообщение.
- 3: Сброс: Это сообщение означает, что оно получило сообщение, но не смого его обработать.
- Запрос
Длина токена (4 бита)
[ редактировать ]- Указывает длину поля токена переменной длины, длина которого может составлять 0–8 байт.
Код запроса/ответа (8 бит)
[ редактировать ]| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| Сорт | Код | ||||||
Три старших бита образуют число, известное как «класс», который аналогичен классу кодов состояния HTTP . Пять младших битов образуют код, который сообщает дополнительную информацию о запросе или ответе. Весь код обычно передается в форме class.code .
Последние коды запросов/ответов CoAP можно найти по адресу [1] , хотя в приведенном ниже списке приведены некоторые примеры:
- Метод: 0.ХХ
- ПУСТОЙ
- ПОЛУЧАТЬ
- ПОЧТА
- ПОМЕЩАТЬ
- УДАЛИТЬ
- ПРИНЕСТИ
- ПЛАСТЫРЬ
- iПАТЧ
- Успех: 2.ХХ
- Созданный
- Удалено
- Действительный
- Измененный
- Содержание
- Продолжать
- Ошибка клиента: 4.XX
- Неверный запрос
- Несанкционированный
- Плохой вариант
- Запрещенный
- Не найдено
- Метод не разрешен
- Не приемлемо
- Объект запроса неполный
- Конфликт
- Предварительное условие не выполнено
- Запрос объекта слишком велик
- Неподдерживаемый формат контента
- Ошибка сервера: 5.XX
- Внутренняя ошибка сервера
- Не реализовано
- Плохой шлюз
- Сервис недоступен
- Тайм-аут шлюза
- Прокси не поддерживается
- Коды сигнализации: 7.XX
- Неназначенный
- ЦСМ
- Пинг
- Понг
- Выпускать
- Прервать
Идентификатор сообщения (16 бит)
[ редактировать ]- Используется для обнаружения дублирования сообщений и сопоставления сообщений типа подтверждения/сброса с сообщениями типа подтверждаемого/неподтверждаемого.
Токен
[ редактировать ]Каждый запрос содержит токен (но он может иметь нулевую длину), значение которого было сгенерировано клиентом. Сервер должен возвращать клиенту каждое значение токена без каких-либо изменений в соответствующем ответе. Он предназначен для использования в качестве локального идентификатора клиента для сопоставления запросов и ответов, особенно для одновременных запросов.
Сопоставление запросов и ответов не выполняется с использованием идентификатора сообщения, поскольку ответ может быть отправлен в сообщении, отличном от подтверждения (которое для сопоставления использует идентификатор сообщения). Например, это можно сделать для предотвращения повторных передач, если получение результата занимает некоторое время. Такой отстраненный ответ называется «отдельный ответ». Напротив, передача ответа непосредственно в подтверждении называется «совмещенным ответом», который, как ожидается, будет предпочтительнее по соображениям эффективности.
Вариант
[ редактировать ]| Битовая позиция | |||||||
|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Опцион дельта | Длина опциона | ||||||
| Расширенная дельта-опция (нет, 8 бит, 16 бит) | |||||||
| Расширенная длина опции (нет, 8 бит, 16 бит) | |||||||
| Стоимость опции | |||||||
Опцион Дельта:
- От 0 до 12: для разницы от 0 до 12: представляет точное значение разницы между последним идентификатором опции и желаемым идентификатором опции, без расширенного значения разницы опции.
- 13: Для дельты от 13 до 268: Расширенная дельта опции — это 8-битное значение, которое представляет значение дельты опции минус 13.
- 14: Для дельты от 269 до 65 804: Расширенная дельта опции — это 16-битное значение, которое представляет значение дельты опции минус 269.
- 15: зарезервировано для маркера полезной нагрузки, где дельта параметра и длина параметра вместе установлены как 0xFF.
Длина опции:
- От 0 до 12: для длины параметра от 0 до 12: представляет точное значение длины без расширенного значения длины параметра.
- 13: Для длины опции от 13 до 268: Расширенная длина опции представляет собой 8-битное значение, которое представляет значение длины опции минус 13.
- 14: Для длины опции от 269 до 65 804: Расширенная длина опции представляет собой 16-битное значение, которое представляет значение длины опции минус 269.
- 15: Зарезервировано для использования в будущем. Установка в поле длины параметра значения 0xFF является ошибкой.
Стоимость опции:
- Размер поля значения опции определяется значением длины опции в байтах.
- Семантика и формат этого поля зависят от соответствующей опции.
Реализации
[ редактировать ]| Имя | Язык программирования | Реализованная версия CoAP | Клиент/Сервер | Реализованные функции CoAP | Лицензия | Связь |
|---|---|---|---|---|---|---|
| плащ | Дарт | RFC 7252 | Клиент | Блочная передача, наблюдение, многоадресная рассылка, проксирование (частичное) | С | https://github.com/shamblett/coap |
| айокоап | Питон 3 | RFC 7252, RFC 7641, RFC 7959, RFC 8323, RFC 7967, RFC 8132, RFC 9176, RFC 8613, RFC 9528 | Клиент + Сервер | Блочные передачи, наблюдение (частичное) | С | https://pypi.python.org/pypi/aiocoap |
| Калифорния | Ява | RFC 7252, RFC 7641, RFC 7959 | Клиент + Сервер | Observe, блочная передача, многоадресная рассылка (начиная с версии 2.x), DTLS (+ идентификатор соединения DTLS 1.2) | АПЛ+ЕДЛ | https://www.eclipse.org/californium https://github.com/eclipse/californium |
| не могу | С++/С | RFC 7252 | Клиент + Сервер | БСД | https://github.com/staropram/cantcoap | |
| Канопус | Идти | RFC 7252 | Клиент + Сервер | Основной | Лицензия Апач 2.0 | https://github.com/zubairhamed/canopus |
| Go-CoAP | Идти | RFC 7252, RFC 8232, RFC 7641, RFC 7959 | Клиент + Сервер | Ядро, наблюдение, блочный режим, многоадресная рассылка, TCP/TLS | Лицензия Апач 2.0 | https://github.com/plgd-dev/go-coap |
| Реализация CoAP для Go | Идти | RFC 7252 | Клиент + Сервер | Ядро + Черновик Подписаться | С | https://github.com/dustin/go-coap |
| CoAP.NET | С# | RFC 7252, коап-13, коап-08, коап-03 | Клиент + Сервер | Ядро, наблюдение, блочные передачи | 3-пунктовый BSD | https://github.com/smeshlink/CoAP.NET |
| КоАПШарп | C#, .NET | RFC 7252 | Клиент + Сервер | Ядро, наблюдение, блокирование, RD | LGPL | http://www.coapsharp.com |
| КоАПтон | Питон | RFC 7252 | Клиент + Сервер + Прямой прокси + Обратный прокси | Наблюдение, обнаружение многоадресного сервера, анализ формата CoRE Link, блочный анализ | С | https://github.com/Tanganelli/CoAPthon |
| КоАП Оболочка | Ява | RFC 7252 | Клиент | Наблюдение, блочная передача, DTLS | Лицензия Апач 2.0 | https://github.com/tzolov/coap-shell |
| Медь | JavaScript (плагин для браузера) | RFC 7252 | Клиент | Наблюдайте за блочными переводами | 3-пунктовый BSD | https://github.com/mkovatsc/Copper https://addons.mozilla.org/firefox/addon/copper-270430/ [ постоянная мертвая ссылка ] |
| ЭКоАП | С | RFC 7252 | Клиент + Сервер | Основной | С | https://gitlab.com/jobol/ecoap |
| Эрбий для Контики | С | RFC 7252 | Клиент + Сервер | Наблюдайте за блочными переводами | 3-пунктовый BSD | http://www.contiki-os.org/ (is-rest-example) |
| FreeCoAP | С | RFC 7252 | Клиент + Сервер + HTTP/CoAP-прокси | Ядро, DTLS, блочная передача | БСД | https://github.com/keith-cullen/FreeCoAP |
| обманщик | Коварство | RFC 7252, RFC 8323 | Клиент + Сервер | GPL-3.0 или новее | https://codeberg.org/eris/guile-coap | |
| iCoAP | Цель-C | RFC 7252 | Клиент | Ядро, наблюдение, блочные передачи | С | https://github.com/stuffrabbit/iCoAP |
| Java-коап | Ява | RFC 7252, RFC 7641, RFC 7959, RFC 8323 | Клиент + Сервер | Лицензия Апач 2.0 | https://github.com/PelionIoT/java-coap | |
| jCoAP | Ява | RFC 7252 | Клиент + Сервер | Наблюдайте за блочными переводами | Лицензия Апач 2.0 | https://code.google.com/p/jcoap/ |
| библиотека libcoap | С | RFC 7252, RFC 7390, RFC 7641, RFC 7959, RFC 7967, RFC 8132, RFC 8323, RFC 8516, RFC 8613, RFC 8768, RFC 8974, RFC 9175, RFC 9177 | Клиент + Сервер | Ядро, наблюдение, многоадресная рассылка, блочная передача, исправление/выборка, OSCORE, DTLS | БСД/GPL | https://github.com/obgm/libcoap |
| LibNyoc | С | RFC 7252 | Клиент + Сервер | Ядро, наблюдение, блокировка, DTLS | С | https://github.com/darconeous/libnyoci |
| лобаро-копир | С | RFC 7252 | Клиент + Сервер | Наблюдайте за блочными переводами | С | http://www.lobaro.com/lobaro-coap |
| микрокопия | С | RFC 7252 | Клиент + Сервер | С | https://github.com/1248/microcoap | |
| микроКоАПи | МикроПитон | RFC 7252 | Клиент + Сервер | Основной | Лицензия Апач 2.0 | https://github.com/insighio/microCoAPy |
| наноКоАП | С | RFC 7252 | Клиент + Сервер | Ядро, блочные передачи, DTLS | LGPL | https://api.riot-os.org/group__net__nanocoap.html |
| нКоап | Ява | RFC 7252 | Клиент + Сервер | Наблюдение, блочная передача, формат ссылки CoRE, проект идентификатора конечной точки | БСД | https://github.com/okleine/nCoAP |
| узел-копир | Javascript | РФК 7252,
RFC 7641, RFC 7959 |
Клиент + Сервер | Ядро, наблюдение, блокирование | С | https://github.com/mcollina/node-coap |
| Рубиновый плащ | Руби | RFC 7252 | Клиент + Сервер (Дэвид) | Ядро, наблюдение, блокирование, RD | Массачусетский технологический институт, лицензия GPL | https://github.com/nning/coap https://github.com/nning/david |
| Библиотека устройств Sensinode C | С | RFC 7252 | Клиент + Сервер | Ядро, наблюдение, блокирование, RD | Коммерческий | https://silver.arm.com/browse/SEN00 |
| Библиотека устройств Sensinode Java | Ява SE | RFC 7252 | Клиент + Сервер | Ядро, наблюдение, блокирование, RD | Коммерческий | https://silver.arm.com/browse/SEN00 |
| Платформа Sensinode NanoService | Ява SE | RFC 7252 | Облачный сервер | Ядро, наблюдение, блокирование, RD | Коммерческий | https://silver.arm.com/browse/SEN00 |
| СвифтКоАП | Быстрый | RFC 7252 | Клиент + Сервер | Ядро, наблюдение, блочные передачи | С | https://github.com/stuffrabbit/SwiftCoAP |
| TinyOS CoapBlip | nesC/C | курт-13 | Клиент + Сервер | Наблюдайте за блочными переводами | БСД | https://web.archive.org/web/20130312140509/http://docs.tinyos.net/tinywiki/index.php/CoAP |
| txThings | Питон (извращенный) | RFC 7252 | Клиент + Сервер | Блочные передачи, наблюдение (частичное) | С | https://github.com/mwasilak/txThings/ |
| коап-рс | Ржавчина | RFC 7252 | Клиент + Сервер | Ядро, многоадресная рассылка, опция наблюдения, слишком много запросов код ответа на | С | https://github.com/Covertness/coap-rs |
| OfCoAP | С | С | https://github.com/RIOT-Makers/YaCoAP |
Реализации прокси
[ редактировать ]- Squid 3.1.9 с прозрачным модулем сопоставления HTTP-CoAP
- jcoap прокси
- Калифорния cf-proxy2
- КоАПтон
- FreeCoAP
Групповое общение CoAP
[ редактировать ]Во многих доменах приложений CoAP важно иметь возможность обращаться к нескольким ресурсам CoAP как к группе, а не обращаться к каждому ресурсу индивидуально. (например, чтобы включить все освещение с поддержкой CoAP в комнате с помощью одного запроса CoAP, инициируемого переключением выключателя света). Чтобы удовлетворить эту потребность, IETF разработал дополнительное расширение для CoAP в виде экспериментального RFC: Group Communication for CoAP — RFC 7390. [3] Это расширение использует многоадресную рассылку IP для доставки запроса CoAP всем членам группы. Использование многоадресной рассылки имеет определенные преимущества, такие как уменьшение количества пакетов, необходимых для доставки запроса участникам. Однако многоадресная рассылка также имеет свои ограничения, такие как низкая надежность и несовместимость с кэшем. Альтернативный метод групповой связи CoAP, использующий одноадресную рассылку вместо многоадресной рассылки, основан на наличии посредника, при котором создаются группы. Клиенты отправляют свои групповые запросы посреднику, который, в свою очередь, отправляет отдельные одноадресные запросы членам группы, собирает от них ответы и отправляет агрегированный ответ клиенту. [4]
Безопасность
[ редактировать ]CoAP определяет четыре режима безопасности: [5]
- NoSec, где DTLS отключен
- PreSharedKey, где включен DTLS, существует список предварительно общих ключей, и каждый ключ включает список узлов, с которыми он может использоваться для связи. Устройства должны поддерживать набор шифров AES.
- RawPublicKey, где DTLS включен и устройство использует асимметричную пару ключей без сертификата, который проверяется вне канала. Устройства должны поддерживать набор шифров AES и алгоритмы эллиптической кривой для обмена ключами.
- Сертификат, в котором включен DTLS и устройство использует сертификаты X.509 для проверки.
Было проведено исследование по оптимизации DTLS путем внедрения партнеров по безопасности в качестве ресурсов CoAP, а не использования DTLS в качестве оболочки безопасности для трафика CoAP. Это исследование показало, что улучшения в 6,5 раз не оптимизируются. [6]
В дополнение к DTLS, RFC8613 [7] определяет протокол безопасности объектов для ограниченных сред RESTful ( OSCORE ), который обеспечивает безопасность CoAP на уровне приложений.
Проблемы безопасности
[ редактировать ]Хотя стандарт протокола включает положения по снижению угрозы DDoS- атак с усилением, [8] эти положения не реализуются на практике, [9] в результате чего обнаружено более 580 000 целей, в основном расположенных в Китае, и проводятся атаки со скоростью до 320 Гбит/с. [10]
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ RFC 7252, Протокол ограниченных приложений (CoAP)
- ^ « Интеграция беспроводных сенсорных сетей с Интернетом. Архивировано 30 августа 2017 г. на Wayback Machine », Уолтер, Колитти, 2011 г.
- ^ RFC 7390, Групповая связь для CoAP
- ^ « Гибкая групповая связь на основе одноадресной рассылки для устройств с поддержкой CoAP », Исхак, И.; Хоебеке, Дж.; Ван ден Абил, Ф.; Росси, Дж.; Моерман, И.; Демистер, П. Датчики, 2014 г.
- ^ RFC 7252, Протокол ограниченных приложений (CoAP)
- ^ Капосселе, Анджело; Черво, Валерио; Де Чикко, Джанлука; Петриоли, Кьяра (июнь 2015 г.). «Безопасность как ресурс CoAP: оптимизированная реализация DTLS для Интернета вещей». Международная конференция IEEE по коммуникациям (ICC) , 2015 г. стр. 529–554. дои : 10.1109/ICC.2015.7248379 . ISBN 978-1-4673-6432-4 . S2CID 12568959 .
{{cite book}}:|journal=игнорируется ( помогите ) - ^ Паломбини, Франческа; Зейтц, Людвиг; Селандер, Геран; Мэттссон, Джон (2019). «Объектная безопасность для ограниченных сред RESTful (OSCORE)» . www.tools.ietf.org . дои : 10.17487/RFC8613 . S2CID 58380874 . Проверено 7 мая 2021 г.
- ^ «TLS 1.3 спасет нас всех, и другие причины, по которым Интернет вещей все еще небезопасен», Дэни Грант, 24 декабря 2017 г.
- ^ «Когда машины не могут говорить: проблемы безопасности и конфиденциальности межмашинных протоколов передачи данных», Федерико Магги и Райнер Восселер, 6 декабря 2018 г.
- ^ «Протокол CoAP — это следующий важный шаг в области DDoS-атак», Каталин Чимпану, 5 декабря 2018 г.
Внешние ссылки
[ редактировать ]
- RFC 7252 «Протокол ограниченных приложений (CoAP)»
- coap.me - тестовый сервер CoAP, управляемый Бременским университетом.