DENIS_Comparacao_de_Protocolos_de_Comunicacao

48 visualizações

Publicada em

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

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

Nenhuma nota no slide
  • RESPONDER PERGUNTAS!
  • Karagiannis, Vasileios et al., 2015 [2] tecnologias preenchem parcialmente os requisitos de IoT
    Falta de padrões
    + Motivação
    Sensores -> Alimentar bancos de dados -> Analytics /Big Data
    Sensores+Atuadores -> Agir no mudo real de forma ubíqua
    The initial goal of oneM2M is to create a common M2M Service Layer which can be readily embedded within different hardware and software,
    disseminar casos de uso,
    discutir nomenclaturas,
    endereçamento,
    interfaces de aplicação (APIs)
    e interfaces de hardware,
    otimizações de rede
    otimizar uso de energia
  • Porque HTTP, MQTT e CoAP?  Pereira e Aguiar,2014 -> oneM2M reforçaram a ideia que os protocolos CoAP, HTTP e MQTT atendem a comunicação.
    Outros candidatos: AMQP
    XMPP
    Niccolò et al., 2013 -> a falta de protocolos de aplicação otimizados para sensores -> necessidade design de protocolos leves -> MQTT e CoAP
    MQTT -> IBM, para M2M
    CoAP -> dispositivos e redes restritas
    HTTP -> compatibilidade e flexibilidade
    _____________________________________________________________
    Uso de banda
    overhead do protocolo,
    número de mensagens de controle
    Confiabilidade
    Segurança
    Qualidade de serviço: capacidade de entregar a mensagem correta, no momento esperado, para o destinatário.
  • Conceitos:
    Arquitetura orientada a Eventos
    Paradigma Publish/Subscribe
    HTTP -> request/response
    MQTT e CoAP -> publish/subscribe
    Desacoplamento de espaço: os produtores não possuem referências dos consumidores,
    Desacoplamento de tempo: Assíncrono, Produtores podem publicar mesmo que os consumidores estejam desconectados
    Desacoplamento de sincronização: não bloqueados aguardando mensagens
    Ferramentas
    Amazon Web Services
    Broker Eclipse Ponte: Ponte is a multi-transport Internet of Things / Machine to Machine broker.
    Tradução de payloads
    Segurança
    Tradução de Protocolos
    Trabalha com diversos SGBDs e Protocolos
    NodeJS: framework e interpretador javascript no lado do servidor, baseado na Engine V8 do Google Chrome
  • Polling
    MQTT  3 níveis de serviço
    At most once (0)
    At least once (1)
    Exactly once (2).
    Conceitos:
    Desacoplamento de espaço: os produtores não possuem referências dos consumidores,
    Desacoplamento de tempo: Assíncrono, Produtores podem publicar mesmo que os consumidores estejam desconectados
    Desacoplamento de sincronização: não bloqueados aguardando mensagens
    Ferramentas
    Amazon Web Services
    Broker Eclipse Ponte: Ponte is a multi-transport Internet of Things / Machine to Machine broker.
    Tradução de payloads
    Segurança
    Tradução de Protocolos
    Trabalha com diversos SGBDs e Protocolos
    NodeJS: framework e interpretador javascript no lado do servidor, baseado na Engine V8 do Google Chrome
  • Conceitos:
    Arquitetura orientada a Eventos
    Paradigma Publish/Subscribe
    HTTP -> request/response
    MQTT e CoAP -> publish/subscribe
    Desacoplamento de espaço: os produtores não possuem referências dos consumidores,
    Desacoplamento de tempo: Assíncrono, Produtores podem publicar mesmo que os consumidores estejam desconectados
    Desacoplamento de sincronização: não bloqueados aguardando mensagens
    Ferramentas
    Amazon Web Services
    Broker Eclipse Ponte: Ponte is a multi-transport Internet of Things / Machine to Machine broker.
    Tradução de payloads
    Segurança
    Tradução de Protocolos
    Trabalha com diversos SGBDs e Protocolos
    NodeJS: framework e interpretador javascript no lado do servidor, baseado na Engine V8 do Google Chrome
  • UDP -> fire and forget
  • Conceitos:
    Arquitetura orientada a Eventos
    Paradigma Publish/Subscribe
    HTTP -> request/response
    MQTT e CoAP -> publish/subscribe
    Desacoplamento de espaço: os produtores não possuem referências dos consumidores,
    Desacoplamento de tempo: Assíncrono, Produtores podem publicar mesmo que os consumidores estejam desconectados
    Desacoplamento de sincronização: não bloqueados aguardando mensagens
    Ferramentas
    Amazon Web Services
    Broker Eclipse Ponte: Ponte is a multi-transport Internet of Things / Machine to Machine broker.
    Tradução de payloads
    Segurança
    Tradução de Protocolos
    Trabalha com diversos SGBDs e Protocolos
    NodeJS: framework e interpretador javascript no lado do servidor, baseado na Engine V8 do Google Chrome
  • Conceitos:
    Arquitetura orientada a Eventos
    Paradigma Publish/Subscribe
    HTTP -> request/response
    MQTT e CoAP -> publish/subscribe
    Desacoplamento de espaço: os produtores não possuem referências dos consumidores,
    Desacoplamento de tempo: Assíncrono, Produtores podem publicar mesmo que os consumidores estejam desconectados
    Desacoplamento de sincronização: não bloqueados aguardando mensagens
    Ferramentas
    Amazon Web Services
    Broker Eclipse Ponte: Ponte is a multi-transport Internet of Things / Machine to Machine broker.
    Tradução de payloads
    Segurança
    Tradução de Protocolos
    Trabalha com diversos SGBDs e Protocolos
    NodeJS: framework e interpretador javascript no lado do servidor, baseado na Engine V8 do Google Chrome
  • LevelDB: banco de dados chave-valor
    Conceitos:
    Arquitetura orientada a Eventos
    Paradigma Publish/Subscribe
    HTTP -> request/response
    MQTT e CoAP -> publish/subscribe
    Desacoplamento de espaço: os produtores não possuem referências dos consumidores,
    Desacoplamento de tempo: Assíncrono, Produtores podem publicar mesmo que os consumidores estejam desconectados
    Desacoplamento de sincronização: não bloqueados aguardando mensagens
    Ferramentas
    Amazon Web Services
    Broker Eclipse Ponte: Ponte is a multi-transport Internet of Things / Machine to Machine broker.
    Tradução de payloads
    Segurança
    Tradução de Protocolos
    Trabalha com diversos SGBDs e Protocolos
    NodeJS: framework e interpretador javascript no lado do servidor, baseado na Engine V8 do Google Chrome
  • Trabalhos futuros
    Qual contribuição o trabalho traz para quem o lê?
    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.
  • Trabalhos futuros
    Qual contribuição o trabalho traz para quem o lê?
    HTTP: justificar saída dos demais testes
    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.
  • Trabalhos futuros
    Qual contribuição o trabalho traz para quem o lê?
    COLOCAR TÍTULO DO terceiro TESTE
    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.
  • HTTP: e para otimizá-lo é necessário um cenário em que a emissão de eventos possa ser previsível.
  • DENIS_Comparacao_de_Protocolos_de_Comunicacao

    1. 1. Comparação de Protocolos de Comunicação CoAP, MQTT e HTTP utilizando Eclipse Ponte e Amazon Web Services Denis Storti da Silva Orientador: Professor Doutor Osvaldo Gogliano Sobrinho São Paulo, 2016
    2. 2. Agenda  Motivação  Por que foi feito? Qual o problema?  Objetivo  O que foi feito?  Desenvolvimento  Como foi feito?  Resultados  Quais os resultados?  Considerações finais
    3. 3. Motivação: Por que foi feito?  Tendência no mercado (Gartner)  Arquitetura referência de Internet of Things (IoT) não estabelecida  Protocolos para Internet of Things aplicados à vários cenários  Diversos requisitos (confiabilidade, segurança, rastreabilidade, flexibilidade e durabilidade) Fonte: Internet of Things Architecture (IOT-A), 2013.
    4. 4. Fonte: Gartner Hype Cycle for Emerging Technologies, 2015. http://www.gartner.com/newsroom/id/3114217
    5. 5. Objetivo: O que foi feito?  Comparação de Protocolos HTTP, MQTT e CoAP (Pereira e Aguiar, 2014) (Niccolò et al, 2013)  Requisitos Uso de banda no tráfego de dados Qualidade de Serviço  Testes e medições: experimentação
    6. 6. Desenvolvimento: Como foi feito? Conceitos: •Paradigma Publish/Subscribe vs Request/Response •Arquitetura com Broker ou sem Broker •Comparação teórica entre os protocolos •Organização do Ambiente de testes •Testes
    7. 7. Comparando protocolos Característica CoAP MQTT HTTP Modelos de comunicação Request-Response, ou Pub-Sub (Padrão Observe) Pub-Sub Request-Response RESTful Sim Não Sim Camadas de transporte UDP ou TCP TCP ou UDP (MQTT- SN [37]) TCP Header 4 Bytes 2 Bytes 26 bytes Mensageria Assíncrono e Síncrono Assíncrono Sìncrono Níveis de qualidade de serviço 2 níveis (CON ou NON) 3 níveis (0, 1 e 2) 1 nível Segurança IPSEC ou DTLS TLS/SSL TLS/SSL
    8. 8. Desenvolvimento: Como foi feito? CoAP com Observe Pattern Fonte: BANDYOPADHYAY et al (2013)
    9. 9. Desenvolvimento: Como foi feito? Característica TCP UDP Conexão Orientado a conexão. Não possui conexão. 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. Verificação e recuperação de erros. Mais rápida porque não existe recuperação de erros, somente verificação. 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. Protocolos de aplicação e transporte •HTTP  TCP •MQTT*  TCP ou UDP •CoAP  UDP *este projeto utilizou MQTT com TCP
    10. 10. Ambiente de teste: Ferramentas • NodeJS como Engine para o backend • Amazon Web Services – Servidores EC2 na nuvem em São Paulo • Broker Eclipse Ponte como centralizador da mensageria
    11. 11. Eclipse Ponte Fonte: Eclipse Ponte
    12. 12. Ambiente de testes: configurações Importante: •Não houve autenticação e autorização •Não utilizaram-se camadas de segurança (TLS, DTLS) •Não utilizou-se simulador de tráfego de rede (WANem) Detalhes: •Paradigma publish/subscribe •Smartphones, browser, e sensor* •Broker centralizador (Ponte) •Persistência: LevelDB (chave-valor) •Sniffer: Wireshark •Infraestrutura: Nuvem AWS •MQTT com QoS nível 1/ CoAP com CON
    13. 13. Ambiente de testes
    14. 14. Testes – Uso de banda  Medição no recebimento de uma mensagem de 200 bytes  Medição no recebimento de uma mensagem de 1 kbyte  Medição no recebimento de mensagens de 1 kbyte a cada 500 ms, por um minuto
    15. 15. Resultados – Uso de banda 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 1. Comparativo de recebimento de 1 mensagem de 200 bytes Protocolo Recebimento (bytes) ACK (bytes) Total (bytes) MQTT (TCP) 1088 + 170 (ping) + 1088 (retransmissão) 100 2446 CoAP (UDP) 1077 46 1123 2. Comparativo de recebimento de 1 mensagem de 1024 bytes Houve retransmissão do pacote Polling (REQ/RES)
    16. 16. Resultados – Uso de banda 471226 bytes 249760 bytes MQTT: 141 pacotes 10 retransmissões Total: 144108 bytes CoAP: 120 pacotes Total: 135000 bytes Diferença: 9108 bytes/min Em um serviço 24/7 Tráfego extra de 87,55 MBytes por semana 3. Medição no recebimento de mensagens de 1 kbyte a cada 500 ms, por um minuto
    17. 17. Considerações Finais  CoAP é o protocolo mais eficiente quando falamos em uso de banda, gerando até 50% menos tráfego que o MQTT.  CoAP se mostrou confiável nos testes (não deixou de entregar nenhum pacote)  O HTTP não se mostrou eficiente em uso de banda.  O MQTT oferece um equilíbrio entre confiabilidade e uso de banda.  MQTT para qualidade de serviço  QoS 2 (exactly send once) que o CoAP não oferece. Trabalhos futuros:  Simulações exaustivas com simulação de rede  Testes utilizando camada de segurança (TLS, DTLS)  Realizar testes em campo  Melhoramento da Broker Ponte Eclipse (outros protocolos e armazenamentos)
    18. 18. Obrigado! Perguntas?

    ×