IoT, nevoeiro e nuvens: fale sobre tecnologia?

O desenvolvimento de tecnologias no campo 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 está crescendo dia a dia e eles geram uma enorme quantidade de dados. Portanto, surge a necessidade de uma arquitetura de sistema conveniente, capaz de processar, armazenar e transmitir esses dados.

Agora eles usam serviços em nuvem para esses fins. No entanto, o crescente paradigma nebuloso (Fog) é capaz de complementar as soluções em nuvem, escalando e otimizando a infraestrutura da IoT.

As nuvens podem fechar a maioria das solicitações de IoT. Por exemplo, para fornecer serviços de monitoramento, processamento rápido de qualquer quantidade de dados gerados pelos dispositivos, bem como sua visualização. A computação confusa é mais eficaz na solução de problemas em tempo real. Eles fornecem resposta rápida às solicitações e atraso mínimo no processamento de dados. Ou seja, o Nevoeiro complementa exatamente as "nuvens", expande suas capacidades.

No entanto, 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 IoT-Fog-Cloud unificado?

Apesar do aparente domínio do HTTP, IoT, Fog e Cloud usam um grande número de outras soluções. Isso ocorre porque a IoT deve combinar a funcionalidade de uma variedade de sensores de dispositivo com a segurança, interoperabilidade e outros requisitos do usuário.

Aqui está apenas uma idéia da arquitetura de referência e do padrão de comunicação simplesmente não existe. Portanto, a criação de um novo protocolo ou o aprimoramento de um existente para tarefas específicas da IoT é uma das tarefas mais importantes que a comunidade de TI enfrenta.

Quais protocolos são usados ​​agora e o que eles podem oferecer? Vamos acertar. Mas primeiro, vamos discutir os princípios de um ecossistema no qual nuvens, névoa e a Internet das coisas interagem.

Arquitetura IoT Fog-to-Cloud (F2C)

Você deve ter notado quanto esforço foi feito para explorar os benefícios e benefícios do gerenciamento da IoT, nuvens e neblina de maneira racional e coordenada. Caso contrário, já existem três iniciativas de padronização: OpenFog Consortium , Edge Computing Consortium e mF2C H2020 EU project .

Se anteriormente apenas dois níveis, nuvens e dispositivos finais eram considerados, a arquitetura proposta introduz um novo nível - a computação em nevoeiro. Nesse 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 o uso 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 poderosos para resolver tarefas que exigem baixa latência. No mesmo sistema, as nuvens são responsáveis ​​por resolver problemas que exigem uma grande quantidade de recursos de computação ou espaço de armazenamento de dados.



Smartphones, smartwatches e outros gadgets também podem fazer parte da IoT. Mas esses dispositivos, como regra, usam protocolos de comunicação proprietários de grandes desenvolvedores. Os dados da IoT gerados são transmitidos para o nível de neblina através do protocolo HTTP REST, que fornece flexibilidade e interoperabilidade ao criar serviços RESTful. Isso é importante à luz da necessidade de compatibilidade com versões anteriores da infraestrutura de computação existente em execução em computadores, servidores ou cluster de servidores locais. Os recursos locais, chamados "nós do nevoeiro", filtram os dados recebidos e os processam localmente ou os enviam para a nuvem para cálculos adicionais.

As nuvens suportam vários protocolos de comunicação, entre os quais o AMQP e o REST HTTP são mais frequentemente encontrados. Como o HTTP é bem conhecido e aprisionado pela Internet, a pergunta pode surgir: “Mas devo usá-lo para trabalhar com a Internet das coisas e o 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 precisamos. Esta é uma 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 ele recebe a solicitação, as processa e retorna uma mensagem de resposta. Os protocolos REST HTTP e CoAP funcionam neste modelo.

O segundo modelo surgiu devido à necessidade de fornecer comunicaçã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), corretor (despachante) e assinante (destinatário). Aqui, o cliente que atua como assinante não deve solicitar informações do servidor. Em vez de enviar solicitações, ele se inscreve em determinados eventos no sistema por meio de um intermediário responsável por filtrar todas as mensagens recebidas e encaminhá-las entre editores e assinantes. E o publicador, quando ocorre um evento referente a um determinado tópico, o publica no broker, que envia os dados do assinante no tópico solicitado.

Em essência, essa arquitetura é orientada a eventos. E esse modelo de interação é interessante para aplicativos em IoT, nuvem e nevoeiro, devido à sua capacidade de fornecer escalabilidade e simplificar a interconexão entre diferentes dispositivos, para oferecer suporte à comunicação dinâmica muitos-para-muitos e comunicação assíncrona. Entre os protocolos de mensagens padronizados mais conhecidos que usam o modelo de publicação-assinatura estão MQTT, AMQP e DDS.

