Янв
05
1971

Коап статья 12 16 коап: КоАП РФ Статья 12.16. Несоблюдение требований, предписанных дорожными знаками или разметкой проезжей части дороги

Posted by

Содержание

Постановление суда по ч. 5 ст. 12.16 КоАП РФ № 05-1394/2016

12-1154/15 РЕШЕНИЕ 26.11.2015 г.

г. Москва Судья Гагаринского районного суда адрес Колесниченко О.А., рассмотрев жалобу фио на постановление по делу об административном правонарушении, вынесенное дата должностным лицом МАДИ, которым заявитель признана виновной в совершении административного правонарушения, предусмотренного ч. 5 ст. 12.16 КРФ об АП, с назначением наказания в виде штрафа в размере сумма,

УСТАНОВИЛ

Должностным лицом МАДИ дата вынесено постановление № 78210177150телефон, которым фио признана виновной в совершении административного правонарушения, предусмотренного ч. 5 ст. 12. 16 КРФ об АП и ей назначено наказание в виде административного штрафа в размере сумма Административное правонарушение зафиксировано работающим в автоматическом режиме специальным техническим средством, имеющим функции фото- и киносъемки.

Не согласившись с указанным постановлением, фио подала жалобу в суд, указывая на то, что ее транспортное средство было припарковано вне действия дорожного знака 3.

27 Прил. 1 ПДД РФ, поэтому правонарушение она не совершала.

фио в судебное заседание не явилась, о дате, времени и месте рассмотрения жалобы извещена надлежащим образом.

Огласив жалобу, исследовав материалы дела, проверив доводы жалобы, прихожу к следующему.

Административная ответственность по ч. 5 ст. 12.16 КРФ об АП наступает за несоблюдение требований, предписанных дорожными знаками или разметкой проезжей части дороги, запрещающими остановку или стоянку транспортных средств, совершенное в городе федерального значения Москве или Санкт- Петербурге.

В соответствии с п. 1.3 Правил дорожного движения РФ участники дорожного движения обязаны знать и соблюдать относящиеся к ним требования Правил, сигналов светофоров, знаков и разметки, а также выполнять распоряжения регулировщиков, действующих в пределах предоставленных им прав и регулирующих дорожное движение установленными сигналами.

В соответствии с примечанием к ст. 1.5 КРФ об АП обязанность доказать свою невиновность возложено на лицо, привлекаемое к административной ответственности, в случае фиксации этих административных правонарушений работающими в автоматическом режиме специальными техническими средствами, имеющими функции фото- и киносъемки, видеозаписи, или средствами фото- и киносъемки, видеозаписи.

В силу положений ст. 2.6.1 КРФ об АП к административной ответственности за административные правонарушения в области дорожного движения и административные правонарушения в области благоустройства территории, предусмотренные законами субъектов Российской Федерации, совершенные с использованием транспортных средств, в случае фиксации этих административных правонарушений работающими в автоматическом режиме специальными техническими средствами, имеющими функции фото- и киносъемки, видеозаписи, или средствами фото- и киносъемки, видеозаписи привлекаются собственники (владельцы) транспортных средств.

Из материалов дела, в частности содержания обжалуемого постановления, следует, что дата в 17 час. 07 мин. по адресу: адрес (дублер), водитель транспортного средства марки «Вольво S80», государственный регистрационный знак Р303ХС177, собственником которого является фио, произвел остановку транспортного средства в нарушение требований дорожного знака 3.27 приложения 1 к ПДД РФ, то есть совершил административное правонарушение, предусмотренное ч. 5 ст. 12. 16 КРФ об АП.

Вина фио в совершении административного правонарушения, предусмотренного ч. 5 ст. 12. 16 КРФ об АП подтверждается фотоматериалом, полученным с применением работающего в автоматическом режиме специального технического средства, ПаркРайт, заводской номер 340, имеющим свидетельство о проверке № СПтелефон, которое действительно до дата Не доверять сведениям, зафиксированным техническим средством, оснований не имеется.

Доводы жалобы о том, что на участке дороги, где фио припарковала свой автомобиль знак 3.27 Приложения N1 к ПДД РФ отсутствовал, суд находит несостоятельными, поскольку использование МКФ » ПаркРайт » для выявления и фиксации административных правонарушений, предусмотренных ч. 5 ст. 12.16 КоАП РФ и ч. 2 ст. 8.14 КоАП Москвы, возможно только в зонах действия соответствующих дорожных знаков и (или) дорожной разметки, в том числе в зонах организации платных городских парковок, понятие которых дано в п.З Правил пользования городскими парковками и размещения на них транспортных средств, утвержденных постановлением Правительства Москвы от дата N 289-ПП «Об организации платных городских парковок в адрес».

Применительно к положениям ч. 5 ст. 12.16 КоАП РФ данный комплекс исключает возможность ошибочной фотовидеофиксации фактов стоянки или остановки транспортных средств в разрешенных местах, а применительно к ч. 2 ст. 8.14 Закона адрес в местах, которые не относятся к перечисленным в Приложении N 1 к постановлению Правительства Москвы от дата N 289-ПП территориальным зонам организации платных парковок, либо относятся к таким зонам, которые еще не введены в действие. Исходя из основных принципов работы комплекса, иное технически невозможно.

Согласно Приложению 1 к Правилам дорожного движения РФ в зоне действия дорожного знака 3.27 «Остановка запрещена» запрещаются остановка и стоянка транспортных средств. Действие указанного дорожного знака распространяется от места его установки до ближайшего перекрестка за ним, а в населенных пунктах при отсутствии перекрестка — до конца населенного пункта, и не прерывается в местах выезда с прилегающих к дороге территорий и в местах пересечения (примыкания) с полевыми, лесными и другими второстепенными дорогами, перед которыми не установлены соответствующие знаки. На маршрутные транспортные средства действие знака 3.27 «Остановка запрещена» Приложения 1 к Правилам дорожного движения РФ не распространяется.

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

В соответствии с положениями п. 1.6 ПДД РФ, лица, нарушившие Правила, несут ответственность в соответствии с действующим законодательством.

Совокупность исследованных доказательств является достаточной для установления виновности фио в совершении инкриминируемого ей деяния.

Вынесенное должностным лицом постановление, а также решение по итогам рассмотрения жалобы на постановление по делу об административном правонарушении, отвечают требованиям закона, при их вынесении все обстоятельства дела, свидетельствующие о наличии события правонарушения, ответственность за которое установлена ч. 5 ст. 12.16 КРФ об АП, установлены правильно.

Наказание в виде административного штрафа наложено на собственника транспортного средства в размере, предусмотренном санкцией ч. 5 ст. 12.16 КРФ об АП, и является безальтернативным.

Порядок и срок давности привлечения к административной ответственности не нарушены.

Нарушений норм материального и процессуального права, влекущих отмену или изменение обжалуемого постановления — не имеется.

Учитывая вышеизложенное, суд приходит к выводу об отсутствии оснований для отмены обжалуемого постановления и удовлетворения жалобы.

На основании изложенного, руководствуясь ст.ст.30.6 — 30.8 КРФ об АП,

РЕШИЛ

Постановление по делу об административном правонарушении № 78210177150телефон, вынесенное дата должностным лицом МАДИ, которым фио признана виновной в совершении административного правонарушения, предусмотренного ч. 5 ст. 12.16 КРФ об АП, с назначением наказания в виде штрафа в размере сумма– оставить без изменения, жалобу без удовлетворения.

Судья Колесниченко О.А.

ВС разъяснил вопросы ответственности за дорожно-транспортные нарушения

Ранее адвокаты отмечали, что разъяснения высшей судебной инстанции являются исчерпывающими и отвечают на многие вопросы о квалификации правонарушений в области дорожного движения.

25 июня Верховный Суд РФ принял Постановление «О некоторых вопросах, возникающих в судебной практике при рассмотрении дел об административных правонарушениях, предусмотренных главой 12 КоАП РФ», большинство разъяснений которого посвящены вопросам квалификации правонарушений в области дорожного движения. Как ранее писала «АГ», проект документа в первом чтении рассматривался 11 июня и был направлен на доработку.

Вопросы квалификации

Читайте также

Адвокаты оценили проект разъяснений ВС об ответственности за нарушения в области дорожного движения

Пленум ВС доработает проект постановления о рассмотрении дел об административных правонарушениях, предусмотренных гл. 12 КоАП

14 Июня 2019

Так, в п. 1 постановления разъясняется, что при рассмотрении дел о правонарушениях, предусмотренных гл. 12 КоАП, водителем признается лицо, управляющее транспортным средством, в том числе не имеющее водительских прав либо лишенное их.

В п. 2 указано, какие средства относятся к транспортным. При этом под управлением подразумевается целенаправленное воздействие лица на ТС, в результате которого оно перемещается, вне зависимости от запуска двигателя.

Из п. 3 после доработки проекта удалено указание, что правонарушение, предусмотренное ч. 1 ст. 12.1 КоАП, является длящимся. В то же время отмечается, что оно выражается в управлении не зарегистрированным в установленном порядке транспортным средством либо регистрация которого прекращена (аннулирована). Административной ответственности в данном случае подлежит водитель. Также в постановлении подчеркивается, что субъективная сторона состава правонарушения, предусмотренного указанной нормой, характеризуется как умышленной, так и неосторожной формой вины, установление которой обязательно при рассмотрении дела.

В п. 4 проекта были внесены поправки, касающиеся регистрационного знака. В постановлении отмечается, что видоизмененным является госномер, в который были внесены изменения, искажающие нанесенные на него символы либо один из них (например, путем заклеивания), либо способ установки которого препятствует его прочтению и идентификации (в частности, путем переворота пластины госзнака). Также из этого пункта было удалено указание, что к подложным относятся госномера, изготовленные неуполномоченными лицами.

В п. 5 разъяснена ответственность водителя за отсутствие полиса ОСАГО. Так, действия водителя квалифицируются по ч. 2 ст. 12.3 КоАП, если на момент проверки у него отсутствовал при себе полис, выданный на бланке. Непредъявление уполномоченному лицу электронного полиса не образует объективную сторону состава правонарушения.

Как указано в п. 6 постановления, установка на передней части ТС световых приборов с огнями красного цвета или красных световозвращающих приспособлений, а также световых приборов, цвет огней и режим работы которых не соответствуют требованиям Основных положений по допуску транспортных средств к эксплуатации и обязанностей должностных лиц по обеспечению безопасности дорожного движения, квалифицируется по ч. 1 ст. 12.4 КоАП.

Пленум ВС указал, что объективная сторона состава правонарушения может иметь место только в случае одновременного несоответствия цвета огней и режима работы приборов установленным требованиям. Несоответствие только цвета или режима может быть квалифицировано по ч. 1 ст. 12.5 КоАП.

В постановлении скорректировано, что под незаконной установкой опознавательного знака «Инвалид» понимается его размещение на ТС, которым управляет лицо, не являющееся инвалидом и не использующее его в момент выявления правонарушения для перевозки инвалидов или детей-инвалидов. Также разъяснена ответственность за незаконное нанесение на наружные поверхности ТС специальных цветографических схем автомобилей оперативных служб, в том числе сходных с ними до степени смешения.

Изменения были внесены и в п. 7. Так, в итоговом тексте постановления указано, что управление ТС, на передней части которого установлен бампер, не предусмотренный конструкцией, без разрешения уполномоченных органов (должностных лиц) квалифицируется по ч. 1 ст. 12.5 КоАП.

В п. 8 разъяснено, что управление ТС водителем, не имеющим прав (за исключением учебной езды), квалифицируется по ч. 1 ст. 12.7 КоАП, а лишенным прав – по ч. 2 данной статьи. Подчеркивается, что лишение водительских прав означает одновременное лишение права управления всеми транспортными средствами независимо от категории. Управление ТС водителем, лишенным прав и не выполнившим условий для их возврата после истечения срока наказания, квалифицируется по ч. 1 ст. 12.7 КоАП (п. 9).

В п. 10 постановления указано, что ответственность по ч. 3 ст. 12.7 КоАП наступает за передачу управления ТС лицу, заведомо не имеющему водительских прав (кроме учебной езды) или лишенному их. Следовательно, не подлежит квалификации по указанной норме передача управления лицу, действие прав которого временно ограничено в соответствии с законодательством об исполнительном производстве. Сам водитель в таком случае может быть привлечен к ответственности по ст. 17.17 КоАП.

Управление ТС водителем в состоянии опьянения или передача управления лицу, находящемуся в таком состоянии, квалифицируются по ст. 12.8 КоАП, а невыполнение водителем требования о прохождении освидетельствования на состояние опьянения – по ст. 12.26 (п. 11). При наличии сомнений в законности акта освидетельствования судья должен проверить сведения о подготовке врача (за исключением психиатра-нарколога) либо фельдшера по вопросам проведения процедуры, а у медицинской организации – наличие лицензии на проведение освидетельствования.

В п. 12 указано, что правонарушения, предусмотренные ст. 12.8 и 12.26 КоАП, не могут быть отнесены к малозначительным, а виновники – освобождены от административной ответственности. Повторное совершение указанных правонарушений влечет уголовное наказание (п. 13).

Читайте также

Правоприменительная практика «сбилась с пути»

Поможет ли проект постановления Пленума ВС вернуть ее в нужное русло?

20 Июня 2019

В п. 14 разъясняется, что ответственность по ч. 2 ст. 12.17 КоАП наступает за непредоставление преимущества в движении специальному ТС. Из п. 15 проекта было удалено указание, что обгон тихоходов не может быть квалифицирован по ч. 4 ст. 12.15 КоАП, если в зоне действия дорожного знака, запрещающего обгон, имеется разметка 1.1 или 1.11. Несоблюдение водителем требований, предписанных дорожными знаками или разметкой, квалифицируется по ч. 1 ст. 12.16 КоАП (п. 16).

В п. 17 постановления указано, что нарушения правил остановки или стоянки транспортных средств квалифицируются по ч. 1 ст. 12.19 КоАП. В результате доработки указанного пункта подчеркивается, что в случае выявления такого нарушения, в том числе при фиксации автоматическими средствами, нарушитель может быть привлечен к ответственности однократно до пресечения противоправного действия (применения меры обеспечения в виде задержания ТС) либо до его добровольного прекращения.

Как отмечается в п. 18, при рассмотрении дел, предусмотренных ч. 1–6 ст. 12.21.1 КоАП, следует учитывать, что в зависимости от способа выявления правонарушения его субъектами являются либо водители, должностные лица, ответственные за перевозку, юрлица, индивидуальные предприниматели, либо только собственники (владельцы) тяжеловесных и (или) крупногабаритных ТС. Привлечение к ответственности указанного лица исключает привлечение за то же правонарушение собственника (владельца) ТС, не являющегося одним из перечисленных субъектов.

Как разъяснено в п. 19 постановления, водитель, нарушивший ПДД или правила эксплуатации ТС, не может одновременно являться лицом, в отношении которого ведется производство по делу об административном правонарушении, и потерпевшим. Так, если в ДТП пострадал только водитель, его действия (бездействие) не подлежат квалификации по ст. 12.24 КоАП. Если при этом здоровью потерпевшего был причинен легкий либо средней тяжести вред, такие действия (бездействие) водителя могут квалифицироваться по ст. 12.12 или ч. 2 ст. 12.5 и по ч. 1 или 2 ст. 12.24 КоАП.

В п. 20 разъясняются вопросы ответственности за ДТП. Так, по ст. 12.27 КоАП привлекается водитель, причастный к аварии. Если участниками ДТП стали лица, управляющие велосипедом, возчики или другие лица, участвующие в дорожном движении и нарушившие ПДД, их действия (бездействие) могут быть квалифицированы по соответствующей части ст. 12.29, 12.30 Кодекса. По ч. 2 ст. 12.27 КоАП, как указано в данном пункте постановления после доработки, квалифицируется невозвращение водителя к месту ДТП, участником которого он являлся, после доставления им пострадавшего на своем ТС в лечебное учреждение.

При решении вопроса о том, образуют ли действия (бездействие) лица, связанные с допуском к управлению ТС водителя, не имеющего прав, состав правонарушения по ст. 12.32 КоАП, необходимо учитывать наличие умысла (п. 21 постановления).

Для правильной квалификации правонарушения, указал ВС в п. 22 постановления, следует исходить из того, что повторным является правонарушение, совершенное лицом, подвергнутым административному наказанию за однородное правонарушение, а также если признак повторности является элементом объективной стороны состава правонарушения. Судье следует иметь в виду, что лицо считается подвергнутым наказанию до истечения года со дня окончания исполнения постановления в полном объеме.

Кроме того, одной из гарантий обеспечения прав лица, в отношении которого ведется производство по делу об административном правонарушении, является требование о применении мер обеспечения производства с участием понятых или с использованием видеозаписи (п. 23).

Военнослужащие и граждане, призванные на военные сборы, несут административную ответственность на общих основаниях (п. 24). Действия (бездействие) должностных лиц, связанные с применением мер обеспечения производства по делу (например, задержание ТС или его возврат после устранения причины задержания), которые не могут повлиять на вывод о виновности либо невиновности лица, но повлекшие нарушение прав и свобод участников производства по делу, могут быть обжалованы в порядке, предусмотренном КАС РФ (п. 25).

Фиксация правонарушений

Как разъясняется в п. 26 постановления, если правонарушение было зафиксировано с помощью технических средств, которые не работали в автоматическом режиме, либо с использованием телефона, видеокамеры или видеорегистратора, в отношении водителя выносится постановление либо составляется протокол на основании ч. 1 ст. 28.2, либо определение о возбуждении дела и проведении административного расследования в порядке ст. 28.7 КоАП. Полученные с использованием технических средств материалы могут быть приобщены к материалам дела в качестве доказательств.

В случае несогласия с вынесенным постановлением собственник ТС освобождается от ответственности, если будет подтверждено, что в момент фиксации правонарушения ТС находилось во владении или пользовании другого лица либо выбыло из обладания владельца в результате противоправных деяний других лиц (п. 27).

Нахождение в момент совершения нарушения правил движения тяжеловесного и (или) крупногабаритного ТС, принадлежащего собственнику (владельцу), во владении или в пользовании другого лица как основание освобождения собственника (владельца) от ответственности не распространяется на случаи управления ТС водителем по трудовому договору, заключенному между ним и собственником (владельцем) (п. 28).

В п. 29 постановления разъяснено, что конструктивные особенности прицепа и невозможность его самостоятельного передвижения без тягача не являются основаниями для освобождения владельца прицепа от ответственности.

При пересмотре постановления о назначении наказания за правонарушение, выявленное и зафиксированное автоматическими средствами, проверке подлежат доводы данного лица о невозможности прекращения им противоправных действий в связи с организацией движения на конкретном участке дороги (п. 30).

Особенности наказания в виде лишения прав

В п. 31 документа ВС отметил, что срок исполнения наказания в виде лишения прав, назначенного лицу, уже лишенному права управления ТС на основании постановления, начинает исчисляться не с момента его вступления в силу, а со дня, следующего за днем окончания срока наказания, примененного ранее (ч. 3 ст. 32.7 КоАП). В то же время необходимо учитывать, что сроки лишения прав и уголовного наказания в виде лишения права заниматься деятельностью по управлению ТС исчисляются самостоятельно.

Наиболее масштабные изменения коснулись п. 32, который был разделен на два пункта.

Согласно разъяснениям, в резолютивной части постановления о назначении наказания в виде лишения прав должно быть указано соответствующее подразделение органа, уполномоченного исполнять такое наказание. Таковым, как правило, выступает подразделение, должностное лицо которого направило дело об административном правонарушении на рассмотрение судье, в том числе если постановление вынесено в отношении лица, проживающего за пределами РФ. В отношении лица, проживающего в России, исполнение постановления может быть возложено на подразделение уполномоченного органа по месту жительства (месту пребывания) нарушителя, в том числе в случае удовлетворения ходатайства о рассмотрении дела по месту его жительства.

При уклонении лица, лишенного прав, от сдачи соответствующего удостоверения срок их лишения прерывается. Течение прерванного срока продолжается со дня сдачи удостоверения либо его изъятия (в том числе если срок его действия истек), а равно со дня получения соответствующим подразделением заявления лица об утрате водительского удостоверения.

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

В п. 33 отмечается, что постановление о назначении наказания в виде лишения прав должно быть направлено судьей в подразделение органа, на которое возложено его исполнение, с отметкой о дне вступления в законную силу, в течение трех суток с указанного дня, а в случае рассмотрения жалобы, протеста – со дня поступления соответствующего решения из суда.

В заключительном пункте указано, что в связи с принятием постановления п. 1–12.2 Постановления Пленума ВС от 24 октября 2006 г. № 18 не подлежат применению.

Как ранее отмечали адвокаты в комментариях «АГ», разъяснения высшей судебной инстанции отвечают на многие вопросы о квалификации правонарушений в области дорожного движения. В то же время, по мнению адвоката МКА «СЕД ЛЕКС» Валерии Аршиновой, с принятием постановления стоило повременить в связи с подготовкой проекта нового КоАП, принятие которого, с учетом указания Председателя Правительства РФ Дмитрия Медведева, ожидается скоро.

Разъяснения прокуратуры. Официальный портал Администрации города Омска

Наличие гражданства иностранного государства как основание для увольнения с госслужбы

14 июля 2021 года, 15:11

О Правилах направления экземпляров документов по жалобам

12 июля 2021 года, 12:13

Об ответственности за хищение денежных средств с банковского счета

30 июня 2021 года, 18:34

Об обеспечении защиты персональных данных работника

30 июня 2021 года, 18:24

Об уголовной ответственности за нарушение санитарно-эпидемиологических правил

22 июня 2021 года, 19:04

О противодействии коррупции

18 июня 2021 года, 12:09

О защите инвалидов

18 июня 2021 года, 12:05

Об антитеррористической защищенности объектов отдыха детей и их оздоровления

18 июня 2021 года, 11:59

Об ответственности за незаконное вознаграждение от юридического лица

15 июня 2021 года, 16:50

Ответственность за оставление ребенка в опасности

15 июня 2021 года, 16:44

Административная ответственность за оскорбление

15 июня 2021 года, 16:35

О дополнительных гарантиях для несовершеннолетних работников

15 июня 2021 года, 16:26

Ответственность аптечных организаций за отсутствие на реализации лекарственных препаратов

15 июня 2021 года, 16:19

Виды дисциплинарных взысканий за коррупционные правонарушения

15 июня 2021 года, 16:10

Льготы и меры социальной поддержки для многодетных семей

15 июня 2021 года, 16:03

О праве пенсионеров на неприкосновенный минимум дохода при удержании задолженности

15 июня 2021 года, 15:55

Основания для включения предпринимателя в ежегодный план проверок

15 июня 2021 года, 15:35

Уголовная ответственность за использование чужой банковской карты

15 июня 2021 года, 15:21

Об оказании медпомощи ребенку с жизнеугрожающим или хроническим заболеванием

09 июня 2021 года, 16:28

О социальной защите

09 июня 2021 года, 16:16

Следующий

Новости об администрировании доходов

В соответствии с приказом Минфина России от 29.11.2019 № 207н внесены изменения в Порядок формирования и применения кодов бюджетной классификации РФ. Для административных штрафов по статьям 12.35, 12.21.1, 12.21.2 КоАП РФ введены дополнительные коды бюджетной классификации:

Код Наименование кода поступлений в бюджет
439 1 16 01123 01 0002 140 Административные штрафы за незаконное ограничение прав на управление транспортным средством и его эксплуатацию.
Ст. 12.35 КоАП РФ
439 1 16 01123 01 0003 140 Административные штрафы за нарушения правил движения тяжеловесного и (или) крупногабаритного транспортного средства, выявленные при осуществлении весового и габаритного контроля.
Ст. 12.21.1 КоАП РФ
439 1 16 01123 01 0004 140 Административные штрафы за нарушение правил перевозки опасных грузов.
Ст. 12.21.2 КоАП РФ

