O Protocolo CoAP para IoT

Já falamos um pouco sobre o protocolo CoAP (Constrained Application Protocol – Protocolo de Aplicação Restrita) para a IoT (Internet of Things – Internet das coisas) aqui. Agora, neste artigo, voltamos com mais detalhes sobre esse protocolo definido pela RFC 7252.

O CoAP é um protocolo de transferência web especializado para uso com nós restritos em redes da Internet das Coisas. O protocolo é projetado para M2M (de máquina-para-máquina), como, por exemplo, aplicações em energia inteligente e automação predial.

O modelo de interação do CoAP é semelhante ao modelo cliente/servidor do protocolo HTTP. No entanto, as interações máquina-máquina normalmente resultam em uma implementação do CoAP que atua nas funções do cliente e do servidor.

Um pedido CoAP é equivalente ao do HTTP e é enviado por um cliente para solicitar uma ação (usando um Código de Método) em um recurso (identificado por uma URI) em um servidor. O servidor envia uma resposta com um código, sendo que esta resposta pode incluir uma representação de recursos.

Ao contrário do HTTP, o CoAP lida com esses intercâmbios de forma assíncrona ao longo de um transporte orientado a datagramas, como o UDP. Isso é feito logicamente usando uma camada de mensagens que suporta uma confiabilidade opcional (com back-off exponencial). O CoAP define quatro tipos de mensagens:

  • confirmação;
  • não confirmação;
  • reconhecimento;
  • reset.

O protocolo CoAP se posiciona, na arquitetura TCP/IP, entre as camadas de Aplicação e Transporte, criando duas subcamadas – Requisição/Resposta e Mensagem, conforme figura 1.

 

Posição do protocolo CoAP na Arquitetura TCP/IP
Figura 1 – Posição do protocolo na Arquitetura TCP/IP

 

Modelo de Mensagens

O modelo de mensagens CoAP baseia-se na troca de mensagens UDP entre os pontos finais, sendo que o CoAP usa um pequeno cabeçalho binário de comprimento fixo (4 bytes) que pode ser seguido de opções binárias compactas e uma carga útil. Este tipo de mensagem compartilha tanto as solicitações como as respostas.

Cada mensagem contém um identificador (ID) de mensagem usado para detectar duplicatas e para uma confiabilidade opcional. O ID da mensagem é compacto e seu tamanho de 16 bits permite até cerca de 250 mensagens por segundo, de um ponto final para outro, estabelecendo parâmetros desta conexão.

A confiabilidade é fornecida marcando uma mensagem como confirmável (CON). Uma mensagem confirmável, figura 2, é retransmitida usando um tempo limite padrão entre retransmissões, até o destinatário, enviando uma mensagem de confirmação (ACK) com o mesmo ID de mensagem.

 

Figura 2 – Transmissão de uma mensagem confiável
Figura 2 – Transmissão de uma mensagem confiável

 

Quando um destinatário não é capaz de processar uma mensagem como confirmável (não é capaz de fornecer uma resposta de erro adequada), ele responde com uma mensagem Reset (RST) em vez de um reconhecimento (ACK).

Uma mensagem que não requer transmissão confiável (por exemplo, uma única medida fora de um fluxo de dados de um sensor) pode ser enviada como uma mensagem não confirmável (NON). Estas não são reconhecidas, mas ainda têm um ID de mensagem para detecção duplicada (neste exemplo, 0x01a0, figura 3). Quando um destinatário não for capaz de processar uma mensagem não confirmável, pode-se responder com uma mensagem Reset (RST).

 

Figura 3 - Transmissão de mensagem não confirmável
Figura 3 – Transmissão de mensagem não confirmável

 

Como o CoAP é executado sobre UDP, que é um protocolo não confiável, também suporta o uso dos endereços multicast IP de destino, permitindo solicitações multicast CoAP, como precaução para evitar o congestionamento da resposta.

Vários modos de segurança são definidos para CoAP, que vão desde sem segurança para segurança baseada em certificados. A RFC especifica uma ligação ao DTLS para garantir o protocolo. O uso do IPsec com o CoAP também é discutido na RFC em [IPsec-CoAP].

 

Modelo de Solicitação/Resposta

A solicitação de CoAP e a semântica de resposta são realizadas nas mensagens do CoAP, que incluem um Código de Método ou Código de Resposta, respectivamente.

Informações de solicitação e resposta opcionais (ou padrão), como a URI, e tipo de mídia de carga são transportados como opções CoAP. Um Token é usado para corresponder as respostas aos pedidos, independentemente das mensagens subjacentes. (Observe que o Token é um conceito separado a partir da identificação da mensagem.)

Uma mensagem de pedido a um determinado elemento da IoT é enviada como confirmável (CON) ou não-confirmável (NON) e, se disponível imediatamente, a resposta a um pedido é também transportada em uma mensagem de confirmação (ACK), conforme figura 4. Isso é chamado de resposta piggybacked. (Não há necessidade de reconhecimento de uma das respostas encaminhadas, uma vez que o cliente irá retransmitir o pedido, se a mensagem de resposta for perdida). Na figura 4, temos dois exemplos para um pedido GET básico de um determinado valor de temperatura em um sensor, com uma resposta, mostrando o caso bem-sucedido com o retorno de 22,5ºC e um caso com erro ou resultando em uma resposta 4.04 (não encontrada).

 

Figura 4 – Dois pedidos GET com respostas encadeadas
Figura 4 – Dois pedidos GET com respostas encadeadas

 

Se o servidor não puder responder imediatamente a uma solicitação realizada em uma mensagem confirmável, ele simplesmente responde com um vazio de mensagem de confirmação para que o cliente possa parar de retransmitir o pedido. Quando a resposta está pronta, o servidor envia-o em uma nova mensagem confirmável (que, por sua vez, deve ser reconhecida pelo cliente). Isso é chamado de “resposta separada”, como ilustrado na figura 5.

 

Figura 5 – um pedido GET com uma resposta separada
Figura 5 – um pedido GET com uma resposta separada

 

Se uma solicitação for enviada em uma mensagem não confirmável, a resposta é enviada usando uma nova mensagem não confirmável, embora o servidor possa, em vez disso, enviar uma mensagem confirmável. Esse tipo de troca é ilustrado na figura 6.

 

Figura 6 – Um pedido e uma resposta realizada em mensagens não confirmáveis
Figura 6 – Um pedido e uma resposta realizada em mensagens não confirmáveis

 

O CoAP faz uso de métodos GET, PUT, POST e DELETE de forma semelhante ao HTTP. A semântica detalhada dos métodos CoAP possui algumas diferenças dos métodos HTTP. Para quem vai trabalhar com este protocolo, vale a pena ler a RFC para maior detalhamento e as diferenças em relação ao HTTP.

Além dos quatro métodos básicos mencionados anteriormente, podem ser adicionados ao CoAP, em separado, novos métodos que não precisam necessariamente usar pedidos e respostas em pares. Mesmo para os métodos existentes, um único pedido pode produzir respostas múltiplas, por exemplo, para um pedido de multicast  com a opção Observe (Observe especifica uma extensão de protocolo simples para CoAP que permite aos clientes do CoAP “observar” os recursos, ou seja, recuperar uma representação de um recurso e manter esta representação atualizada pelo servidor durante um período de tempo).

O suporte a URI em um servidor é simplificado, já que o cliente já analisa o URI e o divide em componentes de host, porta, caminho e consulta, fazendo uso de valores padronizados. Os códigos de resposta se relacionam para um pequeno subconjunto de códigos de status HTTP com alguns códigos específicos do CoAP.

 

Conclusão

Do ponto de vista do desenvolvedor, o CoAP se parece muito com o HTTP. Obter um valor de um sensor de pressão, temperatura, entre outros, não é muito diferente de obter um valor de uma API da Web.

Como o HTTP e o CoAP compartilham o modelo REST, eles podem ser facilmente conectados usando proxies inter-protocolos independentes do aplicativo. Um cliente da Web pode nem sequer perceber que ele acessou apenas um recurso de sensor.

 

Bibliografia

RFC 7252 – The Constrained Application Protocol (CoAP) – IETF Tools

 

3 opiniões sobre “O Protocolo CoAP para IoT

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *