MQTT란?

[MQTT] (1) get started

Robin Hanboram Jang IoT, MQTT ,
  • What Is MQTT ?

MQ Telemetry Transport

Telemetry [원격측정 : 송신기를 이용하여 측정량을 측정 대상으로부터 멀리 떨어진 곳에 보내어 처리하고 기록하는 일.]
Transport[수송]

Design Principles

  1. Publish/subscribe messaging (useful for most sensor applications) : 다수의 클라이언트 연결에 적합한 Publish/Subscribe 네트워크 사용
  2. Minimize the on-the-wire footprint : 프로토콜이 차지하는 모든 면의 리소스 점유를 최소화
  3. Expect and cater for frequent network disruption – built for LOW BANDWIDTH, HIGH LATENCY, UNRELIABLE, HIGH COST networks : 느리고 품질이 낮은 네트워크의 장애와 단절에 대비
  4. Expect that client applications may have very limited processing resources available. : 클라이언트 어플리케이션 동작에 자원 활용이 극히 제한적임을 고려
  5. Provide traditional messaging qualities of service where the environment allows. : 신뢰성 있는 메세징을 위해서 QoS 옵션을 제공
  6. Publish the protocol royalty-free, for ease of adaption by device vendors and third-party software developers. : 개방형 표준 메세징 프로토콜을 지향하며 제3자 기기 제조업체와 소프트웨어 개발업체의 용이한 도입, 적용을 유도

[출처]Introducing MQTT

애초에 MQTT는 발행/구독(Publish/Subscribe) 방식의 메세지 큐(message queue[큐:자료구조:First In First Out])로, 원격 검침(telemetry)영역에 사용하기 위해 개발되었다. 원격 검침기의 대부분이 소형이며 통신 대역폭과 전원이 한정적인 환경에서 동작하므로, 이는 배터리 용량이 제한적이고 통신 품질을 일정 수준으로 유지하기 어렵다는 점에서 스마트폰 환경과 매우 유사하다. 이러한 제한적인 환경을 고려하여 디자인 되었기 때문에 MQTT 프로토콜은 최적의 프로토콜로 주목받고 있다.

  • MQTT 특징
  1. Publish/Subscribe :
    [기본원칙 : 메세지를 발행하고, 관심 있는 주제를 구독한다]
    Publisher와 Subscriber 모두 Broker에 대한 클라이언트로 작동하며, Publisher는 토픽을 발행하기 위한 목적으로, Subscriber는 토픽을 구독하기 위한 목적으로 Broker 서버에 연결한다. 하나 이상의 Pub과 Sub가 Broker에 연결해서 토픽을 발행하거나 구독할 수 있다. 또한 다수의 클라이언트가 하나의 주제를 구독할 수도 있다.
  2. 토픽 : Pub과 Sub이 작동하는 기준이다. 토픽은 (/)를 사용해서 계층적으로 구성할 수 있기 때문에 다수의 센서 기기들을 효율적으로 관리할 수 있다.
  3. 메세지 버스 : MQTT는 메세지 버스 시스템이다. MQTT Broker가 메세지 버스를 만들고, 여기에 메세지를 흘려보내면, 버스에 붙은 어플리케이션들이 메세지를 읽어가는 방식이다. 메세지 버스에는 다양한 주제의 메세지들이 흐를 수 있는데, 메세지를 구분하기 위해서 “Topic”을 이름으로 하는 메세지 채널을 만든다.
  4. Quality-Of-Service : MQTT에서 메세지의 신뢰성을 위해서 제공하는데, 서비스의 종류에 따라서 적당한 QoS 레벨을 선택한다.

0 : 메세지가 1번만 전달, 전달여부 확인 X – 유실 가능성
1 : 메세지가 최소 1번만 전달(1번 이상 전달 되겠다) – 중복 전달 가능성
2 : 메세지가 1번만 전달, 유일하게 핸드셰이킹(?) 과정 추적- 높은 품질을 보장하지만 성능의 희생

발행자와 구독자 모두 QoS를 지정할 수 있지만 발행자가 지정한 최대 QoS 수준이 우선이다. 예를 들어 발행자의 QoS 수준을 0 이라고 지정했을 떄, 구독자의 QoS 수준을 2로 지정했더라도, 브로커에 의해 무시되고 ‘QoS 0’ 수준의 서비스를 받게 된다.

  • MQTT Broker : MQTT 서버라고 하지 않고 중개인이라고 하는 이유는 MQTT가 Pub(발행인)과 Sub(구독자)가 메세지를 주고 받을 수 있도록 다리를 놔주는 역할만하기 때문이다. 다양한 종류의 Broker들이 있다.

Broker(중개인, 서버X)
-mosquitto(C기반, 클리스터링(?)이 안됨)
-HiveMQ(클리스터링은 됨, 저가 상용)
-Rabbit MQ
-IBM MQ
-Vertx

  • 클라이언트
    –이클립스 Paho : The Paho JavaScript Client is a browser-based libaray that uses WebSockets to connect to an MQTT server. A simple utility to demonstrate it tis included, and available online.
    Source : https://github.com/eclipse/paho.mqtt.javascript
  • IoT Connectivity를 위한 MQTT
    • Local connectivity (표준이 존재X)
      퀼컴,LG – Allseen
      얼라이언스 – Alljoyn
      인텔,삼성 – Open Interconnect Consortium
      애플 – Homekit
    • Remote connectivity : IoT기기들과 유저 모바일 기기 그리고 인터넷 서비스들은 IoT Internet Infra에 연결되고, 이때 MQTT를 사용할 수 있게 된다.
    • 인터넷 어플리케이션과의 연동
  1. 유저 모바일 어플리케이션 : 채널 분리, 메세지는 HTTP 기반으로 전송하고, 응답은 MQTT client로 받는다. 네이티브 혹은 하이브리드 앱에서 사용할 수 있다. (Ex. 페이스북 메신저)
  2. 웹 브라우저 : HTTP로 전송하는 건 동일하다. 응답은 웹 소켓을 이용한다. 많은 MQTT Broker들이 웹 소켓 인터페이스를 제공한다.
  3. 소형 디바이스 : MQTT 단일 인터페이스로 송/수신
  4. 웹 어플리케이션 : 그림에는 없지만, 인터넷 서비스와 Server-to-Server 방식으로 연결할 수 있다. 이 경우 양측이 Open API를 제공하고, 서로 호출하는 방식을 사용한다.

Continue reading →