АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Протокол ограниченных приложений

Экспертиза РАН

Logo-ran.pngLogo-ran-black.png
Проводится экспертиза
Российской академией наук
Подробнее
Times2.svg

Экспертиза РАН

Arrow-Right.png
Logo-ran.png
Проводится экспертиза
Российской академией наук
Подробнее

Протоко́л ограни́ченных приложе́ний (англ. Constrained Application Protocol, CoAP) — это специализированный веб-протокол передачи данных, оптимизированный для устройств с ограниченными ресурсами (памятью, вычислительной мощностью) и сетей с потерями, используемых в беспроводных сенсорных сетях для построения интернета вещей (IoT)[1]. Протокол основан на архитектурном стиле REST и использует методы, аналогичные HTTP (GET, POST, PUT, DELETE), что упрощает его интеграцию с веб-системами через прокси-серверы[2]. Ключевыми особенностями CoAP являются легковесная архитектура с компактным бинарным заголовком и асинхронная модель связи, включающая механизм «наблюдения» за ресурсами для получения уведомлений об их изменении[3][4].

Изначально разработанный для работы поверх протокола UDP для минимизации задержек и энергопотребления, CoAP получил значительное развитие после 2016 года[5]. Ключевым нововведением стала поддержка надежных транспортов: стандарт RFC 8323 (2018) определил работу CoAP поверх TCP, TLS и WebSockets[4][6]. Это расширило его применение в средах, требующих гарантированной доставки данных или прохождения через сетевые экраны, блокирующие UDP-трафик[4]. Кроме того, механизм блочной передачи данных (RFC 7959) позволил эффективно обмениваться большими объёмами информации, например, при обновлении прошивок устройств[7].

В экосистеме IoT CoAP занимает нишу протокола для локальных сетей с большим количеством автономных датчиков и исполнительных устройств, где его модель «клиент-сервер» является эффективной для запроса состояния конкретного устройства[1]. Он широко применяется в промышленном интернете вещей (IIoT), умных городах, системах домашней автоматизации и сельском хозяйстве[5]. Безопасность передачи данных обеспечивается протоколом DTLS при работе поверх UDP или TLS при использовании TCP[5].

Описание

Протокол CoAP был разработан рабочей группой CoRE (Constrained RESTful Environment) как развитие работ IETF по спецификации 6LoWPAN, позволяющей использовать IPv6 в ограниченных беспроводных сенсорных сетях. CoAP обеспечивает взаимодействие с этими датчиками через RESTful веб-службы. Разрабатывался специально для ограниченных устройств, работающих от батарей, с маломощными микропроцессорами и с ограниченными объёмами RAM и ROM[8]. CoAP характеризуется простотой, малой избыточностью и рассчитан на сети с низким энергопотреблением и высоким уровнем потерь[8]. Протокол поддерживает M2M-коммуникации, необходимые для взаимодействия и эксплуатации встроенных систем[9] и опирается на нижележащие протоколы и стандарты, в частности 6LoWPAN и IEEE 802.15.4[10].

CoAP отличается от HTTP меньшей сложностью и использованием UDP, что обеспечивает компактный бинарный заголовок фиксированного размера в 4 байта[11], легко обрабатываемый ограниченными устройствами[12]. При работе поверх UDP протокол имеет встроенный механизм надёжности с повторной передачей сообщений, а для защиты данных по умолчанию используется протокол DTLS. Среди основных функций CoAP[10][13]:

  • Минимальный размер заголовка и низкая сложность обработки;
  • Транспорт на UDP с надёжной передачей в режиме unicast и поддержкой multicast;
  • Асинхронный обмен сообщениями, включая механизм «наблюдения» за ресурсами (Observe);
  • Возможность использования прокси и кэширования (для поддержания данных в спящем режиме устройств);
  • Обнаружение ресурсов;
  • Представление ресурсов через URI и поддержка различных типов контента.

Период после 2016 года ознаменовался выходом ключевых стандартов, расширивших возможности протокола. RFC 7959 (2016) ввёл механизм блочной передачи данных (Block-Wise Transfers), позволивший эффективно обмениваться большими объёмами информации, например, при обновлении прошивок устройств[14]. В 2018 году RFC 8323 добавил поддержку надёжных транспортов — TCP, TLS и WebSockets, — что позволило использовать CoAP в средах, требующих гарантированной доставки данных или прохождения через сетевые экраны, блокирующие UDP-трафик. Дальнейшим развитием стали улучшенные опции для блочной передачи (RFC 9177, 2022), которые оптимизировали скорость и восстановление при потере пакетов[15].

В экосистеме IoT CoAP является предпочтительным протоколом для локальных сетей с большим количеством автономных датчиков и исполнительных устройств, где критически важны низкое энергопотребление и минимальная нагрузка на сеть. Его модель «клиент-сервер» эффективна для получения состояния конкретного устройства по запросу[16]. Протокол широко применяется в промышленном интернете вещей (IIoT), умных городах, системах домашней автоматизации и сельском хозяйстве. В сложных IoT-системах CoAP часто используется на уровне оконечных устройств, а шлюзы транслируют их данные в облачные платформы по протоколу MQTT.

Архитектура

undefined

CoAP использует модель клиент-сервер, подобную HTTP: клиент отправляет запросы к REST-ресурсам для получения данных с датчика или управления устройством. В отличие от HTTP, CoAP реализует асинхронный обмен с помощью UDP-дейтаграмм[10]. Реализация HTTP требует значительного объёма кода для ограниченных устройств с объёмом ROM порядка 100 Кбайт и существенно нагружает сеть[12][17].

Запрос CoAP аналогичен запросу HTTP: клиент обращается за выполнением действия GET, POST, PUT или DELETE к ресурсу, идентифицируемому через URI[18]. Сервер отвечает кодом ответа с возможной передачей содержимого ресурса[18].

undefined

Архитектура CoAP разделена на два уровня[10][13]. При работе поверх UDP уровень сообщений обеспечивает надёжность и последовательность обмена, а уровень «Запрос/Ответ» реализует взаимодействие на основе методов и кодов отклика[10]. Это части единого протокола, и соответствующая логика реализована в его заголовке[18].

С принятием стандарта RFC 8323, который определил работу CoAP поверх TCP, TLS и WebSockets, архитектура протокола была адаптирована[19]. При использовании надёжных транспортов собственный механизм надёжности CoAP (подуровень сообщений) становится избыточным и концептуально заменяется механизмом кадрирования (framing) поверх байтового потока TCP. В этой модели сообщения типов `Confirmable` (CON) и `Non-confirmable` (NON) не используются, так как доставку гарантирует транспортный уровень. Для управления самим соединением был введён новый тип сообщений — сигнальные (Signaling Messages), которые используются для обмена информацией о параметрах соединения, проверки его работоспособности (ping/pong) и корректного закрытия сессии[19].

Уровень сообщений (поверх UDP)
undefined

