CoAP

Definição

O CoAP, “Constrained Application Protocol”, ou, em uma tradução aproximada, “Protocolo de Aplicação Restrita”, foi desenvolvido pelo grupo de trabalho CoRE (Constrained Restful Environments) do IETF (SILVA; CARVALHO; NAZARIO, 2012).

O CoAP é um protocolo de transferência de informações da camada de aplicação baseado no método request-response, com o mesmo conjunto de operações básicas se comparado ao HTTP (GET, PUT, POST e DELETE), porém consideravelmente mais simples, consome menos memória, processamento e, consequentemente, energia (BORMANN; CASTELLANI; SHELBY, 2012).

O principal responsável pela redução da complexidade é o uso do UDP ao invés do TCP. O CoAP, diferentemente do UDP que não soluciona este problema, trata a perda de pacotes adicionando uma camada à mensagem para detecção e retransmissão dos pacotes. Por esse motivo, um cabeçalho CoAP tem apenas quatro bytes somados a dois bytes para opções e a resposta da requisição ocupa apenas um byte. Assim, uma requisição geralmente usa de 10 a 20 bytes (WESTPHALL, 2018).

A implementação do CoAP não se atém a um protocolo eficiente para a camada de aplicação, mas supera essa ideia viabilizando uma fácil compatibilidade com requisições HTTP através de proxies. Um proxy é um intermediário com um gateway, que com um lado se comunica usando certo protocolo e com outro lado se comunica usando um protocolo diferente, ou seja, é capaz de ligar protocolos diferente e permitir a troca de informações (BORMANN; CASTELLANI; SHELBY, 2012).

Figura 1 - Compatibilidade entre CoAP e HTTP via proxy

Fonte: BORMANN; CASTELLANI; SHELBY, 2012

Aplicação

Ele é bom em ambientes com recursos limitados: dispositivos com energia limitada, enlaces com baixa largura de banda, redes congestionadas ou com perdas. Em redes congestionadas, CoAP/UDP pode funcionar, porém o MQTT/TCP, alternativa ao CoAP, pode não ser nem capaz de administrar um handshake completo. CoAP pode ser usado onde broadcast e multicast são necessários (Comunicação multicast é uma relação de um para vários endpoints. Dispositivos limitados podem ser associados tanto por sua posição ou propósito, e essas relações podem tanto ser pré-configuradas ou configuradas durante as operações. Exemplo: um grupo de interruptores CoAP onde um simples comando de comunicação para o grupo pode acender ou apagar todas as luzes de um andar específico de um prédio). CoAP é adequado na construção de algo no qual um dispositivo é implantado em modo "report only". Uma vez implantado, o dispositivo apenas reporta dados de volta para o servidor. O CoAP é adequado para redes de comunicações domésticas, posto que ferramentas informativas, equipamentos de controle e de comunicação em redes de Casas Inteligentes precisam ser leves e ter baixo custo (SILVA; CARVALHO; NAZARIO, 2012).

Funcionamento

Figura 2 – Camadas abstratas do CoAP

 

Fonte: SILVA; CARVALHO; NAZARIO, 2012

 

As aplicações podem fazer requisições ou receber repostas, sendo que estas mensagens são tratadas pelo protocolo de segurança DTLS e enviadas via UDP.

 

Figura 3 – Cabeçalho CoAP

Fonte: BORMANN, 2014

Segundo Westphall (2018) os componentes do cabeçalho são:

Version: Indica a versão do protocolo usada, para que os dois lados da comunicação saibam qual versão do protocolo seguir. Caso um valor não conhecido esteja nesse campo, a mensagem deve ser ignorada.

Type:

• Confirmable (0): Mensagem enviada deve ser confirmada pelo receptor através de um “Acknowledgement”, para mensagens com confiabilidade. Essa mensagem é retransmitida com intervalos que crescem exponencialmente até o recebimento do “Ack” ou “Reset”.
• Non-Confirmable(1): Mensagem enviada deve não ser confirmada com “Acknowledgement” e rejeitada caso o receptor não seja capaz de entendê-la.
• Acknowledgement (2): Mensagem enviada como primeira resposta de uma mensagem do tipo Confirmable, identificando o ID da mensagem que está sendo confirmada, indicando seu recebimento.
• Reset (3): Indica que uma mensagem (Confirmable ou Non-Confirmable) foi recebida, mas o receptor não pôde processar adequadamente, provavelmente por não conhecer o contexto adequado da mensagem.

