Monografia_AWS_ProtocolosIOT_DenisStorti_v1.1

124 visualizações

Publicada em

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
124
No SlideShare
0
A partir de incorporações
0
Número de incorporações
7
Ações
Compartilhamentos
0
Downloads
9
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Monografia_AWS_ProtocolosIOT_DenisStorti_v1.1

  1. 1. DENIS STORTI DA SILVA Comparação de Protocolos de Comunicação CoAP, MQTT e HTTP utilizando Eclipse Ponte e Amazon Web Services
  2. 2. 2 São Paulo 2016
  3. 3. 3 DENIS STORTI DA SILVA Comparação de Protocolos de Comunicação CoAP, MQTT e HTTP utilizando Eclipse Ponte e Amazon Web Services Monografia de Conclusão do Curso de Especialização em Tecnologia da Informação Bancária da Escola Politécnica da Universidade de São Paulo. São Paulo 2016
  4. 4. 4 DENIS STORTI DA SILVA Comparação de Protocolos de Comunicação CoAP, MQTT e HTTP utilizando Eclipse Ponte e Amazon Web Services Monografia de Conclusão do Curso de Especialização em Tecnologia da Informação Bancária da Escola Politécnica da Universidade de São Paulo. Área de Concentração: Engenharia de Computação Orientador: Professor Doutor Osvaldo Gogliano Sobrinho São Paulo 2016
  5. 5. 5 AGRADECIMENTOS Aos meus pais e irmão, pelo amor, incentivo е apoio incondicional. À empresa Itaú Unibanco S.A. por ter me apoiado nesta iniciativa e me incentivado a buscar mais conhecimento e me desenvolver profissionalmente. E a todos meus colegas de trabalho no Itaú Unibanco S.A. que contribuíram com sua opinião e conhecimento, me incentivando a fazer um bom trabalho e pensar fora da caixa. À Universidade de São Paulo e Escola Politécnica, sеυ corpo docente, direção е administração que contribuíram com conhecimento, ética e estrutura para que eu me desenvolvesse.
  6. 6. 6 RESUMO Este trabalho tem como objetivo analisar comparativamente alguns protocolos da camada de aplicação utilizados na comunicação sem fio entre dispositivos móveis que possuem restrições de consumo de energia, uso de banda no tráfego de dados e confiabilidade. Em redes Machine to Machine (M2M) onde existe um grande número de sensores ou dispositivos, o uso eficiente do hardware e software pode ser realizado por meio do uso de protocolos de aplicação eficientes e adequados a cada cenário, executando tanto sobre o protocolo da camada de transportes TCP quanto UDP. Os protocolos CoAP, MQTT e HTTP são abordados neste trabalho, elucidando as principais características e benefícios do uso de cada protocolo de acordo com as restrições de menor uso de banda para tráfego e maior controle sobre a entrega de mensagens. Utilizando os protocolos citados acima, os serviços de computação em nuvem da Amazon Web Services e o gateway Eclipse Ponte, foi montado um ambiente de laboratório para a realização de testes e medição. Na conclusão é apresentado o resultado destes testes e em quais cenários os protocolos estudados melhor se adequam, assim como sugestões de trabalhos futuros. Palavras-chave: Internet das coisas. IoT. Protocolos da camada de aplicação. Dispositivos móveis. Sensores.
  7. 7. 7 ABSTRACT This paper aims at comparing some application layer protocols used in wireless communication between mobile devices that have power consumption, bandwidth usage and reliability constraints. In Machine to Machine (M2M) networks where there is a large number of sensors and/or devices, efficient use of hardware and software can be accomplished through the use of efficient application protocols appropriate to each scenario, running over transport layer protocols like TCP and UDP protocols. These protocols COAP, MQTT and HTTP are discussed in this work, explaining the main features and benefits of using each one of them in accordance with the restrictions of lower bandwidth usage for traffic and greater control over message delivery (quality of service). Using the protocols mentioned above, cloud computing services from Amazon Web Services and the gateway Eclipse Ponte, it was set up a lab environment for testing and measurement purposes. In conclusion, it’s presented the results of these tests and in which scenarios the protocols studied best fit, as well as suggestions for further work. Keywords: Internet of Things. IoT. Application Layer Protocols. Mobile Devices. Sensors.
  8. 8. 8 LISTA DE ABREVIATURAS E SIGLAS AMQP Advanced Message Queuing Protocol CoAP Constrained Application Protocol IETF Internet Engineering Task Force MQTT-SN Message Queue Telemetry Transport for Sensors Network IoT Internet of Things M2M DTLS OASIS Machine to Machine Datagram transport layer security Organization for the advancement of structured information HTTP Hypertext Transfer Protocol URI Universal Resource Identifier REST Representational State Transfer XML eXtensible Markup Language JSON JavaScript Object Notation
  9. 9. 9 Lista de Figuras Figura 1 - Algumas aplicações para IoT.....................................................................13 Figura 2 - Gartner Hype Cycle for Emerging Technologies, 2015..............................14 Figura 3 - Grupos que colaboram para a padronização da comunicação M2M.........15 Figura 4 - Um exemplo de arquitetura de IoT.............................................................15 Figura 5 - Desacoplamento de espaço, tempo e sincronização no paradigma publish/subscribe.........................................................................................................22 Figura 6 - Exemplo de arquitetura utilizando broker...................................................24 Figura 7 - Exemplo de arquitetura sem broker............................................................24 Figura 8 - Exemplo de arquitetura utilizando um nó centralizado de endereços........25 Figura 9 - Arquitetura CoAP usando Observer model................................................28 Figura 10 - Padrão Observer.......................................................................................29 Figura 11 - Observando recursos com CoAP.............................................................30 Figura 12 - Arquitetura para o teste em visão macro..................................................33 Figura 13 - Ambiente detalhado dos testes................................................................35 Figura 14 - Arquitetura do broker Eclipse Ponte.........................................................37 Figura 15 - Servidor EC2 iniciado na AWS.................................................................38 Figura 16 - Certificado PEM carregado, pronto para conversão para tipo PPK.........39 Figura 17 - Ferramenta Putty com Host Name preenchido com DNS do servidor EC2 da Amazon..................................................................................................................40 Figura 18 - Conexão com sucesso ao servidor EC2 utilizando Putty.........................40 Figura 19 - Executando Node.js após configurar execução para a pasta /usr/bin/nodejs.............................................................................................................41 Figura 20 - Eclipse Ponte executando sobre Node.js em um servidor EC2 da Amazon........................................................................................................................42 Figura 21 - Forever processando continuamente o broker Ponte..............................42 Figura 22 - Utilização de saída de rede do servidor EC2...........................................44 Figura 23 - Utilização em bytes de entrada de rede do servidor EC2........................44 Figura 24 - Publicação de 200 bytes e recebimento MQTT, CoAP e HTTP..............45 Figura 25 - Tráfego da publicação de 200 bytes........................................................46 Figura 26 - Publicação de 1024 bytes e recebimento MQTT, CoAP e HTTP............47 Figura 27 - Tráfego da publicação de 1024 bytes......................................................47 Figura 28 - Clientes recebendo mensagens de 1 kbyte a cada 500 milissegundos. .48 Figura 29 - Uso total de bytes de rede no servidor EC2.............................................50
  10. 10. 10 Figura 30 - Eficiência energética entre CoAP com Observe e MQTT........................51
  11. 11. 11 Lista de Quadros Quadro 1 - Comparação entre protocolo TCP e UDP................................................27 Quadro 2 - Comparando os protocolos CoAP e MQTT..............................................32 Quadro 3 - Configuração do servidor de teste na AWS..............................................38 Quadro 4 - Comparativo de recebimento de 1 mensagem de 200 bytes...................46 Quadro 5 - Comparativo de recebimento de 1 mensagem de 1024 bytes.................48
  12. 12. 12 SUMÁRIO 1. Introdução................................................................................................................13 1.1 Considerações Iniciais.......................................................................................13 1.2 Objetivo e Motivação da Pesquisa....................................................................18 1.3 Organização do trabalho...................................................................................18 2. Modelos de Comunicação e Paradigmas M2M......................................................19 2.1 Request / Response.........................................................................................19 2.2 Publish / Subscribe ...........................................................................................20 2.3 Arquiteturas de Mensageria...............................................................................22 2.3.1 Com Broker.....................................................................................................22 2.3.2 Sem Broker.....................................................................................................24 3. Características dos Protocolos................................................................................26 3.1 CoAP .................................................................................................................26 3.1.1 CoAP com Observe Pattern...........................................................................29 3.2 MQTT.................................................................................................................30 4. Desenvolvimento.....................................................................................................33 4.1 Detalhes da Arquitetura dos Testes..................................................................33 4.1.2 Ferramentas....................................................................................................34 4.1.3 Configuração do Ambiente.............................................................................37 4.2 Análise de Uso de Banda..................................................................................43 4.3 Análise De Qualidade De Serviço.....................................................................48 4.4 Conclusões sobre o Desenvolvimento..............................................................51 5. Considerações Finais e Trabalhos Futuros............................................................53 6. Referências.............................................................................................................54 APÊNDICE A – Código fonte dos programas de teste...............................................58 1. MQTT Publish......................................................................................................58 2. MQTT Subscribe..................................................................................................58 3. CoAP Publish.......................................................................................................58 4. CoAP Subscribe...................................................................................................58 5. HTTP PUT Request.............................................................................................58 6. HTTP GET Request.............................................................................................58
  13. 13. 13 1. Introdução 1.1 Considerações Iniciais Em 2011 o número de dispositivos interconectados no planeta superou o número de pessoas sendo 9 bilhões atualmente, com crescimento esperado para 24 bilhões até 2020. A proliferação de dispositivos embarcados conectados à internet nos últimos anos com o intuito de medir, inferir e entender os ecossistemas é um dos componentes da internet das coisas (IoT), trazendo com ela a necessidade de troca de dados sob demanda e a capacidade de manter uma rede confiável e íntegra mesmo sob condições adversas [1]. As aplicações de IoT são diversas como algumas ilustradas na Figura 1. Figura 1 - Algumas aplicações para IoT Fonte: Próprio autor. Estes dispositivos estão imersos no ambiente cotidiano de forma transparente, trocando uma enorme quantidade de dados que devem ser facilmente recolhidos, armazenados e analisados. Como esta rede de dispositivos pode apresentar alta volatilidade pela entrada e saída de novos sensores é possível usufruir dos benefícios oferecidos pela computação em nuvem, que consegue oferecer a infraestrutura para suportar este ambiente, como por exemplo a Amazon Web Services e Google Cloud Platform. Quanto aos tipos de comunicação física, os dispositivos prevalecem na utilização de tecnologias sem fio abertas como Bluetooth, RFID (acrônimo para Radio-Frequency IDentification ou, em português, Identificação por Rádio Frequência), Wi-fi e os serviços de dados oferecidos por empresas de telefonia como 2G, 3G ou 4G. Como descrito em [2], a arquitetura para IoT ainda não está totalmente estabelecida, uma vez que cada uma das tecnologias utilizadas preenche
  14. 14. 14 parcialmente os requisitos de IoT e grupos de pesquisa focam em adaptar protocolos existentes. Como apresentado no relatório da Gartner [3] sobre ciclos de tecnologias emergentes, IoT está em seu pico de expectativas infladas no mercado quanto a seu uso e capacidades, ilustrado na Figura 2. Ela passará por um período de estudos de viabilidade e padronização por grupos de estudos nos próximos 5 ou 10 anos para ser delineada e alcançar nível produtivo. Figura 2 - Gartner Hype Cycle for Emerging Technologies, 2015 Fonte: Gartner Hype Cycle for Emerging Technologies, 2015 [3]. O estado da arte da comunicação M2M pretende organizar e disseminar casos de uso, discutir nomenclaturas, endereçamento, interfaces de aplicação (APIs) e interfaces de hardware, otimizações de rede para gerenciar grandes números de dispositivos conectados, otimizar uso de energia por dispositivos, entre outros. O crescimento da indústria de comunicações M2M trouxe a necessidade de padrões para viabilizar a interoperabilidade, e como os grupos de trabalho ainda são recentes até o momento poucas especificações foram publicadas [4]. Na Figura 3 é apresentada uma relação de grupos de trabalho que trabalham em prol da padronização e evolução da comunicação M2M, cada um deles possuindo um foco específico.
  15. 15. 15 Figura 3 - Grupos que colaboram para a padronização da comunicação M2M Fonte: Internet of Things Architecture (IOT-A), 2013 [4]. A discussão de protocolos é essencial quando se busca conhecer qual a forma mais eficiente para se comunicar com dispositivos que possuem restrições em suas comunicações. Alguns aspectos que impactam o consumo de banda e energia são overhead do protocolo, número de mensagens de controle de fluxo e gerenciamento, confiabilidade e segurança. Na Figura 4 é ilustrado um exemplo de fluxo de dados que parte de nós folha, que podem ser sensores ou mesmo smartphones, para um servidor capaz de distribuir e processar estes dados. Esta comunicação pode ocorrer por meio da Internet e assim passar por diversos gateways e roteadores usando um protocolo de aplicação. Figura 4 - Um exemplo de arquitetura de IoT
  16. 16. 16 Fonte: KARAGIANNIS, Vasileios et al (2015) [2]. O uso de protocolos de comunicação na camada de aplicação por estes dispositivos deve atender aos requisitos pretendidos pela rede a ser desenvolvida como confiabilidade, segurança, rastreabilidade, flexibilidade e durabilidade, uma vez que ainda não existe um protocolo totalmente adaptado a uma arquitetura de IoT [2]. Segundo [5], a falta de protocolos de aplicação otimizados para sensores, atuadores e smartphones despertou a necessidade de um novo design de protocolos de aplicação leves, sendo dois deles Message Queuing Telemetry Transport (MQTT) [6], e Constrained Application Protocol (CoAP) [7]. O protocolo CoAP foi especificado na RFC 7252 em junho de 2014 que propõe o CoAP como um padrão para protocolo de troca de mensagens voltado para dispositivos com restrições computacionais e de energia bem como para redes com baixa largura de banda [7]. O protocolo MQTT foi desenhado pela IBM em 1999 em parceria com a empresa Eurotech voltado para troca de mensagens em aplicações Machine to Machine (M2M), onde dispositivos são capazes de se comunicar entre si sem a necessidade manual de assistência humana. Comunicação M2M forma a base do conceito de IoT e é muito utilizada hoje para telemetria como gerenciamento de armazéns, controle remoto de dispositivos, robótica, controle de trânsito, serviços de logística, gerenciamento da cadeia de fornecimento e telemedicina.
  17. 17. 17 As plenárias técnicas do projeto oneM2M [9] reforçaram a ideia que os protocolos CoAP, HTTP e MQTT atendem a comunicação entre dispositivos móveis, apesar de outros protocolos serem candidatos à utilização como Advanced Message Queuing Protocol (AMQP) [10], ou Extensible Messaging and Presence Protocol (XMPP) [11], os primeiros são desenhados para redes e dispositivos restritos, focados na redução do consumo de banda e energia [8]. O conceito de arquitetura REST (Representational State Transfer) proposta por [12] é composta por um conjunto de estilos arquiteturais que permitem que aplicações utilizem baixo acoplamento de forma que os serviços sejam compartilhados e reusáveis. Um recurso, em uma arquitetura REST, é uma abstração identificada por uma URI (Universal Resource Identifier) e existem de forma desacoplada dos serviços que venham a utilizá-los, assim como desacoplado de sua própria representação que pode ser, por exemplo, em XML ou JSON (JavaScript Object Notation). Os clientes podem acessar e manipular os recursos no servidor por meio um protocolo de aplicação, utilizando por exemplos paradigmas de comunicação como request/response ou publish/subscribe. O protocolo mais utilizado atualmente é o protocolo HTTP, principalmente com seus verbos GET, POST, PUT e DELETE que oferecem manipulações de recuperação, criação, alteração e deleção de recursos, respectivamente. O protocolo HTTP não é revisado neste trabalho devido à literatura disponível ser numerosa e altamente difundida [13- 15]. Um broker de mensageria é um padrão arquitetural para validação, transformação e roteamento de mensagens [16]. A ferramenta Eclipse Ponte [17] é um broker de mensageria multiprotocolo para IoT e M2M, e atualmente ela suporta os protocolos MQTT, REST APIs sobre HTTP e CoAP. Ele é capaz de transformar dados entre os tipos JSON, MsgPack, Byson, BSON e XML, assim é possível possuir uma rede com sensores que se comunicam de diferentes formas entre si por meio do broker, reduzindo a complexidade de implementação. Neste trabalho o broker Ponte foi utilizada sobre o um servidor executando Node.js [18], um interpretador da linguagem javascript que executa sobre o motor do Google Chrome V8. No momento deste trabalho Node.js está em alta no mercado por possuir características orientadas a eventos e I/O (entrada e saída) não bloqueante, o que possibilita alta escalabilidade e processamento assíncrono.
  18. 18. 18 1.2 Objetivo e Motivação da Pesquisa O foco deste trabalho foi a comparação dos protocolos CoAP, MQTT e HTTP, utilizando as ferramentas Eclipse Ponte e Node.js, assim como a nuvem Amazon Web Services (AWS) [19] para publicação de um broker de mensageria na nuvem e a análise de qualidade de serviço e uso de banda dos protocolos, usando o paradigma de comunicação publish/subscribe. Ele tem como objetivo listar as principais características dos protocolos de comunicação utilizados para conectar tanto dispositivos quanto usuários finais à internet, e analisá-los comparativamente quanto aos requisitos de quantidade de uso de banda no processo de comunicação e confiabilidade na comunicação baseada em qualidades de serviço (QoS) oferecidas por cada um. Os protocolos estudados são CoAP, MQTT e HTTP, e como resultado espera-se obter sob a ótica dos requisitos analisados uma clara distinção dos benefícios do uso de cada um em diversos cenários. O diferencial acadêmico deste trabalho é apresentar resultados comparativos entre protocolos atualmente reconhecidos como meios de comunicação adequados para redes e dispositivos restritos [9], utilizando um servidor orientado a eventos com Node.js publicado na nuvem AWS e uma ferramenta que serviu como broker entre os protocolos, Ponte. 1.3 Organização do trabalho Para se analisar comparativamente os protocolos é importante caracterizar os principais modelos de comunicação para IoT, portanto no capítulo 2 são apresentados detalhes sobre os modelos de comunicação e paradigmas Publish/Subscribe e Request/response. No capítulo 3 são listadas as principais características dos protocolos os usados na camada de transporte, modelo de comunicação no qual se encaixam, comandos e aspectos de segurança. No capítulo 4 é apresentado o desenvolvimento dos testes com a montagem do ambiente proposto, execução dos testes e análise comparativa dos resultados referente aos dois requisitos propostos neste trabalho, nomeadamente consumo de banda e qualidade de serviço.
  19. 19. 19 2. Modelos de Comunicação e Paradigmas M2M Para se montar um ambiente de comunicação entre dispositivos M2M é necessário definir como a troca de informações irá ocorrer, ou seja, como um dispositivo é capaz de produzir dados e transmiti-los pela rede dentro de suas restrições de ambiente, e como um consumidor consegue obter este dado de forma a ter o mínimo de qualidade desejado. Para as comunicações M2M existem dois tipos de padrões que se destacam: baseado em eventos, ou seja, disparado pela ocorrência de um determinado evento, ou baseado em polling que acontece de tempos em tempos de forma recorrente [4]. Comunicação baseada polling segue basicamente o modelo request/response onde uma aplicação envia uma requisição solicitando dados, como, a leitura de um sensor de umidade. Comunicação baseada em eventos emite requisições de acordo com o acontecimento de eventos específicos, por exemplo a mudança de valor no sensor de umidade. A comunicação baseada em eventos pode emitir menos requisições, e com isso consumir menos banda, se for utilizada em um contexto onde a ocorrência de eventos é menos frequente ou não necessita ser tratada em tempo real, ou seja, assim que o evento for disparado existe a necessidade de disparar processos o quanto antes. De forma contrária, a comunicação baseada em polling pode causar desperdício de banda e energia caso tenha que ler sensores que raramente mudam de valor. Com um bom design de eventos a serem disparados é possível conseguir melhores resultados com a comunicação M2M baseada em eventos em termos de eficiência de recursos. 2.1 Request / Response A literatura sobre o paradigma request/response é vasta uma vez que é o paradigma utilizado na internet por meio do protocolo HTTP. Este paradigma é síncrono e requer que cliente e servidor estejam conectados e prontos para a troca de dados. Além disso, cada requisição é feita no modelo de comunicação baseado em polling uma vez que não se sabe o momento exato da troca de valores em um dispositivo ou sensor, havendo assim a necessidade de requisições recorrentes nos sensores e smartphones. Para redes de sensores que possuem limitações, estas
  20. 20. 20 requisições frequentes acarretam não só um gasto de energia desnecessário como também um possível consumo de banda que não agrega dados novos pois como a requisição é feita em intervalos pré-determinados não é possível determinar se houve alteração de valor nos sensores. Por estes fatos, o paradigma publish/subscribe apresentado na seção 2.2 é o que mais se encaixa nas limitações de uma arquitetura de redes de sensores para comunicações M2M. 2.2 Publish / Subscribe No paradigma de interação publish/subscribe, clientes interessados em receber dados (subscribers) expressam seu interesse em um evento ou padrão de eventos gerados por produtores (publishers) [20]. Uma das maiores vantagens desta arquitetura é o desacoplamento entre produtores e consumidores dos dados. Este desacoplamento permite a esta arquitetura ser altamente escalável e resistente a falhas, uma vez que nós produtores e consumidores podem ser adicionados ou retirados, por exemplo devido a uma falha, sem comprometer o sistema [21]. De fato, o desacoplamento entre produtores e consumidores pode ser dividido em três dimensões [20]: • Desacoplamento de espaço: os produtores não possuem referências dos consumidores, uma vez que os sensores ou smartphones que produzem os dados não necessitam conhecer a identidade dos clientes que estão interessados naquele dado. • Desacoplamento de tempo: Outro benefício é que produtores e consumidores podem interagir de forma assíncrona, ou seja, as partes que interagem não necessitam estar ativamente participando da interação ao mesmo tempo. Produtores podem publicar mesmo que os consumidores estejam desconectados e, inversamente, os consumidores podem ser notificados mesmo que não haja produtores. • Desacoplamento de sincronização: Produtores não são bloqueados enquanto produzem eventos e consumidores podem ser assincronamente notificados da ocorrência de um evento enquanto efetuam outra atividade. Estes tipos de desacoplamento são representados na Figura 5.
  21. 21. 21
  22. 22. 22 Figura 5 - Desacoplamento de espaço, tempo e sincronização no paradigma publish/subscribe Fonte: EUGSTER, Patrick Th et al (2003) [20]. 2.3 ARQUITETURAS DE MENSAGERIA Quando são analisados protocolos para comunicação, é possível dividir as arquiteturas de mensageria basicamente em dois tipos: aquelas que utilizam uma camada intermediária para controle de mensageria, também conhecidas como brokers; e aquelas que não necessitam de um componente de arquitetura para controle, atuando como peer-to-peer (ponto a ponto) de forma independente, também chamadas de brokerless [22]. 2.3.1 Com Broker A arquitetura de mensageria baseada em broker possui um componente centralizado para controle e roteamento de mensagens. Sendo assim os nós ficam organizados em topologias do tipo estrela ou hub, não se comunicando diretamente uns com os outros. Cada aplicação é conectada ao nó central e a comunicação ocorre por meio dele. Não só a comunicação como os controles de pacotes, mecanismos de retransmissão e checagem de consistência ou qualquer outro mecanismo que seja necessário implementar em nível de aplicação pode estar contido no broker. Esta centralização por um lado é uma vantagem pois na prática existirão menos nós com a responsabilidade de brokers do que nós folhas (que podem ser sensores e smartphones), assim o controle de alertas e mecanismos de contingência mais caros ficam centralizados em certos pontos da arquitetura (que
  23. 23. 23 pode conter milhares de nós) e não em cada um dos nós. Brokers podem ser poliglotas, ou seja, permitem que produtores e consumidores usem diferentes protocolos de comunicação (exemplo, produtor utilizando MQTT e consumidor utilizando CoAP) e eles podem suportar transformação de mensagem, por exemplo, transformando a carga das mensagens do formato XML para JSON, aumentando ainda mais a integração da arquitetura com sistemas. As principais vantagens listadas em [22] são: • Aplicações não necessitam saber a localização ou endereço de outras aplicações: O único endereço que as aplicações devem conhecer é do broker, que é responsável por rotear as mensagens para a aplicação destino baseado em critérios de negócio (tópicos, nomes de fila, chave de roteamento, propriedades da mensagem, entre outros) em vez da topologia de rede. • O produtor e o consumidor não necessitam estar ativos simultaneamente: O produtor pode deixar uma mensagem no broker e terminar sua execução. Posteriormente um consumidor pode se conectar ao broker e recuperar a mensagem. • Resistência às falhas nas aplicações: as mensagens que estão no broker estão retidas mesmo que as aplicações falhem. As principais desvantagens do uso de broker são: • Utiliza muita banda de rede: utilizando uma comunicação baseada em serviços por exemplo, um serviço A chamaria um serviço B passando uma mensagem ao broker, que chamaria o serviço B, que retornaria ao broker, e esta retornaria ao serviço A para retornar a resposta final (entrada  serviço A  broker  serviço B  broker  serviço A  resultado), ilustrado na Figura 6. Se não houvesse um broker para centralizar a comunicação, esta poderia ser feita no exemplo por um serviço A, chamando um serviço B que retorna a resposta (entrada  serviço A  serviço B  resultado), ilustrado na Figura 7.
  24. 24. 24 Figura 6 - Exemplo de arquitetura utilizando broker. Fonte: Próprio autor. Figura 7 - Exemplo de arquitetura sem broker. Fonte: Próprio autor. • Broker pode se tornar gargalo: como todas as mensagens devem passar pelo broker, esta pode se tornar o gargalo do sistema, havendo a necessidade de expandir a quantidade de nós broker e com isso aumentando a complexidade de replicação de estado e manutenção da disponibilidade. 2.3.2 Sem Broker Na arquitetura sem um nó ou conjunto de nós que centraliza o processamento de mensagens, não possuímos o broker, e as aplicações se conectam diretamente umas às outras para troca de informações. Nesta arquitetura a principal vantagem é o número de requisições na rede que é diminuída consideravelmente quando comparado à arquitetura com broker, exemplificado nas comunicações da Figura 6 (com broker) e Figura 7 (sem broker). A desvantagem é o aumento de complexidade do gerenciamento dos nós, que agora estão totalmente descentralizados e para que se conectem uns aos outros devem conhecer o endereço de rede do destino que querem alcançar. Em um cenário real com centenas ou milhares de nós esta solução pode ser inviável. Para amenizar os problemas de manutenção de uma arquitetura sem broker, é possível utilizar uma arquitetura mista com um nó centralizado com a única responsabilidade de guardar os endereços e serviços de cada aplicação. Assim no exemplo dado acima, o serviço A consultoria o nó centralizado para saber qual endereço se encontra o serviço B, porém a transferência de mensagens ocorreria diretamente entre as aplicações, como ilustrado na Figura 8.
  25. 25. 25 Figura 8 - Exemplo de arquitetura utilizando um nó centralizado de endereços. Fonte: Próprio autor.
  26. 26. 26 3. Características dos Protocolos 3.1 CoAP O protocolo CoAP (Constrained Application Protocol) é um protocolo de aplicação baseado no estilo arquitetural REST para nós, sensores, smartphones ou qualquer outro aplicativo ou rede que possua restrições de recursos físicos como baixa bateria, perda de pacotes, entre outros. Ele suporta o paradigma de comunicação request/response entre aplicações e foi desenhado para ter uma interface simples com o protocolo HTTP, o que facilita a integração com a maioria das aplicações Web [7]. Segundo [8], as principais características do protocolo CoAP são: • Protocolo desenhado para atender aos requisitos de ambientes M2M; • Utiliza o protocolo User Datagram Protocol (UDP) para transporte, suportando unicast e multicast; • Troca assíncrona de mensagens; • Poucos bytes de header; • Suporta URI e Content-Type; • Recursos de proxy e cache simples; • Possível fazer mapeamento para HTTP de forma transparente (GET, PUT, POST, DELETE); • Para garantir segurança é possível utilizar Datagram Transport Layer Security (DTLS), RFC 6347. Por ser construído sobre o protocolo UDP, ele possui menos overhead que o protocolo Transmission Control Protocol (TCP), devido ao fato do protocolo UDP trabalha com pacotes de dados não confiáveis, sem garantia de entrega, sem conexão e nem ordenação dos pacotes. Por exemplo, o header do TCP tem tamanho de 20 bytes enquanto um header do UDP possui 8 bytes. Existem outras formas de tratar a qualidade do serviço (QoS) mesmo utilizando um protocolo de transporte como o UDP, por exemplo o tratamento de retransmissão na aplicação que pode utilizar o protocolo TCP para troca de informações de controle com o destino a fim de se manter o status das entregas de pacotes UDP. No Quadro 1 é apresentado um comparativo entre os protocolos TCP e UDP. A porta designada
  27. 27. 27 pela Internet Assigned Numbers Authority (IANA), órgão responsável pela distribuição de IPs e tradução de nomes na internet, para o protocolo CoAP é a porta 5683. Quadro 1 - Comparação entre protocolo TCP e UDP Característica TCP UDP Conexão Orientado a conexão. Não possui conexão. Uso Recomendado para aplicações que requerem alta confiabilidade e tempo de transmissão é menos crítico. Recomendado para transmissão rápida. Como não possui estado, é capaz de responder pequenas pesquisas para um grande número de clientes. Protocolos que utilizam HTTP, HTTPs, FTP, SMTP, Telnet DNS, DHCP, TFTP, SNMP, RIP, VOIP. Ordenação de pacotes Organiza os pacotes na ordem especificada. Não possui. Se ordenação for necessária, deve ser feita pela aplicação. Velocidade da transferência Mais lenta. Mais rápida porque não existe verificação de erros nos pacotes. Confiabilidade Apesar dos mecanismos, não há garantia que o dado chegue intacto no destino. Nenhuma. Tamanho do Header 20 bytes 8 bytes Handshake (etapas para abrir uma conexão) SYN, SYN-ACK, ACK Não existe conexão. CoAP suporta caching colocando informações sobre a validade e data de criação da requisição nas respostas. Ele também possui um mecanismo de descoberta (discovery) detalhado na RFC 6690, baseado em duas alternativas definidas pelo IETF: pode ser por caminho do recurso, por exemplo /caminho/recurso (RFC 5785) ou usando recursos armazenados utilizando Web Linking (RFC 5988) que define como devem ser links tipados [5].
  28. 28. 28 Como mencionado acima, o protocolo CoAP possui duas formas principais de interação entre nós: modelo cliente/servidor utilizando request/response onde um cliente inicia uma transação com o servidor, e este pode retornar uma resposta correspondente a esta transação; ou interação publish/subscribe. No paradigma publish/subscribe de comunicação e, ao contrário do protocolo MQTT que oferece a inscrição em tópicos (detalhado na seção 3.2), o CoAP utiliza uma Universal Resource Identifier (URI) para inscrição de um sensor ou smartphone interessado no conteúdo atualizado por um produtor nesta URI. Quando um produtor (publisher) disponibiliza um novo conteúdo na URI, todos os consumidores (subscribers) são notificados sobre o novo valor [23]. Neste modelo, também chamado de Observer model, podemos ter uma arquitetura como a ilustrada na Figura 9. Figura 9 - Arquitetura CoAP usando Observer model Fonte: Davis et al (2013) [21]. CoAP utiliza um tamanho fixo de header (4 bytes) que pode ser seguido por opções e uma carga (payload). Cada mensagem possui um identificador usado para detectar duplicação ou fornecer confiabilidade. Uma mensagem que tem algum nível de confiabilidade é marcada como confirmável (CON), onde é retransmitida após um timeout padrão e utilizando o algoritmo de back-off exponencial, até que o destinatário enviei uma mensagem de confirmação (ACK) com o mesmo ID. Quando o destinatário não é capaz de processar uma mensagem, ele responde com um reset (RST) em vez de um ACK. Uma mensagem que não necessita confirmação pode ser enviada como uma mensagem não-confirmável (NON), a qual não será confirmada pelo destinatário com um ACK, porém quando o destinatário não
  29. 29. 29 consegue processar a mensagem, este também responde com uma mensagem de reset (RST). 3.1.1 CoAP com Observe Pattern O padrão de design Observer foi definido por [24] e permite que objetos interessados sejam avisados da mudança de estado ou outros eventos que ocorrem em um outro objeto. A implementação do paradigma publish/subscribe no CoAP foi baseado neste padrão, e acontece por meio de um sujeito (subject), observador (Observer), registro (registration) e notificação (notification), como ilustrado na Figura 10. Figura 10 - Padrão Observer Fonte: HARTKE, Klaus (2015) [25]. Na Figura 11 é demonstrado o fluxo de um cliente CoAP registrando o interesse em um recurso /temperature e recebendo três notificações: a primeira é o estado atual, as outras duas são mudanças no estado do recurso. O servidor CoAP (server) é o responsável por registrar os recursos observáveis e determinar as condições para mudanças de valores. Na figura o servidor poderia expor a URI coap://server/temperature, por exemplo para atualizar a temperatura de tempos em tempos, como também poderia expor um recurso coap://server/temperature/felt onde a mudança de valor para “FRIO” quando a temperatura está abaixo de 15 graus ou para “QUENTE” quando a temperatura está acima de 25 graus. Os valores para a
  30. 30. 30 opção Observe no header em uma requisição GET são: 0, adiciona entrada na lista se não houver; e 1, remove entrada da lista, se houver. Figura 11 - Observando recursos com CoAP Fonte: BANDYOPADHYAY et al (2013) [26]. 3.2 MQTT O protocolo MQTT foi desenvolvido originalmente pela IBM com o intuito de ser utilizado em redes com pouca banda e alta latência. Ele trabalha de forma assíncrona o modelo publish/subscribe sobre o protocolo de transporte TCP, usando a porta padrão 1883 (IANA). Na arquitetura utilizando MQTT existe um broker que contém tópicos, e cada cliente pode ser um produtor que envia informação para o broker em um tópico específico ou/e também um consumidor que recebe atualizações de um tópico específico na ocorrência de um determinado evento. O MQTT é desenhado ser eficiente também em termos de uso de bateria, o que explica por exemplo porque o aplicativo Facebook Messenger atualmente o utiliza [27]. MQTT garante a qualidade serviço em três diferentes níveis:
  31. 31. 31 1. QoS 0 - Disparar e esquecer (fire and forget): Uma mensagem é enviada somente uma vez e não necessita confirmação (acknowledgement). 2. QoS 1 - Entregue pelo menos uma vez: Uma mensagem é enviada pelo menos uma vez e uma confirmação é necessária. 3. QoS 2 - Entregue exatamente uma vez: É utilizado uma comunicação de 4 passos processo de conexão (handshake) para garantir que a mensagem seja entregue uma única vez. Como o MQTT roda sobre o TCP, ele herda da camada de transporte algumas sobrecargas na comunicação que podem torna-lo mais pesado quando comparado com outros protocolos como o CoAP executando sobre UDP. Para garantir segurança, o broker MQTT pode exigir autenticação utilizando TLS/SSL (Secure Socket Layers), os mesmos protocolos de segurança utilizados no HTTP. As mensagens MQTT podem conter um header variável que vem após o header fixo (que possui apenas 2 bytes) e antes do payload, que é uma carga variável contendo a mensagem em si. Existem 14 tipos diferentes de mensagens de definidos no MQTT, incluindo CONNECT, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, DISCONNECT, PINGREQ e PINGRESP. Alguns destes tipos de mensagens possuem mensagens de confirmação (acknowledges) dedicados, por exemplo, se um consumidor MQTT deseja se inscrever em um tópico, este envia uma mensagem SUBSCRIBE e espera pela resposta SUBACK do broker [6]. O MQTT também possui um mecanismo que informa aos nós interessados que houve a desconexão anormal de um cliente, usando testamento (Last Will and Testament). Esta mensagem de testamento é especificada pelo cliente quando este se conecta ao broker e possui um tópico, flag de retenção, QoS e payload. Ela somente é enviada pelo broker para os clientes que se inscreveram no tópico específico e se for detectada uma desconexão que não ocorreu pelo comando DISCONNECT, ou seja, que pode ter ocorrido por falta de bateria, perda de conexão ou qualquer outra causa. Comparando o MQTT ao CoAP é possível perceber que devido à falta de mecanismos de retransmissão como os do protocolo TCP, o CoAP utilizando UDP tende a ter maior taxa de perda de pacotes. De acordo com os estudos de [23], o protocolo MQTT oferece menor atraso na entrega de mensagens em redes com
  32. 32. 32 baixa perde de pacotes, por outro lado o protocolo CoAP utiliza menos banda para garantir a entrega da mensagem. Um resumo dos protocolos CoAP e MQTT é apresentado no Quadro 2. Quadro 2 - Comparando os protocolos CoAP e MQTT. Característica CoAP MQTT Modelos de comunicação Request-Response, ou Pub- Sub (Padrão Observe) Pub-Sub RESTful Sim Não Camadas de transporte UDP ou TCP TCP ou UDP (MQTT- SN [38]) Header 4 Bytes 2 Bytes Número de tipos de mensagem 4 16 Mensageria Assíncrono e Síncrono Assíncrono Níveis de qualidade de serviço 2 níveis (CON ou NON) 3 níveis (0, 1 e 2) Segurança IPSEC ou DTLS TLS/SSL
  33. 33. 33 4. Desenvolvimento Para analisar os protocolos MQTT, CoAP e HTTP, a arquitetura macro exibida na Figura 12 foi adotada. Cada nó se comunica diretamente com o broker e atua no modelo publish/subscribe tanto publicando quanto recebendo eventos que, neste último caso, são notificados aos outros nós de forma agnóstica ao protocolo utilizado. Os detalhes da arquitetura de teste são fornecidos nas próximas seções. Figura 12 - Arquitetura para o teste em visão macro Fonte: Próprio autor. 4.1 DETALHES DA ARQUITETURA DOS TESTES A arquitetura de testes possui uma única aplicação broker responsável por centralizar o recebimento e roteamento das mensagens, assim como armazenar as mensagens publicadas e conhecer o estado dos dispositivos conectados. Em uma aplicação real, caso o broker se torne um gargalo devido à falta de capacidade de comunicação ela deverá ser escalada ou a arquitetura deve ser reanalisada pois talvez o modelo sem broker. O ambiente criado para testes não possui autenticação e autorização, e não utiliza comunicação criptografada entre sensores e o broker de mensageria com intuito de simplificar os testes, ou seja, os protocolos MQTT e HTTP que rodam sobre o protocolo TCP não utilizaram TLS e o protocolo CoAP sobre UDP não utilizou DTLS.
  34. 34. 34 O paradigma de comunicação escolhido para os testes foi o publish/subscribe devido à sua natureza orientada a eventos que favorece o menor consumo de banda e se encaixa melhor nos requisitos de uma rede de IoT, oferecendo uma comunicação um para muitos, no qual os sensores e smartphones de testes se inscreveram em determinados recursos (para HTTP e CoAP) ou tópicos (MQTT). Os recursos e tópicos podem ser vistos neste teste como uma única entidade, sendo centralizados pelo broker Ponte, porém conceitualmente eles diferem um pouco principalmente pela estrutura de tópicos ser mais hierárquica e possibilitando inscrições mais genéricas como “minhacasa/sala/#”, que abrangeria todos os sub tópicos de “minhacasa/sala/”. A camada de persistência nesta arquitetura, como banco de dados relacionais ou não relacionais, chave/valor ou in-memory, proporciona funcionalidades principalmente referente a novos nós que estão se conectando à rede. Se não houver nenhum tipo de persistência estes novos nós serão capazes de receber somente notificações após a inscrição bem-sucedida com o broker. Por outro lado, com a camada de persistência é possível recuperar imediatamente após a inscrição o último valor publicado no tópico. A camada de persistência traz com ela dificuldade na escalabilidade quando a forma de persistência não suporta replicação e tolerância a falhas. 4.1.2 Ferramentas O ambiente de simulação foi divido em parte cliente e parte broker (servidor). A parte cliente, onde alguns nós se comunicam utilizando um dos três protocolos estudos, é composta por um laptop responsável por executar programas consumidores e produtores de informação. O laptop é equipado com processador core i5-2410M, 2,30GHz, 2,95 GB de memória RAM executando o sistema operacional Windows 7 Ultimate 32 bits, conectado à internet por meio do WiFi em uma conexão de 15 Mbps. No laptop foram executados dois tipos de aplicações: cliente feitos em Node.js para os protocolos MQTT e CoAP e requisições feitas pelo browser Google Chrome para o protocolo HTTP. A parte broker (servidor) é composta por uma máquina EC2 rodando na nuvem AWS localizada na região de São Paulo. Os detalhes do ambiente de testes montado são ilustrados na Figura 13.
  35. 35. 35 Figura 13 - Ambiente detalhado dos testes Fonte: Próprio autor. As ferramentas utilizadas para os testes foram: • Node.js, versão v0.10.40 [18] Interpretador de código JavaScript que funciona do lado do servidor baseado no interpretador V8 do navegador Google Chrome. Foi criado por Ryan Dahl em 2009, e seu desenvolvimento é mantido pela empresa Joyent. • Wireshark Portable 1.12.8 [28] Sniffer de rede utilizado para capturar o tráfego entre a AWS e os clientes (sensores) no laptop local e smartphone. • Putty [29] Cliente de SSH e Telnet para realizar a conexão com o servidor EC2 da Amazon. • Puttygen [30] Usado para converter a chave privada gerada pela Amazon do formato PEM para PPK, para ser utilizada na autenticação pela ferramenta Putty. • Pacotes NPM (embutido no Node.js) O NPM é o gerenciador de pacotes do Node.js e neste experimento foram utilizados os seguintes módulos externos e open source, disponíveis no repositório GitHub.com:
  36. 36. 36 o Eclipse Ponte [31] Adaptador do Eclipse Ponte para Node.js. o Bunyan [32] Biblioteca de logging para serviços Node.js. o Forever [33] Aplicação cliente para garantir a execução contínua de scripts Node.js. o MQTT [34] Biblioteca para o protocolo MQTT para Node.js. o Coap-cli [35] Cliente em Node.js para testes de comunicação utilizando o protocolo CoAP. o Coap [36] Biblioteca para o protocolo CoAP desenvolvida em Node.js. A instalação das ferramentas necessárias para se montar o ambiente exigiu a instalação de algumas dependências que não estavam presentes no laptop. Para sanar estas dependências o gerenciador de pacotes NPM foi utilizado. Uma dependência de vários módulos foi a do compilador Python, o que exigiu também instalação do Python 2.7 [37]. A ferramenta Ponte é a responsável por fazer a ponte entre os três diferentes tipos de protocolo utilizados neste trabalho: HTTP, MQTT e CoAP. A fim de reter os dados para suportar a publicação inicial para novos clientes HTTP/REST, Ponte suporta armazenamento de informações nos bancos de dados não relacionais MongoDB, Redis e LevelDB. Neste trabalho foi utilizado LevelDB [39] que é um banco de dados não-relacional criado pela Google, que provê armazenamento chave-valor.
  37. 37. 37 A arquitetura da ferramenta Ponte é ilustrada na Figura 14. Figura 14 - Arquitetura do broker Eclipse Ponte Fonte: Ponte [17]. 4.1.3 CONFIGURAÇÃO DO AMBIENTE No console de gerenciamento da AWS, foi criado um novo servidor do tipo EC2 na região de São Paulo, com o sistema operacional Linux Ubuntu, conforme detalhado no Quadro 3. A regras de firewall foram criadas pois são necessárias para abrir a comunicação entre o Ponte e a internet, que foi instalado em seguida.
  38. 38. 38 Quadro 3 - Configuração do servidor de teste na AWS Sistema Operacional Ubuntu Server 14.04 LTS 64bits Tipo da instância t2.micro Armazenamento 8 GB SSD Regras de Firewall Inbound: Outbound: Após a criação do servidor com as devidas regras de firewall, ele foi iniciado, como na Figura 15. Figura 15 - Servidor EC2 iniciado na AWS Fonte: Próprio autor. Tipo Protocolo Portas Origem SSH TCP 22 0.0.0.0/0 (qualquer) Custom TCP Rule TCP 1883 0.0.0.0/0 (qualquer) Custom TCP Rule TCP 3000 0.0.0.0/0 (qualquer) Custom UDP Rule UDP 5683 0.0.0.0/0 (qualquer) Tipo Protocolo Portas Origem All traffic All All 0.0.0.0/0 (qualquer)
  39. 39. 39 Para realizar a instalação do Ponte no servidor é necessário realizar uma conexão SSH com o mesmo utilizando um certificado PEM. Este certificado é gerado no painel de gerenciamento EC2 da Amazon, na aba “Network & Security”, “Key Pairs”. Após criar um novo conjunto de chaves pública e privada, é possível realizar o download do arquivo PEM com o conteúdo criptografado (RSA) da chave privada. Porém para se conectar ao servidor utilizando a ferramenta Putty é necessário converter o certificado PEM em um certificado PPK (Putty Private Keys). Para isso foi utilizada a ferramenta PuttyGen, conforme Figura 16. Figura 16 - Certificado PEM carregado, pronto para conversão para tipo PPK Fonte: Próprio autor. Com o certificado PPK e o servidor EC2 rodando é possível realizar a conexão utilizando a ferramenta Putty. Para isso, é necessário preencher o campo “Host Name” do Putty com o DNS público do servidor EC2. Também é necessário apontar o caminho do certificado PPK nas configurações do Putty em Connection, SSH, Auth, na seção Authentication Parameters. A Figura 17 mostra a interface do Putty preenchida com o endereço DNS do servidor EC2.
  40. 40. 40 Figura 17 - Ferramenta Putty com Host Name preenchido com DNS do servidor EC2 da Amazon. Fonte: Próprio autor. Se a conexão não for aberta devido ao erro “Connection timed out” se certificar que a porta 22 está aberta no servidor EC2. Se a conexão ocorrer com sucesso, será exigido um usuário, que por padrão é “ubuntu” para esta imagem instalada no servidor Ubuntu. Se todos os passos ocorreram com sucesso até este ponto, uma tela semelhante à Figura 18 deve ser exibida. Figura 18 - Conexão com sucesso ao servidor EC2 utilizando Putty. Fonte: Próprio autor.
  41. 41. 41 O próximo passo é realizar a instalação do broker neste servidor Ubuntu por meio do terminal Putty conectado. Primeiramente com a instalação do Node.js e depois do broker Ponte. Para instalar o Node.js, é necessário executar os comandos “$ sudo apt-get update” para atualizar a lista de pacotes e “$ sudo apt-get install build-essential” para instalar os compiladores essenciais. Para instalar o Node.js executa-se o comando “$ sudo apt-get install nodejs”. Também é necessário instalar o gerenciador de pacotes NPM utilizando o comando “$ sudo apt-get install npm”. Devido a um conflito com outro pacote, o executável no Ubuntu é chamado nodejs em não node como nos sistemas Windows. Assim, o Eclipse Ponte em sua instalação busca pelo executável node e não o encontra, o que gera um erro em sua instalação. Portanto é necessário indicar ao Ubuntu que o comando node deve apontar para o comando nodejs. Para isso é necessário criar um link simbólico entre o nodejs e node entrando na pasta /usr/bin, e executando o comando “$ sudo ln -s /usr/bin/nodejs /usr/bin/node”, e depois removendo o link existente na pasta /usr/sbin para o node, pelo comando “$ sudo rm node”. Nesta etapa é possível digitar node no terminal ver como resultado “> ” que é o terminal do Node.js, como a Figura 19. Figura 19 - Executando Node.js após configurar execução para a pasta /usr/bin/nodejs. Fonte: Próprio autor. Para instalar o broker Ponte e a biblioteca de logging Bunyan é utilizado o gerenciador NPM, com o comando “$ sudo npm install ponte bunyan -g”. A opção “–g” faz a instalação se tornar global, e os arquivos baixados são movidos para a pasta /usr/local/lib/node_modules. Para testar a instalação do Eclipse Ponte é possível executar o comando “$ ponte -v | bunyan”, o resultado é semelhante à Figura 20. É possível notar no log escrito pelo Bunyan que o servidor foi iniciado com os serviços MQTT, HTTP e CoAP nas portas 1883, 3000 e 5683, respectivamente. Estas portas são as mesmas que foram abertas no firewall do servidor EC2 no seu momento de configuração.
  42. 42. 42 Figura 20 - Eclipse Ponte executando sobre Node.js em um servidor EC2 da Amazon. Fonte: Próprio autor. Como este processo da Ponte está executando em primeiro plano, ele é finalizado assim que a sessão SSH é encerrada. Mas para este ambiente de testes é necessário que o broker esteja sempre ativa, enquanto o servidor estiver online. Para isto foi utilizado o módulo NPM Forever, que garante a execução contínua em segundo plano de qualquer script Node.js. Para instalar o Forever, executa-se o comando “$ sudo npm install forever –g”. Para testar a execução do Ponte com Forever é utilizado o comando “$ forever start "/usr/local/bin/ponte" "-v" ” e o retorno do Forever é “Forever processing file: /usr/local/bin/ponte”, como na Figura 21. Figura 21 - Forever processando continuamente o broker Ponte Fonte: Próprio autor. Neste ponto é possível fechar a conexão SSH da ferramenta Putty, pois o broker Ponte continua executando no servidor EC2 por meio do módulo Forever. O broker Ponte está executando com três serviços: HTTP, MQTT e CoAP. Como definido em sua documentação, é possível acessar recursos de acordo com o protocolo da seguinte forma: • HTTP: http://<Host_do_broker_Ponte_na_AWS>/resources/<algum recurso> • MQTT: mqtt://<Host_do_broker_Ponte_na_AWS>/<algum recurso> • CoAP: coap://<Host_do_broker_Ponte_na_AWS>/r/<algum recurso>
  43. 43. 43 4.2 Análise de Uso de Banda O teste visa evidenciar o requisito de consumo de banda dos protocolos analisados e foi realizado considerando-se somente um recurso nomeado “teste”, conforme as rotas listadas abaixo. O IP atual do broker (54.94.140.93) foi utilizado neste trabalho em vez de seu nome por ser mais curto e claro. • HTTP: http://54.94.140.93:3000/resources/teste • CoAP: coap://54.94.140.93:5683/r/teste • MQTT: mqtt://54.94.140.93:1883/teste Como sniffer para captura do tráfego da placa wireless do laptop foi utilizado o Wireshark, com a opção de filtragem por IP do servidor EC2 da Amazon, ou seja, todo tráfego de entrada ou saída relacionado com o Host da Amazon foi considerado inclusive a manutenção da conexão TCP nos casos dos protocolos MQTT e HTTP (CoAP utilizou UDP). O protocolo MQTT utilizou a qualidade de serviço nível 1 “at least once”, ou seja, a entrega da mensagem pelo menos uma vez. A fim de medir a quantidade de uso de banda em bytes, foram realizados os seguintes testes para cada um dos protocolos estudados: 1. Medição no recebimento de uma mensagem de 200 bytes; 2. Medição no recebimento de uma mensagem de 1 kbyte; Os testes com variação no tamanho da mensagem são importantes uma vez que, caso haja segmentação da mensagem, os protocolos de transporte TCP e UDP tratam de forma diferente este cenário. No caso do UDP pode haver perda de pacote, enquanto o TCP irá requisitar a retransmissão dos pacotes perdidos. Os resultados possuem gráficos CloudWatch disponíveis na AWS, referentes a quantidade de bytes de entrada de rede (Network in) e saída (Network out). Para se ter uma linha base dos bytes de entrada e saída do servidor EC2, foi extraída uma amostra a partir de seu funcionamento em stand by, ou seja, com o servidor no estado Running porém sem a execução explícita de requisições de teste, somente com as requisições de redes comuns à execução do sistema operacional instalado pela imagem do Ubuntu 14.04. A média por hora de saída de bytes na rede é de 384 bytes/hora, conforme a Figura 22. Existe um pico que ocorre às 6:33 AM todos os dias, mas que não afetaram os testes, uma vez que eles foram realizados no período da tarde, com curta duração.
  44. 44. 44 Figura 22 - Utilização de saída de rede do servidor EC2. Fonte: Próprio autor. A média por hora de saída de bytes na rede é de 82 bytes/hora, conforme a Figura 23. Da mesma forma que a saída de rede, existe um pico de entrada de rede por volta das 6:37 AM que não afetou os testes. Figura 23 - Utilização em bytes de entrada de rede do servidor EC2. Fonte: Próprio autor.
  45. 45. 45 4.2.1 Medição no recebimento de uma mensagem de 200 bytes Para iniciar os testes foram executados no laptop os programas clientes MQTT (Apêndice A.2) e CoAP (Apêndice A.4), os quais se inscreveram no tópico “teste”. Em seguida houve a publicação da mensagem de 200 bytes pelo cliente MQTT (Apêndice A.1), o recebimento da mesma pelos clientes inscritos no tópico “teste”, e uma requisição GET (Apêndice A.6) pelo cliente HTTP que está no paradigma request/response. A Figura 24 mostra a publicação (número 2) e recebimento MQTT (número 1), CoAP (número 3) e HTTP (número 4). Figura 24 - Publicação de 200 bytes e recebimento MQTT, CoAP e HTTP. Fonte: Próprio autor. É possível notar, observando a Figura 25, que a partir do tráfego capturado pelo Wireshark que no quadro número 102 ocorre a publicação do laptop para o broker e em 19 ms o broker faz sua publicação para o MQTT no quadro 104, e em
  46. 46. 46 21 ms para o CoAP no quadro 105. A requisição HTTP ocorre no quadro 121 com o GET e sua resposta no quadro 123 com o status OK. Figura 25 - Tráfego da publicação de 200 bytes Fonte: Próprio autor. Desconsiderando a quantidade de bytes necessários para controle e manutenção da conexão TCP do protocolo MQTT, é listada no Quadro 4 o consumo de banda de acordo com o tráfego capturado. Se for considerado o overhead de tráfego gerado pelo MQTT entre os quadros 102 (início da transmissão) e 148, seria necessário adicionar mais 427 bytes de controle, entre comandos de Ping e ACK. Quadro 4 - Comparativo de recebimento de 1 mensagem de 200 bytes Protocolo Recebimento (bytes) ACK (bytes) Total (bytes) MQTT (TCP) 264 + 394 (controle) 54 712 CoAP (UDP) 253 46 299 HTTP (TCP) 150 (REQ) + 373 (RES) 54 577 Analisando os resultados acima é possível perceber que o overhead do controle de conexões do MQTT pode não ser viável quando é necessário transmitir informar em que a qualidade do serviço não seja tão relevante, ou seja, a utilização do protocolo CoAP sem controle de erros e retransmissão seria mais vantajoso do que o MQTT. Quanto ao protocolo HTTP, sua natureza request/response acarreta uma sobrecarga na comunicação indesejável, uma vez que a utilização da banda na ocorrência de eventos é mais eficaz do que a realização de polling (sequênca de
  47. 47. 47 requisições de tempos em tempos) para obter novos dados. Neste teste para o recebimento de apenas uma mensagem não ficou tão evidente quanto o HTTP pode sobrecarregar a comunicação, mas em um outro cenário de exemplo fossem realizadas requisições HTTP a cada 5 segundos, e a taxa de ocorrência de eventos fosse de 5 eventos por minuto, seriam necessárias 12 requisições de 150 bytes, onde no máximo 5 delas seriam eficazes (com mudança no valor do recurso), ou seja, haveria uma perda de 1050 bytes (7 requisições de 150 bytes) por minuto. Postos os dados acima sobre a natureza do HTTP, nos próximos testes foram isolados os protocolos CoAP e MQTT, que utilizam o paradigma publish/subscribe. 4.2.2 Medição no recebimento de uma mensagem de 1 kbyte Na Figura 26 é mostrada a publicação e recepção de uma mensagem de 1024 bytes. Figura 26 - Publicação de 1024 bytes e recebimento MQTT, CoAP e HTTP Fonte: Próprio autor. O tráfego capturado desta publicação é mostrado na Figura 27. O ACK para o pacote MQTT no quadro 20 é recebido no quadro 27, e a publicação CoAP do quadro 21 é confirmada no quadro 24. O protocolo MQTT mantém a sequência de Ping Request/response, consumindo 170 bytes a mais a cada 10 segundos. Figura 27 - Tráfego da publicação de 1024 bytes
  48. 48. 48 Fonte: Próprio autor. Além disso o protocolo MQTT tentou retransmitir o pacote no quadro 28, o que gerou mais um tráfego de 1088 bytes (outra mensagem) e 66 bytes com a resposta no quadro 29 “TCP Dup ACK”, ou seja, indicando ao servidor que o ACK referente a esta requisição foi enviado no quadro 27. O Quadro 5 resume o tráfego total de dados considerando o tráfego de controle. Quadro 5 - Comparativo de recebimento de 1 mensagem de 1024 bytes Protocolo Recebimento (bytes) ACK (bytes) Total (bytes) MQTT (TCP) 1088 + 170 (Ping) + 1088 (retransmissão) 100 2446 CoAP (UDP) 1077 46 1123 Nas análises simples de apenas uma mensagem é possível notar que o protocolo CoAP tem o fluxo de comunicação mais simples e leve do que o protocolo CoAP. Para analisar a qualidade de serviço, que é um dos diferenciais do MQTT frente ao CoAP o próximo teste realiza uma sequência de publicações para os clientes. 4.3 Análise De Qualidade De Serviço 4.3.1 Medição no recebimento de mensagens de 1 kbyte a cada 500 ms, por um minuto A execução deste contou com dois clientes conectados recebendo mensagens de 1 kbyte a cada 500 milissegundos durante um minuto, conforme Figura 28. Figura 28 - Clientes recebendo mensagens de 1 kbyte a cada 500 milissegundos
  49. 49. 49 Fonte: Próprio autor. Houve a transmissão de 120 mensagens, sendo que tanto os clientes com protocolo MQTT quanto o CoAP receberam todas as mensagens enviadas. O total de bytes de entrada (249760 bytes) e saída (471226 bytes) de rede foram capturados pelo CloudWatch diretamente no servidor da Amazon, conforme Figura 29. Este uso abrange tanto o uso de rede pelos clientes consumidores e produtores.
  50. 50. 50 Figura 29 - Uso total de bytes de rede no servidor EC2 Fonte: Próprio autor. O cliente MQTT recebeu 141 pacotes e houve 10 retransmissões do broker para o cliente resultando em 10900 bytes de tráfego extra, assim como 6600 bytes de TCP Dup ACK. O total de ACKs do cliente para o broker foi de 8580 bytes com retransmissões e Ping requests, totalizando 144108 bytes. O cliente CoAP foi responsável por 120 pacotes de 5520 bytes de ACK do cliente para o broker mais 120 pacotes de 1079 bytes (129480 bytes) de envio do broker para o cliente, totalizando 135000 bytes. A diferença total entre os dois protocolos neste teste foi de 9108 bytes em um minuto, o que pode representar para um dado serviço que executa 24 horas por dia 7 dias por semana um acréscimo de 87,55 MBytes por semana, o que é um valor relativamente alta para uma rede limitada em recursos, o que pode significar possível perda de informações, desempenho ou prejuízo financeiro caso a
  51. 51. 51 transmissão física seja cara. Porém é necessário ressaltar que a qualidade de serviço utilizada nas comparações foi nível 1 para o MQTT para se tornar comparável com as mensagens confirmáveis do CoAP. O MQTT ainda disponibiliza o nível de serviço 2, que garante a entrega da mensagem uma única vez, funcionalidade que não possui correspondente no protocolo CoAP. 4.4 CONCLUSÕES SOBRE O DESENVOLVIMENTO Para o ambiente de testes foi proposta e configurada uma arquitetura com base nas orientações teóricas descritas nas seções anteriores. Como resultado dos testes é possível notar que quanto ao requisito de uso de banda (quanto menos melhor) o protocolo CoAP se destaca principalmente por sua comunicação sem conexão, enquanto o protocolo MQTT é sobrecarregado com os fluxos de controle TCP. O protocolo MQTT pode gerar vários Megabytes de tráfego a mais, que utilizariam recursos do sensor, consumindo energia e diminuindo seu tempo de vida. Como evidenciado também no trabalho de [26], que em sua pesquisa utilizou um emulador de rede para simulação de perda de pacotes de rede, o protocolo CoAP é mais eficiente tanto em termos de consumo de banda quanto consumo de energia (Figura 30) quando comparado ao MQTT. Figura 30 - Eficiência energética entre CoAP com Observe e MQTT Fonte: Bandyopadhyay e Bhattacharyya (2013) [26]. Nos testes é possível notar que as retransmissões usando MQTT ocorreram, mesmo em um curto período de tempo, gerando overhead de tráfego. Como
  52. 52. 52 também foi constatado por [23], uma alta taxa de perda de pacotes (25%) faz este efeito se destacar ainda mais no protocolo MQTT. O tamanho da mensagem também causa efeitos colaterais uma vez que pacotes CoAP perdidos tem que ser retransmitidos inteiramente, enquanto que somente segmentos perdidos são retransmitidos no MQTT. Porém em um cenário que a qualidade de serviço é primordial na entrega mensagem, o protocolo MQTT pode ser a escolha mais apropriada. O MQTT também é um protocolo que trabalha nativamente com o paradigma publish/subscribe além do benefício de possuir envio de mensagem “last will and testament” para identificar nós que se desconectaram. O fato de os tópicos serem mais flexíveis também é um diferencial pois é possível um cliente se inscrever em um conjunto de tópicos com uma única chamada para a rede, por exemplo, “cozinha/+/temperatura” inscreveria o cliente no tópico “temperatura” de todos os eletrodomésticos da cozinha.
  53. 53. 53 5. Considerações Finais e Trabalhos Futuros Neste trabalho foram analisados os protocolos HTTP, MQTT e CoAP quanto a dois requisitos: uso de banda e qualidade de serviço. Seu objetivo foi distinguir os melhores cenários para o uso de cada um dos protocolos quando se tem os dois requisitos analisados como essenciais no projeto de uma rede com restrições. Eles foram comparados quanto a suas características de comunicação em um cenário controlado que envolveu testes utilizando um servidor na nuvem da Amazon e clientes locais. Os grupos de trabalho e a literatura atualmente estão focados nos protocolos MQTT e CoAP como protocolos oficiais de IoT, porém o protocolo HTTP foi incluído neste trabalho pela sua vasta literatura, flexibilidade e compatibilidade com os maiores produtos de software do mercado. Para o HTTP, foi evidenciada a diferença tanto de paradigma de comunicação request/response quanto no uso de banda, porém ele ainda possui um importante papel em cenários em que o requisito compatibilidade é mais importante que uso de banda, por exemplo. A ferramenta Eclipse Ponte fez seu papel de integração entre os três protocolos estudados, apresenta baixo atraso no redirecionamento das mensagens. É possível evoluir a ferramenta para que suporte o protocolo MQTT-SN [38] que utiliza como camada de transporte UDP, assim como implementação da camada de segurança para cada um dos protocolos, oferecendo conexões DTLS (para UDP) e SSL (para TCP). Também é possível implementar chaveamentos dinâmicos de protocolo na Eclipse Ponte para que o protocolo mais adequado seja utilizado dependendo das condições da rede ou qualidade de serviço desejada para cada tipo de mensagem, tornando-a um hub inteligente para chaveamento entre os protocolos de IoT a fim de maximizar o desempenho da comunicação. Os testes e resultados obtidos neste trabalho podem ser estendidos com a realização de novos testes utilizando um simulador de rede, como a ferramenta WANem, e camada segura dos protocolos, DTLS e SSL para constatar a diferença no consumo de banda e qualidade de serviço em um cenário que tenha requisitos de segurança. Também é possível conduzir pesquisas variando a arquitetura de testes e paradigmas de comunicação, ou seja, conduzir testes com o modelo P2P entre sensores onde cada sensor também possui uma lista de endereços de seus vizinhos, sem a necessidade de um broker centralizadora destas informações.
  54. 54. 54 6. Referências 1. GUBBI et al. Internet of Things (IoT): A vision, architectural elements, and future directions. Future Generation Computer Systems, v. 29, n. 7, p. 1645-1660, 2013. 2. KARAGIANNIS et al. A Survey on Application Layer Protocols for the Internet of Things. Transaction on IoT and Cloud Computing, v. 3, n. 1, p. 11-17, 2015. 3. Gartner Hype Cycle for Emerging Technologies, 2015. Disponível em: http://www.gartner.com/newsroom/id/3114217. Acesso em 08 de março de 2016. 4. Internet of Things Architecture (IOT-A). Initial M2M API Analysis. Project Deliverable D3.1. 2013. Disponível em: http://www.iot-a.eu/public/public- documents/d3.1/view. Acesso em 22 de setembro de 2015. 5. DE CARO et al. Comparison of two lightweight protocols for smartphone-based sensing. Communications and Vehicular Technology in the Benelux (SCVT), 2013 IEEE 20th Symposium. IEEE, 2013. p. 1-6. 6. MQ Telemetry Transport. Disponível em: http://mqtt.org. Acesso em 17 de agosto de 2015. 7. SHELBY, Z.; HARTKE, K.; BORMANN, C. The Constrained Application Protocol (CoAP). 2014. 8. PEREIRA, C.; AGUIAR, A. Towards Efficient Mobile M2M Communications: Survey and Open Challenges. Sensors, v. 14, n. 10, p. 19582-19608, 2014. 9. OneM2M. Standards for M2M and the Internet of Things. Disponível em: http://www.onem2m.org/images/files/deliverables/TR-0009- Protocol_Analysis-V0_7_0_1.pdf. Acesso em 21 de setembro de 2015. 10.OASIS. AMQP Protocol Specification. Disponível em: http://docs.oasis- open.org/amqp/core/v1.0/os/amqp-core-complete-v1.0-os.pdf. Acesso em 21 de setembro de 2015. 11.XMPP Standards Foundation. XMPP RFCs. Disponível em: http://xmpp.org/xmpp-protocols/rfcs. Acesso em 21 de setembro de 2015. 12.FIELDING, R.. Architectural styles and the design of network-based software architectures. 2000. Tese de Doutorado. University of California, Irvine. 13.TOTTY, B.; GOURLEY, D.; SAYER, M.; AGGARWAL, A.; REDDY, S. HTTP: The Definitive Guide; O’Reilly & Associates, Inc.: Sebastopol, CA, USA, 2002.
  55. 55. 55 14.WONG, C. HTTP Pocket Reference; O’Reilly & Associates, Inc.: Sebastopol, CA, USA, 2000. 15.THOMAS, S. HTTP Essentials: Protocols for Secure, Scaleable, Web Sites; Wiley: Hoboken, NJ, USA, 2001. 16.HOHPE, G.; WOOLF, B. Enterprise integration patterns: Designing, building, and deploying messaging solutions. Addison-Wesley Professional, 2004. 17.Ponte. Disponível em: http://www.eclipse.org/ponte/. Acesso em 14 de novembro de 2015. 18.Node.js. Disponível em: https://Node.js.org. Acesso em 14 de novembro de 2015. 19.Amazon Web Services. Disponível em: https://aws.amazon.com/pt. Acesso em 30 de novembro de 2015. 20.EUGSTER et al. The many faces of publish/subscribe. ACM Computing Surveys (CSUR), v. 35, n. 2, p. 114-131, 2003. 21.DAVIS, E. G.; CALVERAS, A.; DEMIRKOL, I. Improving packet delivery performance of publish/subscribe protocols in wireless sensor networks. Sensors, v. 13, n. 1, p. 648-680, 2013. 22.ZeroMQ. Broker vs. Brokerless. Disponível em: http://zeromq.org/whitepapers:brokerless. Acesso em 6 de outubro de 2015. 23.THANGAVEL et al. Performance evaluation of MQTT and CoAP via a common middleware. Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP), 2014 IEEE Ninth International Conference on. IEEE, 2014. p. 1-6. 24.GAMMA et al. Design patterns: elements of reusable object-oriented software. Pearson Education, 1994. 25.HARTKE, K. Observing resources in CoAP. CoRE Working Group, 2015. 26.BANDYOPADHYAY, S.; BHATTACHARYYA, A. Lightweight Internet protocols for web enablement of sensors using constrained gateway devices. Computing, Networking and Communications (ICNC), 2013 International Conference. IEEE, 2013. p. 334-340. 27.MQTT used by Facebook Messenger. Disponível em: http://mqtt.org/2011/08/mqtt-used-by-facebook-messenger. Acesso em 6 de outubro de 2015. 28.Wireshark. Disponível em: https://www.wireshark.org/download.html. Acesso em 30 de novembro de 2015.
  56. 56. 56 29.Putty. Disponível em: http://www.putty.org. Acesso em 30 de novembro de 2015. 30.Puttygen. Disponível em: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. Acesso em 30 de novembro de 2015. 31.Ponte para Node.js. Disponível em: https://github.com/eclipse/ponte. Acesso em 28 de novembro de 2015. 32.Bunyan para Node.js. Disponível em: https://github.com/trentm/node- bunyan. Acesso em 28 de novembro de 2015. 33.Forever para Node.js. Disponível em: https://github.com/foreverjs/forever. Acesso em 28 de novembro de 2015. 34.MQTT para Node.js. Disponível em: https://github.com/mqttjs/MQTT.js. Acesso em 28 de novembro de 2015. 35.Coap-cli para Node.js. Disponível em: https://github.com/mcollina/coap-cli. Acesso em 28 de novembro de 2015. 36.Coap para Node.js. Disponível em: https://github.com/mcollina/node-coap. Acesso em 28 de novembro de 2015. 37.Python 2.7. Disponível em: https://www.python.org/download/releases/2.7. Acesso em 28 de novembro de 2015. 38.MQTT for Sensor Networks (MQTT-SN) Protocol Specification (Version 1.2). Disponível em: http://mqtt.org/new/wp-content/uploads/2009/06/MQTT- SN_spec_v1.2.pdf. Acesso em 5 de setembro de 2015. 39.Google LevelDB. Disponível em: https://github.com/google/leveldb. Acesso em 28 de novembro de 2015. 40.SEEBACHER, R. T. Messaging Challenges in a Globally Distributed Network. 2013. 41.LUZURIAGA et al. A comparative evaluation of AMQP and MQTT protocols over unstable and mobile networks. Consumer Communications and Networking Conference (CCNC), 2015 12th Annual IEEE. IEEE, 2015. p. 931-936. 42.MAGNONI, L. Modern Messaging for Distributed Sytems. Journal of Physics: Conference Series. IOP Publishing, 2015. p. 012038. 43.DESAI, P; SHETH, A.; ANANTHARAM, P. Semantic gateway as a service architecture for IoT interoperability. arXiv preprint arXiv:1410.4977. 2014. 44.COLLINA, M.; CORAZZA, G. E.; VANELLI-CORALLI, A. Introducing the QEST broker: Scaling the IoT by bridging MQTT and REST. Personal
  57. 57. 57 Indoor and Mobile Radio Communications (PIMRC), 2012 IEEE 23rd International Symposium on. IEEE, 2012. p. 36-41.
  58. 58. 58 APÊNDICE A – CÓDIGO FONTE DOS PROGRAMAS DE TESTE 1. MQTT PUBLISH Conteúdo de script Node.js: var mqtt = require('mqtt') , client = mqtt.connect('mqtt://54.94.140.93:1883'); client.publish('teste', 'MQTT mensagem', {qos: 1, retain: true}); client.end(); 2. MQTT SUBSCRIBE Conteúdo de script Node.js: var mqtt = require('mqtt') , client = mqtt.connect('mqtt://54.94.140.93:1883'); client.subscribe('teste'); client.on('message', function(topic, message) { console.log(message.toString()); }); 3. COAP PUBLISH Na linha de comando executar: coap put -p "COAP mensagem" coap://54.94.140.93:5683/r/teste 4. COAP SUBSCRIBE Na linha de comando executar: coap get -o coap://54.94.140.93:5683/r/teste 5. HTTP PUT REQUEST Na linha de comando executar: curl -X PUT -d 'HTTP mensagem' http://54.94.140.93:3000/resources/teste 6. HTTP GET REQUEST Na linha de comando executar: curl http://54.94.140.93:3000/resources/teste

×