Этот уровень обеспечивает надёжную доставку сообщений типа Confirmable[20] — с контролем доставки и повторной передачей при потере. В протоколе используется «токен» для ассоциации запросов и ответов. Клиент также помещает уникальный «Label» в заголовок для идентификации дубликатов. Если гарантии доставки не нужны, можно использовать сообщения типа Non-Confirmable. Сервер, получив Confirmable-сообщение, обязан отправить клиенту подтверждение (ACK), либо пустое ACK, если ответ задерживается, либо немедленно, если ответ готов. Если сервер не может обработать запрос, он отвечает Reset (RST)[10][21].

Уровень Запрос-Ответ

Помимо базовых методов, стандарт RFC 8132 ввёл три новых метода для частичного доступа к ресурсам, что позволяет избегать передачи полного представления ресурса[22]. CoAP поддерживает следующие методы[20][23][24]:

Метод Действие
GET Извлекает представление информации для ресурса, идентифицируемого URI.
POST Передаёт представление ресурса, указанного URI, обычно приводит к созданию или обновлению ресурса.
PUT Обновляет указанный ресурс, связанный с URI, с использованием передаваемого представления. Формат определяется параметром Content-Format опционально.
DELETE Удаляет ресурс, идентифицированный URI.
FETCH Извлекает частичное представление ресурса. В отличие от GET, позволяет в теле запроса указать, какую часть данных необходимо получить. Является безопасным и идемпотентным.
PATCH Частично обновляет ресурс на основе набора инструкций, переданных в теле запроса. Метод не является идемпотентным.
iPATCH Идемпотентная версия метода PATCH для частичного обновления ресурса. Гарантирует, что повторный запрос не приведёт к некорректному состоянию ресурса.

Ответы кодируются аналогично HTTP (статусы 2.xx — успех, 4.xx — ошибка клиента, 5.xx — ошибка сервера)[23].

Положение в модели OSI

CoAP является протоколом прикладного уровня (уровень 7 по модели OSI), который взаимодействует с различными протоколами на нижележащих уровнях. Хотя CoAP остаётся на прикладном уровне, его стек стал более гибким с появлением новых транспортных опций.

undefined
Уровень 5 (Прикладной)
CoAP как веб-протокол находится на одном уровне с HTTP; верхние уровни — область M2M-приложений.
Уровень 4 (Транспортный)
Изначально CoAP был разработан для работы поверх UDP, что обеспечивает низкие задержки и поддержку multicast. С принятием стандарта RFC 8323 протокол также получил возможность работать поверх надёжных транспортов — TCP и TLS, что расширило его применение в средах, требующих гарантированной доставки данных.
Уровень 3 (Сетевой)
IPv6. Пакеты транспортного уровня (UDP-дейтаграммы или TCP-сегменты) инкапсулируются в IP-пакеты. В ограниченных сетях 6LoWPAN адаптирует и сжимает заголовки, фрагментирует и собирает пакеты, а также отвечает за адресацию и маршрутизацию.
Уровни 2 и 1 (Канальный и физический)
IEEE 802.15.4 — стандарт беспроводных персональных сетей (WPAN), специфицирующий физический и канальный уровни.

Формат сообщения CoAP

undefined

По умолчанию сообщения CoAP переносятся в UDP-дейтаграммах. Возможны также варианты передачи через DTLS, SMS, TCP, SCTP. Сообщения кодируются в простом бинарном формате: фиксированный заголовок длиной 4 байта, далее поле Token (длина которого определяется полем TKL[28]), затем последовательность опций TLV-формата и, опционально, полезные данные, отделяемые маркером 0xFF[29].

Заголовок версии 1 содержит:

Поле Описание[28]
Ver (Version) 2 бита: версия протокола CoAP.
T (Type) Тип сообщения:
  • Confirmable (0): требуется подтверждение, может быть как запросом, так и ответом; при невозможности обработки отправляется Reset.
  • Non-confirmable (1): подтверждение не требуется.
  • Acknowledgment (2): подтверждает приём Confirmable, может содержать сам ответ.
  • Reset (3): используется при невозможности обработки сообщения.
Рисунок 6: Confirmable (0)
Рисунок 7: Acknowledgment (2) c ответом
TKL (Token Length) 4 бита: длина поля Token. Согласно RFC 7252, значения 0-8 напрямую указывают длину токена в байтах. Стандарт RFC 8974 переопределил значения 9-10 для поддержки расширенных токенов[30]:
  • 9: указывает, что длина токена (13–268 байт) закодирована в следующем 1 байте.
  • 10: указывает, что длина токена (269–65804 байт) закодирована в следующих 2 байтах.

Значения 11-15 зарезервированы.

Code 8 бит: 3 бита — класс (c), 5 бит — детали (dd). Формат c.dd (0 — запрос, 2 — OK, 4 — ошибка клиента, 5 — ошибка сервера, 0.00 — пустое сообщение).
Message ID 16 бит: для обнаружения дубликатов и установления соответствия между Confirmable/Non-Confirmable и ACK/Reset.
Token 0-65804 байт: связывает запрос и ответ. Расширенная длина (согласно RFC 8974) позволяет реализовывать «клиентов без состояния» (stateless clients), кодируя состояние запроса непосредственно в токен[30].

Наблюдение (Observation)

undefined

Состояние ресурса может меняться с течением времени, и клиенту может потребоваться получать обновления[31]. В HTTP для отслеживания изменений клиент вынужден периодически выполнять GET-запросы, что неприемлемо для ограниченных по ресурсам устройств. CoAP реализует механизм наблюдения, стандартизованный в RFC7641, где клиент запрашивает регистрацию (observe: 0) на получение уведомлений об изменениях ресурса; отмена подписки соответствует observe: 1[32]. Сервер сам определяет, при каких условиях оповещать подписчиков. Для избежания превышения пропускной способности рекомендуется не посылать уведомления чаще, чем раз в 3 секунды[33]. Механизм развивается (например, CoCoA/CoAP Congestion Control Advanced[34]).

Дальнейшим развитием механизма стала разработка расширения для групповых коммуникаций. Черновик стандарта draft-ietf-core-observe-multicast-notifications определяет, как сервер может отправлять уведомления об изменении состояния ресурса сразу нескольким клиентам через multicast-рассылку. Это позволяет эффективно реализовать модель «публикация-подписка» (publish-subscribe) и защищается с помощью протокола Group OSCORE[35].

Служба обнаружения (discovery)

undefined

В M2M-средах устройства должны автоматически обнаруживать друг друга и свои ресурсы. В CoAP предусмотрены две основные топологии обнаружения[36]: распределённая и централизованная.

Распределённая топология

Обнаружение CoAP
undefined

Клиент отправляет GET-запрос на URI /.well-known/core (см. RFC5785)[37]. В ответе возвращается список ресурсом в формате Core Link (RFC6690)[38]. Если используется unicast, сервер отвечает напрямую; в случае multicast-запроса — все доступные для обнаружения конечные точки. Для ограниченных сетей предпочтителен unicast, чтобы минимизировать энергозатраты[39].

mDNS

Multicast DNS (mDNS, RFC6762)[40] — инфраструктурно-независимый протокол для обнаружения устройств, не требующий ручной настройки[41][42].

Централизованная топология

undefined

Концепция централизованного каталога ресурсов (Resource Directory, RD), изначально предложенная рабочей группой CoRE, была формализована в виде стандарта RFC 9176 «Constrained RESTful Environments (CoRE) Resource Directory», опубликованного в апреле 2022 года[43]. Каталог решает проблему обнаружения ресурсов в крупных сетях IoT, особенно при наличии «спящих» устройств или в средах, где многоадресный трафик неэффективен[43][44].

Каталог ресурсов функционирует как централизованная база данных, хранящая информацию о доступных в сети ресурсах. Согласно RFC 9176, его ключевые функции включают[43]:

  • Регистрация (Registration): устройства (CoAP-серверы) регистрируют в каталоге информацию о своих ресурсах.
  • Обслуживание (Maintenance): механизмы для обновления и поддержания актуальности регистрационной информации.
  • Поиск (Lookup): клиенты отправляют запросы в каталог для поиска необходимых ресурсов по различным атрибутам.
  • Удаление (Removal): процедуры для удаления информации о ресурсах из каталога.

Стандарт продолжает развиваться, о чём свидетельствует выход RFC 9423 в июне 2023 года, который вносит обновления в реестры параметров для каталога[45].

Каталог ресурсов является важным компонентом и в других стандартах IoT. Например, протокол управления устройствами LwM2M использует схожую концепцию, где LwM2M-сервер фактически выполняет функции каталога, храня информацию о зарегистрированных устройствах и их ресурсах[46]. Архитектура W3C Web of Things (WoT) также предусматривает использование CoRE Resource Directory для регистрации и обнаружения «Описаний Вещей» (Thing Descriptions)[47].

DNS-SD

Дополнительно применяется DNS-based Service Discovery (DNS-SD, RFC6763).

Групповая коммуникация

Поддержка групповой (multicast) коммуникации, разработанная рабочей группой IETF CoRE для одновременного управления множеством устройств, после 2016 года получила значительное развитие, направленное на стандартизацию и усиление безопасности[48].

Основой для групповой коммуникации долгое время служил экспериментальный стандарт RFC 7390, опубликованный в 2014 году[49]. Однако он не предлагал комплексного решения для защиты передаваемых данных и был признан устаревшим. На смену ему пришёл новый интернет-черновик draft-ietf-core-groupcomm-bis, который находится в процессе стандартизации и призван полностью заменить RFC 7390[48]. Этот документ обновляет и расширяет правила групповой коммуникации, определяя IP multicast поверх UDP в качестве транспорта по умолчанию и детально специфицируя как незащищённую, так и защищённую коммуникацию[48].

Ключевым нововведением стала интеграция протокола Group OSCORE (Group Object Security for Constrained RESTful Environments) в качестве механизма безопасности по умолчанию[48]. В отличие от DTLS, который предназначен для соединений «точка-точка» и неэффективен для сценариев «один-ко-многим», Group OSCORE обеспечивает сквозную (end-to-end) защиту на уровне объектов (сообщений)[50]. Сообщения шифруются и подписываются отправителем и проверяются каждым получателем в группе, что гарантирует конфиденциальность и целостность данных даже при прохождении через недоверенные прокси-серверы[50]. Для работы протокола требуется наличие общего группового ключа, который может быть установлен с помощью таких протоколов, как EDHOC[51].

Развитие групповых коммуникаций также включает разработку смежных стандартов:

  • Multicast-уведомления (Observe): Черновик draft-ietf-core-observe-multicast-notifications определяет, как сервер может отправлять уведомления об изменении состояния ресурса сразу нескольким клиентам, что позволяет эффективно реализовать модель «публикация-подписка». Этот механизм также защищается с помощью Group OSCORE.
  • Работа через прокси: Документ draft-ietf-core-groupcomm-proxy описывает, как прокси-сервер может обрабатывать unicast-запрос, перенаправлять его группе серверов по multicast и агрегировать ответы[52].

Форматы данных

Протокол CoAP поддерживает различные форматы данных, определённые в реестре Content-Formats стандарта RFC 7252[53]. Хотя исторически для обмена структурированными данными мог использоваться XML[54] и его бинарное представление Efficient XML Interchange (EXI), для современных IoT-устройств они считаются слишком громоздкими.

В современных системах широкое распространение получил JSON (application/json, ID 50) благодаря своей простоте и удобству интеграции с веб-сервисами[53]. Однако для устройств с жёсткими ограничениями по памяти, вычислительной мощности и пропускной способности сети ключевым решением стал бинарный формат CBOR (Concise Binary Object Representation, application/cbor, ID 60)[54]. Стандартизованный в RFC 8949 (обновление RFC 7049), CBOR сохраняет модель данных JSON (карты, массивы, числа, строки), но кодирует их в чрезвычайно компактном бинарном виде[55]. Это позволяет значительно сократить размер сообщений и затраты на их обработку, что критически важно для устройств с батарейным питанием[55].

Помимо этого, CoAP использует и другие форматы, включая:

  • text/plain (ID 0) — для простых текстовых данных[56].
  • application/link-format (ID 40) — для обнаружения ресурсов (RFC 6690)[53].
  • application/octet-stream (ID 42) — для передачи произвольных бинарных данных без определённой структуры[57].

На базе CBOR был разработан ряд специализированных форматов, расширяющих его применение:

  • application/cose — для объектов, защищённых с помощью шифрования и подписей (CBOR Object Signing and Encryption), например, cose-encrypt0 (ID 16) и cose-mac0 (ID 17)[56].
  • application/cbor-seq (ID 62) — для потоковой передачи последовательности объектов CBOR (RFC 8742).
  • application/concise-problem-details+cbor (ID 257) — для передачи детализированной информации об ошибках в компактном виде (RFC 9290)[58].

В протоколе управления устройствами LwM2M, работающем поверх CoAP, также активно используются форматы на основе JSON и CBOR, например, SenML JSON и его более эффективный бинарный аналог SenML CBOR для передачи данных с сенсоров[58][59].

Реализации и практические применения

Существует множество реализаций CoAP на разных языках, в виде библиотек и API для интеграции в сенсорные и встраиваемые среды[60][61]. Ниже представлена таблица актуальных и активно поддерживаемых реализаций.