Token Lengh: Indica o tamanho do campo Token, na segunda linha do cabeçalho.

Code: Indica o tipo de requisição que está sendo feita, semelhante ao HTTP, o CoAP implementa os métodos básicos GET, POST, PUT e DELETE. Tratando-se de uma resposta, o campo Code indica o código da resposta pertencendo a uma das três classes: sucesso, erro do cliente ou erro do servidor.

Message ID: É um identificador, normalmente sequencial, para cada mensagem enviada por determinado emissor, o qual não deve ser reutilizado até o “Ack” não ser mais esperado pelo emissor da mensagem.

Token: Contendo de 0 a 8 bytes de informação útil, serve para relacionar a requisição à determinada resposta. Idealmente, deve ser implementado de maneira que o token para o par cliente-servidor seja único.

Options: É um campo usado para definir informações como: URI do destinatário da mensagem, porta do destinatário, caminho do recurso, query (em caso de parametrização), formato do payload, formato de conteúdo aceito como resposta, tempo limite para cache, condicionais de formato como resposta e outras.

Payload: O payload de uma mensagem é a representação do recurso requisitado ao servidor, em caso de GET, ou do recurso enviado ao servidor, em caso de POST ou PUT. Exemplificando: se o cliente fizer a requisição na URI "humidade", e o servidor possuir a informação de que a humidade é de 50%, então essa informação será retornada no campo de payload.

Transmissão de Dados Grandes

O UDP ordena os pacotes enviados, ou seja, a ordem é aleatória, então transmissões muito grandes formadas por mais de um pacote seriam desordenadas em situações como, por exemplo, uma atualização de firmware, essa situação não seria aplicada em simples leituras de sensores, mas em casos em que outras funções maiores são requisitadas (WESTPHALL, 2018).

Para resolver esse problema o CoAP possui uma versão com transmissão em blocos. Cada bloco é enviado com um identificador e uma flag informando se ele é o último bloco. Sendo que cada envio é respondido por um ACK, evitando assim as perdas de pacotes (BORMANN, 2016).

Função Observador

Na arquitetura REST, na maioria das vezes que um cliente deseja receber uma informação do servidor essa ação deve ser feita através de um comando GET para cada leitura. Dessa maneira, caso o cliente deseje receber uma informação periodicamente, ele deve enviar um GET nos intervalos de tempo desejado. No entanto, dispositivos com restrições energéticas permanecem hibernando por muito tempo e o momento em que o comando GET é enviado pode coincidir com o momento de hibernação. Além disso, lidar com GETs periodicamente sobrecarrega o dispositivo. Para não haver perdas de requisições, nem sobrecarga de dispositivos, o CoAP tem a Função Observador. Com esta função, o cliente envia um GET, com uma flag indicando o desejo de atualização periódica, ao servidor (sensor, microcontrolador etc.). O sensor, então, dorme sem perder requisições e envia periodicamente o dado especificado no GET (WESTPHALL, 2018).

Segurança

Assim como o HTTP é combinado com o TLS (Transport Layer Security) com objetivo de obter segurança nas trocas de mensagens, o CoAP é combinado com o DTLS (Datagram Transport Layer Security), para obter segurança semelhante à presente na Web. Desse modo em um sistema que utiliza CoAP ela pode estar sem segurança (NoSec), apresentar um par de chaves pré-estabelecido (Pre-shared key (PSKs)), apresentar um par assimétrico de chaves sem certificado (Raw Public Key) ou as chaves assimétricas apresentam um certificado X.509 (SILVA; CARVALHO; NAZARIO, 2012).

Em muitos casos, a maneira mais desejável para garantir segurança entre cliente e servidor seria usando o TLS, todavia o uso do UDP não permite que o TLS seja utilizado, por isso o DTLS (TLS para datagramas) foi projetado para ser o mais similar ao TLS possível, minimizando novas invenções de seguranças e possibilitando aproveitamento de código e estrutura do TLS (RESCORLA, 2012).

Figura 4 – Registro DTLS

 

Fonte: KOTHMAYR et al., 2013

Segundo Westphall (2018) os componentes do registro são:

Tipo de Conteúdo da Mensagem: Como no TLS, uma mensagem pode representar quatro situações diferentes: estabelecimento do handshake, mudança de protocolos de segurança, alerta de possível comprometimento de segurança ou uma mensagem da aplicação.