Главным администратором доходов бюджета по указанным статьям главы 12 КоАП РФ является агентство по обеспечению деятельности мировых судей Красноярского края. Приказом установлено, что дополнительные коды применяются к правоотношениям, возникающим при составлении и исполнении бюджета на 2020 год и на плановый период 2021 и 2022 годов.

В случае вынесения мировыми судьями постановлений о наложении административных штрафов, установленных главой 12 КоАП РФ за нарушение Правил дорожного движения, главным администратором доходов бюджета является орган, от имени которого направлен материал об административном правонарушении.

Как обжаловать штраф по ст 12 16 ч 4 КоАП, если я произвел остановку дольше 5 минут?

Добрый вечер Иван Сергеевич!!!

Ознакомившись с Вашим вопросом, могу пояснить следующее: Если Вы не согласны с инкриминируемым Вам нарушением и наложением на Вас административного штрафа, то Вы имеете право обжаловать данное решение в течении 10 суток, с момента получения Вами на руки копии постановления, что Вы в принципе и сделали, направив свою жалобу на сайт ГИБДД.

Срок рассмотрения жалобы на постановление ГИБДД, поданной в досудебном порядке, не должен превышать 30 дней с момента ее регистрации.

Законодательство допускает продление срока рассмотрения документа на 30 дней с обязательным уведомлением заявителя.

По заявлению, рассмотренному в порядке досудебного обжалования, могут быть вынесены следующие решения:

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

В случае, если решение ГИБДД будет оставлено в силе, то Вы имеете право обжаловать это решение в суд, с предоставлением тех нарушений, которые существуют в Вашей копии постановления, а именно:

1. Отсутствие Вашей подписи в графе, порядок и сроки обжалования по делу, предусмотренные ст.ст. 30.1, 03.2, 30.3, мне разъяснены. что говорит о том, что Вам они разъяснены не были, а если Вы отказались от подписи, то должностное лицо, составивший это постановление должен был произвести запись — «от подписи отказался».

2. в графе: копию постановления получил — стоит дата, месяц и год, а Вашей подписи нет. То есть, за копию Вы не расписались, но должностное лицо Вам ее почему то выдало., хотя должен был произвести запись — «от подписи отказался» и копию не выдавать.

Если Вам нужна будет моя помощь, буду рад Вам помочь!!!

Предстоит суд по ч.1 ст. 12.8 КоАП РФ, подскажите в каком случае дают максимальное наказание 2 года? — Адвокат в Самаре и Москве

Добрый день! Предстоит суд по ч.1 ст. 12.8 КоАП РФ, подскажите в каком случае дают максимальное наказание 2 года?

Адвокат Анатолий Антонов

Добрый день!

Согласно части 1 статьи 4.1 Кодекса Российской Федерации об административных правонарушениях при назначении административного наказания физическому лицу учитываются характер совершенного им административного правонарушения, личность виновного, его имущественное положение, обстоятельства, смягчающие административную ответственность, и обстоятельства, отягчающие административную ответственность.

Таким образом, максимальное наказание может быть назначено при наличии отягчающих обстоятельств.

Перечень возможных отягчающих обстоятельств установлен статьей 4.3 Кодекса Российской Федерации об административных правонарушениях и включает в себя: продолжение противоправного поведения, несмотря на требование уполномоченных на то лиц прекратить его; повторное совершение однородного административного правонарушения, то есть совершение административного правонарушения в период, когда лицо считается подвергнутым административному наказанию в соответствии со статьей 4.6 настоящего Кодекса за совершение однородного административного правонарушения; вовлечение несовершеннолетнего в совершение административного правонарушения; совершение административного правонарушения группой лиц; совершение административного правонарушения в условиях стихийного бедствия или при других чрезвычайных обстоятельствах; совершение административного правонарушения в состоянии опьянения либо отказ от прохождения медицинского освидетельствования на состояние опьянения при наличии достаточных оснований полагать, что лицо, совершившее административное правонарушение, находится в состоянии опьянения.

Однако необходимо учитывать, что по отношению к статье 12.8 КоАП РФ состояние опьянения является квалифицирующим признаком, в связи с чем отягчающим обстоятельством являться не будет.

Отказ от освидетельствования образует состав другого правонарушения, ответственность за которое предусмотрена статьей 12.26 КоАП РФ, соответственно отягчающим обстоятельством также являться не может. Кроме того, управление транспортным средством в состоянии опьянения повторно в течение года с момента окончания срока лишения права управления транспортным средством влечет уголовную ответственность.

Таким образом, отягчающее обстоятельство в виде повторного совершения однородного правонарушения к статье 12.8 КоАП РФ также неприменимо.

С уважением, адвокат Анатолий Антонов.

Остались вопросы к адвокату?

Задайте их прямо сейчас здесь, или позвоните по телефону +7 (846) 212-99-71 (круглосуточно), или приходите к нам в офис на консультацию (по предварительной записи)!

ФАС России

№ п/п

Правовое основание по источнику доходов федерального бюджета

Код классификации доходов федерального бюджета (КБК)

Наименование источника доходов федерального бюджета

1.

Ст. 7.29 КоАП РФ

161 1 16 01071 01 0029 140

Федеральный закон № 44-ФЗ

Штрафы за несоблюдение требований при принятии решения о способе и об условиях определения поставщика (подрядчика, исполнителя).

2.

Ст. 7.29.1 КоАП РФ

161 1 16 01071 01 0291 140

Федеральный закон № 275-ФЗ

Штрафы за нарушение порядка определения начальной (максимальной) цены государственного контракта по ГОЗ или цены государственного контракта при размещении ГОЗ.

3.

Ст. 7.29.2 КоАП РФ

161 1 16 01071 01 0292 140

Федеральный закон № 275-ФЗ

Штрафы за отказ или уклонение поставщика (исполнителя, подрядчика) от заключения государственного контракта по ГОЗ, договора, необходимого для выполнения ГОЗ.

4.

Ст. 7.29.3 КоАП РФ

161 1 16 01071 01 0293 140

Федеральный закон № 44-ФЗ

Штрафы за нарушение требований при планировании закупок.

5.

Ст. 7.30 КоАП РФ

161 1 16 01071 01 0030 140

Федеральный закон № 44-ФЗ

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

6.

Ст. 7.32.1 КоАП РФ

161 1 16 01071 01 0321 140

Федеральный закон № 275-ФЗ

Штрафы за нарушение срока и порядка оплаты товаров (работ, услуг) для государственных нужд по ГОЗ.

7.

Ст. 7.31, 7.31.1,7.32, 7.32.3, 7.32.4, 7.32.5, 7.32.6 КоАП РФ

161 1 16 01071 01 9000 140

Федеральные законы № 44-ФЗ, № 135-ФЗ, № 147-ФЗ, № 223-ФЗ, № 381-ФЗ

Иные штрафы, установленные Главой 7 КоАП РФ.

8.

Ст. 9.16 КоАП РФ

161 1 16 01091 01 0016 140

Федеральные законы № 35-ФЗ, № 135- ФЗ, № 147-ФЗ, № 223-ФЗ, № 381-ФЗ

Штрафы за нарушение законодательства об энергосбережении и о повышении энергетической эффективности.

9.

Ст. 9.21 КоАП РФ

161 1 16 01091 01 0021 140

Федеральные законы № 35-ФЗ, № 135-ФЗ, № 147-ФЗ, № 223-ФЗ, № 381-ФЗ

Штрафы за нарушение правил (порядка обеспечения) недискриминационного доступа, порядка подключения (технологического присоединения).

10.

Ст. 9.15 КоАП РФ

161 1 16 01091 01 9000 140

Федеральные законы № 35-ФЗ, № 135-ФЗ, № 147-ФЗ, № 223-ФЗ, № 381-ФЗ

Иные штрафы, установленные Главой 9 КоАП РФ.

11.

Ст. 14.3 КоАП РФ

 

161 1 16 01141 01 0003 140

Федеральный закон № 38-ФЗ

Штрафы за нарушение законодательства о рекламе.

12.

Ст. 14.31 КоАП РФ

161 1 16 01141 01 0031 140

Федеральные законы № 135- ФЗ, № 147-ФЗ, № 223-ФЗ, № 381-ФЗ

Штрафы за злоупотребление доминирующим положением на товарном рынке.

13.

Ст. 14.32 КоАП РФ

161 1 16 01141 01 0032 140

Федеральные законы № 135- ФЗ, № 147-ФЗ, № 223-ФЗ, № 381-ФЗ

Штрафы за заключение ограничивающего конкуренцию соглашения, осуществление ограничивающих конкуренцию согласованных действий, координация экономической деятельности.

14.

Ст. 14.33 КоАП

161 1 16 01141 01 0033 140

Федеральные законы № 135-ФЗ, № 147-ФЗ, № 223-ФЗ, № 381-ФЗ

Штрафы за недобросовестную конкуренцию.

15.

Ст. 14.55 КоАП РФ

161 1 16 01141 01 0055 140

Федеральный закон № 275-ФЗ

Штрафы за нарушение условий государственного контракта по ГОЗ либо условий договора, заключенного в целях выполнения ГОЗ.

16.

Ст. 14.31.2 КоАП РФ

161 1 16 01141 01 0312 140

Федеральный закон № 35-ФЗ

Штрафы за манипулирование ценами на оптовом и (или) розничных рынках электрической энергии (мощности).

17.

Ст. 14.3.1, 14.4.2, 14.9, 14.9.1, 14.24, 14.38, 14.40 — 14.42, 14.49, 14.55.1, 14.55.2 КоАП РФ

161 1 16 01141 01 9002 140

 

 

Федеральные законы № 275-ФЗ, № 135-ФЗ, № 147-ФЗ, № 223-ФЗ, № 381-ФЗ, № 325-ФЗ, № 38-ФЗ

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

18.

Ст. 15.37 КоАП РФ

161 1 16 01151 01 9002 140

 

Федеральные законы № 275-ФЗ, № 44-ФЗ

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

19.

Ст. 15.14 КоАП РФ

161 1 16 01155 01 0000 140

Штрафы за нецелевое использование  бюджетных средств.

20.

Ст. 19.5 КоАП РФ

161 1 16 01191 01 0005 140

Федеральные законы № 38-ФЗ, № 135-ФЗ, № 275-ФЗ

Штрафы за невыполнение в срок законного предписания (постановления, представления, решения).

21.

Ст. 19.7 КоАП РФ

 

161 1 16 01191 01 0007 140

Штрафы за непредставление сведений (информации).

22.

Ст. 19.4.2, 19.7.1, 19.7.2, 19.7.2-1, 19.8, 19.8.1, 19.8.2, 19.31 КоАП РФ

161 1 16 01191 01 9000 140

Федеральные законы № 38-ФЗ, № 275-ФЗ, 44-ФЗ, № 135-ФЗ, № 147-ФЗ, № 223-ФЗ, № 381-ФЗ, № 57-ФЗ

Иные штрафы, установленные Главой 19 КоАП РФ.

23.

Ст. 17.9 КоАП РФ

161 1 16 01171 01 9000 140

Иные штрафы, установленные статьей 17.9 КоАП РФ.

24.

Статьи 46, 51 БК РФ;

Пункт 6-7 статьи 34 Федерального закона № 44-ФЗ

161 1 16 07010 01 9000 140

Штрафы, неустойки, пени, уплаченные в случае просрочки исполнения поставщиком (подрядчиком, исполнителем) обязательств, предусмотренных государственным контрактом, заключенным федеральным государственным органом.

25.

Статьи 46, 51 БК РФ;

Пункт 8 статьи 34 Федерального закона № 44-ФЗ; Федеральный закон № 135-ФЗ; Федеральный закон № 275-ФЗ

161 1 16 07090 01 9000 140

Иные штрафы, неустойки, пени, уплаченные в соответствии с законом или договором в случае неисполнения или ненадлежащего исполнения обязательств перед федеральным государственным органом (в т.ч. незаконно полученный доход, подлежащий перечислению на основании Предписаний ФАС России).

26.

Статьи 46, 51 БК РФ;

Федеральный закон № 44-ФЗ

161 1 16 10051 01 9000 140

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

27.

Статьи 46, 51 БК РФ;

Федеральный закон № 44-ФЗ

161 1 16 10071 01 9000 140

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

28.

Статьи 46, 51 БК РФ;

Статьи 8 — 14.1 Федерального закона № 40-ФЗ «Об обязательном страховании гражданской ответственности владельцев транспортных средств»

161 1 16 10012 01 9000 140

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

29.

Ст. 14.6 КоАП РФ

161 1 16 01141 01 0006 140

Федеральные законы № 135- ФЗ, № 147-ФЗ, № 223-ФЗ, № 381-ФЗ

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

30.

Ст. 14.6 КоАП РФ

 

161 1 16 01331 01 0000 140

 

Штрафы за административные правонарушения в области производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции, а также за административные правонарушения порядка ценообразования в части регулирования цен на этиловый спирт, алкогольную и спиртосодержащую продукцию

31.

Ст. 17.7 КоАП РФ

161 1 16 01171 01 0007 140

 

Штрафы за невыполнение законных требований прокурора, следователя, дознавателя или должностного лица, осуществляющего производство по делу об административном правонарушении.

Протокол ограниченных приложений для Интернета вещей

Протокол ограниченных приложений для Интернета вещей

Аннотация:

Интернет вещей (IoT) — важная часть технологии нового поколения, благодаря которой каждый объект, будь то вещи или человек, может быть подключен к Интернету. Существует множество беспроводных протоколов (например, IEEE 802.11 Series, 802.15 Series, Zigbee и т. Д.) Для связи между устройствами. Однако, учитывая, что многие небольшие устройства не могут эффективно взаимодействовать с ограниченными ресурсами, Инженерная группа Интернета (IETF) разработала упрощенный протокол: протокол ограниченного приложения (CoAP).Во-первых, в этом документе кратко описаны некоторые беспроводные протоколы. Затем вводится CoAP и соответствующий протокол безопасности DTLS. Наконец, подана заявка.

Ключевые слова

IoT, CoAP, DTLS, беспроводные протоколы, умный дом, система управления энергопотреблением

Содержание:

1. Введение

Интернет вещей (IoT) представлен как глобальная сеть, которая разумно соединяет все объекты, будь то устройства, системы или человека, с самонастройкой возможности, основанные на стандартных и совместимых протоколах и форматах [Петербург 12].Благодаря интеллектуальному распознаванию, технологиям идентификации и убедительным вычислениям Интернет вещей стал называется Третьей волной в информационной индустрии вслед за компьютером и Интернетом. IoT поддерживает сотни протоколов. Из множества протоколов беспроводные протоколы играют важную роль в развитии Интернета вещей.

В разделе 1 представлены некоторые беспроводные протоколы на разных уровнях IoT. Дан последний протокол для CoAP прикладного уровня, а также его функции и обобщены функции.Сравнивая его с протоколом передачи гипертекста (HTTP), его представлены преимущества. В разделе 2 объясняются некоторые важные модели CoAP. детали, такие как модель уровня сообщения, модель уровня запроса / ответа и сообщение формат. В разделах 3 описан протокол безопасности Datagram Transport Layer Security (DTLS). для защиты трансмиссии. Достигнут необходимые элементы для крепления CoAP, как целостность, аутентификация и конфиденциальность. Затем приложение CoAP Описаны умные дома, которые помогают пользователям управлять системами управления энергопотреблением, что снижает энергопотребление и предотвращение несчастных случаев.

2. Обзор беспроводных протоколов для Интернета вещей

Интернет вещей должен интегрировать различные датчики, компьютерное и коммуникационное оборудование, которое используя разные протоколы связи. Беспроводные протоколы в основном используются на трех уровнях: которые являются уровнем PHY / MAC, уровнем сети / связи и уровнем приложения.

CoAP — один из последних протоколов прикладного уровня, разработанный IETF для интеллектуальных устройств. для подключения к Интернету. Существует столько же устройств, сколько компонентов в автомобилях и зданиях с ограниченные ресурсы, это приводит к большим изменениям в мощности вычислений, коммуникации пропускная способность и т. д.Таким образом, облегченный протокол CoAP предназначен для использования и рассматривается как замена HTTP на протокол прикладного уровня IoT.

2.1 Протоколы на разных уровнях

Уровни IoT PHY / MAC включают в себя все распространенные технологии беспроводной связи, такие как как серия IEEE 802.11, серия 802.15, HART (удаленный датчик с адресацией на магистрали), Стандарт IEEE 802.15.4 определяет часть MAC / PHY для беспроводной личной зоны большого радиуса действия. сеть (LR-WPAN). Zigbee, WirelessHART основаны на IEEE802.15.4 по добавление верхних слоев.

Поскольку TCP / IP закладывает основу для Интернета, таким образом, сеть связи IoT в основном используют протоколы TCP и UDP. По сравнению с протоколом UDP, протокол TCP более сложный, что затрудняет использование на устройствах с ограниченными ресурсами. Сейчас большая часть Интернета вещей использует протокол UDP. Но UDP нестабилен, что нужно комбинировать с прикладным слоем для повышения стабильности.

Прикладной уровень обычно использует HTTP для предоставления веб-сервисов, но HTTP имеет высокую сложность вычислений, низкая скорость передачи данных и высокое энергопотребление.Таким образом, IETF имеет разработал несколько облегченных протоколов, например CoAP, Embedded Binary HTTP (EBHTTP), Бережливый транспортный протокол (LTP). Протокол ограниченного приложения (CoAP) — это специализированный протокол веб-передачи для использования с узлами с ограничениями и с ограничениями (например, маломощные, с потерями) сети [Z.Shelby13]. EBHTTP — это двоичный формат, экономичное кодирование без сохранения состояния стандартного протокола HTTP / 1.1 [G.Tolle13]. EBHTTP в первую очередь предназначен для передачи небольших данных между ограниченными ресурсами узлов, что аналогично CoAP.LTP — это легкий транспортный протокол веб-службы, который обеспечивает прозрачный обмен сообщениями веб-сервисов между всеми видами ресурсов ограниченные устройства и системы класса серверов или ПК [Glombitza10]. Таблица 1 обобщает протоколы в разных слоях.

2.2 Характеристики CoAP

Ожидается, что после завершения спецификации CoAP будет миллион устройств, развернутых в различных областях приложений в будущем.Диапазон этих приложений от умной энергии, умной сети, управления зданием, интеллектуального управления освещением, промышленного системы управления, отслеживание активов, мониторинг окружающей среды. CoAP станет стандартом протокол для обеспечения взаимодействия между устройствами и поддержки приложений Интернета вещей [S.Keoh23]. Ограниченная среда RESTful (CoRE) — это рабочая группа в IEFT, которая разрабатывает протокол CoAP.

CoAP необходимо рассмотреть возможность оптимизации длины дейтаграммы и соответствия протоколу REST для поддержки URI (унифицированный идентификатор ресурса).Также необходимо обеспечить надежную связь на основе по протоколу UDP. В таблице 2 показаны характеристики CoAP [Петербург12]

2.3 Сравнение CoAP и HTTP

CoAP — это сетевой протокол, использующий функции, аналогичные HTTP, но также позволяющий для низких накладных расходов, многоадресной рассылки и т. д. Поскольку протокол HTTP является долгосрочным успешным стандартом, он может использовать небольшой скрипт для интеграции различных ресурсов и сервисов. Обеспечено взаимодействие HTTP является ключевым моментом IoT, для этого HTTP используется на уровне приложений.Однако, HTTP основан на протоколе TCP с использованием модели связи точка-точка (p2p), которая не подходит для служб уведомлений. Кроме того, для устройств с ограничениями HTTP слишком сложен.

В отличие от протоколов на основе HTTP, CoAP работает через UDP вместо использования сложной перегрузки. управление как в TCP [Koojana11]. CoAP основан на архитектуре REST, которая является общей дизайн для доступа к Интернет-ресурсам. Чтобы преодолеть недостаток в ограниченном ресурс, CoAP необходимо оптимизировать длину дейтаграммы и обеспечить надежную связь.С одной стороны, CoAP предоставляет URI, метод REST, такой как GET, POST, PUT и DELETE. С другой стороны, основанный на облегченном протоколе UDP, CoAP позволяет многоадресную IP-рассылку, что обеспечивает групповое общение. для Интернета вещей. Чтобы компенсировать ненадежность протокола UDP, CoAP определяет повторную передачу механизм и обеспечивает механизм обнаружения ресурса с описанием ресурса [Shelby11]. Рис. 1 показывает стеки протоколов HTTP и CoAP.

Рис.1: Стеки протоколов HTTP и CoAP

CoAP — это не просто сжатие протокола HTTP.Учитывая низкую производительность обработки и низкое энергопотребление требования ограниченного ресурса, CoAP переработал некоторые функции HTTP, чтобы учесть эти ограничения. HTTP используется без ограничений сеть и CoAP используются в ограниченной сети. В последнее время HTTP-CoAP межпротокольный прокси вызывает научный интерес, он имеет и важно роль в решении проблемы перегрузки в стесненной среде [Кастеллани12].

3. Модель структуры CoAP

Интерактивная модель CoAP похожа на модель клиент / сервер HTTP.На рис. 2 показано, что CoAP использует двухуровневую структуру. Нижний уровень — это уровень сообщений, который был разработан для работы с UDP и асинхронной коммутацией. Уровень запроса / ответа касается метода связи и обработки сообщения запроса / ответа.

Рис. 2: Абстрактный слой CoAP [Z.Shelby13]

3.1 Модель уровня сообщений

Уровень сообщений поддерживает 4 типа сообщений: CON (подтверждаемое), NON (неподтвержденное), ACK (подтверждение), RST (сброс) [Z.Shelby13].

a) Надежный транспорт сообщений: продолжайте повторную передачу, пока не получите ACK с тем же идентификатором сообщения (например, 0x8c56 на рис. 3). Использование тайм-аута по умолчанию и экспоненциальное уменьшение времени счета при передаче CON. Если получатель не может обработать сообщение, он отвечает заменой ACK на RST. На рис. 3 показан надежный транспорт сообщений.


Рис. 3: Надежный транспорт сообщений

b) Ненадежный транспорт сообщений: транспортировка с сообщением типа NON.Его не нужно подтверждать, но он должен содержать идентификатор сообщения для наблюдения. в случае ретрансляции. Если получатель не может обработать сообщение, сервер отвечает RST. На рис. 4 показан ненадежный транспорт сообщений.

Рис. 4: Ненадежный транспорт сообщений

3.2 модель уровня запроса / ответа

a) Piggy-backed: клиент отправляет запрос, используя тип CON или тип NON. сообщение и немедленно получает ответный ACK с подтверждающим сообщением.На рис. 5, для успешного ответа ACK содержит ответное сообщение (укажите с помощью токена), для ответа о сбое ACK содержит код ответа о сбое.

Рис. 5: Результаты успешного и неудачного отклика метода GET

б) Отдельный ответ: если сервер получил сообщение типа CON, но не получил может немедленно ответить на этот запрос, он отправит пустой ACK в случае, если клиент повторно отправит это сообщение. Когда сервер готов к ответу этот запрос, он отправит новый CON клиенту, и клиент ответит подтверждаемое сообщение с подтверждением.ACK только для подтверждения CON сообщение, независимо от того, запрос или ответ на перенос сообщения CON (рис. 6).

Рис. 6. Запрос Get с отдельным ответом

c) Неподтверждаемый запрос и ответ: в отличие от ответа Piggy-backed переносить подтверждаемое сообщение, в неподтвержденном запросе клиент отправляет НЕ тип сообщение указывает, что сервер не нуждается в подтверждении. Сервер повторно отправит NON введите сообщение с ответом (рис. 7).

