MQTT

 

✅ MQTT란?

 

 -  IoT 디바이스들 간 통신에 사용하는 publish/subscribe 메시지 전송 프로토콜

 - 경량의 오픈소스 프로토콜이다.

 - 메시지 형식이 Binary format이라서 패킷 사이즈가 작고, 전송이 빠르고, 오버헤드나 전력소모가 적다.

 - 그래서 센서나 IoT 장치처럼 작은 메모리를 가진 저전력 장치끼리의 통신에 사용하기 좋다.

 

 

✅ Publish-Subscribe & 브로커 기반의 메시징 모델

 - MQTT는 Pub/Sub 아키텍처를 따르는 메시징 프로토콜의 일종이다.

 - MQTT 프로토콜은 아래 그림처럼 브로커 기반 모델(Publisher - broker - subscribers 연결된 구조)을 따른다.

 

🐥 Topic

 - 모든 MQTT 메시지에는 topic이라는 문자열이 포함되어 있다.

 - 토픽은 계층적으로 구성되어 있고, 각 계층은 '/'로 구분된다.

 

🐥 MQTT Broker & MQTT Client

- MQTT Client에는 publisher와 subscriber가 있다.

- MQTT Publisher

    -메시지를 MQTT broker에게 전송한다.

- MQTT Broker

    - Publisher와 subscriber 사이의 중개자이다.

    - 발신자로부터 메시지를 받아서 적절한 수신자들에게 전송해준다.

    - MQTT Publisher가 보내주는 MQTT 메시지를 받는다.

    - 어떤 MQTT Subscriber가 어떤 토픽을 구독했는지 알고 있따.

- MQTT Subscriber

    - 자신이 구독하고자 하는 토픽을 MQTT Broker에게 알려준다.

🐥 Publish & Subscribe

 - MQTT 메시지는 클라이언트(publisher)에 의해 특정 토픽에 게시되고,

    메시지가 게시되면 브로커는 특정 토픽을 구독하는 클라이언트(subscriber)에게 전달한다.

 

 - 하나의 메시지가 여러 개의 토픽에 게시될 수 있고,

    하나의 클라이언트가 여러 토픽을 구독할 수도 있다.

 - 여러 구독자가 하나의 토픽을 구독할 수도 있다.

 

 - 토픽을 subscribe할 때에는 와일드카드(#,+)를 사용할 수 있다.

 

 

 - 예시 )

    topic = "town/house/kitchen"

 

     #은 하위 수준 모든 토픽까지 포함, +은 같은 계층의 모든 토픽

 - "town/#" ----> "town/house", "town/house/kitchen", "town/house/bathroom" 구독
 - "town/+" ----> "town/house" 구독
 - "town/+/kitchen" ----> "town/house/kitchen" 구독

 

🐥 Broker

 - MQTT에서는 Publisher와 Subscriber가 분리되어 통신하므로 효율적이다.

 - Publisher와 subscriber는 서로의 존재를 모르며 직접 통신하지 않는다.

 - 따라서 클라이언트끼리는 서로의 IP주소와 포트번호를 알 필요도 없다.

 

 - Publisher - subscribers 는 제3의 요소인 broker를 통해 연결되어 메시지를 주고받는다.

 

 

✅ MQTT Qos(Quality of Service) levels

 

 - MQTT에서는 3가지 수준의 QoS 옵션을 지원한다.

 

🐥  QoS 0

 - 메시지를 "한 번만" 전송한다.

 - 메시지는 확인 없이 전송되며, 손실될 수 있다.

 - 메시지 하나하나가 중요하지 않거나 손실되어도 되는 경우 사용한다.

 - 전력소모가 가장 적다.

 

🐥 QoS 1

 - 메시지를 "최소 한 번" 전송한다.

 - 클라이언트(publisher)는 브로커에게 메시지를 전송하고, 브로커로부터 확인 응답이 올 때까지 기다린다.

 - 지정한 시간 내에 응답이 오지 않으면(timeout 발생하면), 메시지를 재전송한다.

 - 메시지 손실은 허용되지 않고, 구독자(subscriber)가 메시지를 중복으로 받는 것은 허용되는 경우 사용한다.

 

🐥 QoS 2

 - 구독자(subscriber)가 메시지를 "정확히 한 번" 받게끔 전송한다.

 - 클라이언트(publisher)가 브로커에게 메시지를 보내고,

    브로커는 구독자(subscriber)로부터 메시지 수신 확인 응답을 받을 때까지 메시지를 가지고 있는다.

 - 확인 과정이 2번 필요하므로, 전체 flow가 상대적으로 느리고 더 많은 리소스를 사용한다.

 - 메시지 손실과 중복 전송이 모두 허용되지 않는 경우 사용한다.

 

 

✅ MQTT Message persistency options

 

 - MQTT persistency 옵션을 변경하면 네트워크나 서버 장애가 발생하더라도 메시지 손실 없이 전송되는 것이 보장된다.

 

 - 옵션은 다음 3가지 중 하나로 지정 가능하다.

 

🐥  Non-persistent

 - 디폴트 옵션이다.

 - 메시지가 서버에 저장되지 않아서, 네트워크나 서버 장애가 발생하면 메시지가 손실된다.

 

🐥 Queued persistent

 - 메시지가 subsciber에게 전송될 때까지 서버에 저장된다.

 - 클라이언트(subscriber)가 오프라인인 경우에 메시지를 보관하고 있다가, 다시 연결되면 메시지를 전송한다.

 

🐥 Persistent with acknowledgement

 - 메시지가 subsciber에게 전송되고, subsciber로부터 수신 확인 응답을 받을 때까지 서버에 저장된다.

 - Subscriber가 수신 확인 응답을 하지 않으면, 응답할 때까지 메시지를 재전송한다.

 

 

 - Persistency가 보장될수록 메시지 저장공간 등 리소스가 많이 요구되므로, 영속성과 성능 간 tradeoff가 중요하다.

 

 

 

✅ Reference

https://www.hivemq.com/mqtt/