Реализация Язык Статус и ключевые особенности
libcoap C Одна из наиболее известных и широко используемых реализаций. Активно поддерживается, является мультиплатформенной (от POSIX-систем до встраиваемых устройств). Реализует поддержку RFC 7252, а также расширений Observe (RFC 7641), Block-wise transfers (RFC 7959), CoAP over TCP/TLS (RFC 8323) и OSCORE (RFC 8613). Поддерживает TLS/DTLS с использованием GnuTLS, OpenSSL, Mbed TLS и wolfSSL[62][63].
aiocoap Python Ведущая асинхронная библиотека для Python, использующая asyncio. Находится в активной разработке. Поддерживает RFC 7252, Observe, Block-wise, CoAP over TCP/TLS/WebSockets и OSCORE. Работает на Linux, BSD, Windows и macOS[64].
open-coap/java-coap Java Наиболее актуальная и активно развиваемая библиотека для JVM, является форком проекта PelionIoT/java-coap. Обеспечивает поддержку RFC 7252, Observe, Block-wise и RFC 8132 (PATCH/FETCH), а также частичную поддержку CoAP over TCP/TLS. Работает поверх UDP, TCP и DTLS 1.2[65].
plgd-dev/go-coap Go Современная и активно развиваемая реализация. Поддерживает CoAP over UDP/TCP/DTLS/TLS, а также расширения Observe и Block-wise[66].
coapjs/node-coap JavaScript (Node.js) Библиотека для создания CoAP-клиентов и серверов в экосистеме Node.js. Поддерживает RFC 7252, Observe и Block-wise. Активность разработки в последние годы умеренная[67].
Com.AugustCellars.CoAP C# Библиотека для .NET. Разработка неактивна (последние обновления были более пяти лет назад), но реализация доступна через NuGet[68].

Реализации ориентированы на определения IETF по классам устройств[69]:

Класс 0
не способны самостоятельно реализовать IP-стек, требуют шлюза.
Класс 1
ограничены по ресурсам, но могут работать с упрощёнными протоколами. Обычно ~100 КБ ROM и ~10 КБ RAM, используются в низкопотребляющих сетях наподобие IEEE802.15.4 на 6LoWPAN; это базовые устройства интернета вещей[70].
Класс 2
могут выполнять более тяжёлые задачи, ~250 КБ ROM, 50 КБ RAM, отвечают производительности смартфонов.

Эксперименты показывают возможность реализовать CoAP на стеке ~8,5 Кбайт ROM и ~1,5 Кбайт RAM с REST-слоем[71]. Если сообщения умещаются в одну фрейм 802.15.4, энергозатраты минимальны[72].

Системы мониторинга здоровья

CoAP используется в медицинских системах для мониторинга состояния пациентов через беспроводные сенсорные сети, облегчая анализ и быстрое реагирование в экстренных случаях[73]. Все критически важные параметры поступают на медсервисы для немедленного реагирования и мониторинга.

В сетях CoAP-устройств клиенты и серверы могут как объявлять собственные ресурсы, так и запрашивать существующие (GET к /.well-known/core; POST для объявления ресурсов). Механизм наблюдения позволяет клиентам получать асинхронные уведомления об изменении состояния пациентов[74].

Системы управления энергопотреблением (Smart grid)

CoAP применяется в домашних HEMS-системах (Home Energy Management System), связанных с сетями HEC (Home Energy Controller), осуществляя сбор и асинхронную доставку энергетических данных, управление и оптимизацию энергопотребления[75].

Автоматизация зданий

CoAP интегрируется в системы управления зданиями (автоматизация света, вентиляции, доступа), обеспечивая обмен параметрами между устройствами, поддержку групповых сценариев с multicast[76].

Другие области

CoAP находит применение в промышленности, сельском хозяйстве, логистике, транспорте, умных зданиях и других отраслях[77].

Примеры областей применения
Промышленность Производство Мониторинг промышленных объектов
Управление багажом — посадочные операции
Диагностика ТС — производство — автопомощь
Сельское хозяйство и животноводство Учёт аграрных объектов
Контроль ирригации, урожая, продуктов
Отслеживание и сертификация животных
Логистика и жизненный цикл товара Покупки, быстрые платежи
Склад, розница, инвентаризация
Идентификация материалов, устаревших товаров
Здравоохранение и благополучие Медицина и уход Дистанционный мониторинг — параметры здоровья — диагностика
Мониторинг оборудования, безопасный доступ, управление средой
Умные медучреждения — сервисы развлечений
Независимая жизнь Помощь пожилым, инвалидам
Помощь в быту и передвижении
Персональное благополучие
Умный город Безопасность, мониторинг окружающей среды Контроль окружающей среды, территорий
Видеонаблюдение, радары, спутники
Чрезвычайные ситуации, спасательные команды
Умные дома и здания Индустриальная эксплуатация, освещение, ирригация, энергоменеджмент
Видеонаблюдение — контроль доступа — защита детей
Развлечения, комфорт
Интеллектуальная энергетика Управление нагрузкой, хранение, развлечения
Экологичный транспорт, идентификация потребителя, бронирование зарядки
Производство/распределение/хранение/управление энергией
Интеллектуальный транспорт и туризм Платёжные сервисы, гиды, развлечения
Мониторинг дорожных условий, парковка, вывоз отходов
Трафик-менеджмент, аренда машин/велосипедов/грузовиков, многомодальный транспорт

Производительность

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

Задержка

CoAP демонстрирует значительно меньшую задержку по сравнению с HTTP/1.1. Исследования показывают, что CoAP обеспечивает в среднем на 30 % меньшие задержки[78][79]. Это достигается за счёт нескольких факторов:

  • Транспортный протокол: CoAP работает поверх UDP, который не требует установления соединения (handshake) для каждой сессии, в отличие от TCP, используемого в HTTP/1.1. Это устраняет задержку, связанную с трёхэтапным рукопожатием TCP.
  • Асинхронность: Протокол изначально поддерживает асинхронную модель обмена сообщениями.
  • Простота протокола: Меньший размер заголовков и более простая обработка сообщений сокращают время на их формирование и парсинг.

При сравнении с HTTP/2, который может мультиплексировать запросы в рамках одного TCP-соединения, разница в задержке сокращается, однако CoAP часто сохраняет преимущество в сетях с высоким уровнем потерь пакетов.

Энергопотребление

Для устройств, работающих от батарей, CoAP является более энергоэффективным решением. Энергозатраты в среднем на 30 % ниже, чем при использовании HTTP[78]. Это обусловлено меньшим объёмом передаваемых данных благодаря компактным бинарным заголовкам (минимальный размер 4 байта) по сравнению с текстовыми заголовками HTTP (сотни байт). В результате радиомодуль устройства остаётся активным меньшее время. Кроме того, отсутствие необходимости в установлении TCP-соединения для каждой сессии снижает общее количество транзакций. Экономии энергии также способствует возможность энергоэкономичного сна объектов, которые могут получать обновления через механизм наблюдения без необходимости постоянных запросов.

Накладные расходы и пропускная способность

CoAP имеет значительно меньшие накладные расходы на заголовки, что особенно важно в сетях с низкой пропускной способностью (например, LPWAN). Минимальный заголовок CoAP составляет 4 байта, в то время как заголовки HTTP/1.1 могут достигать нескольких сотен байт. Это позволяет передавать больше полезных данных в рамках одного пакета, повышая эффективную пропускную способность. Экономические преимущества проявляются в существенном снижении объёма трафика: по некоторым оценкам, для 10 000 устройств трафик может составлять около 64 ГБ при использовании CoAP против более 400 ГБ для HTTP[80].

