O desenvolvimento de tecnologias na área de software e hardware, juntamente com o surgimento de novos protocolos de comunicação, levou à expansão da Internet das Coisas (IoT). O número de dispositivos cresce diariamente, gerando um enorme volume de dados. Portanto, há uma necessidade de uma arquitetura de sistema conveniente, capaz de processar, armazenar e transmitir esses dados.
Atualmente, serviços em nuvem são utilizados para esses fins. No entanto, a crescente popularidade da paradigma de computação em névoa (Fog) pode complementar as soluções em nuvem, escalando e otimizando a infraestrutura da IoT.
As 'nuvens' podem atender à maioria das demandas da IoT. Por exemplo, oferecem monitoramento de serviços, rápida processamento de qualquer volume de dados gerados pelos dispositivos, além de sua visualização. A computação em névoa é mais eficaz para resolver tarefas em tempo real. Ela proporciona uma resposta rápida a solicitações e uma baixa latência no processamento de dados. Ou seja, o Fog complementa as 'nuvens', ampliando suas capacidades.
No entanto, a questão principal é outra: como tudo isso deve interagir no contexto da IoT? Quais protocolos de comunicação serão mais eficazes ao operar em um sistema unificado IoT-Fog-Cloud?
Apesar da aparente dominância do HTTP, um grande número de outras soluções é utilizado nos sistemas de IoT, Fog e Cloud. Isso se deve ao fato de que a IoT deve combinar as capacidades funcionais de diversos sensores de dispositivos com segurança, compatibilidade e outras exigências dos usuários.
Entretanto, não existe uma visão unificada sobre a arquitetura padrão e o protocolo de comunicação. Portanto, a criação de um novo protocolo ou a adaptação de um existente para as necessidades específicas da IoT é uma das principais tarefas enfrentadas pela comunidade de TI.
Quais protocolos estão sendo utilizados atualmente e o que podem oferecer? Vamos analisar isso. Mas, primeiro, discutiremos os princípios da ecossistema onde interagem nuvens, névoa e Internet das Coisas.
Arquitetura IoT Fog-to-Cloud (F2C)
Você certamente notou o quanto esforços significativos estão sendo feitos para estudar os benefícios e vantagens associados à gestão racional e coordenada de IoT, nuvens e névoa. Caso contrário, aqui estão três iniciativas para padronização: , e .
Se anteriormente considerávamos apenas 2 níveis, nuvens e dispositivos finais, a arquitetura proposta introduz um novo nível — a computação em névoa. Nesse modelo, o nível de névoa pode ser dividido em vários subníveis, dependendo das especificidades dos recursos ou do conjunto de políticas que definem o uso de diferentes dispositivos nesses subníveis.
Como poderia ser essa abstração? Aqui está um ecossistema típico de IoT-Névoa-Nuvem. Dispositivos IoT enviam dados para servidores e dispositivos computacionais mais poderosos, a fim de resolver tarefas que requerem um baixo nível de latência. Nesse mesmo sistema, as nuvens são responsáveis pela resolução de tarefas que exigem um alto volume de recursos computacionais ou espaço de armazenamento.
Smartphones, relógios inteligentes e outros gadgets também podem fazer parte da IoT. No entanto, esses dispositivos geralmente utilizam protocolos de comunicação proprietários de grandes desenvolvedores. Os dados gerados pela internet das coisas são transferidos para o nível de névoa através do protocolo REST HTTP, que garante flexibilidade e compatibilidade funcional na criação de serviços RESTful. Isso é importante à luz da necessidade de garantir a compatibilidade com a infraestrutura computacional existente, que opera em computadores locais, servidores ou clusters de servidores. Recursos locais, chamados de "nós da névoa", 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, entre os quais os mais comuns são AMQP e REST HTTP. Como o HTTP é amplamente conhecido e projetado para a internet, uma pergunta pode surgir: "não deveríamos usá-lo para trabalhar com IoT e névoa?". No entanto, esse protocolo possui problemas de desempenho. A esse respeito, falaremos mais adiante.
De modo geral, existem 2 modelos de protocolos de comunicação adequados para o sistema que precisamos. Estes são o modelo de solicitação-resposta e o de publicação-assinatura. O primeiro modelo é mais amplamente conhecido, especialmente na arquitetura cliente-servidor. O cliente solicita informações ao servidor, que recebe a solicitação, processa-a e retorna uma mensagem de resposta. Os protocolos REST HTTP e CoAP funcionam segundo esse modelo.
O segundo modelo surgiu da necessidade de garantir uma conexão assíncrona, distribuída e fraca entre as fontes que geram dados e os destinatários desses dados.
O modelo envolve três participantes: o editor (fonte de dados), o corretor (gerenciador) e o assinante (destinatário). Aqui, o cliente, atuando como assinante, não deve solicitar informações ao servidor. Em vez de enviar consultas, ele se inscreve em determinados eventos no sistema através do corretor, responsável por filtrar todas as mensagens recebidas e roteá-las entre editores e assinantes. E o editor, quando ocorre um evento relacionado a um determinado tópico, publica isso ao corretor, que envia os dados ao assinante sobre o tópico solicitado.
Essencialmente, essa arquitetura é baseada em eventos. E esse modelo de interação é interessante para aplicações em IoT, nuvem e neblina devido à sua capacidade de garantir escalabilidade e simplificar a interconexão entre diferentes dispositivos, suportando uma comunicação dinâmica de 'muitos para muitos' e comunicação assíncrona. Dentre os protocolos padronizados de troca de mensagens que utilizam o modelo de 'publicação-assinatura', destacam-se o MQTT, AMQP e DDS.
É claro que o modelo de 'publicação-assinatura' possui uma série de vantagens:
- Editores e assinantes não precisam saber da existência um do outro;
- Um assinante pode receber informações de várias publicações diferentes, enquanto um editor pode enviar dados para vários assinantes diferentes (princípio de 'muitos para muitos');
- O editor e o assinante não precisam estar ativos ao mesmo tempo para a troca de dados, pois o corretor (que atua como um sistema de filas) pode armazenar a mensagem para clientes que não estão atualmente conectados à rede.
No entanto, o modelo de 'solicitação-resposta' também tem suas vantagens. Em situações onde as capacidades do lado do servidor para processar solicitações de vários clientes não são um problema, faz sentido usar soluções já testadas 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". O IETF também lançou o CoAP. Na tentativa de resolver o problema da troca de mensagens, várias outras soluções foram criadas, como o protocolo WebSockets ou o uso do protocolo HTTP sobre QUIC (Quick UDP Internet Connections).
No caso do WebSockets, embora seja utilizado para transmitir dados em tempo real do servidor para o cliente web e forneça conexões permanentes com comunicação bidirecional simultânea, ele não é destinado a dispositivos com recursos computacionais limitados. O QUIC também merece atenção, pois o novo protocolo de transporte oferece uma série de novas possibilidades. Mas, como o QUIC ainda não foi padronizado, é prematuro prever sua possível aplicação e impacto nas soluções em IoT. Portanto, deixamos o WebSockets e o QUIC na memória com um olhar para o futuro, mas não vamos estudá-los em detalhes por enquanto.
Quem é o mais querido do mundo: comparando protocolos
Agora vamos falar sobre os pontos fortes e fracos dos protocolos. Antecipando, já deixamos claro que não há um líder absoluto. Cada protocolo tem seus prós e contras.
Tempo de resposta
Uma das características mais importantes dos protocolos de comunicação, especialmente no que diz respeito à Internet das Coisas, é o tempo de resposta. Mas entre os protocolos existentes, não há um vencedor absoluto que demonstre o menor nível de latência em diferentes condições. No entanto, há uma série de pesquisas e comparações das capacidades dos protocolos.
Por exemplo, Comparações de desempenho entre HTTP e MQTT no trabalho com IoT mostraram que o tempo de resposta para requisições no MQTT é menor do que no HTTP. E ao o tempo de envio e recebimento (RTT), descobriu-se que o RTT médio do CoAP é 20% menor do que o do MQTT.
Outro O RTT dos protocolos MQTT e CoAP foi medido em dois cenários: em rede local e em rede IoT. Descobriu-se que o RTT médio é de 2 a 3 vezes maior na rede IoT. O MQTT com QoS0 apresentou um desempenho inferior em comparação ao CoAP, enquanto o MQTT com QoS1 demonstrou um RTT mais alto devido ao ACK em níveis aplicativo e de transporte. Para diferentes níveis de QoS, as latências em uma rede não congestionada para o MQTT foram de milissegundos, enquanto para o CoAP, foram de centenas de microssegundos. No entanto, vale lembrar que, ao operar em redes menos confiáveis, o MQTT, que opera sobre TCP, mostrará resultados completamente diferentes.
O tempo de resposta dos protocolos AMQP e MQTT, ao aumentar a carga útil, mostrou que, em baixa carga, o nível de latência é quase o mesmo. No entanto, ao transferir grandes volumes de dados, o MQTT demonstra um tempo de resposta menor. Em outra O CoAP foi comparado ao HTTP em um cenário de comunicação máquina a máquina com dispositivos implantados em veículos e equipados com sensores de gás, sensores meteorológicos, localização (GPS) e 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 do que o tempo necessário para usar mensagens HTTP.
Foram realizados estudos que compararam não apenas dois, mas três protocolos. Por exemplo, a performance 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 em várias condições de rede adversas. O CoAP baseado em UDP funcionou bem para aplicativos que exigiam resposta rápida, no entanto, devido ao fato de ser baseado em UDP, houve uma perda de pacotes considerável e imprevisível.
Largura de banda
A eficiência do MQTT e do CoAP em relação ao uso da largura de banda foi medida como a quantidade total de dados transmitidos por mensagem. O CoAP apresentou menor largura de banda do que o MQTT ao transmitir pequenas mensagens. Mas ao comparar a eficiência dos protocolos em termos da relação entre a quantidade de bytes úteis de informação e o total de bytes transmitidos, o CoAP se mostrou mais eficiente.
Ao do uso da largura de banda do MQTT, DDS (com TCP como protocolo de transporte) e CoAP, foi constatado que o CoAP geralmente apresentava um consumo de largura de banda relativamente mais baixo, que não aumentava com o aumento das perdas de pacotes de rede ou maior latência da rede, ao contrário do MQTT e do DDS, onde, nos cenários mencionados, houve um aumento no uso da largura de banda. Em outro cenário, foi envolvido um grande número de dispositivos transmitindo dados simultaneamente, o que é comum em ambientes IoT. Os resultados mostraram que, para uma carga maior, o CoAP é mais vantajoso.
Sob uma carga leve, o CoAP usou a menor largura de banda, seguido pelo MQTT e REST HTTP. No entanto, quando o tamanho das cargas úteis aumentou, os melhores resultados foram obtidos com o REST HTTP.
Consumo de energia
A questão do consumo de energia sempre é de grande importância, especialmente em sistemas IoT. Se o consumo de eletricidade entre MQTT e HTTP, o HTTP consome muito mais. Já o CoAP é mais se comparado ao MQTT, permitindo um melhor controle de energia. Em cenários simples, o MQTT é mais adequado para troca de informações em redes de internet das coisas, especialmente quando não há restrições de potência.
Um experimento que comparou as capacidades do AMQP e do MQTT em um ambiente de rede móvel ou instável mostrou que o AMQP oferece mais opções em termos de segurança, enquanto o MQTT é mais eficiente em energia.
Segurança
A segurança é outra questão crucial levantada ao estudar o tema da internet das coisas e computação em névoa/nuvem. O mecanismo de segurança geralmente se baseia em TLS em HTTP, MQTT, AMQP e XMPP, ou DTLS no CoAP, além de suportar ambas as opções no DDS.
TLS e DTLS começam com o processo de estabelecimento de conexão entre os lados cliente e servidor para trocar os conjuntos de cifragem e chaves suportadas. Ambos os lados concordam sobre os conjuntos para garantir que a comunicação posterior ocorra em um canal seguro. A diferença entre eles reside em pequenas modificações que permitem que o DTLS, baseado em UDP, funcione em uma conexão não confiável.
Ao em várias implementações diferentes de TLS e DTLS, constatou-se que o TLS teve um desempenho melhor. Os ataques ao DTLS foram mais bem-sucedidos devido à sua tolerância a falhas.
No entanto, o maior problema desses protocolos é que eles foram originalmente projetados sem considerar o uso em IoT e não foram concebidos para operar em nuvens ou névoas. Através do handshaking, eles adicionam tráfego adicional a cada estabelecimento de conexão, o que esgota os recursos computacionais. Observa-se um aumento médio de 6,5% para TLS e 11% para DTLS na carga útil de controle em comparação com a comunicação sem nível de segurança. Em ambientes ricos em recursos, que geralmente estão localizados em No nível, isso não será um problema, mas na conexão entre IoT e o nível de neblina, isso se torna uma restrição importante.
O que escolher? Não há uma resposta definitiva. MQTT e HTTP parecem ser os protocolos mais promissores, pois são considerados soluções relativamente mais maduras e estáveis para IoT em comparação com outros protocolos.
Soluções baseadas em um único protocolo de comunicação
A prática de uma solução unificadora tem muitos ineficazes. Por exemplo, um protocolo que funciona bem em um ambiente restrito pode não funcionar em um domínio que possui requisitos de segurança rigorosos. Tendo isso em mente, temos que descartar quase todas as possíveis soluções baseadas em um único protocolo 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 interação entre solicitações e respostas REST HTTP na área de IoT-to-Fog: . Os animais são equipados com sensores vestíveis (IoT-cliente, C) e são gerenciados através da computação em nuvem de um sistema de agricultura inteligente (Fog-servidor, S).
No cabeçalho do método POST, é especificado o recurso a ser alterado (\/farm\/animals), bem como a versão do HTTP e o tipo de conteúdo, que neste caso é um objeto JSON representando a fazenda de gado que deve ser gerenciada pelo sistema (Dulcinéia\/vaca). 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 a representação JSON do animal com esse identificador do servidor.
O método PUT é utilizado quando é necessário atualizar um registro específico do recurso. Neste caso, no recurso, é especificado o URI para o parâmetro a ser alterado e o valor atual (por exemplo, que a vaca está atualmente pastando, \/farm\/animals\/1? estado=pastando). Por fim, o método DELETE é usado igualmente ao método GET, mas simplesmente remove o recurso como resultado da operação.
MQTT como uma solução de protocolo único
Vamos pegar a mesma fazenda inteligente, mas em vez do REST HTTP, usaremos o protocolo MQTT. Um servidor local com a biblioteca Mosquitto instalada atua como um corretor. Neste exemplo, um computador simples (designado como servidor da fazenda), o Raspberry Pi, serve como cliente MQTT, implementado através da instalação da biblioteca MQTT Paho, totalmente compatível com o corretor Mosquitto.
Este cliente corresponde ao nível de abstração IoT representando um dispositivo com capacidades de detecção e computação. O intermediário, por outro lado, corresponde a um nível de abstração mais alto, representando um nó de computação na névoa, caracterizado por grandes capacidades de processamento e armazenamento de dados.
No cenário proposto da 'fazenda inteligente', o Raspberry Pi se conecta a um acelerômetro, GPS e sensores de temperatura e publica os dados desses sensores em um nó de névoa. Como você provavelmente sabe, o MQTT considera os tópicos como uma hierarquia. Um publicador MQTT pode publicar mensagens em um conjunto específico de tópicos. No nosso caso, são três. Para o sensor que mede a temperatura no galpão de animais, o cliente escolhe o tópico (animalfarm/shed/temperature). Para os sensores que medem a localização GPS e o movimento dos animais através do acelerômetro, o cliente publica atualizações (animalfarm/animal/GPS) e (animalfarm/animal/movement).
Essas informações serão enviadas ao corretor, que pode temporariamente armazená-las em um banco de dados local, caso mais tarde apareça outro assinante interessado.
Além do servidor local atuando como corretor MQTT na névoa, e ao qual o Raspberry Pi, atuando como clientes MQTT, envia dados dos sensores, pode haver outro corretor MQTT em nível de nuvem. Nesse caso, as informações enviadas ao corretor local podem ser temporariamente armazenadas em um banco de dados local e/ou enviadas para a nuvem. O corretor MQTT da névoa, neste caso, é utilizado para conectar todos os dados ao corretor MQTT da nuvem. Com essa arquitetura, o usuário de um aplicativo móvel pode estar assinado em ambos os corretores.
Em caso de falha na conexão com um dos corretores (por exemplo, na nuvem), o usuário final receberá informações de outro (na neblina). Essa é uma característica típica dos sistemas combinados de nuvem e computação em neblina. Por padrão, o aplicativo móvel pode ser configurado para se conectar primeiro a um corretor MQTT na neblina, e em caso de falha, para se conectar a um corretor MQTT na nuvem. Essa solução é apenas uma das muitas em sistemas IoT-F2C.
Soluções multiprotocólo
Soluções com um único protocolo são populares devido à sua implementação mais fácil. No entanto, é evidente que, em sistemas IoT-F2C, faz sentido combinar diferentes protocolos. A ideia é que diferentes protocolos possam operar em diferentes níveis. Por exemplo, vamos considerar três abstrações: os níveis IoT, neblina e computação em nuvem. Dispositivos no nível IoT geralmente são considerados limitados. Para esta revisão, vamos considerar os níveis IoT como os mais limitados, a nuvem como a menos limitada e a computação em neblina como 'em algum lugar no meio'. Assim, entre IoT e as abstrações da neblina, as atuais soluções de protocolo incluem MQTT, CoAP e XMPP. Entre a neblina e a nuvem, por outro lado, o AMQP é um dos principais protocolos utilizados, junto com o REST HTTP, que, devido à sua flexibilidade, também é utilizado entre IoT e camadas de neblina.
O problema principal aqui é a compatibilidade funcional dos protocolos e a simplicidade da tradução de mensagens de um protocolo para outro. Idealmente, no futuro, a arquitetura do sistema de Internet das Coisas com recursos em nuvem e na neblina será independente do protocolo de comunicação utilizado e garantirá uma boa interoperabilidade entre diferentes protocolos.
Uma vez que isso ainda não é o caso, faz sentido combinar protocolos que não têm diferenças significativas. Para isso, uma solução potencial é baseada na combinação de dois protocolos que seguem o mesmo estilo arquitetônico, REST HTTP e CoAP. Outra solução proposta é baseada na combinação de dois protocolos que fornecem interação no modelo 'publicação-assinatura', MQTT e AMQP. O uso de conceitos semelhantes (tanto MQTT quanto AMQP usam corretores, enquanto CoAP e HTTP usam REST) simplifica a implementação dessas combinações e requer menos esforço de integração.
Na figura (a) estão modelos baseados em solicitações-respostas, HTTP e CoAP, e sua possível colocação na solução IoT-F2C. Uma vez que o HTTP é um dos protocolos mais conhecidos e adaptados nas redes modernas, é improvável que ele seja completamente substituído por outros protocolos de troca de mensagens. Entre os nós que representam dispositivos poderosos, que estão entre a nuvem e a névoa, o REST HTTP é uma solução razoável.
Por outro lado, para dispositivos com recursos computacionais limitados, que se conectam entre os níveis da névoa e IoT, é mais eficiente usar CoAP. Uma das grandes vantagens do CoAP é, na verdade, sua compatibilidade com o HTTP, uma vez que ambos os protocolos são baseados nos princípios REST.
Na figura (b) estão mostrados dois modelos de interação 'publicação-assinatura' em um cenário, incluindo MQTT e AMQP. Embora hipoteticamente ambos os protocolos possam ser usados para comunicação entre nós em cada nível de abstração, sua posição deve ser determinada com base no desempenho. O MQTT foi desenvolvido como um protocolo simplificado para dispositivos com recursos computacionais limitados, portanto, pode ser usado para comunicação entre IoT e névoa. O AMQP é mais adequado para dispositivos mais poderosos, que idealmente o colocariam entre nós da névoa e da nuvem. Em vez do MQTT, o protocolo XMPP pode ser usado na IoT, pois é considerado leve. Mas não é tão amplamente utilizado em tais cenários.
Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.
É improvável que um dos protocolos considerados seja suficiente para abranger toda a comunicação no sistema, desde dispositivos com recursos computacionais limitados até servidores em nuvem. A pesquisa mostrou que as duas opções mais promissoras, que os desenvolvedores usam com mais frequência, são MQTT e RESTful HTTP. Esses dois protocolos são não apenas os mais maduros e estáveis, mas também incluem uma série de implementações bem documentadas e bem-sucedidas e recursos online.
Devido à sua estabilidade e configuração simples, o MQTT é um protocolo que ao longo do tempo provou sua excelente performance em aplicações no nível de IoT com dispositivos limitados. Em partes do sistema onde a conectividade limitada e o consumo de bateria não são um problema, como em algumas áreas de computação em névoa e na maioria das computações em nuvem, o HTTP RESTful é uma escolha simples. O CoAP também deve ser considerado, pois está se desenvolvendo rapidamente como um padrão de troca de mensagens para IoT, e é bastante provável que em breve atinja um nível de estabilidade e maturidade semelhante ao MQTT e HTTP. Mas o padrão atualmente está em desenvolvimento, o que traz problemas de compatibilidade a curto prazo.
O que mais é útil para ler no blog
→
→
→
→
→
Inscreva-se no nosso -canal para não perder o próximo artigo! Publicamos no máximo duas vezes por semana e apenas conteúdo relevante.
Fonte: habr.com