Фиг.7: неподтвержденный запрос и ответ

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

CoAP основан на обмене компактными сообщениями, которые, по умолчанию передаются через UDP (т.е. каждое сообщение CoAP занимает раздел данных одной дейтаграммы UDP) [Petersburg12]. Сообщение CoAP использует простой двоичный формат. Сообщение = 4-байтовый заголовок фиксированного размера плюс токен переменной длины плюс последовательность опций CoAP плюс полезная нагрузка. Формат представлен в таблице 3.

Номер варианта = дельта варианта + номер варианта ex.Формат показан на рис. 8.

Рис.8: Формат опции CoAP

4. Протокол безопасности и приложение для CoAP

CoAP теперь становится стандартным протоколом для приложений Интернета вещей. Безопасность важна для защиты связи между устройствами. В следующей части протокол безопасности Вводится DTLS. Также в этом разделе описывается одно из приложений CoAP — Умные дома.

При рассмотрении вопроса о безопасности можно выделить три основных элемента, а именно: целостность, аутентификация и конфиденциальность.DTLS может достичь всего из них [Котмайр 12]. IETF модифицирует DTLS для разработки другого протокола DTLS. DTLS использует TCP, что слишком сложно. DTLS решает две проблемы: переупорядочивание и потеря пакета. Он добавляет три инструмента: 1 повторная передача пакета. 2 присвоение порядкового номера в рукопожатии. 3 обнаружения повтора.

В отличие от протоколов безопасности сетевого уровня, DTLS на прикладном уровне (рис.9) защитить сквозную связь. Никакая сквозная защита связи не сделает злоумышленнику легко получить доступ ко всем текстовым данным, которые проходят через скомпрометированный узел.DTLS также позволяет избежать проблем с криптографическими накладными расходами, которые возникают в протоколах безопасности нижнего уровня.

4.1 Зачем использовать DTLS для защиты CoAP

При рассмотрении безопасности есть три основных элемента, а именно целостность, аутентификация и конфиденциальность. DTLS может достичь всех из них [Kothmayr12]. IETF модифицирует DTLS для разработки другого протокола DTLS. DTLS использует TCP, который слишком сложно. DTLS решает две проблемы: переупорядочение и потерю пакетов. Он добавляет три реализует: повторную передачу 1 пакета.2 присвоение порядкового номера в рукопожатии. 3 обнаружения повтора.

В отличие от протоколов безопасности сетевого уровня, DTLS на прикладном уровне (рис. 9) защитить сквозную связь. Никакая сквозная защита связи не будет облегчить злоумышленнику доступ ко всем текстовым данным, которые проходят через скомпрометированный узел. DTLS также позволяет избежать криптографических накладных расходов, которые возникают. в протоколах безопасности нижнего уровня.

Рис.9: DTLS в стеке протоколов

4.2 Структура DTLS

В DTLS есть два уровня. Нижний содержит протокол записи. Верхний включает три протокола: оповещение, рукопожатие и данные приложения, в некоторых случаях протокол Change Cipher Spec может заменить один из них. Изменять Сообщение Cipher Spec используется для уведомления протокола записи для защиты последующих записи с набором шифров и ключами только для согласования. [Raza13]

Протокол записи [E.Rescorla12] защищает данные приложения с помощью ключей генерируется во время рукопожатия.Для исходящего сообщения протокол разделения, сжатия, зашифровать и применить к ним код аутентификации сообщения (MAC). Для входящего сообщения соберите протокол, распакуйте, расшифруйте и проверьте их. Заголовок записи состоит из две части, одна — тип содержимого, а другая — поле фрагмента. Тип контента решает, что содержится в поле фрагмента. Это может быть протокол оповещения, протокол рукопожатия или Данные приложений. Сравните с DTLS Record, протокол рукопожатия довольно сложен. один, который включает в себя множество этапов обмена.Отдельные сообщения сгруппированы в сообщение полеты. На рис. 10 показан процесс рукопожатия.

Рис.10: Процесс установления связи

Архитектура, показанная ниже (рис. 11), предназначена для одноадресной связи. (клиент взаимодействует с одним или несколькими серверами). Клиенту также нужны чтобы узнать, какой сертификат или необработанный открытый ключ он должен использовать с конкретным сервером [Hartke13].

Рис.11: Модель связи Uni-cast

4.3 Приложение CoAP для умных домов

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

Сеть умного дома обеспечивает контроль и мониторинг энергии домашних устройств. Системы управления энергопотреблением используют интеллектуальное управление розетками и контролируют энергопотребление оборудование для предоставления информации о напряжении, токе и другой энергии.Он мог понять предупреждение об авариях, дистанционное управление и динамическое энергосбережение. Структура системы показано на рис. 12. Каждый узел сбора данных с клиентом CoAP мог обмениваться информацией с другими узлами. CoAP может быть установлен как в локальной сети, так и в Интернете. В отличие от многих беспроводных протоколы для домашних автомобильных устройств, CoAP не ограничен в локальной сети но обеспечивают фундаментальную основу сети [Bergmann12]. В этой системе прокси CoAP-HTTP используются для обеспечения подключения клиента HTTP к ресурсам CoAP и наоборот.

Рис.12: Система управления энергопотреблением

В системной сети узлы сбора данных состоят из одного прокси, интеллектуального сокета. и беспроводной модуль сбора данных. Информация об энергии и окружающей среде оборудования собирается умной розеткой и транспортируется в модуль сбора данных через беспроводной канал, а затем отправить последовательные данные на прокси-сервер для обработки и упаковки данных. Сервер управления анализирует все данные и сохраняет их в базе данных.Система интегрирует домашняя сеть и Интернет, пользователи могут получить доступ к веб-странице системы для удаленного управления переключателем, управлять конфигурацией, запрашивать потребление энергии и т. д. В то же время i1 / 4OE эта система следить за ситуацией в окружающей среде. Если произойдет что-то ненормальное (например, высокая температура или напряжение за пределами безопасного диапазона) система проанализирует его и закроет соответствующее оборудование.

5. Заключение

В этом отчете обобщены некоторые беспроводные протоколы для Интернета вещей и представлены Подробно о протоколе CoAP с описанием основных функций и модулей.CoAP основан на протоколе HTTP и предназначен для ограниченных ресурсов устройств. Сравнивая CoAP и HTTP вместе, преимущества CoAP для IoT. Этот отчет также обеспечивает соответствующую безопасность протокол DTLS и одно возможное применение CoAP для IoT. Как ряд протоколы совершенствуются, все больше и больше умных домов будут использовать эти беспроводные протоколы для интеллектуального управления.

6. Список литературы

  • [Петербург12] г. Санкт-Петербург.Санкт-Петербург, «Интернет вещей, интеллектуальные пространства и сети нового поколения», Россия, 27-29 августа 2012 г. http://link.springer.com/book/10.1007%2F978-3-642-32686-8
  • [Z. Shelby13] З. Шелби, Сенсинод, К. Хартке, «Протокол ограниченного приложения (CoAP)», draft-ietf-core-coap-18. [2013-06-28] http://tools.ietf.org/html/draft-ietf-core-coap-18
  • [G.Tolle13] Г.Толле, Arch Rock Corporation. Встроенный двоичный HTTP (EBHTTP) draft-tolle-core-ebhttp-00.[2010-03-23] https://tools.ietf.org/html/draft-tolle-core-ebhttp-00
  • [Glombitza10] Glombitza, N .; Pfisterer, D .; Фишер С., «LTP: эффективный протокол передачи веб-сервисов для устройств с ограниченными ресурсами», Sensor Mesh and Ad Hoc Communications and Networks (SECON), 7-я ежегодная конференция общества связи IEEE 2010 г., том, №, стр.1 , 9, 21-25 июня 2010 г. http://ieeexplore.ieee.org/document/5508255/
  • [С. Keoh23] С.Кео, Philips Research, З. Шелби, Sensinode. Профилирование DTLS для приложений Интернета вещей на основе CoAP draft-keoh-dice-dtls-profile-iot-00 [2013-11-05] http://tools.ietf.org/html/draft-keoh-dice-dtls-profile-iot-00
  • [Koojana11] Кожана Куладинити, Олаф Бергманн, Томас Потч Маркус Беккер, Кармелита Горг, «Внедрение CoAP и его применение в транспортной логистике», в материалах семинара по расширению Интернета для сетей с низким энергопотреблением и с потерями (апрель 2011 г.) http: // hinrg.cs.jhu.edu/joomla/images/stories/coap-ipsn.pdf
  • [Shelby11] Зак Шелби, «Формат ссылки CoRE», draft-ietf-core-link-format-07 https://tools.ietf.org/html/draft-ietf-core-link-format-01
  • [Castellani12] Castellani, A .; Fossati, T .; Лорето, С., «Межпротокольный прокси HTTP-CoAP: точка зрения реализации», Mobile Adhoc and Sensor Systems (MASS), 2012 IEEE 9-я международная конференция, издание Дополнение, №, стр.1,6, 8-11 Октябрь 2012 г. http: // ieeexplore.ieee.org/document/6708523/
  • [Kothmayr12] Архитектура сквозной безопасности на основе DTLS для Интернета вещей с двусторонней аутентификацией Томас Котмайр, Коринна Шимитт, Вен Ху, Майкл Брюнинг. 2012 г. http://kothmayr.net/wp-content/papercite-data/pdf/kothmayr2012dtls.pdf
  • [Raza13] Raza, S .; Shafagh, H .; Hewage, K .; Hummen, R .; Фойгт, Т., «Lithe: легкий безопасный протокол CoAP для Интернета вещей», журнал Sensors, IEEE, vol.13, № 10, стр. 3711,3720, октябрь 2013 г. http://ieeexplore.ieee.org/document/6576185/
  • [E. Rescorla12] Э. Рескорлаи, Н. Модадугу, «Безопасность транспортного уровня дейтаграмм, версия 1.2», стандарт RFC 6347, январь 2012 г. http://tools.ietf.org/html/rfc6347
  • [Hartke13] Клаус Хартке, Ханнес Чофениг, Профиль DTLS для Интернета вещей draft-hartke-dice-profile-00, [2013-11-04] http://tools.ietf.org/html/draft-hartke-dice-profile-00
  • [Bergmann12] Бергманн, О.; Hillmann, K.T .; Гердес, С., «Шлюз CoAP для умных домов», «Компьютеры, сети и связь (ICNC)», Международная конференция 2012 г., стр. 446 450, 30 января 2012 г. — февраль. 2 2012 http://ieeexplore.ieee.org/document/6167461/

7. Сокращения

Интернет вещей Интернет вещей
ИЭФТ Инженерная группа Интернета
CoAP Протокол ограниченного приложения
HTTP Протокол передачи гипертекста
HART Дистанционный преобразователь с адресацией по магистрали
LR-WPAN Низкоскоростная беспроводная персональная сеть
EBHTTP Встроенный двоичный HTTP
LTP Протокол бережливого транспорта
CoRE Ограниченные среды RESTful
ОТДЫХ Государственная передача представления
URI Унифицированный идентификатор ресурса
P2P От точки к точке
DTLS Дейтаграмма безопасности транспортного уровня
Последнее изменение: 30 апреля 2014 г.
Этот и другие документы по актуальным вопросам беспроводных и мобильных сетей. доступны в Интернете по адресу http: // www.cse.wustl.edu/~jain/cse574-14/index.html
Вернуться на домашнюю страницу Раджа Джайна

Платформа пользовательских сервисов — стандартизированное управление и контроль Интернета вещей

  1. Сопоставление конечных точек USP с URI CoAP
  2. Сопоставление записей USP с сообщениями CoAP
    1. Обработка успешного запроса CoAP
    2. Обработка сбоев запроса CoAP
  3. Шифрование сообщений MTP

Протокол ограниченного приложения (CoAP) MTP передает записи USP между конечными точками USP, используя протокол CoAP, как определено в RFC 7252.Сообщения, которые передаются между клиентами и серверами CoAP, используют взаимодействие обмена сообщениями типа запрос / ответ на основе архитектурных принципов RESTful. На следующем рисунке изображена передача записей USP между конечными точками USP.

Рисунок COAP.1 — Пример: запрос / ответ USP через CoAP MTP

В этом примере запрос USP кодируется в записи USP и инкапсулируется в сообщение запроса CoAP. Когда конечная точка USP получает сообщение запроса CoAP, конечная точка USP немедленно отправляет ответное сообщение CoAP (без записи USP), чтобы указать получение сообщения.Ответ USP, закодированный в записи USP, инкапсулируется в новое сообщение запроса CoAP. Когда конечная точка USP получает ответ USP, она отправляет ответное сообщение CoAP, которое указывает на получение сообщения. Следовательно, все конечные точки, поддерживающие CoAP, будут реализовывать как клиент, так и сервер CoAP.

Как отмечено в определении запроса USP, эта запись USP либо запрашивает у агента выполнение определенного действия (создание, обновление, удаление, действие и т. Д.), Запрашивает информацию об агенте или одном или нескольких элементах службы, либо действует как означает доставку уведомлений от агента к контроллеру.Уведомления вызовут появление ответа USP только в том случае, если это указано в запросе на уведомление. Однако ответ CoAP будет отправляться всегда.

Сопоставление конечных точек USP с URI CoAP

Раздел 6 RFC 7252 обсуждает схемы URI для идентификации ресурсов CoAP и предоставляет средства определения местоположения ресурса. Эти ресурсы организованы иерархически и управляются сервером CoAP, который прослушивает запросы CoAP на заданном порту. Конечные точки USP — это один из типов ресурсов CoAP, который идентифицируется и обнаруживается.

R-COAP.0 — Поскольку конечная точка USP является ресурсом, управляемым сервером CoAP, сервер CoAP также ДОЛЖЕН быть идентифицирован, как определено в разделе 6 RFC 7252.

R-COAP.1 — Конечная точка USP ДОЛЖНА быть представлена ​​как ресурс CoAP со следующими атрибутами ресурсов:

  • Идентификатор на сервере CoAP (uri-path)
  • Тип ресурса (RT): « bbf.usp.endpoint »
    • Интерфейс
  • (если): « bbf.usp.c » для контроллера USP или « bbf.usp.a ”для агента USP

Идентификатор на сервере CoAP используется для доставки сообщений конечной точке USP. Когда этот идентификатор используется для доставки сообщений в конечную точку USP, этот идентификатор представляет собой uri-path, который представляет конечную точку USP.

R-COAP.2 — Сообщение запроса CoAP ДОЛЖНО включать параметр Uri-Query, который предоставляет URI сервера CoAP конечной точки, которая является источником запроса CoAP, в формате ? Reply-to = .URI coap и coaps определены в разделах 6.1 и 6.2 RFC 7252. URI НЕ ДОЛЖЕН включать в себя какие-либо дополнительные запросы.

R-COAP-2a — Когда конечная точка USP получает сообщение запроса CoAP, она ДОЛЖНА использовать параметр Uri-Query ответа, включенный в запрос CoAP, в качестве URI CoAP для ответа USP (если ответ требуется входящий запрос USP).

R-COAP.3 — При создании записей DNS-SD (см. Использование DNS) конечная точка ДОЛЖНА установить атрибут «path» записи TXT DNS-SD, равный значению идентификатора сервера CoAP (uri-path).

Сопоставление записей USP с сообщениями CoAP

R-COAP.4 — Чтобы записи USP передавались между контроллером USP и агентом с использованием CoAP, запись USP ДОЛЖНА быть инкапсулирована в сообщение CoAP, как определено в RFC 7252.

R-COAP.5 — Записи USP, размер которых превышает размер сообщения CoAP, ДОЛЖНЫ быть блочно инкапсулированы в соответствии с RFC 7959.

Записи

USP передаются с использованием ресурса CoAP, который представляет получающую конечную точку USP, с использованием метода POST CoAP, как определено в RFC 7252.

R-COAP.6 — Формат содержимого CoAP для записей USP ДОЛЖЕН быть приложением / потоком октетов (ID = 42) для кодирования protobuf.

Обработка успешного запроса CoAP

R-COAP.7 — После успешного приема сообщения CoAP с помощью POST сервер CoAP ДОЛЖЕН ответить кодом ответа 2,04 (изменено) .

Обработка сбоев запроса CoAP

Иногда запросы CoAP не могут быть выполнены из-за проблем в базовом транспорте (например,g., тайм-аут) или код ответа сбоя, полученный от сервера CoAP из-за проблем в запросе CoAP, отправленном клиентом CoAP (4.xx), или проблем с реализацией сервера CoAP (5.xx).

R-COAP.8 — Клиенты и серверы CoAP ДОЛЖНЫ реализовывать требуемые коды ответов CoAP, определенные в разделе 5.9 RFC 7252.

R-COAP.9 — Когда клиент CoAP получает индикацию отказа (например, тайм-аут) от нижележащего транспортного уровня, клиент CoAP ДОЛЖЕН указать тайм-аут для конечной точки USP.

R-COAP.10 — Когда клиент CoAP получает код ответа 4.xx или 5.xx, клиент CoAP ДОЛЖЕН указать конечной точке USP отказ CoAP.

Когда клиент CoAP отправляет запрос CoAP, клиент CoAP может предоставить неверную или отсутствующую информацию в запросе CoAP. Например, клиент CoAP может отправить запрос CoAP с:

  • Неверный метод CoAP: сервер CoAP отвечает 4,05
  • Неверные параметры формата содержимого: сервер CoAP отвечает 4.15
  • Неверная или непонятная полезная нагрузка: сервер CoAP отвечает 4,00

R-COAP.11 — Когда сервер CoAP получает запрос CoAP с недопустимым методом CoAP, сервер CoAP ДОЛЖЕН ответить кодом ответа 4,05 .

R-COAP.12 — Когда сервер CoAP получает запрос CoAP с недопустимой опцией формата содержимого CoAP, сервер CoAP ДОЛЖЕН ответить кодом ответа 4.15 .

R-COAP.13 — Когда сервер CoAP получает запрос CoAP и принимающая конечная точка USP не может интерпретировать или декодировать запись USP для обработки, сервер CoAP ДОЛЖЕН ответить кодом ответа 4,00 .

Шифрование сообщений MTP

Шифрование сообщений

CoAP MTP обеспечивается с использованием DTLS, как описано в разделе 9 RFC 7252.

В разделе 9 RFC 7252 сообщения CoAP защищены одним из трех режимов:

  • NoSec: DTLS отключен
  • PreSharedKey: DTLS включен, и конечная точка MTP использует общие ключи, которые используются для проверки подлинности конечных точек CoAP, участвующих в обмене сообщениями
  • RawPublicKey: DTLS включен, и конечная точка MTP имеет асимметричную пару ключей без сертификата.Конечная точка MTP имеет идентификатор, рассчитанный на основе открытого ключа и списка других конечных точек MTP, с которыми она может связываться
    • Сертификат
  • : DTLS включен, и конечная точка MTP имеет асимметричную пару ключей с сертификатом X.509.

R-COAP.14 — Клиенты и серверы CoAP ДОЛЖНЫ реализовывать режимы безопасности CoAP NoSec и Certificate, как определено в RFC 7252.

В то время как раздел 9 RFC 7252 предоставляет руководство по защите CoAP, дальнейшие рекомендации, связанные с реализациями DTLS для Интернета вещей, представлены в RFC 7925.

R-COAP.15 — клиенты и серверы CoAP ДОЛЖНЫ реализовывать обязательные операторы RFC 7925, за исключением того, что:

  • Раздел 4.4.1 Сертификаты контроллера USP могут содержать доменные имена с подстановочными знаками в соответствии с рекомендациями RFC 6125.
  • Раздел 4.4.2 Идентификаторы сертификатов клиента не используют идентификатор EUI-64, а вместо этого используют идентификатор, определенный для сертификатов клиентов в этом рабочем тексте.
  • Раздел 4.4.5 URL-адреса сертификата клиента не требуется.

Поскольку оконечные точки USP играют роль как клиента, так и сервера CoAP; когда MTP защищен с использованием режима сертификата безопасности CoAP, конечная точка USP предоставляет сертификат X.509 партнеру MTP.

R-COAP.16 — Когда режим сертификата CoAP используется для защиты MTP, конечная точка USP ДОЛЖНА предоставить партнеру MTP сертификат X.509.

Обратите внимание, что сеансы DTLS, установленные для клиента CoAP конечной точки и сервера CoAP, различны. Следовательно, CoAP может быть зашифрован в одном направлении, а не в другом.Если это произойдет, требования и потоки в Аутентификации и Авторизации будут диктовать использование безопасного обмена сообщениями.

Использование RELOAD и CoAP для глобальной сети датчиков и исполнительных механизмов | Журнал EURASIP по беспроводной связи и сети

В этом разделе мы представим результаты моделирования в разделах 8.1 и 8.2. В Разделе 8.3 мы представим результаты запуска экспериментального прототипа нашей архитектуры в реальных сетях и оборудовании.

8.1 Задержки

В первом наборе моделирования мы сосредоточились на измерении задержек, связанных с установлением отношений наблюдения CoAP. Задержки для четырех сценариев показаны на рисунках 7 и 8. Рисунок 7 показывает среднюю задержку установления отношения наблюдения CoAP, тогда как рисунок 8 показывает среднюю задержку отдельных транзакций CoAP. Планки погрешностей на рисунках представляют собой 95% доверительные интервалы.

Рисунок 7

Задержка установления отношения наблюдения CoAP .На рисунке показана средняя задержка установления отношений наблюдения CoAP. На рисунке сравниваются четыре сценария: (1) оверлей RELOAD используется вместе с выделенными соединениями для CoAP, (2) используется оверлей RELOAD и передача сигналов CoAP туннелируется через оверлей, (3) используется архитектура клиент / сервер и используются выделенные соединения. используется для CoAP, и (4) используется архитектура клиент / сервер, и сообщения CoAP отправляются через центральный сервер.

Рисунок 8

Задержка транзакций CoAP .На рисунке показана задержка последующих транзакций CoAP, отправленных после установления отношения наблюдения CoAP.

Из рисунка 7 видно, что задержки установления отношения наблюдения CoAP с использованием выделенного соединения, согласованного с помощью ICE, составляют 28,1 с и 6,3 с в сценариях, предназначенных для RELOAD и C / S, соответственно. Когда все сообщения CoAP туннелируются, задержки установления отношения наблюдения CoAP составляют 25,5 с и 3,0 с для сценариев RELOAD-tunnel и C / S-tunnel соответственно.Как и ожидалось, задержки RELOAD во много раз превышают задержки C / S. Это связано с дополнительной задержкой, связанной с отправкой сообщений RELOAD Fetch, Attach и Tunnel через несколько переходов через оверлей. Каждый переход включает в себя отправку сообщения дважды через беспроводной радиоинтерфейс 3G (т. Е. В сетях беспроводного доступа отправителя и получателя).

Из рисунка мы можем заметить, что причина, по которой выделенные соединения дороже для сценариев RELOAD и C / S, чем использование запросов RELOAD Tunnel для установления отношений наблюдения, связана с переговорами ICE, которые занимают примерно 3 раза.2 с для RELOAD и C / S (разница в задержках между сценариями RELOAD и C / S не является статистически значимой).

На рисунке 8 показаны задержки последующих транзакций CoAP, отправленных после установления отношения наблюдения. Как и ожидалось, задержки равны примерно 1,1 с для сценариев RELOAD и C / S. Задержки туннелирования сообщений CoAP через оверлей или через центральный сервер составляют 11,7 с и 1,8 с для сценариев RELOAD-tunnel и C / S-tunnel соответственно.Таким образом, туннелированные сценарии имеют явно более высокую стоимость, чем сценарии с использованием выделенных соединений. В частности, стоимость туннелирования CoAP через оверлей RELOAD настолько высока, что это может оказаться невозможным на практике, если наблюдателям требуется информация от датчиков в реальном или близком к реальному времени.