Versão do DTLS: Versões diferentes do DTLS possuem diferentes recursos, algoritmos e maneiras de tratar erros. Por isso, no cabeçalho existe o campo para indicar a versão do protocolo entre duas entidades, a fim de haver compatibilidade no uso do DTLS.

Número de sequência: A principal função do número de sequência é a reordenação de mensagens. No DTLS, cada mensagem recebe um número de sequência específico e quando um dispositivo recebe uma mensagem X ele consegue determinar se X é a próxima mensagem esperada. Se for, ela é processada. Se não for, X é direcionada a uma fila para ser processada no momento correto.

Época da mensagem: A época da mensagem é um campo incrementado a cada troca de configurações de segurança (cipher state change) e serve para mensagens serem interpretadas de acordo com as configurações adequadas. Durante a transmissão, os pacotes sofrem alteração de ordem, sendo posteriormente reordenados pelo número de sequência.

Vetor de Inicialização: Cifras de bloco possuem modos de operação como o CBC (Cipher Block Chaining), no qual a saída de um bloco é usado como entrada para cifrar o bloco seguinte. Na cifra do primeiro bloco é usado um vetor de inicialização, geralmente aleatório, necessário para o destinatário decifrar a mensagem.

Payload: O payload é a mensagem em si, que será interpretada pela aplicação após decifração.

MAC: Assim como no TLS, o MAC é calculado para verificação de integridade e autenticidade da mensagem enviada. Todavia, diferentemente do TLS, no DTLS um erro de MAC implica em um alerta e um descarte da mensagem, sem término de conexão. O MAC é calculado com base em uma chave e a concatenação dos campos presentes na Figura 8, considerando o payload em texto claro e excluindo os campos MAC, MAC cont, padding e PL.

CoAP x MQTT

Figura 5 – Comparação CoAP x MQTT

Fonte: ACERVO LIMA, 2021

Referências Bibliográficas

ACERVO LIMA. Diferença entre os protocolos CoAP e MQTT. [S. l.], 2021. Disponível em: https://acervolima.com/diferenca-entre-os-protocolos-coap-e-mqtt/. Acesso em: 14 jun. 2022.

BORMANN, C. The Constrained Application Protocol (CoAP). 2014. Disponível em: https://tools.ietf.org/html/rfc7252. Acesso em: 14 jun. 2022.

BORMANN, C. Block-Wise Transfers in the Constrained Application Protocol (CoAP). 2016. Disponível em: https://tools.ietf.org/html/rfc7959. Acesso em: 14 jun. 2022.

BORMANN, C.; CASTELLANI, A. P.; SHELBY, Z. Coap: An application protocol for billions of tiny internet nodes. IEEE Internet Computing, v. 16, n. 2, p. 62–67, March 2012. ISSN 1089-7801.

KOTHMAYR, T. et al. Dtls based security and two-way authentication for the internet of things. Ad Hoc Networks, v. 11, n. 8, p. 2710 – 2723, 2013. ISSN 1570-8705. Disponível em: http://www.sciencedirect.com/science/article/pii/S1570870513001029. Acesso em: 14 jun. 2022.

RESCORLA, E. Datagram Transport Layer Security Version 1.2. 2012. Disponível em: https://tools.ietf.org/html/rfc6347. Acesso em: 14 jun. 2022.

SILVA, Aryane Barros Maciel; CARVALHO, Felipe Fadul; NAZARIO, Mariana Dabul. Constrained Application Protocol. [S. l.], 2019. Disponível em: https://www.gta.ufrj.br/ensino/eel878/redes1-2019-1/vf/coap/index.html. Acesso em: 14 jun. 2022.

WESTPHALL, Johann. Desenvolvimento de uma Aplicação com dispositivo IoT usando Protocolos DTLS e CoAP. 2018. Trabalho de Conclusão de Curso (Grau de Bacharel em Ciências da Computação) - Universidade Federal de Santa Catarina, [S. l.], 2018. Disponível em: https://repositorio.ufsc.br/bitstream/handle/123456789/192164/Monografia_Johann_Westphall.pdf?sequence=1&isAllowed=y. Acesso em: 14 jun. 2022.

 

[ID:107] Autor:Leonardo Bonfim Lopes - Criado em: 2022-06-27 16:10:41 - [ Compartilhar ]