Quais são as vantagens do MQTT em comparação com o protocolo HTTP tradicional

HTTP é o protocolo mais amplamente usado e popular. Mas o MQTT ganhou terreno rapidamente nos últimos anos. Ao discutir o desenvolvimento de IoT, os desenvolvedores devem escolher entre esses dois.

O MQTT se concentra em dados, enquanto o HTTP se concentra em documentos. O HTTP é um protocolo de solicitação-resposta para computação cliente-servidor, que nem sempre é otimizado para dispositivos móveis. Nesses termos, as principais vantagens do MQTT são: leveza (o MQTT transfere dados na forma de matrizes de bytes) e modelo de publicação/assinatura, o que torna o MQTT muito adequado para dispositivos com recursos limitados e ajuda a economizar bateria. Além disso, o modelo de publicação/assinatura permite que os clientes sejam independentes uns dos outros, aumentando assim a confiabilidade do sistema geral. No caso de uma falha do cliente, todo o sistema continua a funcionar normalmente.

Ainda há muitas vantagens do MQTT, como segue:

1. Baixa sobrecarga de protocolo, o MQTT é único porque seu cabeçalho por mensagem pode ser tão curto quanto 2 bytes. Tanto o MQ quanto o HTTP têm uma sobrecarga por mensagem muito maior. Com o HTTP, restabelecer a conexão HTTP para cada nova mensagem de solicitação incorre em uma sobrecarga significativa. As conexões persistentes usadas pelo MQ e MQTT reduzem significativamente essa sobrecarga.

2. Tolerância a redes instáveis, o MQTT e o MQ podem se recuperar de falhas como desconexão, e não há mais requisitos de código. No entanto, o HTTP não pode fazer isso nativamente, exigindo que os clientes tentem novamente a codificação, o que pode aumentar os problemas de idempotência.

3. Baixo consumo de energia, o MQTT é especialmente projetado para baixo consumo de energia. O HTTP não foi projetado para levar isso em consideração, aumentando assim o consumo de energia.

4. Clientes com milhões de conexões, na pilha HTTP, mantendo milhões de conexões simultâneas, exigem muito trabalho para fornecer suporte. Embora esse suporte seja possível, a maioria dos produtos comerciais é otimizada para lidar com conexões persistentes dessa ordem de magnitude. A IBM oferece o IBM MessageSight, um servidor de montagem em rack único testado para lidar com até 1 milhão de dispositivos conectados simultaneamente por MQTT. Em contraste, o MQTT não foi projetado para um grande número de clientes simultâneos.

5. Notificações push, você precisa ser capaz de entregar notificações aos clientes em tempo hábil. Para isso, algum tipo de pesquisa periódica ou push deve ser empregado; push é a melhor solução de uma perspectiva de bateria, carga do sistema e largura de banda.

Nosso negócio pode precisar enviar informações confidenciais sem a intermediação de terceiros. Isso reduz o valor de soluções específicas do sistema operacional (como Apple iOS, notificações do Google Play) como o mecanismo de transporte primário.

HTTP permite apenas um método chamado COMET, usando solicitações HTTP persistentes para executar pushes. Essa abordagem é cara tanto da perspectiva do cliente quanto do servidor. Tanto o MQ quanto o MQTT suportam push como um recurso fundamental deles.

6. Diferenças de plataforma do cliente, tanto os clientes HTTP quanto os MQTT foram implementados em um grande número de plataformas. A simplicidade do MQTT ajuda a implementar o MQTT em clientes adicionais com muito pouco esforço.

7. Tolerância a falhas de firewall, alguns firewalls corporAtivos restringem conexões de saída a algumas portas definidas. Essas portas geralmente são restritas a HTTP (porta 80), HTTPS (porta 443), etc. O HTTP pode obviamente funcionar nessas situações. O MQTT pode ser encapsulado em uma conexão WebSockets que aparece como uma solicitação de atualização HTTP, permitindo a operação nesses casos. O MQTT não permite esse padrão.

Comparado ao HTTP, o protocolo MQTT garante uma alta taxa de transferência. Existem três níveis de qualidade de serviço:

A. No máximo uma vez: tente garantir a entrega.

B. Pelo menos uma vez: certifique-se de que o e-mail seja enviado pelo menos uma vez, mas a mensagem também pode ser entregue mais de uma vez.

C. Apenas uma vez: certifique-se de que cada mensagem seja recebida apenas uma vez pela outra parte.

Na verdade, o MQTT é amplamente utilizado. Você pode encontrar MQTT em quase qualquer grande empresa de hardware e Internet, como Facebook, BP, alibaba, baidu, etc.

Devido às várias vantagens técnicas do próprio MQTT, mais e mais empresas tendem a escolher o MQTT como o protocolo padrão para comunicação de produtos IoT. Portanto, os engenheiros descobriram gradualmente que o protocolo MQTT tem algumas funções que precisam ser aprimoradas para que seja comercializado em larga escala. por exemplo:

1. Não há um SDK completo, e diferentes terminais heterogêneos precisam de pacotes SDK de software correspondentes para se comunicar com o servidor MQTT. Por exemplo, para obter interconexão entre MCU, Linux, Android, IOS, WEB, etc., diferentes pacotes SDK devem ser necessários.

2. Arquivo e AV não são suportados. Em alguns cenários de aplicação, as informações a serem transmitidas podem não estar limitadas a instruções, como sinais de áudio e sinais de vídeo, que precisam se comunicar por meio de Arquivo e AV.

3. Ele não suporta a integração com HTTP de terceiros. Emborah o protocolo MQTT é superior ao protocolo HTTP comum, servidores WEB baseados no protocolo HTTP tradicional ainda ocupam o mercado convencional, então esses servidores devem realizar a interconexão com o protocolo MQTT para reduzir atualizações O custo também é crítico.

4. Ele não suporta balanceamento de carga. Para evitar alta simultaneidade e ataques maliciosos, um servidor de balanceamento de carga também é essencial.

5. Ele não suporta a interface de gerenciamento de usuários. É particularmente importante para os usuários analisarem dados de comportamento do dispositivo, o que é um requisito inevitável da Indústria 4.0 e da era do big data.

6. Ele não suporta mensagens offline e compensa o problema de que o servidor MQTT perde as informações de controle do dispositivo depois que o dispositivo fica offline.

7. A comunicação ponto a ponto não é suportada e o protocolo MQTT padrão é adotado. Em teoria, a comunicação ponto a ponto pode ser realizada por meio de assinatura mútua, mas a lógica é relativamente complicada e há preocupações sobre a segurança do dispositivo. Quando o dispositivo B e o dispositivo C estão no mesmo tópico, o dispositivo A não pode saber se é o dispositivo B ou o dispositivo C que enviou a mensagem, e também é possível que a mensagem seja interceptada pelo dispositivo D.

8. Ele não suporta comunicação de grupo e gerenciamento de grupo, e realiza o gerenciamento de membros do grupo, e os membros do grupo podem se comunicar entre si. No cenário em que um dispositivo é controlado por várias pessoas, ou vários dispositivos são controlados por uma pessoa, especialmente útil.