Хотя задержка, связанная с установлением отношения наблюдения CoAP, в 4,5 раза выше для сценария, выделенного для RELOAD, чем для сценария, выделенного для C / S, стоит отметить, что эта задержка происходит только один раз при установлении отношения.В сценарии, посвященном RELOAD, после этой единовременной стоимости последующие транзакции CoAP не испытывают дополнительной задержки по сравнению со случаем, посвященным C / S. Таким образом, если можно допустить эти единовременные дополнительные расходы, как и следовало ожидать в типичном случае использования, использование наложения RELOAD не дороже, чем использование центрального сервера, когда дело касается задержек CoAP.

8.2 Загрузка трафика

8.2.1 Первый набор моделирования

Поскольку все PN используют сотовый радиодоступ, интересно сравнить общие нагрузки трафика, генерируемые в наших четырех сценариях.Нагрузку трафика следует минимизировать, чтобы минимизировать нагрузку на сеть сотового доступа, а также из соображений энергоэффективности. Сначала мы опишем результаты для нагрузки трафика в первом наборе моделирования. Результаты второго и третьего сеансов моделирования описаны в разделах ниже.

Общий объем трафика протокола приложения (т. Е. CoAP, RELOAD и STUN), которым обмениваются в оверлее в течение часового периода в первом наборе моделирования, показан на рисунке 9 для наших четырех сценариев.В сценарии, специально предназначенном для RELOAD, трафик состоит из сообщений CoAP, трафика поддержки активности STUN для RELOAD и CoAP, а также служебного трафика наложения RELOAD. В сценарии RELOAD-tunnel трафик состоит из трафика обслуживания RELOAD, трафика приложения RELOAD (т. Е. Запросов туннеля) и сообщений проверки активности STUN для RELOAD. В сценарии, посвященном C / S, трафик состоит из сообщений поддержки активности STUN для CoAP и RELOAD (мы использовали сообщения RELOAD для передачи сигналов клиент / сервер между PN и центральным сервером) и сообщений CoAP.В сценарии C / S-туннеля трафик состоит только из сообщений поддержки активности STUN и сообщений CoAP (сообщения CoAP были инкапсулированы в сообщения туннеля RELOAD).

Рисунок 9

Общий трафик, 2000 прокси-узлов . На рисунке показан общий объем трафика протокола приложений, которым обменивается система в течение периода измерения при использовании 2000 прокси-узлов и 10-минутного интервала уведомления CoAP. Предполагалось, что прокси-узлы расположены за NAT, дружественным к P2P.

Из рисунка видно, что в сценарии, выделенном для RELOAD, общий трафик в течение часового периода составляет 938 МБ, тогда как в сценарии, выделенном для C / S, он составляет 365 МБ.Сценарий RELOAD-туннеля генерирует 750 МБ трафика, тогда как C / S-туннель генерирует только 124 МБ. Более высокая стоимость сценариев RELOAD объясняется, в частности, трафиком обслуживания наложения RELOAD и большим объемом трафика STUN, необходимого для поддержания соединений RELOAD между PN (каждый PN поддерживает соединения со всеми одноранговыми узлами в таблице маршрутизации, размер которой составляет 8 пальцев, 3 преемника и 3 предшественника, как описано в таблице 1). Во всех сценариях большая часть общего трафика — это STUN keeplives.Процентное соотношение составляет 71%, 43%, 96% и 53% для сценариев RELOAD-выделенный, RELOAD-туннель, выделенный C / S и C / S-туннель соответственно. Для сценариев, предназначенных для RELOAD и C / S, крупнейшим источником трафика являются пакеты поддержки активности STUN для подключений CoAP. Доля сообщений проверки активности STUN для CoAP от общего трафика составляет 40% и 89% для сценариев RELOAD и C / S, соответственно.

Таким образом, мы можем сделать вывод, что, как и ожидалось, с моделью трафика, описанной в таблице 1, сценарии C / S генерируют значительно меньше общего трафика, чем сценарии RELOAD.Однако основное различие, конечно, состоит в том, что в сценарии C / S центральный сервер должен обрабатывать либо весь (C / S-туннель), либо часть (C / S-специализированный) общего трафика. Поэтому интересно также изучить входящий трафик, который необходимо обрабатывать центральному серверу. Мы сделаем это во втором наборе моделирования, описанном ниже.

8.2.2 Второй набор симуляций

Во втором наборе симуляций мы сравнили транспортную нагрузку наших четырех различных сценариев в более сложных условиях (которые были описаны в Разделе 7.3).

Общий объем трафика, которым обмениваются в каждом из четырех сценариев во втором наборе моделирования, показан на рисунке 10. Для оси y на рисунке используется логарифмическая шкала. Из рисунка видно, что сценарий C / S-туннеля по-прежнему имеет самый низкий общий объем трафика. В отличие от рисунка 9, сценарий RELOAD-туннеля теперь имеет самый высокий общий объем трафика (за исключением случая, когда на каждый WSN приходится только один LN). Объем трафика в сценарии, выделенном для C / S, начинает приближаться и в конечном итоге становится почти равным трафику в сценарии, выделенном для RELOAD, по мере увеличения количества LN на WSN.Это связано с тем, что сообщения CoAP и пакеты поддержки активности STUN для CoAP начинают преобладать, и, таким образом, дополнительные затраты на использование RELOAD поверх C / S становятся незначительными при рассмотрении общих уровней трафика.

Рисунок 10

Общий трафик, 10 000 прокси-узлов . На рисунке показан общий объем трафика протокола приложения, которым обменивается система в течение периода измерения при использовании 10 000 прокси-узлов (PN), 1–100 локальных узлов (LN) на PN и 10-минутного интервала уведомления CoAP.Предполагалось, что подмножество PN находится за P2P-недружественными NAT.

На рисунке 11 показано количество входящих Мбит / с для центрального сервера в сценариях C / S и для среднего однорангового узла в сценариях RELOAD. Для оси y на рисунке используется логарифмический масштаб. Из рисунка видно, что в сценариях RELOAD PN особо не загружаются. Однако в сценариях C / S нагрузка на центральный сервер начинает быстро расти. Например, при наличии 10 LN на WSN сервер должен уже иметь возможность обрабатывать нагрузку входящего трафика, равную 3.6 и 11,1 Мбит / с в сценариях выделенного C / S и C / S-туннеля соответственно. Таким образом, мы можем сделать вывод, что масштабируемость сценариев RELOAD оказывается намного лучше, чем масштабируемость архитектуры C / S.

Рисунок 11

Входящий трафик в секунду, 10 000 прокси-узлов . На рисунке показано количество входящих Мбит / с для центрального сервера в сценариях C / S и для среднего однорангового узла в сценариях RELOAD при использовании 10 000 прокси-узлов (PN), 1-100 локальных узлов (LN) на PN и 10-минутный интервал уведомления CoAP.Предполагалось, что подмножество PN находится за P2P-недружественными NAT.

8.2.3 Третий набор симуляций

В нашем третьем и последнем наборе симуляций мы уменьшили средний интервал уведомлений CoAP до 60 с, сохраняя при этом значения всех других параметров идентичными по сравнению со вторым набором симуляций. Итоговый общий трафик в наших четырех сценариях показан на рисунке 12. Из рисунка мы можем заметить, что при высокой частоте уведомлений CoAP сценарии RELOAD-туннеля и C / S-туннеля становятся явно более дорогостоящими, чем RELOAD. специализированные и специализированные сценарии C / S с точки зрения общего трафика.Кроме того, если посмотреть на количество входящих Мбит / с на средний одноранговый узел (сценарии RELOAD) или на центральный сервер (сценарии C / S), показанные на рисунке 13, мы можем увидеть, что сценарий, посвященный RELOAD, явно превосходит другие сценарии. В худшем случае (100 LN на WSN) средний Мбит / с, полученный средним одноранговым узлом или центральным сервером, составляет 0,04 Мбит / с, 0,40 Мбит / с, 42 Мбит / с и 1078 Мбит / с для выделенного RELOAD , Сценарии RELOAD-tunnel, выделенный C / S и C / S-туннель соответственно. Таким образом, мы снова можем видеть, что сценарии RELOAD (особенно RELOAD выделенные) очень хорошо масштабируются, тогда как в сценариях C / S нагрузка трафика для центральных серверов может стать очень высокой.

Рисунок 12

Общий трафик, 10 000 прокси-узлов, интервал уведомления 60 с . На рисунке показан общий объем трафика протокола приложений, которым обменивается система в течение периода измерения при использовании 10 000 прокси-узлов (PN), 1-100 локальных узлов (LN) на PN и интервала уведомления CoAP 60 с. Предполагалось, что подмножество PN находится за P2P-недружественными NAT.

Рисунок 13

Входящий трафик в секунду, 10 000 прокси-узлов, интервал уведомления 60 с .На рисунке показано количество входящих Мбит / с для центрального сервера в сценариях C / S и для среднего однорангового узла в сценариях RELOAD при использовании 10 000 прокси-узлов (PN), 1-100 локальных узлов (LN) на PN и интервал уведомления CoAP 60 секунд. Предполагалось, что подмножество PN находится за P2P-недружественными NAT.

8.3 Оценка системы в реальной сети и аппаратном обеспечении

Мы работаем над испытательным прототипом нашей сетевой архитектуры датчиков и исполнительных механизмов с широким охватом.В прототипе мы используем небольшие одноплатные компьютеры Gumstix Overo Earth COM — с процессором ARM Cortex-A8 600 МГц в качестве узлов сети. Одноплатные компьютеры работают под управлением встроенной операционной системы Linux. Мы оснастили одноплатные компьютеры ключом 3G и ключом Libelium Waspmote b ZigBee Gateway, оба из которых подключаются через USB. Ключ 3G обеспечивает широкополосное соединение (например, Интернет). Ключ ZigBee Gateway используется для связи с ZigBee WSN.Мы используем датчики Libelium Waspmote ZigBee в качестве устаревших LN. В прототипе используется та же кодовая база, что и в нашем симуляторе. Это обеспечивается уровнем абстракции, скрывающим тот факт, используется ли реальный или смоделированный сетевой уровень. Поскольку наш прототип основан на Java, мы запускаем виртуальную машину Java CACAO, c , которая поддерживает процессоры ARM, на одноплатных компьютерах. Мы также разработали несколько дополнительных модулей для прототипа. К ним относятся, например, модуль, обеспечивающий взаимодействие между CoAP / UDP / IP и стеком протоколов ZigBee.Наконец, мы используем стороннюю библиотеку ZigBee API под названием xbee-api d для взаимодействия прототипа с устройством шлюза ZigBee.

Мы провели серию дополнительных измерений, используя наш экспериментальный прототип. Во всех этих измерениях использовался сценарий, посвященный ПЕРЕЗАГРУЗКЕ. В измерениях две сети PN, PN-A и PN-B, действовали как клиенты в оверлейной сети RELOAD из 1000 узлов, работающей в PlanetLab. Мы решили использовать наложение PlanetLab, а не наложение, созданное только PN, чтобы иметь возможность экспериментировать с достаточно большим количеством узлов (у нас было только ограниченное количество доступного оборудования PN).Узлы PlanetLab использовали ту же версию Java Standard Edition нашего прототипа, что и одноплатные компьютеры. Оба PN были расположены за NAT с использованием независимого отображения конечных точек и режима фильтрации. В измерениях мы сосредоточились на измерении задержек связи, связанных с одним LN, LN-A, и начали наблюдать за ресурсом CoAP другого LN, LN-B, расположенного за другим PN. Мы измеряли отдельно задержки между каждым LN и его PN, а также задержки между двумя PN. Поскольку наложение выполнялось в PlanetLab, только первый переход (от PN к узлу PlanetLab) и последний переход (от узла PlanetLab к PN) в наложении проходил по сотовой радиосвязи.При измерениях LN и PN располагались в одном помещении без препятствий между ними.

Результаты измерений показаны в таблице 3. Таблица содержит среднюю задержку, рассчитанную по 100 измерениям для каждого компонента задержки. Задержка сбора кандидатов ICE в LN-A показана отдельно в таблице. В таблице значение в скобках представляет собой стандартное отклонение. Результаты выглядят немного иначе по сравнению с результатами по задержке в нашем моделировании из-за того, что при измерениях только первый и последний переходы в оверлее RELOAD проходили через радиоинтерфейс 3G; все промежуточные переходы маршрутизации происходили между узлами PlanetLab.Мы видим, что общая задержка с момента, когда LN-A инициирует сообщение CoAP, до момента получения ответа CoAP от LN-B составляет в среднем 12,9 с. Связь через ZigBee составляет только 10% от общей задержки. Самый большой компонент задержки — это процедура Attach. Большая задержка прикрепления, особенно по сравнению со значительно меньшей задержкой поиска, объясняется двумя факторами. Во-первых, запрос и ответ на прикрепление дважды проходят через радиоинтерфейс 3G (в сетях доступа PN-A и PN-B).Напротив, на запрос Lookup отвечает узел PlanetLab, и поэтому он проходит через 3G только на стороне отправляющего PN. В общем, все компоненты задержки, которые требуют обмена сообщениями по сети 3G как на стороне A, так и на стороне B, высоки. К ним относятся задержка присоединения, задержка согласования ICE и задержка PN-PN CoAP. Вторая причина большой задержки Attach заключается в том, что она также включает сбор кандидатов ICE в PN-B. Главный дополнительный результат этих измерений по сравнению с моделированием заключается в том, что связь между LN и PN составляет лишь незначительную часть сквозной задержки.

Таблица 3 Измерения в PlanetLab

CoAP — это «современный» протокол Интернета вещей — OMA SpecWorks

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

22 июня 2016 г., Салли Джонсон, TechTarget — Для переноса Интернета на ограниченные устройства, которые не обладают возможностями компьютеров или смартфонов, требуется специальный протокол IoT, и CoAP является одним из таких протоколов, который отвечает этим требованиям.

Более новый протокол, чем большинство других, Инженерная группа Интернета (IETF) стандартизировала протокол ограниченного приложения или CoAP как RFC 7252 в 2014 году — по сути, как HTTP, разработанный специально для ограниченных устройств.

Протокол ограниченного приложения был необходим, потому что традиционные протоколы считаются «слишком тяжелыми» для приложений Интернета вещей, включающих ограниченные устройства. Сети конечных узлов IoT, как правило, работают с потерями, но ожидается, что маломощные устройства, которые на них работают, будут продолжать функционировать — питаясь от батарей или собирая энергию — в течение многих лет и должны потреблять как можно меньше энергии.

CoAP — это программный протокол, который позволяет простым «вещам» с ограничениями, таким как маломощные датчики и исполнительные механизмы, обмениваться данными в интерактивном режиме через Интернет. Он работает на устройствах, поддерживающих протокол пользовательских дейтаграмм (UDP), и реализует «облегченный» прикладной уровень, который обеспечивает небольшие размеры сообщений, управление сообщениями и легкие служебные данные, идеально подходящие для устройств с низким энергопотреблением и малым объемом памяти.

В области Интернета вещей CoAP широко используется в качестве протокола для домашней автоматизации и во многих промышленных приложениях.Он также используется для управления устройствами с использованием протокола облегченного межмашинного взаимодействия (LWM2M) Open Mobile Alliance (OMA), а другие организации, в том числе Open Connectivity Foundation и ZigBee, используют CoAP в качестве основного протокола для своих фреймворков и реализаций продуктов. .

Чтобы идти в ногу с кембрийским взрывом роста подключенных «вещей», протокол IoT, разработанный специально для ограниченных устройств, таких как CoAP, должен сыграть решающую роль.

Sierra Wireless, одна из первых использовала CoAP для своего облака IoT.«В основном мы используем его для подключения устройств на базе legato.io к нашему облаку с помощью OMA LWM2M, который основан на CoAP», — сказал Жюльен Вермиллард, главный инженер по разработке программного обеспечения для Sierra Wireless.

Существует множество других приложений IoT для CoAP, и Крис Матье, директор по разработке Интернета вещей в Citrix Octoblu, считает, что он «чаще всего используется для сценариев с низкой пропускной способностью, таких как спутниковая связь и небольшие энергоэффективные датчики».

CoAP по сравнению с другими протоколами Интернета вещей

При разработке протокола ограниченного приложения IETF стремилась обеспечить его хорошее масштабирование и возможность расширения — и это действительно так, благодаря парадигме коммуникации, на которой он основан.

Другие протоколы IoT включают хорошо известные HTTP, WebSocket, Extensible Messaging and Presence Protocol (XMPP) и MQ Telemetry Transport (MQTT), большинство из которых существует уже не менее десяти или двух лет.

По словам Карстена Бормана и Хайме Хименеса, председателей рабочей группы IETF по ограниченным средам RESTful (CoRE), некоторые из этих других протоколов по-прежнему выполняют удаленные вызовы процедур или продвигают простую публикацию / подписку, например MQTT.

Хотя на первый взгляд эти другие альтернативы часто кажутся привлекательными, «они плохо масштабируются и не предлагают расширяемости основанных на RESTful, таких как CoAP», — отметили Борман и Хименес.

Важно отметить, что CoAP и другие протоколы IoT могут прекрасно работать вместе. Матье видит переход на CoAP для управления дронами и потоковой передачи данных с датчиков для сельскохозяйственных приложений IoT, и «оба этих варианта использования больше зависят от энергоэффективности и более быстрой связи, чем от гарантированной доставки сообщений», — отметил он. Платформа Octoblu «позволяет устройствам CoAP« взаимодействовать »с устройствами MQTT, HTTP, WebSocket, XMPP и AMQP — и наоборот — поэтому легко смешивать и согласовывать устройства и протоколы в зависимости от требований каждого варианта использования.”

В конечном счете, поскольку CoAP использует хорошо известную веб-модель RESTful для устройств и сетей с ограничениями, «она лучше всего подходит для приложений, в которых устройство поддерживается как можно более« немым »- открывая только значения датчиков и конечные точки исполнительных механизмов», — сказал Вермиллард.

Ключевые преимущества CoAP

Согласно Борману и Хименесу, одним из основных преимуществ протокола ограниченного приложения является то, что он предназначен для бесшовного сопоставления с существующими веб-протоколами, такими как HTTP.По их словам, он также «обеспечивает простое обнаружение ресурсов, безопасность и поддерживает ключевые концепции, используемые в Интернете, такие как унифицированные идентификаторы ресурсов, методы и типы носителей». Возможно, не менее важно то, что «это очень просто и основано на RESTful».

Ранние последователи согласны с тем, что протокол ограниченного приложения очень хорошо работает для ограниченных сетей и устройств. Что-то не так хорошо известно: «В очень перегруженной беспроводной сети — Wi-Fi или сотовой — CoAP может продолжать работать там, где протокол на основе протокола управления передачей (TCP), такой как MQTT, не может даже выполнить рукопожатие», — сказал Вермиллард. сказал.Это связано с тем, что в отличие от большинства других протоколов IoT, CoAP построен на UDP. Другими словами, это означает отсутствие подтверждения протокола или исправления ошибок, которые встречаются в TCP. «CoAP может быть не таким надежным, как HTTP, и не гарантирует доставку сообщений, таких как MQTT, но он очень быстр», — отметил Матье. «Если вас устраивает, что некоторые сообщения не принимаются, вы можете отправить еще много сообщений в те же сроки».

Быстрая отправка большого количества сообщений может пригодиться. Один из разработчиков Octoblu использовал CoAP для управления роботом в соревновании BattleBot и смог отправить своему роботу в три раза больше сообщений, чем другие конкуренты, что в конечном итоге позволило ему выиграть соревнование.

Ограниченная безопасность протокола приложений

IETF разработал CoAP, чтобы «обеспечить полную безопасность за счет использования Datagram Transport Layer Security (DTLS), версии того же протокола Transport Layer Security (TLS), который защищает большую сеть — без ущерба для параметров безопасности», Борман и — сказал Хименес.

Поскольку безопасность CoAP основана на твердом стандарте DTLS, Вермиллард сказал, что его это не беспокоит. «Если вам нужен механизм управления ключами поверх CoAP, им может управлять LWM2M», — добавил он.

Для дополнительной безопасности Octoblu решила реализовать свой REST API в каждом поддерживаемом протоколе. «Наш API CoAP основан на уникальных идентификаторах устройств (UUID) и секретных токенах», — пояснил Матье. «Это та же практика, что и наш HTTP REST API. Подсистема управления ролями Интернета вещей Octoblu позволяет вам указать, какие UUID имеют доступ для обнаружения, подписки, отправки сообщений или настройки других UUID ».

У протокола ограниченного приложения есть некоторые довольно интересные особенности в отношении шифрования трафика, как отметил Матье.Поскольку CoAP является протоколом на основе UDP, в отличие от других протоколов Интернета вещей, он не может использовать шифрование TLS. «CoAP должен использовать DTLS, который намеренно похож на TLS», — сказал он. «За исключением того, что DTLS должен решать две проблемы: потерю пакетов и переупорядочение. DTLS реализует повторную передачу пакетов, присваивая порядковый номер в пределах рукопожатия и обнаруживая повторное воспроизведение ». Подробнее см. RFC 6347.

CoAP быстро развивается

Как и при развертывании всех новых протоколов, ведется работа по дальнейшему совершенствованию CoAP.Будущая работа IETF по CoAP включает «новые режимы безопасности, отличные от DTLS, группового взаимодействия, управления и моделей взаимодействия», — заявили Борман и Хименес. Рабочая группа IETF CoRE занимается этими вопросами, и ее участие приветствуется.

Что касается проблем, с которыми столкнулись ранние последователи протокола ограниченного приложения, Вермиллард предупредил, что средства передачи CoAP могут немного снижать производительность. «Так что будьте осторожны и протестируйте производительность своего CoAP-приложения с высокой потерей пакетов, чтобы избежать обнаружения проблем позже», — посоветовал он.

Проблема, связанная с CoAP, с которой Octoblu столкнулась со своим стеком IoT, который в настоящее время работает в Amazon Web Services, заключается в том, что сервис AWS Elastic Load Balancing отлично подходит для поддержки IPv6 для трафика TCP, но не UDP. «Чтобы расширить поддержку IPv6 до CoAP, мы развернули сервис IPv6 на основе UDP за пределами AWS», — отметил Матье. «Хотя поддержка CoAP имела некоторые начальные проблемы … это очень современный протокол Интернета вещей с множеством новых преимуществ».

Что такое протокол CoAP | Введение в протокол CoAP | Обзор | автор: Харшвардхан Мишра

Прочтите сообщение в моем блоге полностью https: // iotbyhvm.ooo / what-is-coap-protocol /

Протокол приложений с ограничениями CoAP — это специализированный протокол Интернет-приложений для ограниченных устройств, как определено в RFC 7252. Он позволяет устройствам обмениваться данными через Интернет. Он определен как Contrained Application Protocol и представляет собой протокол, предназначенный для использования в очень простом оборудовании. Протокол особенно нацелен на ограниченное оборудование, такое как 8-битные микроконтроллеры, маломощные датчики и аналогичные устройства, которые не могут работать по HTTP или TLS.Это упрощение протокола HTTP, работающего на UDP, что помогает сэкономить полосу пропускания. Он разработан для использования между устройствами в одной и той же сети с ограничениями (например, сети с низким энергопотреблением и потерями), между устройствами и общими узлами в Интернете, а также между устройствами в разных сетях с ограничениями, которые соединены Интернетом. CoAP также используется с помощью других механизмов, таких как SMS в сетях мобильной связи.

Рабочая группа по ограниченным средам RESTful (IETF CoRE) Целевой группы разработчиков Интернета выполнила основную работу по стандартизации CoAP.Ядро протокола определено в RFC 7252, что означает, что CoAP все еще не является стандартным протоколом.

Две новые функции, разработанные специально для Интернета вещей и M2M:

  • Наблюдать за новыми событиями, происходящими на датчиках или исполнительных механизмах.
  • Управление устройствами и возможность обнаружения с внешних устройств.

Основными особенностями этого протокола являются:

  • Веб-протокол, используемый в M2M с ограниченными требованиями
  • Асинхронный обмен сообщениями
  • Низкие накладные расходы и очень простой анализ
  • Поддержка URI и типов содержимого
  • Возможности прокси и кэширования

Некоторые из конкретных случаев, в которых полезен CoAP:

  • Ваше оборудование не может запускать HTTP или TLS: Если это так, то выполнение CoAP и DTLS может практически делать то же самое, что и HTTP.Если кто-то является экспертом по HTTP API, миграция будет простой. Вы получаете GET для чтения и POST, PUT и DELETE для мутаций, а безопасность работает на DTLS.
  • Ваше оборудование использует батарею: Если это одна из проблем, то запуск CoAP улучшит производительность батареи по сравнению с HTTP через TCP / IP. UDP экономит часть полосы пропускания и делает протокол более эффективным.
  • Необходима подписка: Если невозможно запустить MQTT и HTTP-опрос невозможен, то решение — это CoAP.

Вам также может понравиться: MQTT Public Brokers List

Вы можете например: Как создать безопасный брокер MQTT

Некоторые функции протоколов CoAP очень похожи на HTTP, даже если CoAP не следует рассматривать как сжатый протокол HTTP, потому что он специально разработан для IoT и более подробно для M2M, поэтому он очень оптимизирован для этой задачи.

На уровне протокола абстракции CoAP может быть представлен как:

На этой диаграмме выше вы можете видеть, что существует два разных уровня, которые составляют протокол CoAp: сообщение и запрос / ответ. Уровень сообщений имеет дело с UDP и асинхронными сообщениями. Уровень запроса / ответа управляет взаимодействием запрос / ответ на основе сообщений запроса / ответа.

Протокол CoAP поддерживает четыре различных типа сообщений:

  • Подтверждаемое
  • Неподтвержденное
  • Подтверждение
  • Сброс

Теперь мы обсудим некоторые термины, относящиеся к протоколу CoAP.

Конечная точка : объект, который участвует в протоколе CoAP. Обычно конечная точка идентифицируется с хостом

Отправитель : объект, который отправляет сообщение

Получатель : место назначения сообщения

Клиент : объект, который отправляет запрос и место назначения ответа

Сервер : объект, который получает запрос от клиента и отправляет ответ клиенту.

Сообщение CoAP является нижним уровнем и занимается обменом сообщениями UDP между конечными точками.Сообщение CoAP имеет уникальный идентификатор и три части:

  • двоичный заголовок
  • компактные параметры
    • полезная нагрузка
Протокол

CoAP использует два типа сообщений:

  • Подтверждаемое сообщение
  • Неподтвержденное сообщение

A CoAP подтверждаемое сообщение — надежное сообщение. Во время обмена сообщениями между двумя конечными точками эти сообщения могут быть надежными. В протоколе CoAP надежное сообщение получается с помощью подтверждаемого сообщения (CON).Используя этот тип сообщения, клиент может быть уверен, что сообщение будет доставлено на сервер. Подтверждаемое сообщение CoAP отправляется снова и снова, пока другая сторона не отправит подтверждающее сообщение (ACK). Сообщение ACK содержит тот же идентификатор подтверждаемого сообщения (CON).

На приведенной выше диаграмме вы можете видеть связь, но если у сервера есть проблемы с управлением входящим запросом, он может отправить обратно сообщение Rest (RST) вместо сообщения подтверждения (ACK).

Неподтверждаемые (NON) сообщения , не требующие подтверждения от сервера.Эти сообщения являются ненадежными сообщениями и не содержат важной информации, которая должна быть доставлена ​​на сервер. К этой категории относятся сообщения, содержащие значения, считанные с датчиков. Даже если эти сообщения ненадежны, у них есть уникальный идентификатор.

Это второй уровень в уровне абстракции. Здесь запрос отправляется с помощью сообщения с подтверждением (CON) или без подтверждения (NON). Существует несколько сценариев в зависимости от того, может ли сервер ответить немедленно на запрос клиента или ответ, если он недоступен:

  • Если сервер может немедленно ответить на запрос клиента, тогда, если запрос передается с использованием подтверждаемого сообщения (CON), то сервер отправляет обратно клиенту сообщение подтверждения, содержащее ответ или код ошибки:

Здесь токен отличается от идентификатора сообщения и используется для сопоставления запроса и ответа.

  • Если сервер не может ответить на запрос, то сервер отправляет подтверждение с пустым ответом. Как только ответ доступен, сервер отправляет клиенту новое сообщение Confirmable, содержащее ответ. На этом этапе клиент отправляет обратно сообщение с подтверждением:

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

Сообщение состоит из нескольких частей:

Где:

Версия : Это 2-битовое целое число без знака, указывающее версию

T : 2-битное целое число без знака, указывающее тип сообщения: 0 подтверждаемое , 1 неподтвержденный

TKL : Длина маркера — это 4-битная длина маркера

Код : это ответ кода (длина 8 бит)

Идентификатор сообщения : Это идентификатор сообщения, выраженный с помощью 16 bit

node-coap — это клиентская и серверная библиотека для CoAP, смоделированная на основе модуля http .

Эта библиотека следующая:

Он не анализирует протокол, но вместо этого использует CoAP-пакет.

Если вам нужен интерфейс командной строки для CoAP, проверьте coap-cli.

node-coap — это проект с открытым исходным кодом OPEN , см. Раздел «Содействие», чтобы узнать, что это означает.

$ npm install coap --save

Базовый пример

В следующем примере открывается UDP-сервер и отправляется ему сообщение CoAP:

 var coap = require ('coap') 
, server = coap.createServer () 
 server.on ('запрос', функция (req, res) {
 res.end ('Hello' + req.url.split ('/') [1] + '\ n') 
}) 
 // порт CoAP по умолчанию - 5683 
 server.listen (function () {
 var req = coap.request ('coap: // localhost / Matteo') 
 req.on ('response', function (res) { 
 res.pipe (process.stdout) 
 res.on ('end', function () {
 process.exit (0) 
}) 
}) 
 req.end () 
})

Как сделать Использование — Посетите https: // www.npmjs.com/package/coap

CoAP Протокол достаточно прост для реализации с нуля для простого приложения. Для приложений, где это нежелательно, становятся доступными общие реализации для множества платформ. Многие из этих реализаций остаются частными, но некоторые из них публикуются с либеральными лицензиями с открытым исходным кодом, такими как Apache 2.0 или лицензия MIT.

Посетите — http://coap.technology/impls.html

И MQTT, и CoAP:

  • Являются открытыми стандартами
  • Лучше подходят для ограниченных сред, чем HTTP
  • Обеспечивают механизмы для асинхронной связи
  • Работают на IP
  • Имеют ряд реализаций

В следующей таблице сравниваются различные функции COAP и MQTT и приводится разница между CoAP и протоколы MQTT.

Функции CoAP MQTT Полноформатный протокол приложения с ограничениями Очередь сообщений Телеметрия Транспортная модель, используемая для связи Запрос-ответ, публикация-подписка Опубликовать-подписка RESTful Да Нет Транспортный уровень Предпочтительно также можно использовать UDP, TCP. Предпочтительно TCP, также можно использовать UDP (MQTT-S). Размер заголовка 4 байта 2 байта Количество используемых типов сообщений 4 16 Обмен сообщениями Асинхронный и синхронный Асинхронный Надежность приложений 2 уровня 3 уровня безопасности IPSEC или DTLS Не определено в стандартных посредниках ДА ДА (MQTT-S) Пригодность LLN (тыс. Узлов) Отличное честное приложение истории успеха Utility Field Area Network Расширение корпоративных сообщений до приложений IoT

MQTT и CoAP полезны в качестве протоколов IoT, но имеют фундаментальные различия.

MQTT — это протокол связи «многие ко многим» для передачи сообщений между несколькими клиентами через центрального брокера. Он разделяет производителя и потребителя, позволяя клиентам публиковать сообщения, а брокер решает, куда направлять и копировать сообщения. Хотя MQTT имеет некоторую поддержку постоянства, он лучше всего работает в качестве коммуникационной шины для данных в реальном времени.

CoAP — это, прежде всего, протокол «один-к-одному» для передачи информации о состоянии между клиентом и сервером. Хотя он поддерживает наблюдение за ресурсами, CoAP лучше всего подходит для модели передачи состояния, а не исключительно на основе событий.

MQTT-клиенты устанавливают долговременное исходящее TCP-соединение с брокером. Обычно это не представляет проблемы для устройств за NAT. Клиенты и серверы CoAP отправляют и получают пакеты UDP. В среде NAT можно использовать туннелирование или переадресацию портов, чтобы разрешить CoAP, или устройства могут сначала инициировать соединение с головным узлом, как в LWM2M.

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

У обоих протоколов есть свои плюсы и минусы, выбор правильного зависит от вашего приложения.

Рекомендовано:

Надеюсь, вам понравится этот пост. Есть вопросы? Оставьте комментарий ниже!

CoAP — протокол ограниченного приложения

Модель REST для небольших устройств

Как и HTTP, CoAP основан на чрезвычайно успешной модели REST: Серверы делают ресурсы доступными по URL-адресу, а клиенты получают доступ к этим ресурсам с помощью таких методов, как GET, PUT, POST и DELETE.

Передача существующих навыков

С точки зрения разработчика, CoAP очень похож на HTTP. Получение значения от датчика мало чем отличается от получения значения из веб-API.

Готов к интеграции

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

Выберите свою модель данных

Как и HTTP, CoAP может нести различные типы полезной нагрузки и может определять, какой тип полезной нагрузки используется.CoAP интегрируется с XML, JSON, CBOR, или любой формат данных по вашему выбору.

Сделано для миллиардов узлов

Интернету вещей потребуются миллиарды узлов, многие из которых должны быть недорогими. CoAP был разработан для работы с микроконтроллерами с объемом оперативной памяти всего 10 КБ и пространством кода 100 КБ (RFC 7228).

Контролируйте отходы

CoAP предназначен для использования минимальных ресурсов как на устройстве, так и в сети.Вместо сложного транспортного стека он использует UDP на IP. Фиксированный 4-байтовый заголовок и компактное кодирование опций позволяют небольшие сообщения, которые не вызывают или вызывают небольшую фрагментацию ссылки слой. Многие серверы могут работать полностью без сохранения состояния.

Интегрированное открытие

Каталог ресурсов CoAP предоставляет способ обнаружить свойства узлов в вашей сети.

Хорошо разработанный протокол

CoAP был разработан как документ стандартов Интернета, RFC 7252. Протокол рассчитан на десятилетия. Не решены такие сложные вопросы, как контроль перегрузки под ковриком, но были решены с использованием современного уровня техники.

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

Интернет вещей не может распространяться до тех пор, пока хакеры могут использовать его по своей воле.CoAP не только на словах говорит о безопасности, но и обеспечивает надежную защиту. Выбор параметров DTLS по умолчанию для CoAP эквивалентен 3072-битные ключи RSA, но все же отлично работают на самых маленьких узлах.

CoAP (протокол ограниченного приложения) по TCP, TLS и WebSockets

CoAP (протокол ограниченного приложения) по TCP, TLS и WebSockets

CoAP (протокол ограниченного приложения) через TCP, TLS и WebSockets
draft-ietf-core-coap-tcp-tls-latest

Протокол ограниченного приложения (CoAP), хотя и вдохновлен HTTP, был разработан для использования UDP вместо TCP.Уровень сообщений протокола CoAP over UDP включает поддержку надежной доставки, простое управление перегрузкой и управление потоком.

Некоторые среды выигрывают от доступности CoAP, передаваемого через надежные транспортные средства, такие как TCP или TLS. В этом документе описаны изменения, необходимые для использования транспорта CoAP через TCP, TLS и WebSockets. Он также официально обновляет RFC 7641 для использования с этими транспортами и RFC 7959, чтобы разрешить использование более крупных сообщений через надежный транспорт.

Этот Интернет-проект представлен в полном соответствии с положениями BCP 78 и BCP 79.

Internet-Drafts — это рабочие документы Инженерной группы Интернета (IETF). Обратите внимание, что другие группы также могут распространять рабочие документы как Интернет-проекты. Список текущих Интернет-проектов находится на https://datatracker.ietf.org/drafts/current/.

Internet-Draught — это черновики документов, срок действия которых не превышает шести месяцев, и они могут быть обновлены, заменены или отменены другими документами в любое время. Неуместно использовать Интернет-черновики в качестве справочного материала или цитировать их иначе, как «незавершенную работу».«

Срок действия этого Интернет-проекта истекает 21 июня 2018 г.

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

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

Ограниченный протокол приложений (CoAP) был разработан для развертываний Интернета вещей (IoT), предполагая, что UDP [RFC0768] может использоваться беспрепятственно, как и протокол безопасности транспортного уровня дейтаграмм (DTLS [RFC6347]) через UDP. Использование CoAP поверх UDP нацелено на простоту, имеет небольшой объем кода и небольшой размер передаваемых по сети сообщений.

Основная причина внедрения CoAP поверх TCP [RFC0793] и TLS [RFC5246] заключается в том, что некоторые сети не пересылают пакеты UDP. Согласно [EK2016], полная блокировка UDP происходит примерно в 2–4% наземных сетей доступа. Ухудшение UDP особенно сосредоточено в корпоративных сетях и сетях в географических регионах с другими проблемами подключения. Некоторые сети также ограничивают скорость UDP-трафика, как сообщается в [BK2015], а исследования развертывания, связанные со стандартизацией QUIC, показали, что числа около 0.3% [SW2016].

Внедрение CoAP поверх TCP также приводит к некоторым дополнительным эффектам, которые могут быть желательны в конкретном развертывании:

  • Там, где NAT присутствуют на пути связи, CoAP через TCP приводит к другому поведению обхода NAT, чем CoAP через UDP. NAT часто рассчитывает таймеры истечения срока действия на основе протокола транспортного уровня, используемого протоколами приложений. Многие NAT поддерживают привязки NAT на основе TCP в течение более длительных периодов времени, исходя из предположения, что протокол транспортного уровня, такой как TCP, предлагает дополнительную информацию о жизненном цикле сеанса.UDP, с другой стороны, не предоставляет такую ​​информацию NAT, и таймауты обычно намного короче [HomeGateway]. Согласно [HomeGateway] среднее время ожидания привязки TCP и UDP к NAT составляет 386 минут (TCP) и 160 секунд (UDP). Более короткие значения тайм-аута требуют более частой отправки сообщений поддержки активности. Следовательно, использование CoAP поверх TCP требует менее частой передачи сообщений проверки активности.
  • TCP использует более сложные механизмы управления перегрузкой и потоком, чем механизмы по умолчанию, предоставляемые CoAP через UDP, что полезно для передачи больших объемов данных.(Однако продолжается работа по добавлению расширенного контроля перегрузки в CoAP через UDP, см. [I-D.ietf-core-cocoa].)

Обратите внимание, что использование CoAP через UDP (и CoAP через DTLS через UDP) по-прежнему является рекомендуемым транспортом для использования в сетях с ограниченными узлами, особенно при использовании совместно с поблочной передачей. CoAP через TCP применим в тех случаях, когда сетевая инфраструктура не оставляет другого выбора. Использование CoAP поверх TCP приводит к большему размеру кода, большему количеству циклов обмена, повышенным требованиям к оперативной памяти и большим размерам пакетов.Разработчикам, реализующим CoAP через TCP, рекомендуется обратиться к [I-D.gomez-lwig-tcp-constrained-node-networks] для получения рекомендаций по реализации TCP с малым объемом памяти для устройств IoT.

Стандарты

, основанные на CoAP, такие как Lightweight Machine to Machine [LWM2M], в настоящее время используют CoAP поверх UDP в качестве транспорта; добавление поддержки CoAP через TCP позволяет им решать указанные выше проблемы для конкретных развертываний и защищать инвестиции в существующие реализации и развертывания CoAP.

Хотя HTTP / 2 также потенциально может удовлетворить потребность в обходе корпоративного межсетевого экрана, такой переход с CoAP на HTTP / 2 приведет к дополнительным затратам и задержкам.В настоящее время также доступно меньше реализаций HTTP / 2 для устройств с ограничениями по сравнению с CoAP. Поскольку CoAP также поддерживает групповую связь с использованием многоадресной рассылки на уровне IP и ненадежной связи, устройства IoT должны будут поддерживать HTTP / 2 в дополнение к CoAP.

Кроме того, CoAP может быть интегрирован в веб-среду, где внешний интерфейс использует CoAP через UDP от устройств IoT к облачной инфраструктуре, а затем CoAP через TCP между внутренними службами. Шлюз TCP-UDP можно использовать на границе облака для связи с устройством IoT на основе UDP.

Наконец, приложения CoAP, работающие в веб-браузере, могут не иметь доступа к другим соединениям, кроме HTTP. В этом случае протокол WebSocket [RFC6455] может использоваться для передачи запросов и ответов CoAP, в отличие от их перекрестного проксирования через HTTP на перекрестный прокси HTTP-CoAP. Это сохраняет функциональность CoAP без трансляции, в частности, механизм Observe [RFC7641].

Чтобы удовлетворить вышеупомянутые требования к развертыванию, этот документ определяет, как транспортировать CoAP через TCP, CoAP через TLS и CoAP через WebSockets.В этих случаях надежность, предлагаемая транспортным протоколом, включает функции надежности уровня сообщений, используемых для CoAP через UDP. (Обратите внимание, что как для надежного транспорта, так и для уровня сообщений CoAP через UDP, надежность предлагается для каждого транспортного узла: если задействованы прокси-серверы — см. Разделы 5.7 и 10 [RFC7252], функция надежности этого уровня не распространяется от конца до конца. -end.) Рисунок 1 иллюстрирует наслоение:

  + -------------------------------- +
  | Приложение |
  + -------------------------------- +
  + -------------------------------- +
  | Запросы / Ответы / Сигнализация | CoAP (RFC 7252) / этот документ
  | -------------------------------- |
  | Обрамление сообщений | Этот документ
  + -------------------------------- +
  | Надежный транспорт |
  + -------------------------------- +

Рисунок 1: Уровни CoAP по надежным транспортным средствам

Этот документ определяет, как получить доступ к ресурсам с помощью запросов и ответов CoAP по протоколам TCP, TLS и WebSocket.Это позволяет приложениям с ограниченным соединением получать сквозное соединение CoAP либо путем прямого обмена данными CoAP с сервером CoAP, доступным через соединение TCP, TLS или WebSocket, либо через посредника CoAP, который передает запросы и ответы CoAP между различными транспортными потоками, такими как между WebSockets и UDP.

В разделе 7

обновлена ​​спецификация «Наблюдение за ресурсами в протоколе ограниченного приложения» для использования с CoAP через надежные транспорты. [RFC7641] — это расширение протокола CoAP, которое позволяет клиентам CoAP «наблюдать» за ресурсом на сервере CoAP.(Клиент CoAP извлекает представление ресурса и регистрируется, чтобы получать уведомление от сервера CoAP, когда представление обновляется.)

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ОБЯЗАТЕЛЬНО», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «МОЖЕТ» НЕОБЯЗАТЕЛЬНО »в этом документе следует интерпретировать, как описано в [RFC2119].

В этом документе предполагается, что читатели знакомы с терминами и концепциями, которые используются в [RFC6455], [RFC7252], [RFC7641] и [RFC7959].

Термин «надежный транспорт» используется только для обозначения транспортных протоколов, таких как TCP, которые обеспечивают надежную и упорядоченную доставку потока байтов.

Блочное расширение для надежной транспортировки (BERT):

BERT расширяет [RFC7959], позволяя использовать более крупные сообщения через надежный транспорт.
BERT Опция:

Опция Block1 или Block2, включающая значение SZX, равное 7.
Блок BERT:

Полезная нагрузка сообщения CoAP, на которое влияет опция BERT при описательном использовании (см. Раздел 2.1 из [RFC7959]).
Транспортное соединение:

Базовое надежное соединение с потоком байтов, напрямую предоставляемое TCP или косвенно через TLS или WebSockets.
Подключение:

Транспортное соединение, если явно не указано иное.
Инициатор подключения:

Одноранговый узел, открывающий транспортное соединение, т. Е. Активное средство открытия TCP, клиент TLS или клиент WebSocket.
Приемник подключения:

Одноранговый узел, который принимает транспортное соединение, открытое другим одноранговым узлом, т.е.е., пассивное средство открытия TCP, сервер TLS или сервер WebSocket.

Модель взаимодействия запрос / ответ CoAP через TCP такая же, как CoAP через UDP. Основные отличия заключаются в уровне сообщений. Уровень сообщений CoAP over UDP поддерживает дополнительную надежность, определяя четыре типа сообщений: подтверждаемые, неподтвержденные, подтверждение и сброс. Кроме того, сообщения включают идентификатор сообщения, чтобы связать подтверждения с подтверждаемыми сообщениями и обнаружить повторяющиеся сообщения.

Управление транспортными соединениями оставлено на усмотрение приложения, т. Е. Настоящая спецификация не описывает, как приложение решает открыть соединение или повторно открыть другое при наличии сбоев (или того, что оно сочло бы ошибочным). отказ, см. также раздел 5.4). В частности, инициатор соединения не обязательно должен быть клиентом первого запроса, размещенного в соединении. Некоторые реализации могут захотеть реализовать динамическое управление подключением, подобное тому, которое описано в разделе 6 [RFC7230] для HTTP, открывая соединение, когда первый клиентский запрос готов к отправке, и повторно использовать его для дальнейших сообщений на некоторое время, пока не будет сообщение отправляется в течение определенного времени, и нет ожидающих запросов (возможно, с настраиваемым временем простоя), и запускается процесс выпуска (раздел 5.5). В реализациях этого типа освобождение или прерывание соединения могут не указываться приложению как ошибки, а могут быть просто обработаны автоматическим переподключением, когда необходимость снова возникает. Другие реализации могут быть основаны на сконфигурированных соединениях, которые постоянно остаются открытыми и приводят к уведомлениям системы управления о выпуске или прерывании. Протокол, определенный в настоящей спецификации, предназначен для работы с любой моделью (или другими моделями управления соединением для конкретных приложений).

Концептуально CoAP через TCP заменяет большую часть уровня сообщений CoAP через UDP механизмом кадрирования поверх байтового потока, предоставляемого TCP / TLS, передавая информацию о длине для каждого сообщения, которое на транспорте дейтаграмм предоставляется UDP / Слой дейтаграммы DTLS.

TCP обеспечивает надежную передачу сообщений, поэтому уровень сообщений CoAP поверх TCP не требуется для поддержки подтверждений или обнаружения повторяющихся сообщений. В результате поля «Тип» и «Идентификатор сообщения» больше не требуются и удаляются из формата сообщения CoAP over TCP.

Рисунок 2 иллюстрирует разницу между CoAP по UDP и CoAP по надежному транспорту. Удаленные поля Тип и Идентификатор сообщения обозначены тире.

CoAP-клиент CoAP-сервер CoAP-клиент CoAP-сервер
    | | | |
    | ВЫН [0xbc90] | | (-------) [------] |
    | GET / температура | | GET / температура |
    | (Токен 0x71) | | (Токен 0x71) |
    + -------------------> | + -------------------> |
    | | | |
    | ACK [0xbc90] | | (-------) [------] |
    | 2.05 Содержание | | 2.05 Содержание |
    | (Токен 0x71) | | (Токен 0x71) |
    | «22,5 C» | | «22,5 C» |
    | <------------------- + | <------------------- +
    | | | |

        CoAP через UDP CoAP через надежный
                                         транспорт

