Comparação de protocolos CoAP, MQTT e HTTP

DENIS STORTI DA SILVA
Comparação de Protocolos de Comunicação CoAP, MQTT e HTTP
utilizando Eclipse Ponte e Amazon Web Services

3
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
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
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
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
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
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
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
Figura 30 - Eficiência energética entre CoAP com Observe e MQTT........................51

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
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
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
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
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
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
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
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
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
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.

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
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
Figura 6 - Exemplo de arquitetura utilizando broker.
Figura 7 - Exemplo de arquitetura sem broker.
• 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
Figura 8 - Exemplo de arquitetura utilizando um nó centralizado de endereços.

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
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
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
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
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
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
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
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
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
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
Figura 13 - Ambiente detalhado dos testes
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
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
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
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
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
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
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
Figura 17 - Ferramenta Putty com Host Name preenchido com DNS do servidor EC2 da
Amazon.
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.

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.
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
Figura 20 - Eclipse Ponte executando sobre Node.js em um servidor EC2 da Amazon.
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
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
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
Figura 22 - Utilização de saída de rede do servidor EC2.
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.

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.
É 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
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
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
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
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
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
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
Figura 29 - Uso total de bytes de rede no servidor EC2
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
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
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
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
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
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
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
31.Ponte para Node.js. Disponível em: https://github.com/eclipse/ponte.
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.
34.MQTT para Node.js. Disponível em: https://github.com/mqttjs/MQTT.js.
35.Coap-cli para Node.js. Disponível em: https://github.com/mcollina/coap-cli.
36.Coap para Node.js. Disponível em: https://github.com/mcollina/node-coap.
37.Python 2.7. Disponível em: https://www.python.org/download/releases/2.7.
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
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
Indoor and Mobile Radio Communications (PIMRC), 2012 IEEE 23rd
International Symposium on. IEEE, 2012. p. 36-41.

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
coap get -o coap://54.94.140.93:5683/r/teste
5. HTTP PUT REQUEST
curl -X PUT -d 'HTTP mensagem' http://54.94.140.93:3000/resources/teste
6. HTTP GET REQUEST
curl http://54.94.140.93:3000/resources/teste

Comparação de protocolos CoAP, MQTT e HTTP

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Comparação de protocolos CoAP, MQTT e HTTP

Semelhante a Comparação de protocolos CoAP, MQTT e HTTP (20)

Comparação de protocolos CoAP, MQTT e HTTP