O desenvolvimento de tecnologias na área de software e hardware, o surgimento de novos protocolos de comunicação levaram à expansão da Internet das Coisas (IoT). O número de dispositivos cresce a cada dia e geram uma enorme quantidade de dados. Portanto, existe a necessidade de uma arquitetura de sistema conveniente, capaz de processar, armazenar e transmitir esses dados.
Agora, os serviços em nuvem são usados para esses fins. No entanto, o cada vez mais popular paradigma da computação em neblina (Fog) pode complementar as soluções em nuvem, ampliando e otimizando a infraestrutura de IoT.
As nuvens são capazes de cobrir a maioria das solicitações de IoT. Por exemplo, para proporcionar monitoramento de serviços, processamento rápido de qualquer quantidade de dados gerados pelos dispositivos, bem como sua visualização. A computação em névoa é mais eficaz na resolução de problemas em tempo real. Eles fornecem resposta rápida às solicitações e latência mínima no processamento de dados. Ou seja, o Fog complementa as “nuvens” e amplia suas capacidades.
Porém, a questão principal é diferente: como tudo isso deve interagir no contexto da IoT? Quais protocolos de comunicação serão mais eficazes ao trabalhar em um sistema combinado IoT-Fog-Cloud?
Apesar do aparente domínio do HTTP, há um grande número de outras soluções utilizadas em sistemas IoT, Fog e Cloud. Isso ocorre porque a IoT deve combinar a funcionalidade de uma variedade de sensores de dispositivos com a segurança, compatibilidade e outros requisitos dos usuários.
Mas simplesmente não existe uma ideia única sobre a arquitetura de referência e o padrão de comunicação. Portanto, criar um novo protocolo ou modificar um existente para tarefas específicas de IoT é uma das tarefas mais importantes que a comunidade de TI enfrenta.
Quais protocolos estão em uso atualmente e o que eles podem oferecer? Vamos descobrir. Mas primeiro, vamos discutir os princípios do ecossistema no qual as nuvens, a neblina e a Internet das coisas interagem.
Arquitetura IoT Fog-to-Cloud (F2C)
Você provavelmente já percebeu quanto esforço está sendo feito para explorar as vantagens e benefícios associados ao gerenciamento inteligente e coordenado de IoT, nuvem e nevoeiro. Caso contrário, aqui estão três iniciativas de padronização: , и .
Se anteriormente eram considerados apenas 2 níveis, nuvens e dispositivos finais, então a arquitetura proposta introduz um novo nível – a computação em neblina. Neste caso, o nível de neblina pode ser dividido em vários subníveis, dependendo das especificidades dos recursos ou de um conjunto de políticas que determinam a utilização de diferentes dispositivos nesses subníveis.
Como seria essa abstração? Aqui está um típico ecossistema IoT-Fog-Cloud. Os dispositivos IoT enviam dados para servidores e dispositivos de computação mais rápidos para resolver problemas que exigem baixa latência. No mesmo sistema, as nuvens são responsáveis por solucionar problemas que exigem grande quantidade de recursos computacionais ou espaço de armazenamento de dados.
Smartphones, relógios inteligentes e outros gadgets também podem fazer parte da IoT. Mas esses dispositivos, via de regra, usam protocolos de comunicação proprietários de grandes desenvolvedores. Os dados IoT gerados são transferidos para a camada fog por meio do protocolo REST HTTP, que fornece flexibilidade e interoperabilidade na criação de serviços RESTful. Isto é importante à luz da necessidade de garantir a compatibilidade retroativa com a infraestrutura de computação existente em execução em computadores locais, servidores ou clusters de servidores. Recursos locais, chamados “nós de neblina”, filtram os dados recebidos e os processam localmente ou os enviam para a nuvem para cálculos adicionais.
As nuvens suportam diferentes protocolos de comunicação, sendo os mais comuns AMQP e REST HTTP. Como o HTTP é bem conhecido e adaptado para a Internet, pode surgir a pergunta: “não deveríamos usá-lo para trabalhar com IoT e nevoeiro?” No entanto, este protocolo tem problemas de desempenho. Mais sobre isso mais tarde.
Em geral, existem 2 modelos de protocolos de comunicação adequados ao sistema que necessitamos. Estes são solicitação-resposta e publicação-assinatura. O primeiro modelo é mais conhecido, especialmente na arquitetura servidor-cliente. O cliente solicita informações do servidor e o servidor recebe a solicitação, processa-a e retorna uma mensagem de resposta. Os protocolos REST HTTP e CoAP operam neste modelo.
O segundo modelo surgiu da necessidade de fornecer acoplamento assíncrono, distribuído e fraco entre as fontes geradoras de dados e os destinatários desses dados.
O modelo assume três participantes: um editor (fonte de dados), um corretor (despachante) e um assinante (receptor). Aqui, o cliente que atua como assinante não precisa solicitar informações do servidor. Em vez de enviar solicitações, ele assina determinados eventos do sistema por meio de um corretor, que é responsável por filtrar todas as mensagens recebidas e encaminhá-las entre editores e assinantes. E o editor, quando ocorre algum evento referente a um determinado tema, publica para a corretora, que envia os dados sobre o tema solicitado ao assinante.
Essencialmente, esta arquitetura é baseada em eventos. E esse modelo de interação é interessante para aplicações em IoT, nuvem, nevoeiro devido à sua capacidade de fornecer escalabilidade e simplificar a interconexão entre diferentes dispositivos, suportar comunicação dinâmica muitos-para-muitos e comunicação assíncrona. Alguns dos protocolos de mensagens padronizados mais conhecidos que usam um modelo de publicação-assinatura incluem MQTT, AMQP e DDS.
Obviamente, o modelo publicar-assinar tem muitas vantagens:
- Editores e assinantes não precisam saber da existência um do outro;
- Um assinante pode receber informações de muitas publicações diferentes e um editor pode enviar dados para muitos assinantes diferentes (princípio de muitos para muitos);
- O publicador e o assinante não precisam estar ativos ao mesmo tempo para se comunicarem, pois o corretor (funcionando como um sistema de filas) poderá armazenar a mensagem para clientes que não estejam atualmente conectados à rede.
Contudo, o modelo solicitação-resposta também tem seus pontos fortes. Nos casos em que a capacidade do lado do servidor de lidar com múltiplas solicitações de clientes não é um problema, faz sentido usar soluções comprovadas e confiáveis.
Existem também protocolos que suportam ambos os modelos. Por exemplo, XMPP e HTTP 2.0, que suportam a opção “server push”. A IETF também lançou um CoAP. Na tentativa de resolver o problema do envio de mensagens, diversas outras soluções foram criadas, como o protocolo WebSockets ou a utilização do protocolo HTTP sobre QUIC (Quick UDP Internet Connections).
No caso do WebSockets, embora seja utilizado para transferir dados em tempo real de um servidor para um cliente web e forneça conexões persistentes com comunicação bidirecional simultânea, não se destina a dispositivos com recursos computacionais limitados. O QUIC também merece atenção, uma vez que o novo protocolo de transporte oferece muitas novas oportunidades. Mas como o QUIC ainda não está padronizado, é prematuro prever a sua possível aplicação e impacto nas soluções IoT. Portanto, mantemos WebSockets e QUIC em mente com os olhos postos no futuro, mas não iremos estudá-los com mais detalhes por enquanto.
Quem é o mais fofo do mundo: comparando protocolos
Agora vamos falar sobre os pontos fortes e fracos dos protocolos. Olhando para o futuro, façamos imediatamente uma reserva de que não existe um líder claro. Cada protocolo tem algumas vantagens/desvantagens.
Tempo de resposta
Uma das características mais importantes dos protocolos de comunicação, principalmente em relação à Internet das Coisas, é o tempo de resposta. Mas entre os protocolos existentes, não há um vencedor claro que demonstre o nível mínimo de latência ao trabalhar em diferentes condições. Mas há muitas pesquisas e comparações de capacidades de protocolo.
Por exemplo, comparações da eficácia de HTTP e MQTT ao trabalhar com IoT mostraram que o tempo de resposta para solicitações de MQTT é menor do que para HTTP. E quando O tempo de ida e volta (RTT) do MQTT e do CoAP revelou que o RTT médio do CoAP é 20% menor que o do MQTT.
Outro com RTT para os protocolos MQTT e CoAP foi realizado em dois cenários: rede local e rede IoT. Descobriu-se que o RTT médio é 2 a 3 vezes maior em uma rede IoT. O MQTT com QoS0 apresentou resultado inferior em relação ao CoAP, e o MQTT com QoS1 apresentou RTT superior devido aos ACKs nas camadas de aplicação e transporte. Para diferentes níveis de QoS, a latência da rede sem congestionamento foi de milissegundos para MQTT e centenas de microssegundos para CoAP. Porém, vale lembrar que ao trabalhar em redes menos confiáveis, o MQTT rodando sobre TCP apresentará um resultado completamente diferente.
O tempo de resposta dos protocolos AMQP e MQTT aumentando a carga útil mostrou que com uma carga leve o nível de latência é quase o mesmo. Mas ao transferir grandes quantidades de dados, o MQTT demonstra tempos de resposta mais curtos. em mais um O CoAP foi comparado ao HTTP em um cenário de comunicação máquina a máquina com dispositivos implantados em veículos equipados com sensores de gás, sensores meteorológicos, sensores de localização (GPS) e uma interface de rede móvel (GPRS). O tempo necessário para transmitir uma mensagem CoAP pela rede móvel foi quase três vezes menor que o tempo necessário para usar mensagens HTTP.
Foram realizados estudos que compararam não dois, mas três protocolos. Por exemplo, desempenho dos protocolos IoT MQTT, DDS e CoAP em um cenário de aplicação médica utilizando um emulador de rede. O DDS superou o MQTT em termos de latência de telemetria testada sob uma variedade de condições de rede ruins. O CoAP baseado em UDP funcionou bem para aplicações que exigiam tempos de resposta rápidos; no entanto, por ser baseado em UDP, houve perda significativa e imprevisível de pacotes.
Largura de banda
MQTT e CoAP em termos de eficiência de largura de banda foram realizados como um cálculo da quantidade total de dados transmitidos por mensagem. O CoAP mostrou rendimento inferior ao MQTT ao transmitir mensagens pequenas. Mas ao comparar a eficiência dos protocolos em termos da relação entre o número de bytes de informação útil e o número total de bytes transferidos, o CoAP revelou-se mais eficaz.
em usando MQTT, DDS (com TCP como protocolo de transporte) e largura de banda CoAP, descobriu-se que CoAP geralmente apresentava consumo de largura de banda comparativamente menor, que não aumentava com o aumento da perda de pacotes de rede ou aumento da latência da rede, ao contrário do MQTT e DDS, onde havia um aumento na utilização da largura de banda nos cenários mencionados. Outro cenário envolveu um grande número de dispositivos transmitindo dados simultaneamente, o que é típico em ambientes IoT. Os resultados mostraram que para maior utilização é melhor usar CoAP.
Sob carga leve, o CoAP usou menos largura de banda, seguido pelo MQTT e REST HTTP. No entanto, quando o tamanho das cargas aumentou, o REST HTTP teve os melhores resultados.
Consumo de energia
A questão do consumo de energia é sempre de grande importância, principalmente num sistema IoT. Se Enquanto MQTT e HTTP consomem eletricidade, o HTTP consome muito mais. E CoAP é mais comparado ao MQTT, permitindo gerenciamento de energia. Porém, em cenários simples, o MQTT é mais adequado para troca de informações em redes da Internet das Coisas, especialmente se não houver restrições de energia.
Um experimento que comparou os recursos do AMQP e do MQTT em um ambiente de teste de rede sem fio móvel ou instável descobriu que o AMQP oferece mais recursos de segurança, enquanto o MQTT é mais eficiente em termos de energia.
segurança
A segurança é outra questão crítica levantada ao estudar o tema da Internet das Coisas e da computação em nuvem/nevoeiro. O mecanismo de segurança é normalmente baseado em TLS em HTTP, MQTT, AMQP e XMPP, ou DTLS em CoAP, e suporta ambas as variantes DDS.
TLS e DTLS começam com o processo de estabelecimento de comunicação entre os lados do cliente e do servidor para trocar conjuntos de criptografia e chaves suportadas. Ambas as partes negociam conjuntos para garantir que a comunicação posterior ocorra em um canal seguro. A diferença entre os dois está em pequenas modificações que permitem que o DTLS baseado em UDP funcione em uma conexão não confiável.
em Várias implementações diferentes de TLS e DTLS descobriram que o TLS fez um trabalho melhor. Os ataques ao DTLS foram mais bem-sucedidos devido à sua tolerância a erros.
No entanto, o maior problema com esses protocolos é que eles não foram originalmente projetados para uso em IoT e não foram projetados para funcionar no nevoeiro ou na nuvem. Através do handshaking, eles adicionam tráfego adicional a cada estabelecimento de conexão, o que esgota recursos computacionais. Em média, há um aumento de 6,5% para TLS e 11% para DTLS em overhead em comparação com comunicações sem camada de segurança. Em ambientes ricos em recursos, que normalmente estão localizados em nível, isso não será um problema, mas na conexão entre IoT e nível de neblina, isso se torna uma limitação importante.
O que escolher? Não há resposta clara. MQTT e HTTP parecem ser os protocolos mais promissores, pois são considerados soluções de IoT comparativamente mais maduras e mais estáveis em comparação com outros protocolos.
Soluções baseadas em protocolo de comunicação unificada
A prática de uma solução de protocolo único tem muitas desvantagens. Por exemplo, um protocolo adequado a um ambiente restrito pode não funcionar em um domínio que tenha requisitos de segurança rígidos. Com isso em mente, resta-nos descartar quase todas as soluções possíveis de protocolo único no ecossistema Fog-to-Cloud em IoT, exceto MQTT e REST HTTP.
REST HTTP como uma solução de protocolo único
Há um bom exemplo de como as solicitações e respostas REST HTTP interagem no espaço IoT-to-Fog: . Os animais são equipados com sensores vestíveis (cliente IoT, C) e controlados via computação em nuvem por um sistema de agricultura inteligente (servidor Fog, S).
O cabeçalho do método POST especifica o recurso a modificar (/farm/animals), bem como a versão HTTP e o tipo de conteúdo, que neste caso é um objeto JSON que representa a fazenda de animais que o sistema deve gerenciar (Dulcinea/cow) . A resposta do servidor indica que a solicitação foi bem-sucedida enviando o código de status HTTPS 201 (recurso criado). O método GET deve especificar apenas o recurso solicitado no URI (por exemplo, /farm/animals/1), que retorna uma representação JSON do animal com aquele ID do servidor.
O método PUT é usado quando algum registro de recurso específico precisa ser atualizado. Neste caso, o recurso especifica o URI do parâmetro a ser alterado e o valor atual (por exemplo, indicando que a vaca está andando no momento, /farm/animals/1? state=walking). Finalmente, o método DELETE é usado igualmente ao método GET, mas simplesmente exclui o recurso como resultado da operação.
MQTT como uma solução de protocolo único
Vamos usar o mesmo farm inteligente, mas em vez de REST HTTP usamos o protocolo MQTT. Um servidor local com a biblioteca Mosquitto instalada atua como corretor. Neste exemplo, um computador simples (chamado de servidor farm) Raspberry Pi serve como um cliente MQTT, implementado por meio de uma instalação da biblioteca Paho MQTT, que é totalmente compatível com o corretor Mosquitto.
Este cliente corresponde a uma camada de abstração IoT que representa um dispositivo com capacidades de detecção e computação. Já o mediador corresponde a um nível de abstração superior, representando um nó de computação em névoa caracterizado por maior capacidade de processamento e armazenamento.
No cenário de fazenda inteligente proposto, o Raspberry Pi se conecta ao acelerômetro, GPS e sensores de temperatura e publica dados desses sensores em um nó de neblina. Como você provavelmente sabe, o MQTT trata os tópicos como uma hierarquia. Um único publicador MQTT pode publicar mensagens para um conjunto específico de tópicos. No nosso caso, existem três deles. Para um sensor que mede a temperatura em um celeiro de animais, o cliente seleciona um tema (fazenda/galpão/temperatura). Para sensores que medem a localização GPS e o movimento dos animais através do acelerômetro, o cliente publicará atualizações para (animalfarm/animal/GPS) e (animalfarm/animal/movement).
Essas informações serão repassadas à corretora, que poderá armazená-las temporariamente em um banco de dados local, caso outro assinante interessado apareça posteriormente.
Além do servidor local, que atua como um corretor MQTT no nevoeiro e para o qual Raspberry Pis, atuando como clientes MQTT, envia dados do sensor, pode haver outro corretor MQTT no nível da nuvem. Neste caso, as informações transmitidas ao corretor local podem ser armazenadas temporariamente em um banco de dados local e/ou enviadas para a nuvem. O corretor fog MQTT nesta situação é usado para associar todos os dados ao corretor MQTT em nuvem. Com esta arquitetura, um usuário de aplicativo móvel pode ser assinante de ambas as corretoras.
Caso a conexão com um dos corretores (por exemplo, nuvem) falhe, o usuário final receberá informações do outro (nevoeiro). Esta é uma característica dos sistemas combinados de neblina e computação em nuvem. Por padrão, o aplicativo móvel pode ser configurado para se conectar primeiro ao broker MQTT de névoa e, se isso falhar, para se conectar ao broker MQTT de nuvem. Esta solução é apenas uma entre muitas em sistemas IoT-F2C.
Soluções multiprotocolo
As soluções de protocolo único são populares devido à sua implementação mais fácil. Mas está claro que em sistemas IoT-F2C faz sentido combinar diferentes protocolos. A ideia é que diferentes protocolos possam operar em diferentes níveis. Tomemos, por exemplo, três abstrações: as camadas de IoT, nevoeiro e computação em nuvem. Os dispositivos no nível IoT são geralmente considerados limitados. Para esta visão geral, vamos considerar as camadas de IoT como as mais restritas, a nuvem como as menos restritas e a computação em névoa como "em algum lugar no meio". Acontece então que entre IoT e abstrações de nevoeiro, as soluções de protocolo atuais incluem MQTT, CoAP e XMPP. Já entre fog e cloud, o AMQP é um dos principais protocolos utilizados, junto com REST HTTP, que por sua flexibilidade também é utilizado entre IoT e camadas de fog.
O principal problema aqui é a interoperabilidade dos protocolos e a facilidade de transferência de mensagens de um protocolo para outro. Idealmente, no futuro, a arquitetura de um sistema de Internet das Coisas com recursos de nuvem e nevoeiro será independente do protocolo de comunicação utilizado e garantirá uma boa interoperabilidade entre os diferentes protocolos.
Como este não é o caso atualmente, faz sentido combinar protocolos que não apresentem diferenças significativas. Para este fim, uma solução potencial é baseada na combinação de dois protocolos que seguem o mesmo estilo arquitetural, REST HTTP e CoAP. Outra solução proposta é baseada na combinação de dois protocolos que oferecem comunicação de publicação-assinatura, MQTT e AMQP. Usar conceitos semelhantes (tanto MQTT quanto AMQP usam corretores, CoAP e HTTP usam REST) torna essas combinações mais fáceis de implementar e requer menos esforço de integração.
A Figura (a) mostra dois modelos baseados em solicitação-resposta, HTTP e CoAP, e sua possível colocação em uma solução IoT-F2C. Como o HTTP é um dos protocolos mais conhecidos e adotados nas redes modernas, é improvável que seja completamente substituído por outros protocolos de mensagens. Entre os nós que representam dispositivos poderosos localizados entre a nuvem e a neblina, REST HTTP é uma solução inteligente.
Por outro lado, para dispositivos com recursos computacionais limitados que se comunicam entre as camadas Fog e IoT, é mais eficiente utilizar CoAP. Uma das grandes vantagens do CoAP é na verdade a sua compatibilidade com HTTP, uma vez que ambos os protocolos são baseados em princípios REST.
A Figura (b) mostra dois modelos de comunicação de publicação-assinatura no mesmo cenário, incluindo MQTT e AMQP. Embora ambos os protocolos possam hipoteticamente ser usados para comunicação entre nós em cada camada de abstração, sua posição deve ser determinada com base no desempenho. O MQTT foi projetado como um protocolo leve para dispositivos com recursos computacionais limitados, para que possa ser usado para comunicação IoT-Fog. AMQP é mais adequado para dispositivos mais potentes, o que o posicionaria idealmente entre nós de neblina e nuvem. Em vez do MQTT, o protocolo XMPP pode ser usado na IoT por ser considerado leve. Mas não é tão amplamente utilizado em tais cenários.
Descobertas
É improvável que um dos protocolos discutidos seja suficiente para cobrir todas as comunicações num sistema, desde dispositivos com recursos computacionais limitados até servidores em nuvem. O estudo descobriu que as duas opções mais promissoras que os desenvolvedores mais usam são MQTT e RESTful HTTP. Esses dois protocolos não são apenas os mais maduros e estáveis, mas também incluem muitas implementações e recursos online bem documentados e bem-sucedidos.
Devido à sua estabilidade e configuração simples, o MQTT é um protocolo que comprovou seu desempenho superior ao longo do tempo quando usado no nível IoT com dispositivos limitados. Em partes do sistema onde a comunicação limitada e o consumo de bateria não são um problema, como alguns domínios de neblina e a maior parte da computação em nuvem, o RESTful HTTP é uma escolha fácil. O CoAP também deve ser levado em consideração, pois também está evoluindo rapidamente como um padrão de mensagens IoT e é provável que atinja um nível de estabilidade e maturidade semelhante ao MQTT e HTTP num futuro próximo. Mas o padrão está evoluindo atualmente, o que traz problemas de compatibilidade de curto prazo.
O que mais você pode ler no blog?
→
→
→
→
→
Assine o nosso -channel para não perder o próximo artigo! Escrevemos no máximo duas vezes por semana e apenas a negócios.
Fonte: habr.com