Рисунок 2: Сравнение CoAP с ненадежным и надежным транспортом

Формат сообщения CoAP, определенный в [RFC7252], как показано на рисунке 3, основан на передаче дейтаграмм (UDP или DTLS поверх UDP) для разделения отдельных сообщений и предоставления информации о длине.

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Ver | Т | ТКЛ | Код | ID сообщения |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Токен (если есть, байты TKL) ...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Варианты (если есть) ...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 1 1 1 1 1 1 1 1 | Полезная нагрузка (если есть)...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Рисунок 3: RFC 7252 определил формат сообщения CoAP

Формат сообщения CoAP через TCP очень похож на формат, указанный для CoAP через UDP. Отличия заключаются в следующем:

  • Поскольку базовое TCP-соединение обеспечивает повторную передачу и дедупликацию, нет необходимости в механизмах надежности, обеспечиваемых CoAP через UDP. Поля Тип (T) и Идентификатор сообщения в заголовке сообщения CoAP опускаются.
  • Поле Версия (Версия) также опускается. В отличие от формата сообщения CoAP через UDP, формат сообщения для CoAP через TCP не включает номер версии. CoAP определен в [RFC7252] с номером версии 1. В настоящее время нет известной причины для поддержки номеров версий, отличных от 1. Если согласование версии необходимо решить в будущем, тогда сообщения о возможностях и настройках (см. CSM Раздел 5.3) были специально разработаны для включения такой потенциальной функции.
  • В потоковом транспортном протоколе, таком как TCP, необходима форма разграничения сообщений. Для этой цели CoAP over TCP вводит поле длины с переменным размером. На рисунке 4 показан скорректированный формат сообщения CoAP с измененной структурой для фиксированного заголовка (первые 4 байта CoAP поверх заголовка UDP), который включает информацию о длине переменного размера.
 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Лен | ТКЛ | Увеличенная длина (если есть, по выбору Лена)...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Код | Токен (если есть, байты TKL) ...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Варианты (если есть) ...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 1 1 1 1 1 1 1 1 | Полезная нагрузка (если есть) ...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Рисунок 4: Рама CoAP для надежной транспортировки

Длина (л.):
4-битовое целое число без знака.Значение от 0 до 12 включительно указывает длину сообщения в байтах, начиная с первого бита поля Параметры. Для специальных конструкций зарезервированы три значения:
13:
8-битовое целое число без знака (расширенная длина) следует за начальным байтом и указывает длину опций / полезной нагрузки минус 13.
14:
16-битовое целое число без знака (расширенная длина) в сетевом порядке байтов следует за начальным байтом и указывает длину опций / полезной нагрузки минус 269.
15:
32-битное целое число без знака (расширенная длина) в сетевом порядке байтов следует за начальным байтом и указывает длину опций / полезной нагрузки минус 65805.

Кодирование поля "Длина" моделируется после поля "Длина параметра" в параметрах CoAP (см. Раздел 3.1 [RFC7252]).

Для простоты маркер полезной нагрузки (0xFF) показан на рисунке 4; Маркер полезной нагрузки указывает начало необязательной полезной нагрузки и отсутствует для полезной нагрузки нулевой длины (см. раздел 3 [RFC7252]).(Если он присутствует, маркер полезной нагрузки включается в длину сообщения, которая отсчитывается от начала поля «Параметры» до конца поля «Полезная нагрузка».)

Например: сообщение CoAP, содержащее только код 2.03 с токеном 7f и без параметров или полезной нагрузки, кодируется, как показано на рисунке 5.

 0 1 2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 0x01 | 0x43 | 0x7f |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

 Len = 0 ------> 0x01
 ТКЛ = 1 ___ /
 Код = 2.03 -> 0x43
 Токен = 0x7f

Рисунок 5: Сообщение CoAP без параметров или полезной нагрузки

Семантика других полей заголовка CoAP остается неизменной.

После установления транспортного соединения каждая конечная точка ДОЛЖНА отправить сообщение о возможностях и настройках (CSM, см. Раздел 5.3) в качестве своего первого сообщения в соединении. В этом сообщении устанавливаются начальные настройки и возможности конечной точки, такие как максимальный размер сообщения или поддержка поблочных передач.Отсутствие опций в CSM указывает на то, что базовые значения предполагаются.

Чтобы избежать взаимоблокировки, Инициатор соединения НЕ ДОЛЖЕН ждать, пока приемник соединения отправит свое начальное сообщение CSM, прежде чем отправлять свое собственное начальное сообщение CSM. И наоборот, приемник соединения МОЖЕТ дождаться, пока инициатор соединения отправит свое начальное сообщение CSM, прежде чем отправлять свое собственное начальное сообщение CSM.

Чтобы избежать ненужной задержки, инициатор соединения МОЖЕТ отправлять дополнительные сообщения после своего первоначального CSM, не дожидаясь получения CSM принимающего соединения; однако важно отметить, что CSM получателя соединения может указывать возможности, которые влияют на то, как инициатор должен взаимодействовать с принимающим устройством.Например, принимающий CSM может указать параметр максимального размера сообщения (см. Раздел 5.3.1), который меньше базового значения (1152), чтобы ограничить как требования к буферизации, так и блокировку заголовка строки.

Конечные точки ДОЛЖНЫ обрабатывать отсутствующий или недопустимый CSM как ошибку соединения и прерывать соединение (см. Раздел 5.6).

Обмен запросами и ответами

CoAP осуществляется асинхронно по транспортному соединению. Клиент CoAP может отправлять несколько запросов, не дожидаясь ответа, а сервер CoAP может возвращать ответы в любом порядке.Ответы ДОЛЖНЫ быть возвращены через то же соединение, что и исходный запрос. Параллельные запросы различаются по их токену, который привязан к локальному соединению.

Транспортное соединение является двунаправленным, поэтому запросы могут отправляться как объектом, установившим соединение (инициатор соединения), так и удаленным хостом (приемником соединения). Если на одной стороне не реализован сервер CoAP, ДОЛЖЕН быть возвращен ответ об ошибке для всех запросов CoAP с другой стороны.Самый простой подход - всегда возвращать 5.01 (не реализовано). Более сложный фиктивный сервер также может возвращать ответы 4.xx, например, 4.04 (не найдено) или 4.02 (плохой вариант), где это необходимо.

Повторная передача и дедупликация сообщений обеспечивается протоколом TCP.

Пустые сообщения (код 0.00) всегда могут быть отправлены и ДОЛЖНЫ быть проигнорированы получателем. Это обеспечивает базовую функцию проверки активности, которая может обновлять привязки NAT.

Если клиент CoAP не получает никакого ответа в течение некоторого времени после отправки запроса CoAP (или, аналогично, когда клиент наблюдает за ресурсом и не получает никаких уведомлений в течение некоторого времени), он может отправить сообщение CoAP Ping Signaling ( см. раздел 5.4), чтобы протестировать транспортное соединение и убедиться, что сервер CoAP отвечает.

Когда базовое транспортное соединение закрывается или сбрасывается, состояние сигнализации и любое состояние наблюдения (см. Раздел 7.4), связанное с соединением, удаляется. В полете сообщения могут быть потеряны, а могут и нет.

CoAP через WebSockets намеренно похож на CoAP через TCP; поэтому в этом разделе указываются только различия между транспортами.

CoAP через WebSockets можно использовать в различных конфигурациях.Самая простая конфигурация - это получение или обновление клиентом CoAP ресурса CoAP, расположенного на сервере CoAP, который предоставляет конечную точку WebSocket (см. Рисунок 6). Клиент CoAP действует как клиент WebSocket, устанавливает соединение WebSocket и отправляет запрос CoAP, на который сервер CoAP возвращает ответ CoAP. Соединение WebSocket можно использовать для любого количества запросов.

 ___________ ___________
| | | |
| _ | ___ запросы ___ | _ |
| CoAP / \ \ -------------> / / \ CoAP |
| Клиент \ __ / __ / <------------- \ __ \ __ / Сервер |
| | ответы | |
| ___________ | | ___________ |
        WebSocket =============> WebSocket
          Сервер клиентских подключений

Рисунок 6. Клиент CoAP (клиент WebSocket) обращается к серверу CoAP (сервер WebSocket)

Проблема с этой конфигурацией заключается в том, как идентифицировать ресурс в пространстве имен сервера CoAP.Когда протокол WebSocket используется выделенным клиентом напрямую (т. Е. Не с веб-страницы через веб-браузер), клиент может подключиться к любой конечной точке WebSocket. Раздел 8.3 и Раздел 8.4 определяют новые схемы URI, которые позволяют клиенту идентифицировать как конечную точку WebSocket, так и путь и запрос ресурса CoAP в этой конечной точке.

Другая возможная конфигурация - установить прокси-сервер пересылки CoAP в конечной точке WebSocket. В зависимости от того, какие транспорты доступны прокси-серверу, он может перенаправить запрос на сервер CoAP с конечной точкой CoAP UDP (рисунок 7), конечной точкой SMS (a.к.а. мобильный телефон) или даже другую конечную точку WebSocket. Клиент CoAP указывает ресурс, который должен быть обновлен или получен в опции Proxy-Uri.

 ___________ ___________ ___________
| | | | | |
| _ | ___ ___ | _ _ | ___ ___ | _ |
| CoAP / \ \ ---> / / \ CoAP / \ \ ---> / / \ CoAP |
| Клиент \ __ / __ / <--- \ __ \ __ / Прокси \ __ / __ / <--- \ __ \ __ / Сервер |
| | | | | |
| ___________ | | ___________ | | ___________ |
        WebSocket ===> WebSocket UDP UDP
          Клиент Сервер Клиент Сервер

Рисунок 7. Клиент CoAP (клиент WebSocket) обращается к серверу CoAP (серверу UDP) через прокси CoAP (сервер WebSocket / клиент UDP)

Третья возможная конфигурация - это сервер CoAP, работающий внутри веб-браузера (рисунок 8).Веб-браузер сначала подключается к конечной точке WebSocket, а затем становится доступным через сервер WebSocket. Когда соединение отсутствует, сервер CoAP недоступен. Поскольку сервер WebSocket - единственный способ связаться с сервером CoAP, прокси-сервер CoAP должен быть обратным прокси-сервером.

 ___________ ___________ ___________
| | | | | |
| _ | ___ ___ | _ _ | ___ ___ | _ |
| CoAP / \ \ ---> / / \ CoAP / / \ ---> / \ \ CoAP |
| Клиент \ __ / __ / <--- \ __ \ __ / Прокси \ __ \ __ / <--- \ __ / __ / Сервер |
| | | | | |
| ___________ | | ___________ | | ___________ |
           UDP UDP WebSocket <=== WebSocket
         Клиент Сервер Сервер Клиент

Рисунок 8: Клиент CoAP (клиент UDP) обращается к серверу CoAP (клиент WebSocket) через прокси CoAP (сервер UDP / сервер WebSocket)

Возможны и другие конфигурации, в том числе те, в которых соединение WebSocket устанавливается через прокси-сервер HTTP.

Перед обменом запросами и ответами CoAP устанавливается соединение WebSocket, как определено в разделе 4 [RFC6455]. На рисунке 9 показан пример.

Клиент WebSocket ДОЛЖЕН включить имя подпротокола «coap» в список протоколов, что указывает на поддержку протокола, определенного в этом документе.

Клиент WebSocket включает имя хоста сервера WebSocket в поле заголовка Host своего рукопожатия согласно [RFC6455]. Поле заголовка Host также указывает значение по умолчанию для параметра Uri-Host в запросах от клиента WebSocket к серверу WebSocket.

ПОЛУЧИТЬ /.well-known/coap HTTP / 1.1
Хост: example.org
Обновление: websocket
Подключение: Обновление
Sec-WebSocket-ключ: dGhlIHNhbXBsZSBub25jZQ ==
Sec-WebSocket-Протокол: coap
Sec-WebSocket-Версия: 13

HTTP / 1.1 101 Протоколы переключения
Обновление: websocket
Подключение: Обновление
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK + xOo =
Sec-WebSocket-Протокол: coap

Рисунок 9: Пример начального рукопожатия

Как только соединение WebSocket установлено, запросы и ответы CoAP можно обмениваться как сообщениями WebSocket.Поскольку CoAP использует двоичный формат сообщения, сообщения передаются в двоичных кадрах данных, как указано в разделах 5 и 6 [RFC6455].

Формат сообщения, показанный на рисунке 10, такой же, как формат сообщения CoAP через TCP (см. Раздел 3.2) с одним изменением. Поле Length (Len) ДОЛЖНО быть установлено в ноль, потому что фрейм WebSockets содержит длину.

  0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Len = 0 | ТКЛ | Код | Токен (байты TKL)...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Варианты (если есть) ...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 1 1 1 1 1 1 1 1 | Полезная нагрузка (если есть) ...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Рисунок 10: Формат сообщения CoAP через WebSockets

Как и в случае с CoAP через TCP, формат сообщения для CoAP через WebSockets исключает поле версии, определенное в CoAP через UDP. Если в будущем потребуется согласование версии CoAP, CoAP через WebSockets может удовлетворить это требование путем определения нового идентификатора подпротокола, который согласовывается во время открывающего рукопожатия.

Запросы и ответные сообщения могут быть фрагментированы, как указано в разделе 5.4 [RFC6455], хотя обычно они отправляются нефрагментированными, поскольку они имеют тенденцию быть небольшими и полностью буферизоваться перед передачей. Протокол WebSocket не предоставляет средств для мультиплексирования. Если нежелательно, чтобы большое сообщение монополизировало соединение, запросы и ответы могут передаваться по блокам, как определено в [RFC7959].

Как и в случае с CoAP через TCP, каждая конечная точка ДОЛЖНА отправить сообщение о возможностях и настройках (CSM см.3) в качестве их первого сообщения при соединении WebSocket.

Обмен запросами и ответами

CoAP осуществляется асинхронно через соединение WebSocket. Клиент CoAP может отправлять несколько запросов, не дожидаясь ответа, а сервер CoAP может возвращать ответы в любом порядке. Ответы ДОЛЖНЫ быть возвращены через то же соединение, что и исходный запрос. Параллельные запросы различаются по их токену, который привязан к локальному соединению.

Соединение является двунаправленным, поэтому запросы могут отправляться как объектом, установившим соединение, так и удаленным хостом.

Как и в случае с CoAP через TCP, повторная передача и дедупликация сообщений обеспечивается протоколом WebSocket. Таким образом, CoAP через WebSockets не делает различий между подтверждаемыми и неподтверждаемыми сообщениями и не предоставляет сообщения подтверждения или сброса.

Как и в случае с CoAP через TCP, клиент CoAP может проверить работоспособность CoAP через соединение WebSocket, отправив сообщение CoAP Ping Signaling (раздел 5.4). WebSocket Ping и нежелательные фреймы Pong (Раздел 5.5 [RFC6455]) НЕ СЛЕДУЕТ использовать для предотвращения передачи избыточного трафика обслуживания.

Сигнальные сообщения

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

  • Изучите связанные характеристики, такие как максимальный размер сообщения для соединения
  • Отключите соединение в установленном порядке
  • Предоставляет диагностическую информацию при разрыве соединения в ответ на состояние серьезной ошибки

Сигнализация - это третий основной вид сообщений в CoAP после запросов и ответов.Сообщения сигнализации имеют общую структуру с существующими сообщениями CoAP. Есть код, токен, параметры и дополнительная полезная нагрузка.

(См. Раздел 3 [RFC7252] для полной структуры формата сообщения, формата опции и формата значения опции.)

Код в диапазоне 7.00-7.31 указывает на сигнальное сообщение. Значения в этом диапазоне назначаются подрегистром «Сигнальные коды CoAP» (см. Раздел 11.1).

Для каждого сообщения есть отправитель и партнер, получающие сообщение.

Полезные данные

в сообщениях сигнализации - это полезные данные диагностики, как определено в разделе 5.5.2 [RFC7252]), если иное не определено опцией сообщения сигнализации.

Номера опций для сигнальных сообщений зависят от кода сообщения. Они не разделяют пространство номеров с опциями CoAP для сообщений запроса / ответа или с сообщениями сигнализации, использующими другие коды.

Номера опций

назначаются суб-реестром «Номера опций сигнализации CoAP» (см. Раздел 11.2).

Опции сигнализации являются факультативными или критическими, как определено в Разделе 5.4.1 [RFC7252]. Если опция сигнализации критична и не понятна получателю, она ДОЛЖНА прервать соединение (см. Раздел 5.6). Если опция понятна, но не может быть обработана, опция документирует поведение.

Сообщения о возможностях и настройках

(CSM) используются для двух целей:

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

Один CSM ДОЛЖЕН быть отправлен каждой конечной точкой в ​​начале транспортного соединения.Дальнейший CSM МОЖЕТ быть отправлен в любое другое время любой конечной точкой в ​​течение срока службы соединения.

Возможности и параметры настройки суммируются. CSM не делает недействительным ранее отправленное указание или настройку возможностей, даже если они не повторяются. Сообщение о возможности без какой-либо опции - это не операция (и может использоваться как таковая). Отправленный параметр может переопределить предыдущее значение для того же параметра. Опция определяет, как поступить в этом случае, если это необходимо.

Базовые значения для параметров CSM перечислены ниже.Это значения возможностей и настроек до того, как какие-либо сообщения о возможностях и настройках отправят измененное значение.

Это не значения по умолчанию для опции, как определено в разделе 5.4.4 в [RFC7252]. Значения по умолчанию применяются для каждого сообщения и, таким образом, сбрасываются, если значение отсутствует в данном сообщении о возможностях и настройках.

Сообщения о возможностях и настройках

обозначаются кодом 7.01 (CSM).

Отправитель может использовать выборочную опцию Max-Message-Size, чтобы указать максимальный размер сообщения в байтах, которое он может получить.Указанный размер сообщения включает все сообщение, начиная с первого байта заголовка сообщения и заканчивая концом полезной нагрузки сообщения.

(Обратите внимание, что нет никакой связи размера сообщения с общим размером тела запроса или ответа, которое может быть достигнуто при поблочной передаче. Например, обмен, изображенный ниже на рисунке 13, может быть выполнен, если клиент CoAP указывает значение около 6000 байт для параметра Max-Message-Size, даже несмотря на то, что общий размер тела, передаваемого клиенту, составляет 3072 + 5120 + 4711 = 12903 байта.)

C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
2 CSM Максимальный размер сообщения uint 0-4 1152

Согласно разделу 4.6 [RFC7252], базовое значение (и значение, используемое, когда эта опция не реализована) составляет 1152.

Активное значение параметра «Максимальный размер сообщения» заменяется каждый раз, когда параметр отправляется с измененным значением. Его начальное значение - это его базовое значение.

C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
4 CSM Блок-мудрая передача пустой 0 (нет)

Отправитель может использовать опцию выборочной блочной передачи, чтобы указать, что он поддерживает протокол поблочной передачи [RFC7959].

Если опция не указана, одноранговый узел не имеет информации о том, поддерживается ли блочная передача отправителем или нет. Реализация, желающая предложить своему партнеру блочную передачу, поэтому должна указать вариант блочной-мудрой-передачи.

Если опция максимального размера сообщения указана со значением, превышающим 1152 (в том же или другом сообщении CSM), опция Block-Wise-Transfer также указывает на поддержку BERT (см. Раздел 6). Впоследствии, если параметр максимального размера сообщения указан со значением, равным или меньшим 1152, поддержка BERT больше не указывается.(Обратите внимание, что указание на поддержку BERT не обязывает ни один из партнеров фактически выбрать использование BERT.)

Примечание по реализации: при указании значения параметра Max-Message-Size с намерением включить BERT, указывающая реализация может захотеть выбрать сообщение размера BERT, которое она хочет поощрять, и добавить дельту для заголовка и любых параметров, которые также должны быть включены в сообщение. Раздел 4.6 [RFC7252] добавляет 128 байтов к максимальному размеру блока 1024, чтобы получить размер сообщения по умолчанию, равный 1152.Реализация с поддержкой BERT может захотеть указать размер блока BERT 2048 или больше, кратное 1024, и в то же время быть более щедрым для размера заголовка и добавленных опций (скажем, 256 или 512). Однако добавление 1024 или более к базовому размеру блока BERT может побудить одноранговую реализацию изменять размер блока BERT в зависимости от размера включенных опций, что может быть труднее установить для взаимодействия.

В CoAP через надежные транспорты пустые сообщения (код 0.00) всегда могут быть отправлены и ДОЛЖНЫ быть проигнорированы получателем.Это обеспечивает базовую функцию поддержания активности. Напротив, сообщения Ping и Pong являются двусторонним обменом.

После получения сообщения Ping получатель ДОЛЖЕН вернуть в ответ сообщение Pong с идентичным токеном. Если Ping не содержит опцию с семантикой задержки, например опцию Custody, он ДОЛЖЕН ответить как можно скорее. Как и все сигнальные сообщения, получатель сообщения Ping или Pong ДОЛЖЕН игнорировать необязательные параметры, которые он не понимает.

Сообщения

Ping и Pong обозначаются цифрой 7.Код 02 (Ping) и код 7.03 (Pong).

Обратите внимание, что, как и в случае с аналогичными механизмами, определенными в [RFC6455] и [RFC7540], настоящая спецификация не определяет какое-либо конкретное максимальное время, в течение которого отправитель сообщения Ping может ожидать ответа Pong. Любые ограничения терпения для этого ответа зависят от приложения, использующего эти сообщения, как и любой подход к восстановлению после неспособности ответить вовремя.

C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
2 Пинг, Понг Хранение пустой 0 (нет)

При ответе на сообщение Ping получатель может включить в сообщение Pong факультативную опцию хранения.Этот параметр указывает, что приложение обработало все сообщения запроса / ответа, полученные до сообщения Ping в текущем соединении. (Обратите внимание, что не существует определения конкретной семантики приложения для «обработанного», но ожидается, что получатель сообщения Pong с опцией хранения должен иметь возможность освобождать буферы на основе этого указания.)

Отправитель может также включить выборочную опцию опеки в сообщение Ping, чтобы явно запросить включение выборной опции опеки в соответствующее сообщение Pong.В этом случае получателю СЛЕДУЕТ отложить свое сообщение Pong до тех пор, пока он не завершит обработку всех сообщений запроса / ответа, полученных до сообщения Ping в текущем соединении.

Сообщение Release указывает, что отправитель не хочет продолжать поддерживать транспортное соединение и выбирает упорядоченное завершение работы, но хочет предоставить партнеру возможность фактически начать закрытие соединения. Подробности в опциях. МОЖЕТ быть включена полезная нагрузка диагностики (см. Раздел 5.5.2 [RFC7252]).

Одноранговый узел обычно отвечает на сообщение Release, закрывая транспортное соединение. (В случае, если этого не происходит, отправитель релиза может захотеть реализовать механизм тайм-аута, если избавление от соединения действительно важно для него.)

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

Отправителю сообщения Release НЕ РЕКОМЕНДУЕТСЯ продолжать посылать запросы по тому соединению, которое он уже указал как разорванное: одноранговый узел может закрыть соединение в любое время и пропустить эти запросы. Однако партнер не обязан проверять это условие.

Сообщения о выпуске

обозначаются кодом 7.04 (выпуск).

Сообщения о выпуске

могут указывать на одну или несколько причин с помощью дополнительных опций.Определены следующие параметры:

C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
2 х Выпуск Альтернативный адрес строка 1-255 (нет)

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

Опция альтернативного адреса - это повторяемая опция, как определено в разделе 5.4.5 [RFC7252]. Если включено несколько экземпляров опции, одноранговый узел может выбрать любой из альтернативных транспортных адресов.

C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
4 Выпуск Задержка uint 0–3 (нет)