Obviamente, o modelo de publicação-assinatura tem muitas vantagens:

• Editores e assinantes não precisam saber sobre a 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 (o princípio “muitos para muitos”);
• O publicador e o assinante não precisam estar ativos simultaneamente para a troca de dados, porque o broker (trabalhando como um sistema de filas) poderá armazenar uma mensagem para clientes que atualmente não estão conectados à rede.

No entanto, o modelo de solicitação-resposta também possui seus próprios pontos fortes. Nos casos em que os recursos do servidor para processar solicitações de vários clientes não são um problema, faz sentido usar soluções confiáveis ​​já comprovadas.

Também existem protocolos que suportam os dois modelos. Por exemplo, XMPP e HTTP 2.0 que suportam a opção de envio do servidor. A IETF também lançou o CoAP. Na tentativa de resolver o problema do sistema de mensagens, várias outras soluções foram criadas, como o protocolo WebSockets ou o protocolo HTTP por meio do QUIC (Quick UDP Internet Connections).

No caso do WebSockets, embora seja usado para transferência de dados em tempo real do servidor para o web client e forneça conexões constantes com comunicação bidirecional simultânea, ele não se destina a dispositivos com recursos computacionais limitados. O QUIC também merece atenção, pois o novo protocolo de transporte fornece muitos novos recursos. Mas como o QUIC ainda não está padronizado, é prematuro prever sua possível aplicação e impacto nas soluções de IoT. Portanto, deixamos o WebSockets e o QUIC na memória de olho no futuro, mas ainda não estudaremos mais detalhadamente.

Quem é o mais doce do mundo: comparamos protocolos

Agora vamos falar sobre os pontos fortes e fracos dos protocolos. No futuro, fazemos uma reserva imediata de que não há um líder claro. Cada protocolo tem algumas vantagens / desvantagens.

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á destaque demonstrando um nível mínimo de atraso ao trabalhar em diferentes condições. Mas há um monte de pesquisas e comparações de recursos de protocolo.

Por exemplo, os resultados da comparação da eficácia do HTTP e do MQTT ao trabalhar com a IoT mostraram que o tempo de resposta para solicitações do MQTT é menor que o do HTTP. E, ao estudar o tempo de recepção e transmissão (RTT) do MQTT e CoAP, verificou-se que o RTAP CoAP médio é 20% menor que o do MQTT.

Outro experimento com RTT para os protocolos MQTT e CoAP foi realizado em dois cenários: uma rede local e uma rede IoT. Verificou-se que o RTT médio é 2-3 vezes maior na rede IoT. O MQTT com QoS0 mostrou um resultado menor em comparação ao CoAP, e o MQTT com QoS1 mostrou um RTT mais alto devido à ACK nos níveis de aplicação e transporte. Para diferentes níveis de QoS, os atrasos na rede sem congestionamento no MQTT foram milissegundos e, para o CoAP, centenas de microssegundos. No entanto, vale lembrar que, ao trabalhar em redes menos confiáveis, o MQTT em execução no TCP mostrará um resultado diferente.

A comparação do tempo de resposta para os protocolos AMQP e MQTT, aumentando a carga útil, mostrou que, com uma carga pequena, o nível de atraso é quase o mesmo. Porém, ao transmitir grandes quantidades de dados, o MQTT demonstra menos tempo de resposta. Em outro estudo, 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 climáticos, localização (GPS) e uma interface de rede móvel (GPRS). O tempo necessário para enviar uma mensagem CoAP por uma rede móvel foi quase três vezes menor que o tempo necessário para usar as mensagens HTTP.

Foram realizados estudos que compararam não dois, mas três protocolos. Por exemplo, comparando o desempenho dos protocolos IoT MQTT, DDS e CoAP em um caso de uso médico usando um emulador de rede. O DDS superou o MQTT em termos de latência de telemetria experiente em várias condições de rede ruins. O CoAP baseado em UDP funcionou bem para aplicativos que precisavam de uma resposta rápida, mas como era baseado em UDP, houve uma perda de pacotes imprevisível significativa.

Rendimento

A comparação do MQTT e CoAP em termos de utilização da largura de banda foi realizada como um cálculo da quantidade total de dados transmitidos por mensagem. O CoAP mostrou menos largura de banda que o MQTT ao enviar pequenas mensagens. Porém, ao comparar a eficácia dos protocolos em termos da razão entre o número de bytes de informações úteis e o número total de bytes transmitidos, o CoAP foi mais eficaz.

Ao analisar o uso do MQTT, DDS (com TCP como protocolo de transporte) e largura de banda CoAP, verificou-se que o CoAP tendia a mostrar um consumo de largura de banda relativamente menor, que não aumentava com o aumento da perda de pacotes de rede ou com o atraso na rede, diferentemente MQTT e DDS, onde nos cenários mencionados houve um aumento no uso da capacidade do canal. Em outro cenário, um grande número de dispositivos transmitia dados simultaneamente, o que é um caso típico em ambientes de IoT. Os resultados mostraram que, para uma carga maior, é melhor usar o CoAP.

Com uma carga leve, o CoAP usou a menor largura de banda, seguida pelo MQTT e HTTP REST. No entanto, quando o tamanho da carga útil aumentou, o HTTP REST obteve os melhores resultados.

Consumo de energia

A questão do consumo de energia é sempre de grande importância, principalmente no sistema de IoT. Se compararmos o consumo de energia do MQTT e HTTP, o HTTP "consumirá" muito mais. E o CoAP é mais eficiente em termos de energia que o MQTT, permitindo gerenciar energia. Além disso, em cenários simples, o MQTT é mais adequado para a troca de informações na Internet, principalmente se não houver restrições de energia.

Outro experimento, que comparou os recursos do AMQP e do MQTT em um banco de testes para uma rede sem fio móvel ou instável, mostrou que o AMQP oferece mais opções 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 tópico da Internet sobre coisas e computação em neblina / nuvem. O mecanismo de segurança geralmente é baseado em TLS em HTTP, MQTT, AMQP e XMPP, em ou DTLS em CoAP, e também suporta as duas versões do DDS.

O TLS e o DTLS começam com o processo de estabelecer comunicação entre os lados do cliente e do servidor para trocar conjuntos e chaves de criptografia suportados. Ambas as partes negociam kits para garantir que mais comunicação 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 ataques de teste em várias implementações diferentes de TLS e DTLS, 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 na IoT e não envolveram trabalho no nevoeiro ou na nuvem. Através de uma troca consistente (handshaking), eles adicionam tráfego extra a cada conexão, o que esgota os recursos de computação. Em média, há um aumento de 6,5% para TLS e 11% para DTLS na carga de trabalho em comparação com a comunicação sem um nível de segurança. Em ambientes ricos em recursos que normalmente são baseados na nuvem , isso não será um problema, mas isso se tornará uma limitação importante entre a IoT e o nível de neblina.

O que escolher? Não há resposta definitiva. MQTT e HTTP parecem ser os protocolos mais promissores, pois são considerados soluções relativamente mais maduras e mais estáveis ​​para a IoT em comparação com outros protocolos.

Soluções de protocolo de comunicações unificadas

A prática de uma solução de protocolo único tem muitas desvantagens. Por exemplo, um protocolo que satisfaça um ambiente limitado pode não funcionar em um domínio que possui requisitos rígidos de segurança. Com isso em mente, resta descartar quase todas as soluções possíveis com base em um protocolo no ecossistema Fog-to-Cloud na IoT, exceto o MQTT e o REST HTTP.

HTTP REST como uma solução de protocolo único

Há um bom exemplo de interação de solicitação e resposta HTTP REST IoT-to-Fog: farm inteligente . Os animais são equipados com sensores vestíveis (cliente IoT, C) e controlados via computação em nuvem por um sistema agrícola inteligente (servidor Fog, S).

O título do método POST indica o recurso a ser alterado (/ 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 gado que o sistema deve gerenciar (Dulcinea / vaca). Uma resposta do servidor indica que a solicitação foi bem-sucedida enviando um código de status HTTPS 201 (recurso criado). O método GET deve indicar 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 é usado quando você precisa atualizar um registro de recurso específico. Nesse caso, o URI é indicado no recurso para o parâmetro a ser alterado e o valor atual (por exemplo, indicando que a vaca está andando no momento, / farm / animals / 1? State = walking). Por fim, o método DELETE é usado igualmente para o método GET, mas simplesmente exclui o recurso como resultado da operação.

MQTT como uma solução de protocolo único



Pegue o mesmo farm inteligente, mas, em vez do HTTP REST, usamos o protocolo MQTT. O servidor local com a biblioteca Mosquitto instalada atua como um intermediário. Neste exemplo, um computador simples (referido como servidor de farm) Raspberry Pi serve como cliente MQTT, implementado através da instalação da biblioteca MQTT Paho, que é totalmente compatível com o intermediário Mosquitto.

Esse cliente corresponde à camada de abstração da IoT que representa um dispositivo com recursos de detecção e computação. O intermediário, por outro lado, corresponde a um nível mais alto de abstração, representando o nó de computação do nevoeiro, caracterizado por grande poder em termos de processamento e armazenamento de dados.

No cenário proposto do Smart Farm, o Raspberry Pi se conecta ao acelerômetro, GPS e sensores de temperatura e publica dados desses sensores no nó de neblina. Como você provavelmente sabe, o MQTT trata os tópicos como uma hierarquia. Um editor do MQTT pode postar em um conjunto específico de tópicos. No nosso caso, existem três deles. Para um sensor que mede a temperatura em um celeiro, o cliente seleciona um tema (fazenda / galpão / temperatura). Para sensores que medem a localização do GPS e o movimento dos animais por meio do acelerômetro, o cliente publicará atualizações (fazenda animal / animal / GPS) e (fazenda animal / animal / movimento).

Essas informações serão transmitidas ao broker, que pode armazená-las temporariamente em um banco de dados local, caso outro assinante interessado apareça mais tarde.

Além do servidor local que atua como intermediário do MQTT no nevoeiro e para o qual o Raspberry Pi, atuando como clientes do MQTT, envia dados dos sensores, pode haver outro intermediário do MQTT no nível da nuvem. Nesse caso, as informações transmitidas ao broker local podem ser temporariamente armazenadas no banco de dados local e / ou enviadas para a nuvem. O broker MQTT nebuloso nessa situação é usado para vincular todos os dados ao broker MQTT na nuvem. Com essa arquitetura, um usuário de aplicativo móvel pode ser inscrito nos dois intermediários.

No caso de uma falha na conexão com um dos intermediários (por exemplo, nuvem), o usuário final receberá informações de outro (nebuloso). 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 a primeira conexão com o broker MQTT nebuloso e, em caso de falha, para conectar-se ao broker MQTT na nuvem. Esta solução é apenas uma das muitas nos sistemas IoT-F2C.

Soluções Multiprotocolo

As soluções de protocolo único são populares devido à sua implementação mais fácil. Mas é óbvio que nos sistemas IoT-F2C faz sentido combinar diferentes protocolos. O ponto é que diferentes protocolos podem funcionar em diferentes níveis. Tomemos, por exemplo, três abstrações: níveis de IoT, neblina e computação em nuvem. Os dispositivos IoT são geralmente considerados limitados. Para esta revisão, vejamos os níveis de IoT como os mais limitados, a nuvem como menos limitada e o cálculo de neblina como "em algum lugar no meio". Acontece que, entre a IoT e as abstrações de neblina, as decisões atuais do protocolo incluem MQTT, CoAP e XMPP. Entre o nevoeiro e a nuvem, por outro lado, o AMQP é um dos principais protocolos usados ​​junto com o HTTP REST, que devido à sua flexibilidade também é usado entre a IoT e as camadas de nevoeiro.

O principal problema aqui é a interoperabilidade dos protocolos e a simplicidade da tradução de mensagens de um protocolo para outro. Idealmente, no futuro, a arquitetura do sistema IoT com recursos de nuvem e neblina será independente do protocolo de comunicação usado e fornecerá boa interoperabilidade entre diferentes protocolos.



Como não é assim no momento, faz sentido combinar protocolos que não apresentam diferenças significativas. Para esse fim, uma solução em potencial é baseada em uma combinação de dois protocolos que seguem o mesmo estilo arquitetural, HTTP REST e CoAP. Outra solução proposta é baseada em uma combinação de dois protocolos que oferecem interação publicação-assinatura, MQTT e AMQP. O uso de conceitos próximos (MQTT e AMQP usam intermediários, CoAP e HTTP usam REST), simplifica a implementação dessas combinações e requer menos esforço de integração.



A Figura (a) mostra dois modelos baseados em solicitação-resposta, HTTP e CoAP, e seu possível posicionamento na solução IoT-F2C. HTTP , , . , , , REST HTTP .

, , IoT, CoAP. CoAP HTTP, REST.

() «-» , MQTT AMQP. , . MQTT , IoT . AMQP , . MQTT IoT XMPP, . .

Conclusões

, , . , , , MQTT RESTful HTTP. , -.

, MQTT , IoT . , , , , RESTful HTTP . CoAP , IoT, , , MQTT HTTP. , .

O que mais é útil para ler no blog do Cloud4Y

→ O computador vai te deixar gostoso
→ IA ajuda a estudar animais na África
→ O verão está quase no fim. Quase nenhum dado vazou
→ 4 maneiras de economizar em backups na nuvem
→ ,

Assine o nosso canal Telegram para não perder outro artigo! Escrevemos não mais do que duas vezes por semana e apenas a negócios.