Надёжность

Хотя HTTP работает поверх надёжного протокола TCP, CoAP также имеет встроенный механизм для обеспечения надёжной доставки сообщений поверх ненадежного UDP. Он использует подтверждаемые сообщения (Confirmable messages, CON), которые требуют подтверждения (Acknowledgement, ACK) от получателя. Это делает CoAP достаточно надёжным для большинства IoT-приложений, сохраняя при этом легковесность UDP.

Сводная таблица сравнения

Параметр CoAP HTTP/1.1
Основной транспорт UDP TCP
Модель Асинхронная, запрос-ответ Синхронная, запрос-ответ
Размер заголовка Минимальный, 4 байта, бинарный Большой, текстовый
Задержка Низкая Высокая (из-за TCP handshake)
Энергопотребление Низкое Высокое
Накладные расходы Очень низкие Высокие
Основное применение Ограниченные устройства и сети (IoT) Веб, корпоративные системы

Управление перегрузками

Протокол CoAP, работающий преимущественно поверх UDP, включает встроенные механизмы для предотвращения перегрузки сети. Базовый механизм, определённый в RFC 7252, является простым, но после 2016 года были предложены более продвинутые, хотя и не стандартизированные, подходы.

Базовый механизм управления перегрузкой является консервативным и включает два основных элемента:

  • Экспоненциальная выдержка (англ. Exponential Back-off): для подтверждаемых сообщений (CON) время ожидания повторной передачи (RTO) удваивается после каждой неудачной попытки[81]. Начальное значение RTO выбирается случайным образом в диапазоне от 2 до 3 секунд[82].
  • Ограничение одновременных запросов: по умолчанию CoAP-устройство может иметь только один не подтверждённый запрос (CON) к другому устройству (параметр NSTART = 1)[83].

Этот подход надёжен, но не способен адаптироваться к изменяющимся условиям сети, что может приводить к неэффективному использованию канала[81].

Ключевой разработкой в этой области стал механизм CoCoA (англ. CoAP Simple Congestion Control/Advanced). Он был предложен в рамках рабочей группы IETF CoRE, но соответствующий черновик стандарта (draft-ietf-core-cocoa) не был принят, и его статус истёк в 2018 году[84]. Несмотря на это, CoCoA и его улучшенная версия CoCoA+ остаются влиятельными в академических кругах. В отличие от базового механизма, CoCoA динамически вычисляет RTO на основе измерений времени кругового пути (RTT) и использует более сложные оценщики и переменный фактор выдержки[82], что позволяет лучше адаптироваться к потерям пакетов. Исследования показывают, что CoCoA+ превосходит как базовый механизм, так и CoCoA в ряде сценариев[85]. Помимо CoCoA, в научной среде были предложены и другие алгоритмы, например, CoCo-RED[86] и FASOR[87].

При работе CoAP поверх TCP, что стандартизировано в RFC 8323, протокол не использует собственные механизмы контроля, а полностью полагается на встроенные в TCP продвинутые алгоритмы управления перегрузкой.

Безопасность

CoAP поддерживает защиту трафика DTLS (Datagram Transport Layer Security, RFC 6347)[88]. DTLS обеспечивает шифрование и аутентификацию, используя симметричные и асимметричные ключи; возможны четыре режима: NoSec (без шифрования), PreSharedKey (с предраспределёнными ключами), RawPublicKey (асимметричные без сертификата), Certificate (асимметричные с сертификатом X.509)[89][90]. При использовании DTLS к URI ресурса добавляется префикс coaps вместо coap. Безопасность групповых (multicast) коммуникаций, ранее не стандартизированная в экспериментальном RFC 7390, обеспечивается с помощью отдельного протокола Group OSCORE.

OSCORE

В качестве более современного и легковесного механизма защиты был разработан протокол OSCORE (англ. Object Security for Constrained RESTful Environments), стандартизированный в RFC 8613[91]. В отличие от DTLS, который работает на транспортном уровне, OSCORE обеспечивает сквозную защиту на прикладном уровне[92]. Он шифрует и защищает целостность только полезной нагрузки и критически важных опций CoAP, оставляя часть заголовков, необходимых для маршрутизации, в открытом виде. Это позволяет передавать сообщения через недоверенные промежуточные узлы (например, прокси), которые могут кэшировать или перенаправлять запросы, не имея доступа к конфиденциальным данным[92].

Сравнение с DTLS

Ключевое различие между протоколами заключается в модели безопасности. DTLS создаёт защищённый канал между двумя соседними узлами (англ. hop-by-hop), что требует расшифровки и повторного шифрования трафика на каждом промежуточном прокси, создавая потенциальные уязвимости[93]. OSCORE, напротив, обеспечивает сквозную (англ. end-to-end) защиту от отправителя до конечного получателя[92].

OSCORE также более производителен в ограниченных средах:

  • Низкие накладные расходы: OSCORE добавляет около 9 байт служебных данных к сообщению, в то время как DTLS 1.2 — 21 байт[94].
  • Энергоэффективность: OSCORE не требует ресурсоёмкого процесса «рукопожатия» (англ. handshake) для каждой сессии, полагаясь на предварительно согласованный «контекст безопасности», что снижает энергопотребление и сетевой трафик. Для динамического согласования ключей был разработан легковесный протокол EDHOC (англ. Ephemeral Diffie-Hellman Over COSE)[95].

В некоторых случаях, когда требуется максимальный уровень защиты, OSCORE и DTLS могут использоваться совместно: OSCORE обеспечивает сквозную защиту данных, а DTLS — защиту канала между отдельными узлами[92].

Безопасность групповых коммуникаций

Протокол DTLS, предназначенный для соединений «точка-точка», неэффективен для защиты многоадресных (групповых) рассылок. Эту задачу решает Group OSCORE — расширение OSCORE для сценариев «один-ко-многим». Он обеспечивает сквозную защиту сообщений в группе с использованием общего криптографического ключа, который может быть установлен с помощью таких протоколов, как EDHOC. Group OSCORE является механизмом безопасности по умолчанию в современном стандарте для групповых коммуникаций CoAP, который приходит на смену устаревшему RFC 7390.

В ограниченных сетях также возможна защита через IPsec, но из-за проблем совместимости (брендмауэры/NAT, долгие заголовки) предпочтение отдаётся DTLS[96].

Безопасность CoAP включает также контроль целостности, отказоустойчивость и конфиденциальность:

Аспект Угроза
Целостность Загрузка вредоносного кода
Доступность Атака отказа в обслуживании (DoS)
Конфиденциальность Анализ трафика, перехват (eavesdropping)

История

Рабочая группа CoRE создала CoAP на основе развития протоколов 6LoWPAN. Цель — расширить архитектуру WEB на M2M и IoT приложения на базе ограниченных устройств[97].

Вехи:

Декабрь 2009
Базовые проекты протокола.
Май 2010
Первые спецификации.
2010—2014
Развитие черновиков до 18 версии.
Июнь 2014
Выпуск RFC 7252 The Constrained Application Protocol (CoAP).
Октябрь 2014
RFC 7390 — групповое взаимодействие CoAP.
Сентябрь 2015
RFC 7641 — механизм наблюдения (Observe).
Август 2016
RFC 7959 — блочная передача больших сообщений.
Февраль 2018
RFC 8323 — стандартизация работы CoAP поверх надёжных транспортов (TCP, TLS и WebSockets).
Июль 2019
RFC 8613 — стандарт OSCORE, обеспечивающий сквозную защиту на уровне объектов.
Январь 2021
RFC 8974 — введение расширенных токенов для поддержки «клиентов без состояния» (stateless clients).
Ноябрь 2023
RFC 9482 — спецификация для передачи сообщений протокола управления сертификатами (CMP) через CoAP[98].

После 2023 года работа рабочей группы IETF CoRE сосредоточилась на уточнении существующих стандартов и разработке новых функций. Ключевые направления включают:

  • Коррекция и уточнение: Работа над черновиком draft-ietf-core-corr-clar, который устраняет неясности и ошибки в базовых RFC (7252, 7641, 7959 и др.) для улучшения совместимости реализаций[99].
  • Интерфейс управления: Разработка интерфейса управления CORECONF (draft-ietf-core-comi), который позиционируется как аналог NETCONF и RESTCONF для IoT, работающий поверх CoAP с использованием моделей данных YANG и формата CBOR[100].
  • Архитектура «публикация-подписка»: Создание брокерской модели обмена сообщениями (draft-ietf-core-coap-pubsub) для расширения применения CoAP в сценариях, требующих более гибкой рассылки данных[101].