Выборочная опция удержания указывает, что сервер запрашивает, чтобы одноранговый узел не подключался к нему повторно в течение количества секунд, указанного в значении.

Сообщение Abort указывает, что отправитель не может продолжать поддерживать транспортное соединение и даже не может дождаться упорядоченного разъединения. Отправитель завершает соединение сразу после прерывания (и может или не может дождаться сообщения Release или Abort или закрытия соединения в обратном направлении). Полезные данные диагностики (см. Раздел 5.5.2 [RFC7252]) ДОЛЖНЫ быть включены в сообщение Abort. Когда отправитель решает отправить сообщение об отмене, сообщения могут находиться в полете, или ответы могут быть не получены.Обычно ожидается, что они НЕ будут обработаны.

Сообщения об отмене обозначаются кодом 7.05 (Отмена).

Сообщения об отмене могут указывать на одну или несколько причин с помощью дополнительных опций. Определен следующий вариант:

C = критический, R = повторяемый
# С R Относится к Имя Формат Длина Базовое значение
2 Прервать Bad-CSM-Option uint 0-2 (нет)

Выборочная опция Bad-CSM-Option указывает, что отправитель не может обработать опцию CSM, идентифицированную его номером опции, e.г. когда это критично и номер опции неизвестен отправителю, или когда существует проблема параметра со значением выборной опции. СЛЕДУЕТ включать более подробную информацию в качестве диагностической полезной нагрузки.

Для CoAP через UDP сообщения, содержащие нарушения синтаксиса, обрабатываются как ошибки формата сообщения. Как описано в разделах 4.2 и 4.3 [RFC7252], такие сообщения отклоняются путем отправки соответствующего сообщения Reset или игнорирования сообщения в противном случае.

Для CoAP через надежные транспорты получатель отклоняет такие сообщения, отправляя сообщение Abort, а в противном случае игнорирует (не обрабатывает) сообщение.В этом случае для сообщения Abort не определена конкретная опция, так как детали лучше оставить диагностической полезной нагрузке.

Закодированный пример сообщения Ping с непустым токеном показан на рисунке 11.

    0 1 2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | 0x01 | 0xe2 | 0x42 |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

    Len = 0 -------> 0x01
    ТКЛ = 1 ___ /
    Код = 7.02 Пинг -> 0xe2
    Токен = 0x42

Рисунок 11: Пример сообщения Ping

Закодированный пример соответствующего сообщения Pong показан на рисунке 12.

    0 1 2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | 0x01 | 0xe3 | 0x42 |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

    Len = 0 -------> 0x01
    ТКЛ = 1 ___ /
    Код = 7.03 Понг -> 0xe3
    Токен = 0x42

Рисунок 12: Пример сообщения Pong

Ограничения размера сообщения, определенные в разделе 4.6 CoAP [RFC7252], чтобы избежать фрагментации IP, не являются необходимыми, когда CoAP используется поверх надежного транспорта. Хотя это говорит о том, что протокол блочной передачи [RFC7959] также больше не нужен, он остается применимым для ряда случаев:

  • большие сообщения, такие как загрузки микропрограмм, могут вызвать нежелательную блокировку заголовка линии при использовании одного транспортного соединения
  • шлюз UDP-TCP может просто не иметь контекста для преобразования сообщения с параметром блокировки в эквивалентный обмен без использования параметра блокировки (потребуется преобразовать весь поблочный обмен от начала до конца в один обмен)

«Блочное расширение для надежного транспорта (BERT)» расширяет блочный протокол, позволяя использовать более крупные сообщения поверх надежного транспорта.

Использование этого нового расширения сигнализируется отправкой параметров блока 1 или блока 2 с SZX == 7 («параметр BERT»). SZX == 7 - это зарезервированное значение в [RFC7959].

При использовании управления опция BERT интерпретируется так же, как эквивалентная опция с SZX == 6, за исключением того, что она также указывает на возможность обработки блоков BERT. Как и в случае с базовым блочным протоколом, получателю запроса CoAP с опцией BERT при использовании управления разрешается ответить другим значением SZX, например.г. вместо этого отправить блок, отличный от BERT.

В описательном использовании опция BERT интерпретируется так же, как эквивалентная опция с SZX == 6, за исключением того, что полезная нагрузка также может содержать несколько блоков. Для неокончательных блоков BERT полезная нагрузка всегда кратна 1024 байтам. Для конечных блоков BERT полезная нагрузка кратна (возможно 0) 1024 байтам плюс частичный блок размером менее 1024 байтов.

Получатель неокончательного блока BERT (M ​​= 1) концептуально разделяет полезную нагрузку на последовательность блоков размером 1024 байта и действует точно так же, как если бы он получил эту последовательность вместе с номерами блоков, начинающимися с и последовательно увеличивающимися с, номер блока, указанный в опции блокировки.Другими словами, весь блок BERT позиционируется в позиции байта, которая получается в результате умножения номера блока на 1024. Положение дополнительных блоков, подлежащих передаче, указывается путем увеличения номера блока на количество элементов в этой последовательности (т. Е. размер полезной нагрузки, деленный на 1024 байта).

Как и в случае SZX == 6, получатель последнего блока BERT (M ​​= 0) просто добавляет полезную нагрузку в позицию байта, которая обозначена номером блока, умноженным на 1024.

Следующие примеры иллюстрируют параметры BERT. Значение SZX == 7 помечается как «BERT» или как «BERT (nnn)» для обозначения полезной нагрузки размера nnn.

Во всех этих примерах параметр блока раскладывается, чтобы указать тип параметра блока (1 или 2), за которым следует двоеточие, номер блока (ЧИСЛО), дополнительный бит (M) и размер блока (2 ** (SZX +4)) через косую черту. Например, значение параметра Block2, равное 33, будет отображаться как 2: 2/0/32), или значение параметра Block1, равное 59, будет отображаться как 1: 3/1/128.

На рисунке 13 показан запрос GET с ответом, разделенным на три блока BERT. Первый ответ содержит 3072 байта полезной нагрузки; второй - 5120; и третий, 4711. Обратите внимание, как увеличивается номер блока, чтобы переместить позицию внутри тела ответа вперед.

CoAP-клиент CoAP-сервер
  | |
  | GET, / status ------> |
  | |
  | <------ 2.05 Контент, 2: 0/1 / BERT (3072) |
  | |
  | GET, / status, 2: 3/0 / BERT ------> |
  | |
  | <------ 2.05 Содержание, 2: 3/1 / BERT (5120) |
  | |
  | GET, / status, 2: 8/0 / BERT ------> |
  | |
  | <------ 2.05 Содержание, 2: 8/0 / BERT (4711) |

Рисунок 13: GET с блоками BERT

Рисунок 14 демонстрирует обмен PUT с блоками BERT.

CoAP-клиент CoAP-сервер
  | |
  | PUT, / options, 1: 0/1 / BERT (8192) ------> |
  | |
  | <------ 2.31 Продолжить, 1: 0/1 / BERT |
  | |
  | PUT, / options, 1: 8/1 / BERT (16384) ------> |
  | |
  | <------ 2.31 Продолжить, 1: 8/1 / BERT |
  | |
  | PUT, / options, 1: 24/0 / BERT (5683) ------> |
  | |
  | <------ 2.04 Изменено, 1: 24/0 / BERT |
  | |

Рисунок 14: PUT с блоками BERT

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

При использовании параметра наблюдения с CoAP через UDP в уведомлениях от сервера для параметра устанавливается возрастающий порядковый номер для обнаружения переупорядочения на клиенте, поскольку сообщения могут поступать в другом порядке, чем они были отправлены.Этот порядковый номер не требуется для CoAP через надежные транспорты, поскольку протокол TCP обеспечивает надежную и упорядоченную доставку сообщений. Значение параметра наблюдения в уведомлениях 2.xx МОЖЕТ быть пустым при передаче и ДОЛЖНО игнорироваться при приеме.

Примечание по реализации: это означает, что прокси-сервер от переупорядочивающего транспорта к надежному (упорядоченному) транспорту (например, прокси-сервер UDP-TCP) должен обрабатывать параметр наблюдения в уведомлениях в соответствии с правилами в разделе 3.4 из [RFC7641].

Для CoAP через UDP уведомления сервера клиенту могут быть подтверждаемыми или неподтвержденными. Подтверждаемое сообщение требует, чтобы клиент ответил либо сообщением подтверждения, либо сообщением сброса. Сообщение подтверждения указывает, что клиент активен и желает получать дальнейшие уведомления. Сообщение сброса указывает, что клиент не распознает маркер, из-за чего сервер удаляет связанную запись из списка наблюдателей.

Поскольку TCP устраняет необходимость в уровне сообщений для поддержки надежности, CoAP поверх надежных транспортов не поддерживает подтверждаемые или неподтверждаемые типы сообщений.Все уведомления надежно доставляются клиенту с положительным подтверждением получения на уровне TCP. Если клиент не распознает токен в уведомлении, он МОЖЕТ немедленно прервать соединение (см. Раздел 5.6).

Для CoAP через UDP, если клиент не получает уведомление в течение некоторого времени, он МОЖЕТ отправить новый запрос GET с тем же токеном, что и исходный запрос, чтобы повторно зарегистрировать свою заинтересованность в ресурсе и убедиться, что сервер все еще отвечает .Для CoAP над надежными транспортными средствами более эффективно проверять работоспособность соединения (и всех его активных наблюдений), отправляя одно сообщение CoAP Ping Signaling (раздел 5.4), а не отдельные запросы для подтверждения каждого активного наблюдения. (Обратите внимание, что такой пинг / понг подтверждает только один прыжок: прокси-сервер не обязан и не ожидать реакции на пинг путем проверки всех своих последующих наблюдений или всех соединений, если таковые имеются, лежащих в их основе. Прокси-сервер МОЖЕТ поддерживать свой собственный график для подтверждения будущих наблюдений, на которые он полагается; однако, как правило, прокси не рекомендуется генерировать большое количество исходящих проверок на основе одной входящей проверки.)

Для CoAP через UDP клиент, который больше не заинтересован в получении уведомлений, может «забыть» наблюдение и ответить на следующее уведомление от сервера сообщением сброса, чтобы отменить наблюдение.

Для CoAP через надежные транспорты клиент ДОЛЖЕН явным образом отменить регистрацию, выполнив запрос GET, в котором в поле Token установлен маркер наблюдения, которое нужно отменить, и включает параметр наблюдения со значением, установленным на 1 (отмена регистрации).

Если клиент наблюдает за одним или несколькими ресурсами через надежный транспорт, то сервер CoAP (или посредник в роли сервера CoAP) ДОЛЖЕН удалить все записи, связанные с конечной точкой клиента, из списков наблюдателей, когда соединение закрывается или время вышло.

CoAP через UDP [RFC7252] определяет схемы URI «coap» и «coap». В этом документе представлены четыре дополнительных схемы URI для идентификации ресурсов CoAP и предоставления средств поиска ресурса:

  • схема URI «coap + tcp» для CoAP через TCP
  • схема URI «coaps + tcp» для CoAP через TCP, защищенная TLS
  • схема URI «coap + ws» для CoAP через WebSockets
  • схема URI «coaps + ws» для CoAP через WebSockets, защищенная TLS

Ресурсы, доступные через эти схемы, не имеют общего идентификатора, даже если их идентификаторы ресурсов указывают на одинаковые полномочия (тот же хост слушает один и тот же порт TCP).Они размещены в разных пространствах имен, поскольку каждая схема URI подразумевает отдельный исходный сервер.

Синтаксис схем URI в этом разделе определяется с использованием расширенной формы Бэкуса-Наура (ABNF) [RFC5234]. Определения «host», «port», «path-abempty» и «query» взяты из [RFC3986].

Раздел 8

(Multicast CoAP) в [RFC7252] не применим к этим схемам.

Как и в случае схем «coap» и «coap», определенных в [RFC7252], все схемы URI, определенные в этом разделе, также поддерживают префикс пути «/.well-known / », определенный в [RFC5785] для« хорошо известных местоположений »в пространстве имен хоста. Это обеспечивает обнаружение в соответствии с разделом 7 [RFC7252].

Схема URI «coap + tcp» идентифицирует ресурсы CoAP, которые должны быть доступны с использованием CoAP через TCP.

  coap-tcp-URI = "coap + tcp:" "//" хост [":" порт]
    path-abempty ["?" запрос ]

Синтаксис, определенный в разделе 6.1 [RFC7252], применяется к этой схеме URI со следующими изменениями:

  • Подкомпонент порта указывает порт TCP, на котором находится приемник подключения CoAP.(Если он пуст или не задан, предполагается, что по умолчанию используется порт 5683, как и в случае с UDP.)
Рекомендации по кодированию:
Кодирование схемы соответствует правилам кодирования, установленным для URI в [RFC3986].
Соображения по совместимости:
Нет.
Соображения безопасности:
См. Раздел 11.1 [RFC7252].

Схема URI «coaps + tcp» определяет ресурсы CoAP, которые предназначены для доступа с использованием CoAP через TCP, защищенных с помощью TLS.

  coaps-tcp-URI = "coaps + tcp:" "//" хост [":" порт]
    path-abempty ["?" запрос ]

Синтаксис, определенный в разделе 6.2 [RFC7252], применяется к этой схеме URI со следующими изменениями:

  • Подкомпонент порта указывает порт TCP, на котором расположен сервер TLS для приемника соединения CoAP. Если он пуст или не задан, предполагается порт по умолчанию 5684.
  • Если сервер TLS не поддерживает расширение согласования протокола прикладного уровня (ALPN) [RFC7301] или желает приспособить клиентов TLS, которые не поддерживают ALPN, он МОЖЕТ предложить конечную точку coaps + tcp на TCP-порту 5684.Эта конечная точка также МОЖЕТ быть включена ALPN. Сервер TLS МОЖЕТ предлагать конечные точки coaps + tcp на портах, отличных от TCP-порта 5684, который ДОЛЖЕН быть включен ALPN.
  • Для TCP-портов, отличных от порта 5684, клиент TLS ДОЛЖЕН использовать расширение ALPN для объявления идентификатора протокола «coap» (см. Раздел 11.7) в списке протоколов в своем ClientHello. Если TCP-сервер выбирает и возвращает идентификатор протокола «coap», используя расширение ALPN в своем ServerHello, то соединение устанавливается успешно. Если сервер TLS либо не согласовывает расширение ALPN, либо возвращает предупреждение no_application_protocol, клиент TLS ДОЛЖЕН закрыть соединение.
  • Для TCP-порта 5684 клиент TLS МОЖЕТ использовать расширение ALPN для объявления идентификатора протокола «coap» в списке протоколов в своем ClientHello. Если сервер TLS выбирает и возвращает идентификатор протокола «coap», используя расширение ALPN в своем ServerHello, то соединение устанавливается успешно. Если сервер TLS возвращает предупреждение no_application_protocol, клиент TLS ДОЛЖЕН закрыть соединение. Если сервер TLS не согласовывает расширение ALPN, неявно выбирается coaps + tcp.
  • Для TCP-порта 5684, если клиент TLS не использует расширение ALPN для согласования протокола, то неявно выбирается coaps + tcp.
Рекомендации по кодированию:
Кодирование схемы соответствует правилам кодирования, установленным для URI в [RFC3986].
Соображения по совместимости:
Нет.
Соображения безопасности:
См. Раздел 11.1 [RFC7252].

Схема URI «coap + ws» идентифицирует ресурсы CoAP, которые предназначены для доступа с использованием CoAP через WebSockets.

  coap-ws-URI = "coap + ws:" "//" хост [":" порт]
    path-abempty ["?" запрос ]

Подкомпонент порта НЕОБЯЗАТЕЛЬНЫЙ. По умолчанию это порт 80.

Конечная точка WebSocket идентифицируется URI «ws», который состоит из авторитетной части URI «coap + ws» и хорошо известного пути «/.well-known/coap» [RFC5785] [ID.bormann- hybi-ws-wk]. Части пути и запроса URI «coap + ws» идентифицируют ресурс в указанной конечной точке, с которым можно работать с помощью методов, определенных CoAP:

      coap + ws: // пример.орг / датчики / температура? u = Cel
           \ ______ ______ / \ ___________ ___________ /
                  \ / \ /
                                     Uri-Path: "датчики"
ws: //example.org/.well-known/coap Uri-Path: "температура"
                                     Uri-запрос: "u = Cel"

Рисунок 15. Схема URI «coap + ws»

Рекомендации по кодированию:
Кодирование схемы соответствует правилам кодирования, установленным для URI в [RFC3986].
Соображения по совместимости:
Нет.
Соображения безопасности:
См. Раздел 11.1 [RFC7252].

Схема URI «coaps + ws» идентифицирует ресурсы CoAP, которые предназначены для доступа с использованием CoAP через WebSockets, защищенные TLS.

  coaps-ws-URI = "coaps + ws:" "//" хост [":" порт]
    path-abempty ["?" запрос ]

Подкомпонент порта НЕОБЯЗАТЕЛЬНЫЙ. По умолчанию это порт 443.

Конечная точка WebSocket идентифицируется URI «wss», который состоит из авторитетной части URI «coaps + ws» и общеизвестного пути «/.хорошо известный / coap »[RFC5785] [I-D.bormann-hybi-ws-wk]. Части пути и запроса URI «coaps + ws» идентифицируют ресурс в указанной конечной точке, с которым можно работать с помощью методов, определенных CoAP.

      coaps + ws: //example.org/sensors/temperature? u = Cel
            \ ______ ______ / \ ___________ ___________ /
                   \ / \ /
                                     Uri-Path: "датчики"
wss: //example.org/.well-known/coap Uri-Path: "температура"
                                     Uri-запрос: "u = Cel"

Рисунок 16. Схема URI «coaps + ws»

Рекомендации по кодированию:
Кодирование схемы соответствует правилам кодирования, установленным для URI в [RFC3986].
Соображения по совместимости:
Нет.
Соображения безопасности:
См. Раздел 11.1 [RFC7252].

CoAP через надежный транспорт поддерживает свойство из Раздела 5.10.1 [RFC7252]:

  • Значения по умолчанию для параметров Uri-Host и Uri-Port достаточны для запросов к большинству серверов.

Если не указано иное, значением по умолчанию для параметра Uri-Host Option является литерал IP, представляющий IP-адрес пункта назначения сообщения запроса.Значение по умолчанию для параметра Uri-Port - TCP-порт назначения.

Для CoAP через TLS эти значения по умолчанию одинаковы, если не согласовано указание имени сервера (SNI) [RFC6066]. В этом случае значением по умолчанию для параметра Uri-Host в запросах от клиента TLS к серверу TLS является хост SNI.

Для CoAP через WebSockets значение по умолчанию параметра Uri-Host Option в запросах от клиента WebSocket к серверу WebSocket указывается в поле заголовка Host в подтверждении связи WebSocket.

Шаги такие же, как указано в разделе 6.4 [RFC7252] с небольшими изменениями.

Этот шаг из [RFC7252]:

3. Если | url | не имеет компонента , значение которого, когда
    конвертируется в нижний регистр ASCII, принимает значение «coap» или «coaps», затем не выполняется
    этот алгоритм.

обновлен до:

3. Если | url | не имеет компонента , значение которого, когда
    преобразован в нижний регистр ASCII, это "coap + tcp", "coaps + tcp",
    «coap + ws» или «coaps + ws», то этот алгоритм не работает.

Этот шаг из [RFC7252]:

7. Если | порт | не совпадает с UDP-портом назначения запроса,
    включите параметр Uri-Port, и пусть значение этого параметра будет | порт |.

обновлен до:

7. Если | порт | не совпадает с TCP-портом назначения запроса,
    включите параметр Uri-Port, и пусть значение этого параметра будет | порт |.

Шаги такие же, как указано в разделе 6.5 [RFC7252] с небольшими изменениями.

Этот шаг из [RFC7252]:

1.Если запрос защищен с помощью DTLS, пусть | url | быть строкой
    «копы: //». В противном случае пусть | url | быть строкой «coap: //».

обновлен до:

1. Для CoAP через TCP, если запрос защищен с помощью TLS, пусть | url |
    быть строкой "coaps + tcp: //". В противном случае пусть | url | быть строкой
    "coap + tcp: //". Для CoAP через WebSockets, если запрос
    защищено с помощью TLS, пусть | url | быть строкой "coaps + ws: //".
    В противном случае пусть | url | быть строкой «coap + ws: //».

Этот шаг из [RFC7252]:

4.Если запрос включает параметр Uri-Port, пусть | порт | будь то
    стоимость опциона. В противном случае пусть | порт | быть просьбой
    порт назначения UDP.

обновлен до:

4. Если запрос включает параметр Uri-Port, пусть | port | будь то
    стоимость опциона. В противном случае пусть | порт | быть просьбой
    TCP-порт назначения.

Security Challenges for the Internet of Things [SecurityChallenges] рекомендует:

  • … важно, чтобы в наборах протоколов IoT было указано обязательное для реализации, но необязательное для использования решение безопасности.Это гарантирует, что безопасность будет доступна во всех реализациях, но ее можно будет настроить для использования, когда в ней нет необходимости (например, в закрытой среде). … Даже если эти функции расширяют возможности таких устройств.

Решение безопасности ДОЛЖНО быть реализовано для защиты CoAP через надежные транспорты и ДОЛЖНО быть включено по умолчанию. В этом документе определяется привязка TLS, но при необходимости МОГУТ использоваться альтернативные решения на разных уровнях стека протоколов для защиты CoAP через надежные транспорты.Обратите внимание, что продолжается работа по поддержке модели безопасности на основе объектов данных для CoAP, которая не зависит от транспорта (см. [I-D.ietf-core-object-security]).

Применяется руководство по использованию TLS в [RFC7925], включая руководство по комплектам шифров в этом документе, которые являются производными от обязательных для реализации (MTI) комплектов шифров, определенных в [RFC7252].

Это руководство предполагает реализацию в ограниченном устройстве или для связи с ограниченным устройством. Однако CoAP через TCP / TLS имеет более широкое применение.Это может, например, быть реализовано на шлюзе или на устройстве, которое менее ограничено (например, смартфон или планшет), для связи с одноранговым узлом, который также менее ограничен, или в серверной среде, которая взаимодействует только с ограниченные устройства через прокси. В качестве исключения из предыдущего абзаца в этом случае более уместны рекомендации [RFC7525].

Поскольку рекомендации, предлагаемые в [RFC7925] и [RFC7525], различаются с точки зрения алгоритмов и типов учетных данных, предполагается, что реализация CoAP через TCP / TLS, которая должна поддерживать оба случая, реализует рекомендации, предлагаемые обеими спецификациями.

На этапе инициализации устройству CoAP предоставляется необходимая информация о безопасности, включая материалы для ключей, списки управления доступом и серверы авторизации. В конце фазы инициализации устройство будет в одном из четырех режимов безопасности:

NoSec:
TLS отключен.
PreSharedKey:
TLS включен. Применяются рекомендации в разделе 4.2 [RFC7925].
RawPublicKey:
TLS включен.Применяются рекомендации в разделе 4.3 [RFC7925].
Сертификат:
TLS включен. Применяются рекомендации в разделе 4.4 [RFC7925].

Режим «NoSec» является необязательным для реализации. Система просто отправляет пакеты по обычному TCP, на что указывает схема «coap + tcp» и порт TCP CoAP по умолчанию. Система защищена только тем, что злоумышленники не могут отправлять или получать пакеты из сети с узлами CoAP.

«PreSharedKey», «RawPublicKey» или «Сертификат» являются обязательными для реализации для привязки TLS в зависимости от типа учетных данных, используемых с устройством.Эти режимы безопасности достигаются с использованием TLS и обозначаются схемой «coaps + tcp» и портом по умолчанию CoAP, защищенным TLS.

