Alunos:
Breno de Lima Galves
Ellizeu Rodrigues Sena
Lucas de Queiroz dos Reis
Professor:
Luís Henrique Maciel Kosmalski Costa
Protocol para dispositivos de baixo processamento e de funcionalidade semelhante ao HTTP. Assim como o HTTP é um protocolo da camada de aplicação, porém este é construído sobre UDP enquanto HTTP é feito sobre TCP. Possui diversas ferramentas para flexibilidade como suporte a multicast, service/resource discovery e compatibilidade com HTTP. A principal aplicação do CoAP é em IoT e sistemas embarcados semelhantes.
O Constrained Application Protocol (CoAP) é um protocolo de transferência web (camada de aplicação) construído sobre UDP (camada de transporte) para aplicações M2M para uso em nós e redes de capacidade de hardware e potência baixas.
Inicialmente foi criado para microcontroladores de 8-bits com baixa quantidade de ROM e RAM.
Em redes como 6LoWPAN (IPv6 Low-Power Wireless Personal Area Networks) tem perda de pacote muito alta e throughput de dezenas de kbps.
CoAP utiliza um modelo de request/response entre os endpoints da aplicação. Este modelo é muito semelhante ao HTTP, uma vez que o protocolo foi construído para possuir uma interface de integração com a web através do HTTP.
O CoAP também adiciona uma feature ao HTTP conhecida como “observação”. Esta permite o streaming de mudanças de estado (state changes) apenas quando estas ocorrerem, sem necessidade do receptor fazer query para estas mudanças. De maneira geral, o CoAP foi criado com a perspectiva de reorganizar o HTTP de maneira mais compacta, implementando features M2M como service discovery, suporte a multicast e troca de mensagens assíncronas.
Este protocolo está definido nas seguinte RFCs:
Dispositivos de potência e processamento limitado como microcontroladores e Single Board Computers (SBCs), este dispositivos normalmente são utilizados para observação de sensores e controle de atuadores, e conectados à internet através de dispositivos de gateway devido a sua limitação de processamento.
O CoAP utiliza um header fixo de 4 bytes que pode ser seguido por opções e um payload. Este formato é utilizado tanto pelos requests quanto pelas responses. Toda mensagem contém um ID para detectar duplicatas.
A confiabilidade das mensagens é provida pela mensagem de confirmação (CON). O CON é restransmitido durante um timeout default até que o recipiente receba um ACK. Também existe a opção de utilizar mensagens não-confirmáveis (NON). Também há mensagens de reset (RST) para quando o recipiente não for capaz de processar CON ou NON.
Ao utilizar endereços multicast há diversos cuidados a serem tomados para evitar congestionamento da rede por excesso de mensagens, como utilizar apenas NON e não retornar um RST. O envio de RST será idêntico a uma mensagem unicast e se o enviante ainda estiver ativo terá o mesmo Message ID. Devido a estas questões os modos de segurança estão desabilitados para multicast.
| Campo de Mensagem CoAP | Descrição |
|---|---|
| Ver (Versão) | Identifica a versão do CoAP. |
| T (Tipo) |
Define um dos quatro tipos de mensagem a seguir:
|
| TKL (tamanho do token) | Especifica o tamanho (0-8 bytes) do campo Token. |
| Code | Indica o método de solicitação para uma mensagem de solicitação e um código de resposta para uma mensagem de resposta. Para obter uma lista completa de valores para este campo, consulte RFC 7252. |
| Message ID | Detecta a duplicação de mensagens e é usado para corresponder os tipos de mensagens ACK e RST aos tipos de mensagens CON e NON. |
| Token | Com um comprimento especificado por TKL, correlaciona solicitações e respostas. |
| Options | Especifica o número da opção, comprimento e valor da opção. Os recursos fornecidos pelo campo de opções incluem especificar o recurso de destino de uma solicitação e funções de proxy. |
| Payload | Transporta os dados do aplicativo CoAP. Este campo é opcional, mas quando está presente, um único byte de todos os 1's (0xFF) precede o payload. A finalidade desse byte é delinear o final do campo de opções e o início do payload. |
Da mesma forma que HTTP, os métodos são GET, POST, PUT e DELETE.
Responses específicas podem ser cacheadas no endpoint ou por um intermediário com o objetivo de reduzir o tempo de resposta e reutilizar respostas armazenadas por motivos de performance. A validade do cache é dada através de “freshness”, no qual a resposta é armazenada por um prazo determinado prazo de expiração.
Proxying é útil em Constrained Networks como método de limitar tráfego da rede, melhorar performance, acessar recursos de dispositivos inativos e por segurança. A combinação de proxying com caching permite o balanceamento do tráfego da rede de uma maneira otimizada.
Utilizando a porta default 5683 (5684 em DTLS) é possível oferecer e encontrar recursos entre nós de uma rede CoAP. Discovery permite a configuração automática, eliminando configurações manuais entre nós, além de uma lista dos recursos do servidor para o cliente junto com seus media types.
Alternativamente pode-se utilizar o endereço multicast 224.0.1.187 ou FF0X::FD.
NON são sempre QoS 0 (fire and forget).
Diferente do HTTP, há a possibilidade de usando o campo de options Accept no request escolher um formato preferencial da response. Caso o formato não possa ser retornado gera erro 4.06 (NOT ACCEPTABLE).
Sendo a versão do TLS sobre TCP no HTTP para o CoAP, Datagrama TLS sobre UDP define configurações mínimas de segurança para o CoAP, como unicast only. Os 4 modos de segurança definidos são NoSec, PreSharedKey, RawPublicKey e Certificate. Somente NoSec e RawPublicKey são obrigatórios.
O envio de pacotes de uma fonte falsa através de pacotes UDP. O atacante envia uma mensagem a um CoAP endpoint com um endereço de source falso e a vítima recebe os pacotes que são interpretados por um protocolo diferente. Este é um método capaz de burlar firewall uma vez que a comunicação do atacante com a vítima passa por um endpoint válido na rede.
Uma vez que não há handshake um endpoint indesejado pode escrever e ler mensagens na Constrained Network. Caso um RST seja enviado a um nó que enviou um CON ou NON haverá negação de serviço (DoS).
Pensado como protocolo para dispositivos de capacidade restrita, a arquitetura REST do CoAP a relação cliente-servidor.
Uma forma de se classificar estes dispositivos utilizada é dividí-los entre Constrained Device Application (CDA) e Gateway Device Application (GDA).
CDAs normalmente são os microcontroladores da borda como os utilizados no arduino e raspberry pi pico.
GDAs normalmente utilizam hardware um pouco mais robusto para possibilitar a comunicação com múltiplos CDAs e podem ser outros microcontroladores, mini-computadores como raspberry pi.
Pensando em uma solução na qual CDAs fazem a leitura de sensores, é normal pensar em CDAs apenas como clientes. Porém a natureza do protocolo permite o envio de dados ao CDA através dos métodos GET e PUT para acionar um atuador, por exemplo.
Utilizando multicast para enviar um única mensagem para vários endpoints onde requests são enviados por um IP multicast e responses recebidas com um IP unicast, aplicações para IoT como observabilidade e notificação de recursos em um servidor são resolvidas para o mesmo grupo que compartilha e depende das informações desta rede. A norma de segurança DTLS não comporta multicast, portanto este modelo deve ser utilizado com restrição e moderação.
Uma vez que HTTP e CoAP possuem métodos semelhantes há uma maneira de mapear HTTP para CoAP e vice-versa através de proxying. O CoAP-HTTP proxying acessa recursos HTTP através de um intermediário. Este é iniciado incluindo a Proxy-URI ou Proxy-Scheme Option com uma URI http/https em um request CoAP para um CoAP-HTTP Proxy. Da mesma forma o HTTP-CoAP proxying permite acessar recursos CoAP através de um proxy intermediário via HTTP.
Diferente do seu maior "concorrente" MQTT, o CoAP por sua natureza UDP busca resolver problemas de topologia de rede como descoberta de serviços e metodologias de trocas de dados através do discovery e também suporte a multicast. O CoAP está expandindo dentro de redes como LWM2M (Lightweight Machine to Machine) e semelhantes devido as suas características focadas em interoperabilidade. Desta maneira, as novas iniciativas sobre o CoAP focam em segurança, gerenciamento e suporte a comunicação em grupo.
[1] RFC 7252: The Constrained Application Protocol (CoAP)
[2] D. Hanes, G. Salgueiro, P. Grossetete, IoT Fundamentals: Networking Technologies, Protocols, and Use Cases for the Internet of Things
[3] A. C. King, Programming the Internet of Things: An Introduction to Building Integrated, Device-to-Cloud IoT Solutions
Este trabalho foi totalmente produzido pelos autores que declaram não terem violado os direitos autorais de terceiros, sejam eles pessoas físicas ou jurídicas. Havendo textos, tabelas e figuras transcritos de obras de terceiros com direitos autorais protegidos ou de domínio público tal como ideias e conceitos de terceiros, mesmo que sejam encontrados na Internet, os mesmos estão com os devidos créditos aos autores originais e estão incluídas apenas com o intuito de deixar o trabalho autocontido. O(s) autor(es) tem(êm) ciência dos Artigos 297 a 299 do Código Penal Brasileiro e também que o uso do artifício de copiar/colar texto de outras fontes e outras formas de plágio é um ato ilícito, condenável e passível de punição severa. No contexto da Universidade a punição não precisa se restringir à reprovação na disciplina e pode gerar um processo disciplinar que pode levar o(s) aluno(s) à suspensão
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.