Примечания

  1. ↑ 1 2 CoAP: A Smart Solution Enabling M2M Applications. IoT For All. Дата обращения: 3 ноября 2025. Архивировано 19 февраля 2025 года.
  2. ↑ CoAP vs MQTT: Comparing IoT Messaging Protocols. Cloud Studio. Дата обращения: 3 ноября 2025. Архивировано 16 июня 2025 года.
  3. ↑ CoAP Protocol: A Comprehensive Overview for IoT. EMQ. Дата обращения: 3 ноября 2025. Архивировано 19 июля 2025 года.
  4. ↑ 1 2 3 Constrained Application Protocol (CoAP). Devopedia. Дата обращения: 3 ноября 2025. Архивировано 25 июня 2025 года.
  5. ↑ 1 2 3 IoT Protocols: MQTT, CoAP, XMPP, SOAP, UPnP. Sirin Software. Дата обращения: 3 ноября 2025. Архивировано 8 сентября 2025 года.
  6. ↑ CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets. Semantic Scholar. Дата обращения: 3 ноября 2025. Архивировано 20 апреля 2024 года.
  7. ↑ RFC 7959: Block-Wise Transfers in the Constrained Application Protocol (CoAP). IETF. Дата обращения: 3 ноября 2025. Архивировано 15 августа 2025 года.
  8. ↑ 1 2 RFC7252: The Constrained Application Protocol (CoAP) (англ.). ietf.org (июнь 2014). Дата обращения: 10 июня 2024. Архивировано 16 марта 2019 года.
  9. ↑ Vilaverde (июль 2012). “Constrained Application Protocol for Low Power Embedded Networks: A Survey”. IMIS [англ.]: 702. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  10. ↑ 1 2 3 4 5 6 M.Palattella (декабрь 2012). “Standardized Protocol Stack for the Internet of (Important) Things”. IEEE Communications Surveys & Tutorials [англ.]: 1400. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  11. ↑ MQTT vs. CoAP: A Comprehensive Comparison of IoT Protocols. EMQ. Дата обращения: 3 ноября 2025. Архивировано 17 сентября 2025 года.
  12. ↑ 1 2 C.Bormann (1 марта 2012). “CoAP: An Application Protocol for Billions of Tiny Internet Nodes”. IEEE Internet Computing [англ.]: 64. Дата обращения 2024-06-10. |access-date= требует |url= (справка)
  13. ↑ 1 2 R A. Raham (март 2016). “Security analysis of IoT protocols: A focus in CoAP”. ICBDSC [англ.]: 3. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  14. ↑ New Block-Wise Transfer Options for CoAP. IETF. Дата обращения: 3 ноября 2025. Архивировано 7 сентября 2020 года.
  15. ↑ RFC 9177: CoAP: Echo, Request-Tag, and Token Processing. IETF. Дата обращения: 3 ноября 2025. Архивировано 11 октября 2025 года.
  16. ↑ MQTT vs CoAP: Comparing IoT Protocols. Rejig Digital. Дата обращения: 3 ноября 2025. Архивировано 6 сентября 2025 года.
  17. ↑ 1 2 R A. Raham (март 2016). “Security analysis of IoT protocols: A focus in CoAP”. ICBDSC [англ.]: 4. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  18. ↑ 1 2 3 RFC7252: The Constrained Application Protocol (CoAP) (англ.). ietf.org 10 (июнь 2014). Дата обращения: 10 июня 2024.
  19. ↑ 1 2 RFC 8323: CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets. IETF. Дата обращения: 3 ноября 2025. Архивировано 10 октября 2025 года.
  20. ↑ 1 2 M. Prakash (март 2016). “An Analysis of Types of Protocol Implemented in Internet of Things Based on Packet Loss Ratio”. ICTCS '16 [англ.]: 3. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  21. ↑ RFC7252: The Constrained Application Protocol (CoAP) (англ.). ietf.org 11 (июнь 2014). Дата обращения: 10 июня 2024.
  22. ↑ RFC 8132: PATCH and FETCH Methods for the Constrained Application Protocol (CoAP). IETF. Дата обращения: 3 ноября 2025. Архивировано 20 ноября 2024 года.
  23. ↑ 1 2 M.Palattella (декабрь 2012). “Standardized Protocol Stack for the Internet of (Important) Things”. IEEE Communications Surveys & Tutorials [англ.]: 1401. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  24. ↑ RFC7252: The Constrained Application Protocol (CoAP) (англ.). ietf.org 47 (июнь 2014). Дата обращения: 10 июня 2024.
  25. ↑ S. Bandyopadhyay (январь 2013). “Lightweight Internet protocols for web enablement of sensors using constrained gateway devices”. Computing, Networking and Communications (ICNC) [англ.]: 336. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  26. ↑ R A. Raham (март 2016). “Security analysis of IoT protocols: A focus in CoAP”. ICBDSC [англ.]: 1. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  27. ↑ R A. Raham (март 2016). “Security analysis of IoT protocols: A focus in CoAP”. ICBDSC [англ.]: 2. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  28. ↑ 1 2 RFC7252: The Constrained Application Protocol (CoAP) (англ.). ietf.org 16 (июнь 2014). Дата обращения: 10 июня 2024.
  29. ↑ RFC7252: The Constrained Application Protocol (CoAP) (англ.). ietf.org 17 (июнь 2014). Дата обращения: 10 июня 2024.
  30. ↑ 1 2 RFC 8974: Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP). IETF (январь 2021). Дата обращения: 3 ноября 2025. Архивировано 12 октября 2025 года.
  31. ↑ RFC7641: Observing Resources in the Constrained Application Protocol (CoAP) (англ.). tools.ietf.org 5 (сентябрь 2015). Дата обращения: 10 июня 2024. Архивировано 10 марта 2016 года.
  32. ↑ RFC7641: Observing Resources in the Constrained Application Protocol (CoAP) (англ.). tools.ietf.org 18 (сентябрь 2015). Дата обращения: 10 июня 2024. Архивировано 10 марта 2016 года.
  33. ↑ A. Betzler (декабрь 2016). “Experimental evaluation of congestion control for CoAP communications without end-to-end reliability”. Ad Hoc Networks [англ.]. 52: 3. DOI:10.1016/j.adhoc.2016.07.011. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  34. ↑ CoAP Simple Congestion Control/Advanced draft-ietf-core-cocoa-00 (англ.). ietf.org (15 ноября 2016). Дата обращения: 10 июня 2024. Архивировано 7 сентября 2024 года.
  35. ↑ Multicast Notifications for the Constrained Application Protocol (CoAP). IETF CoRE WG. Дата обращения: 3 ноября 2025. Архивировано 17 июня 2021 года.
  36. ↑ B. Carballido (1 января 2014). “Service Discovery Protocols for Constrained Machine-to-Machine Communications”. IEEE Communications Surveys Tutorials [англ.]. 16 (1): 44. Дата обращения 2024-06-10. |access-date= требует |url= (справка)
  37. ↑ RFC5785: Defining Well-Known Uniform Resource Identifiers (URIs) (англ.). tools.ietf.org (апрель 2010). Дата обращения: 10 июня 2024. Архивировано 12 апреля 2010 года.
  38. ↑ RFC6690: Constrained RESTful Environments (CoRE) Link Format (англ.). tools.ietf.org (август 2012). Дата обращения: 10 июня 2024. Архивировано 21 сентября 2012 года.
  39. ↑ B. Carballido (1 января 2014). “Service Discovery Protocols for Constrained Machine-to-Machine Communications”. IEEE Communications Surveys Tutorials [англ.]. 16 (1): 48. Дата обращения 2024-06-10. |access-date= требует |url= (справка)
  40. ↑ RFC6762: Multicast DNS (англ.). tools.ietf.org (февраль 2013). Дата обращения: 10 июня 2024. Архивировано 21 марта 2013 года.
  41. ↑ A. Al-Fuqaha (июнь 2015). “Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications”. IEEE Communications Surveys & Tutorials [англ.]. 17 (4): 2357. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  42. ↑ B. Carballido (1 января 2014). “Service Discovery Protocols for Constrained Machine-to-Machine Communications”. IEEE Communications Surveys Tutorials [англ.]. 16 (1): 50. Дата обращения 2024-06-10. |access-date= требует |url= (справка)
  43. ↑ 1 2 3 RFC 9176: Constrained RESTful Environments (CoRE) Resource Directory. IETF. Дата обращения: 3 ноября 2025. Архивировано 11 октября 2025 года.
  44. ↑ Lightweight M2M Resource Model. IETF. Дата обращения: 3 ноября 2025. Архивировано 5 марта 2024 года.
  45. ↑ RFC 9423: CoRE Resource Directory and Discovery Parameter Registries Update. IETF. Дата обращения: 3 ноября 2025. Архивировано 9 октября 2025 года.
  46. ↑ LWM2M architecture. ResearchGate. Дата обращения: 3 ноября 2025.
  47. ↑ Web of Things (WoT) Discovery. W3C. Дата обращения: 3 ноября 2025. Архивировано 26 августа 2025 года.
  48. ↑ 1 2 3 4 Group Communication for the Constrained Application Protocol (CoAP). IETF CoRE WG. Дата обращения: 3 ноября 2025. Архивировано 15 апреля 2024 года.
  49. ↑ RFC 7390: Group Communication for the Constrained Application Protocol (CoAP). IETF (октябрь 2014). Дата обращения: 3 ноября 2025. Архивировано 9 октября 2025 года.
  50. ↑ 1 2 OSCORE, Group OSCORE and EDHOC. aiocoap documentation. Дата обращения: 3 ноября 2025. Архивировано 16 февраля 2025 года.
  51. ↑ Security Architecture for Secure Multicast CoAP Applications. ResearchGate. Дата обращения: 3 ноября 2025.
  52. ↑ Group Communication with CoAP. IETF Datatracker. Дата обращения: 3 ноября 2025. Архивировано 6 ноября 2024 года.
  53. ↑ 1 2 3 CoAP Spec. coap.space. Дата обращения: 3 ноября 2025. Архивировано 21 апреля 2025 года.
  54. ↑ 1 2 Constrained Application Protocol (CoAP). CQR. Дата обращения: 3 ноября 2025. Архивировано 23 июля 2024 года.
  55. ↑ 1 2 CBOR vs the other guys. cborbook.com. Дата обращения: 3 ноября 2025. Архивировано 3 октября 2025 года.
  56. ↑ 1 2 CoAP. RIOT-OS documentation. Дата обращения: 3 ноября 2025.
  57. ↑ LwM2M: How to send binary data? #365. GitHub. Дата обращения: 3 ноября 2025. Архивировано 1 декабря 2020 года.
  58. ↑ 1 2 Lightweight M2M (LwM2M) Client. Zephyr Project Documentation. Дата обращения: 3 ноября 2025. Архивировано 11 августа 2025 года.
  59. ↑ IoT Device Management Using LwM2M. IoT For All. Дата обращения: 3 ноября 2025. Архивировано 24 июня 2025 года.
  60. ↑ R. Abdul Rahman (март 2016). “Security analysis of IoT protocols: A focus in CoAP”. ICBDSC [англ.]: 4. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  61. ↑ Vilaverde (июль 2012). “Constrained Application Protocol for Low Power Embedded Networks: A Survey”. IMIS [англ.]: 706. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  62. ↑ libcoap. libcoap.net. Дата обращения: 3 ноября 2025.
  63. ↑ obgm/libcoap. GitHub. Дата обращения: 3 ноября 2025. Архивировано 19 сентября 2025 года.
  64. ↑ chrysn/aiocoap: Python CoAP Library. GitHub. Дата обращения: 3 ноября 2025. Архивировано 23 июля 2025 года.
  65. ↑ open-coap/java-coap: A CoAP protocol implementation in Java. GitHub. Дата обращения: 3 ноября 2025. Архивировано 21 апреля 2025 года.
  66. ↑ plgd-dev/go-coap: CoAP implementation in Go. GitHub. Дата обращения: 3 ноября 2025. Архивировано 17 августа 2025 года.
  67. ↑ coapjs/node-coap: A CoAP library for node.js. GitHub. Дата обращения: 3 ноября 2025. Архивировано 29 августа 2025 года.
  68. ↑ Com.AugustCellars/CoAP-CSharp. GitHub. Дата обращения: 3 ноября 2025. Архивировано 13 июня 2024 года.
  69. ↑ M. Kovatsch (сентябрь 2013). “CoAP for the web of things: from tiny resource-constrained devices to the web browser”. UbiComp’13 Adjunct [англ.]: 1497. DOI:10.1145/2494091.2497583. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  70. ↑ C. Bormann (1 марта 2012). “CoAP: An Application Protocol for Billions of Tiny Internet Nodes”. IEEE Internet Computing [англ.]: 63. Дата обращения 2024-06-10. |access-date= требует |url= (справка)
  71. ↑ M.Kovatsch (октябрь 2011). “A Low-Power CoAP for Contiki”. Mobile Adhoc and Sensor Systems (MASS) [англ.]: 858. DOI:10.1109/MASS.2011.100. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  72. ↑ M.Kovatsch (октябрь 2011). “A Low-Power CoAP for Contiki”. Mobile Adhoc and Sensor Systems (MASS) [англ.]: 860. DOI:10.1109/MASS.2011.100. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  73. ↑ H. A. Khattak (14 января 2014). “CoAP-based healthcare sensor networks: A survey”. 2014 11th International Bhurban Conference on Applied Sciences Technology (IBCAST) [англ.]: 500. DOI:10.1109/IBCAST.2014.6778196. Дата обращения 2024-06-10. |access-date= требует |url= (справка)
  74. ↑ H. A. Khattak (14 января 2014). “CoAP-based healthcare sensor networks: A survey”. 2014 11th International Bhurban Conference on Applied Sciences Technology (IBCAST) [англ.]: 501. DOI:10.1109/IBCAST.2014.6778196. Дата обращения 2024-06-10. |access-date= требует |url= (справка)
  75. ↑ G.Belcredi (1 октября 2015). “An implementation of a home energy management platform for Smart Grid”. 2015 IEEE PES Innovative Smart Grid Technologies Latin America [англ.]: 270. DOI:10.1109/ISGT-LA.2015.7381166. Дата обращения 2024-06-10. |access-date= требует |url= (справка)
  76. ↑ Vilaverde (июль 2012). “Constrained Application Protocol for Low Power Embedded Networks: A Survey”. IMIS [англ.]: 704. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  77. ↑ B. Borgia (2014). “The Internet of Things vision: Key features, applications and open issues”. Computer Communications [англ.]. 54: 9. DOI:10.1016/j.comcom.2014.09.008. Дата обращения 2024-06-10. |access-date= требует |url= (справка)
  78. ↑ 1 2 W. Colitti (1 октября 2011). “Evaluation of constrained application protocol for wireless sensor networks”. 2011 18th IEEE Workshop on Local Metropolitan Area Networks [англ.]: 1—6. DOI:10.1109/LANMAN.2011.6076934. Дата обращения 2024-06-10. |access-date= требует |url= (справка)
  79. ↑ Integrating Wireless Sensor Networks with the Web (англ.). Semanticscholar. Дата обращения: 10 июня 2024. Архивировано 2 февраля 2017 года.
  80. ↑ T. Leva (июль 2014). “Comparing the cost-efficiency of CoAP and HTTP in Web of Things applications”. Decision Support Systems [англ.]. 63: 33. DOI:10.1016/j.dss.2013.09.009. Дата обращения 2024-06-10. Проверьте дату в |date= (справка на английском); |access-date= требует |url= (справка)
  81. ↑ 1 2 CoAP Congestion Control for the Internet of Things. scispace. Дата обращения: 3 ноября 2025.
  82. ↑ 1 2 CoCoA+: An Advanced Congestion Control Mechanism for CoAP. MDPI. Дата обращения: 3 ноября 2025. Архивировано 6 февраля 2025 года.
  83. ↑ Congestion Control for CoAP Cloud Services. scispace. Дата обращения: 3 ноября 2025.
  84. ↑ CoAP Simple Congestion Control/Advanced (CoCoA). IETF Datatracker. Дата обращения: 3 ноября 2025. Архивировано 7 сентября 2024 года.
  85. ↑ Performance Evaluation of CoAP Congestion Control Mechanisms: CoCoA and CoCoA+. arXiv. Дата обращения: 3 ноября 2025. Архивировано 23 августа 2025 года.
  86. ↑ CoCo-RED: A Congestion Control Algorithm for CoAP in IoT. PMC. Дата обращения: 3 ноября 2025. Архивировано 9 февраля 2025 года.
  87. ↑ FASOR: A Fast and Slow RTO Mechanism for CoAP. University of Helsinki. Дата обращения: 3 ноября 2025.
  88. ↑ RFC4347: Datagram Transport Layer Security (англ.). ietf.org (апрель 2006). Дата обращения: 10 июня 2024. Архивировано 22 февраля 2007 года.
  89. ↑ RFC7252: The Constrained Application Protocol (CoAP) (англ.). ietf.org 68 (июнь 2014). Дата обращения: 10 июня 2024.
  90. ↑ RFC4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) (англ.). ietf.org (декабрь 2005). Дата обращения: 10 июня 2024.
  91. ↑ RFC 8613: Object Security for Constrained RESTful Environments (OSCORE). IETF. Дата обращения: 3 ноября 2025. Архивировано 12 октября 2025 года.
  92. ↑ 1 2 3 4 Evaluating the performance of the OSCORE security protocol in constrained IoT networks. Lund University. Дата обращения: 3 ноября 2025. Архивировано 16 января 2025 года.
  93. ↑ Object Security for Constrained RESTful Environments (OSCORE). potaroo.net. Дата обращения: 3 ноября 2025.
  94. ↑ Payload overhead for DTLS 1.2 and OSCORE. ResearchGate. Дата обращения: 3 ноября 2025.
  95. ↑ A Review of Security Protocols for Constrained Application Protocol. Tishreen University Journal. Дата обращения: 3 ноября 2025.
  96. ↑ Constrained Application Protocol draft-ietf-core-coap-12 (англ.). ietf.org (октябрь 2012). Дата обращения: 10 июня 2024. Архивировано 1 февраля 2013 года.
  97. ↑ CoAP Feature Analysis draft-shelby-6lowapp-coap-00 (англ.). ietf.org (декабрь 2009). Дата обращения: 10 июня 2024. Архивировано 12 июля 2024 года.
  98. ↑ RFC 9482: Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol. IETF (ноябрь 2023). Дата обращения: 3 ноября 2025. Архивировано 16 июня 2025 года.
  99. ↑ Corrections and Clarifications to CoAP. IETF Datatracker. Дата обращения: 3 ноября 2025. Архивировано 25 января 2025 года.
  100. ↑ CoAP Management Interface (CORECONF). IETF CoRE WG. Дата обращения: 3 ноября 2025. Архивировано 7 сентября 2020 года.
  101. ↑ Constrained RESTful Environments (core). IETF Datatracker. Дата обращения: 3 ноября 2025. Архивировано 14 августа 2025 года.

Литература

Ссылки

Категории