Клиент CoAP, запрашивающий ресурс, идентифицированный URI «coaps + ws», согласовывает безопасное соединение WebSocket с конечной точкой сервера WebSocket с URI «wss». Это описано в Разделе 8.4.

Клиент ДОЛЖЕН выполнить квитирование TLS после открытия соединения с сервером. Применяются рекомендации в разделе 4.1 [RFC6455]. Когда сервер CoAP предоставляет ресурсы, идентифицированные URI «coaps + ws», руководство в Разделе 4.4 [RFC7925] применяется к обязательной реализации функциональности TLS для сертификатов. В отношении требований на стороне сервера при приеме входящих подключений через порт HTTPS (HTTP-over-TLS) применяются рекомендации в разделе 4.2 [RFC6455].

Обратите внимание, что это формально наследует обязательные для реализации наборы шифров, определенные в [RFC5246]. Однако обычно современные браузеры реализуют более свежие наборы шифров, которые затем автоматически выбираются через JavaScript WebSocket API. Серверы WebSocket, которые обеспечивают Secure CoAP через WebSockets для варианта использования браузера, должны будут следовать настройкам браузера и ДОЛЖНЫ следовать [RFC7525].

Применяются соображения безопасности [RFC7252]. Для CoAP через WebSockets и CoAP через WebSockets, защищенные TLS, также применяются соображения безопасности [RFC6455].

Невозможно слепо следовать указаниям, предоставляемым опцией альтернативного адреса. В частности, одноранговый узел НЕ ДОЛЖЕН предполагать, что успешное соединение с альтернативным адресом наследует все свойства безопасности текущего соединения.

IANA просят создать третий суб-реестр для значений поля кода в заголовке CoAP (раздел 12.1 из [RFC7252]). Название этого подрегистра - «Сигнальные коды CoAP».

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

Первоначальные записи в этом подрегистре следующие:

Сигнальные коды CoAP
Код Имя Номер ссылки
7,01 CSM [RFCthis]
7.02 Пинг [RFCthis]
7,03 Понг [RFCthis]
7,04 Выпуск [RFCthis]
7,05 Прервать [RFCthis]

Все остальные сигнальные коды не назначены.

Политика IANA в отношении будущих дополнений к этому субреестру - «Проверка IETF или Утверждение IESG», как описано в [RFC8126].

IANA просят создать вспомогательный реестр для номеров опций, используемых в опциях сигнализации CoAP в реестре «Параметры CoRE».Имя этого подрегистра - «Номера опций сигнализации CoAP».

Каждая запись в суб-реестре должна включать один или несколько кодов из субрегистра сигнальных кодов (раздел 11.1), номер опции, название опции и ссылку на документацию по опции.

Первоначальные записи в этом подрегистре следующие:

Коды опций сигнала CoAP
Относится к Номер Имя Номер ссылки
7.01 2 Максимальный размер сообщения [RFCthis]
7,01 4 Блок-мудрая передача [RFCthis]
7,02, 7,03 2 Хранение [RFCthis]
7,04 2 Альтернативный адрес [RFCthis]
7,04 4 Задержка [RFCthis]
7.05 2 Bad-CSM-Option [RFCthis]

Политика IANA для будущих дополнений к этому субреестру основана на диапазонах номеров для номеров опций, аналогично политике, определенной в разделе 12.2 [RFC7252]. (Политика скорее аналогична, чем идентична, поскольку структура подрегистра включает дополнительный столбец; однако значение этого столбца не влияет на политику.)

В документации для номера опции сигнализации должна быть указана семантика опции с этим номером, включая следующие свойства:

  • Является ли вариант критическим или факультативным, в зависимости от номера варианта.
  • Повторяемость параметра.
  • Формат и длина значения опции.
  • Базовое значение для опции, если таковая имеется.

IANA запрашивает назначение номера порта 5683 и имени службы «coap + tcp» в соответствии с [RFC6335].

Название службы.

coap + tcp
Транспортный протокол.

tcp
Правопреемник.

IESG
Связаться.

Председатель IETF
Описание.

Протокол ограниченного приложения (CoAP)
Ссылка.

[RFCthis]
Номер порта.

5683

IANA запрашивает назначение номера порта 5684 и имени службы «coaps + tcp» в соответствии с [RFC6335]. Номер порта запрашивается в исключительном случае реализаций TLS, которые не поддерживают «Расширение согласования протокола прикладного уровня» [RFC7301].

Название службы.

колпачки + tcp
Транспортный протокол.

tcp
Правопреемник.

IESG
Связаться.

Председатель IETF
Описание.

Протокол ограниченного приложения (CoAP)
Ссылка.

[RFC7301], [RFCthis]
Номер порта.

5684
Схемы

URI зарегистрированы в реестре «Схемы унифицированного идентификатора ресурса (URI)», который ведется в [IANA.ури-схемы].

IANA запрашивает регистрацию схемы универсального идентификатора ресурса (URI) «coap + tcp». Этот запрос на регистрацию соответствует [RFC7595].

Название схемы:

coap + tcp
Статус:

Навсегда
Приложения / протоколы, использующие это имя схемы:

Схема используется конечными точками CoAP для доступа к ресурсам CoAP с помощью TCP.
Контакт:

Председатель IETF
Контроллер изменений:

IESG
Артикул:

Раздел 8.1 в [RFCthis]

IANA запрашивает регистрацию схемы универсального идентификатора ресурса (URI) «coaps + tcp». Этот запрос на регистрацию соответствует [RFC7595].

Название схемы:

колпачки + tcp
Статус:

Навсегда
Приложения / протоколы, использующие это имя схемы:

Схема используется конечными точками CoAP для доступа к ресурсам CoAP с помощью TLS.
Контакт:

Председатель IETF
Контроллер изменений:

IESG
Артикул:

Раздел 8.2 в [RFCthis]

IANA запрашивает регистрацию схемы универсального идентификатора ресурса (URI) «coap + ws». Этот запрос на регистрацию соответствует [RFC7595].

Название схемы:

coap + ws
Статус:

Навсегда
Приложения / протоколы, использующие это имя схемы:

Схема используется конечными точками CoAP для доступа к ресурсам CoAP с использованием протокола WebSocket.
Контакт:

Председатель IETF
Контроллер изменений:

IESG
Артикул:

Раздел 8.3 в [RFCthis]

IANA запрашивает регистрацию схемы универсального идентификатора ресурса (URI) «coaps + ws». Этот запрос на регистрацию соответствует [RFC7595].

Название схемы:

колпачки + WS
Статус:

Навсегда
Приложения / протоколы, использующие это имя схемы:

Схема используется конечными точками CoAP для доступа к ресурсам CoAP с использованием протокола WebSocket, защищенного с помощью TLS.
Контакт:

Председатель IETF
Контроллер изменений:

IESG
Ссылки:

Раздел 8.4 в [RFCthis]

IANA запрашивает регистрацию хорошо известного URI «coap» в реестре «Well-Known URIs». Этот запрос на регистрацию соответствует [RFC5785]:

Суффикс URI.

копчик
Заменить контроллер.

IETF
Документ (ы) спецификации.

[RFCthis]
Связанная информация.

Нет.

IANA запрошено присвоить следующее значение в реестре «Идентификаторы протокола согласования протоколов уровня приложений (ALPN)», созданном [RFC7301]. Строка «coap» идентифицирует CoAP при использовании поверх TLS.

Протокол.

CoAP
Идентификационная последовательность.

0x63 0x6f 0x61 0x70 («колпак»)
Ссылка.

[RFCthis]

IANA запрашивает регистрацию подпротокола WebSocket CoAP в «Реестре имен подпротокола WebSocket»:

Идентификатор подпротокола.

копчик
Общее имя подпротокола.

Протокол ограниченного приложения (CoAP)
Определение подпротокола.

[RFCthis]

IANA просят добавить [RFCthis] к ссылкам на следующие записи, зарегистрированные [RFC7959] в подреестре «Номера вариантов CoAP», определенном в [RFC7252]:

Номера опций CoAP
Номер Имя Номер ссылки
23 Блок2 RFC 7959, [RFCthis]
27 Блок1 RFC 7959, [RFCthis]
[I-D.bormann-hybi-ws-wk] Борман, К., «Хорошо известные URI для протокола WebSocket», Internet-Draft draft-bormann-hybi-ws-wk-00, май 2017 г.
[RFC0793] Постел, Дж., "Протокол управления передачей", STD 7, RFC 793, DOI 10.17487 / RFC0793, сентябрь 1981 г.
[RFC2119] Браднер, С., «Ключевые слова для использования в RFC для обозначения уровней требований», BCP 14, RFC 2119, DOI 10.17487 / RFC2119, март 1997.
[RFC3986] Бернерс-Ли, Т., Филдинг, Р. и Л. Масинтер, «Универсальный идентификатор ресурса (URI): общий синтаксис», STD 66, RFC 3986, DOI 10.17487 / RFC3986, январь 2005 г.
[RFC5246] Диркс, Т. и Э. Рескорла, "Протокол безопасности транспортного уровня (TLS), версия 1.2", RFC 5246, DOI 10.17487 / RFC5246, август 2008 г.
[RFC5785] Ноттингем, М.и Э. Хаммер-Лахав, «Определение хорошо известных универсальных идентификаторов ресурсов (URI)», RFC 5785, DOI 10.17487 / RFC5785, апрель 2010 г.
[RFC6066] Истлейк 3-й, Д., «Расширения безопасности транспортного уровня (TLS): определения расширений», RFC 6066, DOI 10.17487 / RFC6066, январь 2011 г.
[RFC6455] Фетте, И. и А. Мельников, "Протокол WebSocket", RFC 6455, DOI 10.17487 / RFC6455, декабрь 2011 г.
[RFC7252] Шелби, З., Хартке, К. и К. Борман, «Протокол ограниченного приложения (CoAP)», RFC 7252, DOI 10.17487 / RFC7252, июнь 2014 г.
[RFC7301] Фридл, С., Попов, А., Лэнгли, А. и Э. Стефан, «Расширение согласования протокола уровня приложений безопасности транспортного уровня (TLS)», RFC 7301, DOI 10.17487 / RFC7301, июль 2014 г.
[RFC7525] Шеффер, Ю., Хольц, Р. и П. Сен-Андре, «Рекомендации по безопасному использованию безопасности транспортного уровня (TLS) и безопасности транспортного уровня дейтаграмм (DTLS)», BCP 195, RFC 7525, DOI 10.17487 / RFC7525, май 2015 г.
[RFC7595] Талер Д., Хансен Т. и Т. Харди, «Рекомендации и процедуры регистрации для схем URI», BCP 35, RFC 7595, DOI 10.17487 / RFC7595, июнь 2015 г.
[RFC7641] Хартке, К., «Наблюдение за ресурсами в протоколе ограниченного приложения (CoAP)», RFC 7641, DOI 10.17487 / RFC7641, сентябрь 2015 г.
[RFC7925] Чофениг, Х.и Т. Фоссати, «Профили безопасности транспортного уровня (TLS) / дейтаграммной безопасности транспортного уровня (DTLS) для Интернета вещей», RFC 7925, DOI 10.17487 / RFC7925, июль 2016 г.
[RFC7959] Борман, К. и З. Шелби, «Блочные передачи в протоколе с ограничениями приложений (CoAP)», RFC 7959, DOI 10.17487 / RFC7959, август 2016 г.
[RFC8126] Коттон, М., Лейба, Б. и Т. Нартен, «Рекомендации по написанию раздела о соображениях IANA в RFC», BCP 26, RFC 8126, DOI 10.17487 / RFC8126, июнь 2017 г.
[BK2015] Бирн, К. и Дж. Клеберг, «Рекомендации по развертыванию UDP», Proceedings draft-byrne-opsec-udp-advisory-00 (срок действия истек), 2015 г.
[EK2016] Эделин, К., Кюлевинд, М., Траммелл, Б., Абен, Э. и Б. Доннет, «Использование UDP для развития Интернет-транспорта», Proceedings arXiv preprint 1612.07816, 2016.
[HomeGateway] Эггерт, Л., «Экспериментальное исследование характеристик домашних шлюзов», Труды 10-й ежегодной конференции по измерению Интернета, 2010.
[I-D.gomez-lwig-tcp-ограниченные-узлы-сети] Гомес, К., Кроукрофт, Дж. И М. Шарф, «TCP через сети с ограниченными узлами», Internet-Draft draft-gomez-lwig-tcp-constrained-node-networks-03, июнь 2017 г.
[I-D.ietf-core-какао] Борман, К., Бецлер, А., Гомес, К.и И. Демиркол, «Простой контроль перегрузки CoAP / расширенный», Internet-Draft draft-ietf-core-cocoa-02, октябрь 2017 г.
[I-D.ietf-core-object-security] Селандер, Г., Матссон, Дж., Паломбини, Ф. и Л. Зейтц, «Безопасность объектов для ограниченных сред RESTful (OSCORE)», Internet-Draft draft-ietf-core-object-security-07, ноябрь 2017 г.
[схемы IANA.uri] IANA, «Схемы унифицированного идентификатора ресурса (URI)»
[LWM2M] Открытый мобильный альянс, Техническая спецификация "Легкие машины в машины", версия 1.0 ", февраль 2017 г.
[RFC0768] Постел, Дж., «Протокол дейтаграмм пользователя», STD 6, RFC 768, DOI 10.17487 / RFC0768, август 1980 г.
[RFC5234] Крокер, Д. и П. Оверелл, «Расширенный BNF для спецификаций синтаксиса: ABNF», STD 68, RFC 5234, DOI 10.17487 / RFC5234, январь 2008 г.
[RFC6335] Коттон, М., Эггерт, Л., Тач, Дж., Вестерлунд, М. и С. Чешир, «Процедуры управления адресами Интернета (IANA) для управления реестром имени службы и номера порта транспортного протокола», BCP 165 , RFC 6335, DOI 10.17487 / RFC6335, август 2011 г.
[RFC6347] Рескорла, Э. и Н. Модадугу, «Версия 1.2 безопасности транспортного уровня дейтаграмм», RFC 6347, DOI 10.17487 / RFC6347, январь 2012 г.
[RFC7230] Филдинг, Р. и Дж. Решке, «Протокол передачи гипертекста (HTTP / 1.1): синтаксис сообщений и маршрутизация», RFC 7230, DOI 10.17487 / RFC7230, июнь 2014 г.
[RFC7540] Белше, М., Peon, R. и M. Thomson, "Hypertext Transfer Protocol Version 2 (HTTP / 2)", RFC 7540, DOI 10.17487 / RFC7540, May 2015.
[Проблемы безопасности] Полк, Т. и С. Тернер, «Проблемы безопасности для Интернета вещей», Interconnecting Smart Objects with the Internet / IAB Workshop, February 2011.
[SW2016] Светт, И., "QUIC Deployment Experience @Google", Proceedings https://www.ietf.org/proceedings/96/slides/slides-96-quic-3.pdf, 2016.

В этом разделе приведены примеры первых двух конфигураций, обсуждаемых в разделе 4.

Пример процесса, которому следует клиент CoAP для извлечения представления ресурса, идентифицированного URI «coap + ws», может быть следующим. На рисунке 17 ниже подробно показан обмен сообщениями WebSocket и CoAP.

  1. Клиент CoAP получает URI , например, из представления ресурса, которое он получил ранее.
  2. Устанавливает соединение WebSocket с URI конечной точки, состоящим из авторитета «example.org» и известного пути «/.well-known/coap», .
    3. Обмен сообщениями
  3. CSM (раздел 5.3) (не показаны из-за недостатка места).
  4. Он отправляет однокадровое замаскированное двоичное сообщение, содержащее запрос CoAP. Запрос указывает целевой ресурс с параметрами Uri-Path («датчики», «температура») и Uri-Query («u = Cel»).
  5. Ожидает ответа от сервера.
  6. Клиент CoAP использует соединение для дальнейших запросов, или соединение закрывается.
   CoAP CoAP
  Клиент-сервер
(WebSocket (WebSocket
  Клиент) Сервер)

     | |
     | |
     + =========> | ПОЛУЧИТЬ /.well-known/coap HTTP / 1.1
     | | Хост: example.org
     | | Обновление: websocket
     | | Подключение: Обновление
     | | Sec-WebSocket-ключ: dGhlIHNhbXBsZSBub25jZQ ==
     | | Sec-WebSocket-Протокол: coap
     | | Sec-WebSocket-Версия: 13
     | |
     | <========= + HTTP / 1.1101 коммутационных протоколов
     | | Обновление: websocket
     | | Подключение: Обновление
     | | Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK + xOo =
     | | Sec-WebSocket-Протокол: coap
     ::
     : <-------->: Обмен сообщениями CSM (не показано)
     | |
     + ---------> | Двоичный кадр (код операции =% x2, FIN = 1, MASK = 1)
     | | + ------------------------- +
     | | | ПОЛУЧИТЬ |
     | | | Токен: 0x53 |
     | | | Uri-Path: «датчики» |
     | | | Ури-Путь: «температура» |
     | | | Uri-запрос: "u = Cel" |
     | | + ------------------------- +
     | |
     | <--------- + Двоичный кадр (код операции =% x2, FIN = 1, MASK = 0)
     | | + ------------------------- +
     | | | 2.05 Содержание |
     | | | Токен: 0x53 |
     | | | Полезная нагрузка: «22,3 кэла» |
     | | + ------------------------- +
     ::
     ::
     + ---------> | Закрыть кадр (код операции =% x8, FIN = 1, MASK = 1)
     | |
     | <--------- + Закрыть кадр (код операции =% x8, FIN = 1, MASK = 0)
     | |

Рисунок 17: Клиент CoAP извлекает представление ресурса, идентифицированного URI «coap + ws»

На рисунке 18 показано, как клиент CoAP использует прокси-сервер CoAP с конечной точкой WebSocket для получения представления ресурса coap: // [2001: db8 :: 1] / .Использование прокси-сервера пересылки и адрес конечной точки WebSocket определяется клиентом из правил локальной конфигурации. URI запроса указывается в опции Proxy-Uri. Поскольку URI запроса использует схему URI «coap», прокси выполняет запрос, отправляя подтверждаемый запрос GET по UDP на сервер CoAP и возвращая ответ клиенту через соединение WebSocket.

   CoAP CoAP CoAP
  Клиентский прокси-сервер
(WebSocket (WebSocket (UDP
  Клиент) Сервер) Конечная точка)

     | | |
     + ---------> | | Двоичный кадр (код операции =% x2, FIN = 1, MASK = 1)
     | | | + ------------------------------------ +
     | | | | ПОЛУЧИТЬ |
     | | | | Токен: 0x7d |
     | | | | Proxy-Uri: "coap: // [2001: db8 :: 1] /" |
     | | | + ------------------------------------ +
     | | |
     | + ---------> | Сообщение CoAP (Ver = 1, T = Con, MID = 0x8f54)
     | | | + ------------------------------------ +
     | | | | ПОЛУЧИТЬ |
     | | | | Токен: 0x0a15 |
     | | | + ------------------------------------ +
     | | |
     | | <--------- + сообщение CoAP (Ver = 1, T = Ack, MID = 0x8f54)
     | | | + ------------------------------------ +
     | | | | 2.05 Содержание |
     | | | | Токен: 0x0a15 |
     | | | | Полезная нагрузка: «готово» |
     | | | + ------------------------------------ +
     | | |
     | <--------- + | Двоичный кадр (код операции =% x2, FIN = 1, MASK = 0)
     | | | + ------------------------------------ +
     | | | | 2.05 Содержание |
     | | | | Токен: 0x7d |
     | | | | Полезная нагрузка: «готово» |
     | | | + ------------------------------------ +
     | | |

Рисунок 18: Клиент CoAP получает представление ресурса, идентифицированного URI «coap», через прокси CoAP с поддержкой WebSocket

Редактору RFC предлагается удалить этот раздел при публикации.

Объединенный draft-savolainen-core-coap-websockets-07 Объединенный draft-bormann-core-block-bert-01 Объединенный draft-bormann-core-coap-sig-02

Редакционные обновления

Добавлен обязательный обмен сообщениями Возможности и Настройки после подключения

Добавлена ​​поддержка coaps + tcp порт 5684 и дополнительные сведения о согласовании протокола уровня приложений (ALPN)

Добавлены инструкции по использованию CoAP Signaling Ping-Pong в сравнении с WebSocket Ping-Pong

Обновленные ссылки и требования по соображениям безопасности TLS

Обновленные ссылки

Добавлено приложение: обновления в RFC7641 для наблюдения за ресурсами в протоколе ограниченного приложения (CoAP)

Обновлен обмен сообщениями о возможностях и настройках (CSM) в открывающем рукопожатии, чтобы инициатор мог отправлять сообщения до получения CSM-получателя.

Адресованный отзыв от последнего звонка рабочей группы

Добавлен раздел «Обеспечение безопасности CoAP» и информативная ссылка на OSCOAP

.

Удалены параметры Server-Name и Bad-Server-Name.

Уточнен обмен сообщениями о возможностях и настройках (CSM)

Обновленные требования к ответам Pong

Добавлена ​​терминология инициатора соединения и приемника соединения, где это необходимо.

Обновлен LWM2M 1.0 информативная ссылка

Адресованный отзыв от второй рабочей группы Последний звонок

Адресованный отзыв от последнего звонка IETF

Адресованный отзыв из обзора ARTART

Адресованный отзыв из обзора GENART

Адресованный отзыв из обзора TSVART

Добавлены идентификаторы фрагментов в схемы URI

Добавлены «Обновления RFC7959» для BERT

Добавлены «Обновления RFC6455» для расширения известного механизма URI на ws и wss

Уточнено использование известного механизма URI для всех схем URI

Заменен NoSec на необязательный для реализации

Мы хотели бы поблагодарить Стивена Берара, Джеффри Кристалло, Оливье Делаби, Эско Дейка, Кристиана Гровса, Надира Джаведа, Майкла Костера, Матиаса Ковача, Ахима Крауса, Дэвида Наварро, Шимона Сасина, Горана Селандера, Зака ​​Шелби, Эндрю Саммерса, Джулиена Вермилла и Gengyu Wei за их отзывы.

Последние обзоры от Йошифуми Нисида, Марка Ноттингема и Мерала Ширазипура, а также нескольких рецензентов IESG предоставили обширные комментарии; от IESG мы хотели бы особо выделить Бена Кэмпбелла, Мирью Кюлевинд, Эрика Рескорла, Адама Роуча и ответственного AD Алексея Мельникова.

Маттиас Ковач
Siemens AG
Отто-Хан-Ринг 6
Мюнхен D-81739

Телефон: + 49-173-5288856
Электронная почта: [email protected]


Теему Саволайнен
Nokia Technologies
Hatanpaan valtatie 30
Тампере FI-33100
Финляндия

Электронная почта: [email protected]


Валик Солорзано Барбоса
Зебра Технологии
820 W. Jackson Blvd. Люкс 700
Чикаго 60607
Соединенные Штаты Америки

Телефон: + 1-847-634-6700
Электронная почта: [email protected]
Карстен Борман Борман Университет Бремена TZI Постфах 330440 Бремен, D-28359 Германия Телефон: + 49-421-218-63921 Электронная почта: [email protected]
Саймон Лемей Lemay Зебра Технологии 820 W. Jackson Blvd. Люкс 700 Чикаго, 60607 Соединенные Штаты Америки Телефон: + 1-847-634-6700 Электронная почта: slemay @ zebra.ком
Клаус Хартке Хартке Университет Бремена TZI Постфах 330440 Бремен, D-28359 Германия Телефон: + 49-421-218-63905 Электронная почта: [email protected]
Билханан Сильвераджан Сильвераджан Технологический университет Тампере Korkeakoulunkatu 10 Тампере, FI-33720 Финляндия Электронная почта: [email protected]
.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *