IoT e protocolos de rede
A cada ano, avançamos mais na era da Internet das Coisas. Os dispositivos IoT estão encontrando novos usos em muitos campos e indústrias diferentes, com o desenvolvimento da automatização de muitos aspectos da vida e dos negócios, onde criamos uma gama de tecnologias inteligentes, como fábricas, agricultura, monitoramento de redes, petróleo e gás, e mesmo a nossa casa não escapou de se tornar uma casa inteligente.
Esses são alguns dos centenas de novos casos de uso da tecnologia IoT. Como resultado, o desenvolvimento da IoT está se tornando cada vez mais sofisticado para acompanhar esta demanda crescente. Com tanto foco na IoT, é importante não apenas olhar para os dispositivos em si, mas também para os protocolos de comunicação que são usados na entrega de dados nos quais os dispositivos de IoT dependem.
Se você estiver um pouco enferrujado no que são protocolos de comunicação, aqui está o básico: os protocolos de comunicação são conjuntos de regras mutuamente acordadas que regem como os dados são transferidos através da rede mundial de computadores. São as regras que garantem que quando um computador envia informações, o dispositivo receptor seja capaz de entender os dados enviados a ele. Mesmo que você não seja um especialista na área de protocolo, alguns nomes de protocolo serão imediatamente familiares para você.
O IP, como endereço IP, significa Protocolo Internet e é o protocolo principal entre todos os da Internet. O HTTP também é um dos grandes e sem dúvida, você vê frequentemente como início de suas URLs.
O HTTP opera na camada de aplicação da Internet, a camada mais relevante para os usuários humanos, e é por isso que interagimos tão frequentemente com ele. Mas, ainda que o HTTP seja um grande protocolo de comunicação, não é o único na camada de aplicação, e, quando se trata de usos do IoT, ele pode não ser o melhor.
O MQTT (Message Queuing Telemetry Transport) é um protocolo menos conhecido que ganhou popularidade no mundo de IoT. Desenvolvido em 1999, seu objetivo original era monitorar gasodutos e plataformas de petróleo remotas. Como estes locais eram frequentemente offshore e distantes dos servidores primários, o MQTT foi construído para operar em ambientes de largura de banda extremamente baixa, permitindo o encaminhamento de informações para destinos em que os protocolos de maior largura de banda simplesmente visualizariam como zonas mortas inacessíveis.
Em 2011, o Facebook percebeu que o MQTT poderia ser aplicado a mais do que apenas plataformas petrolíferas, escolhendo-o como o protocolo que alimentaria seu novo Messenger. Em 2013, com o crescimento da popularidade da IoT, as pessoas começaram a perceber que o foco de baixa largura de banda do MQTT tinha aplicações ainda mais amplas. Seu design o tornou perfeito para o IoT.
MQTT e HTTP
Para entender o que torna o MQTT especial, é importante entender os princípios de design por trás do HTTP, e as principais diferenças entre os dois protocolos.
Request/Response vs. Publish-Subscribe
O HTTP segue um modelo de request/response para suas conexões, a forma mais simples de conexão que um protocolo de rede pode ter. As requisições de request/response são dirigidas ao cliente. Isso significa que as conexões HTTP são iniciadas pelo cliente a um servidor, e as requisições tomam a forma de uma mensagem do cliente para o servidor, para a qual o servidor então envia uma resposta. Esta é uma operação muito simples, o que é uma das razões pelas quais o HTTP é tão popular.
A abordagem do MQTT é um pouco menos direta. O modelo de publicação de assinaturas do MQTT (conhecido na indústria como pub/sub) não é dirigido ao cliente da mesma forma que o HTTP. Sim, o cliente ainda inicia a conexão, mas uma vez que a conexão é feita, tanto o cliente quanto o servidor são livres para iniciar conversas diferentes enviando novas requisições.
Entretanto, essas solicitações não se movem com tanta facilidade entre o remetente e o destinatário. Ao invés disso, o dispositivo que emite informações publica seus dados para uma subseção específica de seu servidor MQTT, chamada de variável. Outros dispositivos podem assinar essa variável, e ao fazê-lo, serão atualizados cada vez que o valor da variável mudar de um novo carregamento de dados.
Escalonamento
Embora a abordagem MQTT seja menos direta e, portanto, menos eficiente para uma simples comunicação 1-to-1, ela tem a vantagem de simplificar o compartilhamento de dados entre uma grande série de dispositivos mais simples, como aqueles encontrados na IoT. Basicamente, uma requisição HTTP é como uma mensagem de texto, enquanto que uma requisição MQTT é mais como uma publicação em mídia social.
Uma requisição HTTP será sempre um dispositivo que envia uma única requisição para outro, portanto, para fazer uma grande rede de dispositivos conectados por HTTP funcionar, você acaba com milhares de solicitações individuais voando por aí, substituindo por uma configuração de mensagem de grupo mais suave.
Com a configuração em estilo de mídia social do MQTT, não importa se há um dispositivo inscrito a uma variável ou cem. A estrutura é independente do número de receptores. O transmissor posta, e todos os assinantes da rede são atualizados. Esta separação entre o editor e o número de assinantes é chamada de desacoplamento e escala independente, e é um dos argumentos de venda mais potentes para um sistema baseado no MQTT.
Conexões momentâneas vs. de longo prazo
Devido a estas diferenças nas requisições, a duração da conexão para estes dois protocolos também é muito diferente. As requisições HTTP são muito breves. O cliente envia a requisição, o servidor responde, e então a conexão é imediatamente interrompida. Se o mesmo cliente quiser enviar outra , uma conexão totalmente nova deve ser feita. Por outro lado, devido à forma como publish/subscribe funciona, as conexões MQTT continuam a operar enquanto o dispositivo estiver inscrito no servidor. Qualquer informação enviada entre o dispositivo e o servidor é transmitida através desta única conexão. De certa forma, esta é apenas mais uma maneira que o HTTP demonstra sua eficiência.
Muitos sistemas só podem lidar com um determinado número de conexões ao mesmo tempo, e a rápida remoção de conexões não utilizadas do HTTP pode poupar o sistema de muito esforço. Mas esta eficiência vem com o custo da segurança. Uma conexão é mais vulnerável à interferência externa no momento em que está sendo estabelecida e, desta forma, as conexões de longo prazo do MQTT impedem menos pontos de entrada para invasores do que o ciclo constante de HTTP.
O HTTP ainda é muito seguro, mas o MQTT apenas leva isso um passo adiante. Além disso, enquanto as conexões momentâneas do HTTP tornam mais rápido o estabelecimento de conexões, as conexões de longo prazo do MQTT fornecem um rendimento significativamente mais rápido na área chave do tempo de requisição. Ao dedicar tempo para estabelecer uma conexão realmente sólida e estável, o MQTT é capaz de garantir que qualquer dado transportado através dessa conexão seja enviado muito mais rápido do que uma rede baseada em HTTP, cujos milhões de conexões significam que ela não pode investir tempo no aperfeiçoamento de uma única conexão.
A área em que o MQTT se destaca neste aspecto são as grandes redes estáveis, com muitos dispositivos de longo prazo, mas poucos dispositivos adicionados ou eliminados da rede em períodos de tempo mais curtos. Quando o número específico de dispositivos ligados à rede geralmente permanece constante no dia a dia, o estabelecimento de conexão mais lenta do MQTT se paga, construindo conexões realmente fortes e leves que acabam economizando muito tempo no final da requisição e resposta .
Então por que o MQTT hype?
Quando você divide as diferenças entre MQTT e HTTP, é difícil afirmar que um dos protocolos é definitivamente “melhor” do que o outro. O MQTT geralmente ganha em escalabilidade e menor latência, enquanto os pontos fortes do HTTP incluem alta tolerância a falhas e maior compatibilidade com muitos outros sistemas que rodam HTTP que enchem a web. Mas é justo dizer que o MQTT é certamente o protocolo mais especializado e, quanto mais você mergulhar nele, mais notará como essa especialização se adapta às necessidades da IoT moderna.
O modelo publish/subscribe do MQTT torna muito mais fácil fazer conexões entre os muitos pequenos dispositivos que compõem a IoT, e sua configuração de longo prazo torna-as mais fáceis de manter em baixa largura de banda, onde a IoT é tão frequentemente encontrada. É muito impressionante que um protocolo projetado bem antes da internet das coisas estar em voga funcione tão bem com um ambiente de IoT, mas o MQTT realmente se encaixa como uma luva.
MQTT no edge
Aqui na Azion, estamos focados em oferecer suporte à infraestrutura de IoT por meio de nossas tecnologias de edge da rede. Nosso Edge DNS e outras ferramentas de rede são totalmente compatíveis com os protocolos MQTT e HTTP, e nosso Edge Orchestrator é capaz de provisionar infraestrutura IoT remotamente usando seus recursos zero-touch.
Assim que o protocolo escolhido for configurado em sua rede, nosso pacote Edge Analytics monitora as conexões de seus dispositivos IoT em tempo real, garantindo a integridade do dispositivo e a transparência da rede. E, claro, todo o seu sistema IoT pode ser alojado no edge de nossa rede distribuída, aumentando sua segurança e aumentando as velocidades de conexão ao trazer os servidores aos quais a IoT está subordinada para mais perto deles, movendo para a rede edge.
Quanto a se o MQTT ou HTTP é o melhor protocolo para sua rede, a verdade é que ambos são fortes, testados e verdadeiros. Se configurados com as ferramentas certas, oferecerão conexões de requisições sólidas e confiáveis.
Se seu sistema é bastante padrão e você não quer complicar demais as coisas, o HTTP é fácil, direto e funciona muito bem. Se a IoT desempenha um papel maior para seu negócio, e a ideia de um protocolo que se concentra mais diretamente em suas necessidades específicas de IoT é atraente, provavelmente vale a pena examinar mais de perto o MQTT.
E, claro, se você não consegue decidir, você pode apenas usar os dois. Chame isso de abordagem híbrida.
