MQTT vs CoAP

경량 IoT 통신 프로토콜

MQTT와 CoAP는 인터넷에 기반의 풍부한 리소스를 가진 디바이스로부터 IoT 기반의 제한된 리소스를 가진 디바이스로 통신을 지원한다.

CoAP와 MQTT는 모두 경량 애플리케이션 계층을 구현하며, 에러 보정의 많은 부분은 메시지 재시도, 간단한 신뢰성 전략에 넘기거나 최종 노드의 원데이터에 대한 후처리를 리소스가 더 풍부한 기기에 맡긴다. 자세한 내용은 그림 2를 참조할 수 있다.

 MQTT 및 CoAP는 클라우드와 스마트폰에 대한 통신을 지원한다

 

 

MQTT(Message Queuing Telemetry Transport)

• ISO 표준(IOS/IEC PRF 20922)
• 경량의 Publish/Subscribe(Pub/Sub) 메시징 프로토콜
• M2M(machine-to-machine)와 IoT(Internet of things)에서의 사용하려고 만들었다.
• IoT를 위해서 낮은 전력, 낮은 대역폭 환경에서도 사용할 수 있도록 설계됐다.
• 저전력, 신뢰할 수 없는 네트워크, No TCP/IP 기반에서 운용할 수 있다는 장점

Publisher는 Topic을 발행(publish)하고, Subscriber는 Topic에 구독(subscribe)한다.

Broker는 이들을 중계하는 역할을 하며, 단일 Topic에 여러 Subscriber가 구독할 수 있기 때문에, 1:N 통신 구축에도 매우 유용하다.

 

MQTT 특징

Publish/Subscribe

• 메시지를 발행(publishing) 하고, 관심 있는 주제를 구독(subscribe) 하는 것을 기본 원칙으로 한다.
• Publisher과 Subscriber은 모두 Broker에 대한 클라이언트로 작동한다.
• Publisher는 토픽을 발행하기 위한 목적으로 Subscriber은 토픽을 구독하기 위한 목적으로 Broker 서버에 연결한다.
• 하나 이상의 Pub와 Sub가 브로커에 연결해서 토픽을 발행 하거나 구독할 수 있다. 또한 다수의 클라이언트가 하나의 주제를 구독할 수도 있다.

Topic

• Pub와 Sub는 토픽을 기준으로 작동한다. 
• 토픽은 슬래시(/)를 이용해서 계층적으로 구성할 수 있어서 대량의 센서 기기들을 효율적으로 관리 할 수 있다. 

Message Bus

• MQTT는 메시지 버스 시스템이다. 
• MQTT Broker가 메시지 버스를 만들고 여기에 메시지를 흘려보내면, 버스에 붙은 애플리케이션들이 메시지를 읽어가는 방식이다. 
• 메시지 버스에는 다양한 주제의 메시지들이 흐를 수 있는데, 메시지를 구분하기 위해서 "Topic"을 이름으로 하는 메시지 채널을 만든다.
• 애플리케이션들은 Message Bus에 연결하고 관심있는 토픽(Topic)을 등록 해서 메시지를 구독(SUB)하거나 발행(PUB)한다.

QoS

MQTT는 3단계의 QoS(Quality of service)를 제공한다.

• 0 : 메시지는 한번만 전달하며, 전달여부를 확인하지 않는다. Fire and Forget 타입이다.
• 1 : 메시지는 반드시 한번 이상 전달된다. 하지만 메시지의 핸드셰이킹 과정을 엄밀하게 추적하지 않기 때문에, 중복전송될 수도 있다.
• 2 : 메시지는 한번만 전달된다. 메시지의 핸드셰이킹 과정을 추적한다. 높은 품질을 보장하지만 성능의 희생이 따른다.

서비스의 종류에 따라서 적당한 QoS 레벨을 선택해야 한다.

• No TCP/IP와 TCP/IP가 섞여있는 로컬 네트워크에서는 QoS 1, 2를 선택하는게 좋을 것 같다. 
  • 네트워크 구간을 신뢰할 수 없으며, 메시지 전송이 실패 했을 때, 메시지 박스에 저장하는 일을 하는 소프트웨어 시스템을 구축하기가 쉽지 않기 때문이다.
• 원격 네트워크에서는 0번이 좋을 것 같다. QoS 1이 적당할 것 같지만, 1이나 2를 선택할 경우 메시지 관리가 힘들어진다. 
  • 예를들어 offline 모드에서의 메시징을 지원하기 위해서 메시지 박스 서비스를 제공한다고 가정해 보자. 
  • QoS 1로 설정을 하면, 다음 연결에 메시지를 보내기 위해서 자체 queue에 저장을 한다. 그러면 시스템 입장에서는 MQTT queue에 있는 메시지를 읽어야 하는데, 메시지 박스에서 읽어야 하는지를 판단해야 한다.

 

CoAP

Constrained Application Protocol (제한적인 애플리케이션 프로토콜)

• 제약이 있는 장치들을 위한 특수한 인터넷 애플리케이션 프로토콜
• 간단한 전자 기기들의 인터넷 통신을 지원하기 위해 만든 프로토콜
• 저전력 센서, 스위치, 밸브 등의 기기를 표준적인 인터넷 환경에서 제어하기 위한 목적으로 만들어짐
• 무선 센서 네트워크(WSN:Wireless Sensor Network) 노드들처럼 제한된 자원의 인터넷 연결을 지원함
• 사물통신 시나리오에 요구를 충족하면서 REST 적합하게 셀계됨
• MQTT와 같이 RAM, ROM 메모리가 적은 마이컴에 적합함
• HTTP와 비슷한 메시지 구조를 가지고 있어서, HTTP와도 효과적으로 연결됨
• UDP 멀티캐스트를 지원, 사물인터넷과 M2M 디바이스 같은 환경에서 오버헤드를 줄일 수 있음
• WoT : Web of Things Protocol  이라고도 부른다.
• CoAP의 특징 : RESTful 프로토콜, 동기, 비동기 메시지 교환을 모두 지원, 제약 조건이 많은 단말, 네트워크 고려, 신뢰성 있는 유니캐스트, 멀티캐스트를 UDP 프로토콜을 이용하여 지원, 간단하게 파싱할 수 있는 헤더
• HTTP와 CoAP의 변환을 쉽게 할 수 있다.

 

MQTT vs CoAP

MQTT	CoAP
MQTT는 발행/구독을 기반으로 중앙에 있는 브로커와 연결됨 메시지는 브로커로 모여서 구독자에게 메시지를 복사해서 전달 지속적인 연결을 지원 실시간 데이터를 전달하는데 적당함	기본적으로 하나의 서버와 하나의 클라이언트가 참여하는 1:1 프로토콜 자원을 발견, 관찰할 수 있기는 하지만 이벤트 기반 데이터 통신에는 적합하지 않음 분산 환경에서의 상태 정보에 적당한 프로토콜
TCP/IP 기반 프로토콜로 서버(브로커)와 지속적인 연결을 맺기 때문에 NAT(Network Address Translation)와 같은 환경에서 문제없이 작동함	UDP 패킷만을 사용하기 때문에 NAT 환경에서 사용하기 힘듦 NAT 환경에서 사용하려면 터널링을 하거나 포트 포워딩(Port Forwarding)을 해야 함
서비스 발경 기능이 없기 때문에 DNS-SD, SSDP의 도움이 필요함	서비스 발견 기능을 기본으로 지원하기 때문에, 어떤 형식의 데이터를 사용해야 할지를 알고 있음

 

---

References

• https://www.hellot.net/news/article.html?no=27478%EF%BB%BF