[IoT 통신] MQTT 프로토콜 이론(1)

1. MQTT 프로토콜 배경

2. MQTT 프로토콜 개념

3. MQTT 구조 및 구성 요소

4. MQTT 프로토콜 Layer

5. MQTT 프로토콜 Topic 개념

6. MQTT 프로토콜 QoS 개념

7. 참고 문헌

MQTT 프로토콜 배경

MQTT (Message Queuing Telemetry Transport) 프로토콜은 Andy Stanford Clark(IBM)과 Arlen Nipper(Cirrus Link)이 1999년도에 공동으로 발명한 프로토콜이다. 그들은 위성을 통해 송유관과 연결하기 위해 최소한의 배터리 손실과 최소한의 대역폭을 가진 프로토콜이 필요했다.  

 

두 발명가들은 미래 개발할 프로토콜을 위해 몇 가지 요구사항을 정리했다. 

• Simple implementation
• Quality of Service(QoS) data deliver
• Lightweight and bandwidth efficient
• Data-agnostic
• Continuous session awareness

MQTT 프로토콜이란?

MQTT is a Client Server publish/subscribe messaging transport protocol. It is lightweight, open, simple, and designed so as to be easy to implement. These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium.

 

오피셜 MQTT 3.1.1 specification에 의하면 위와 같이 설명할 수 있다. 즉, MQTT는 Publish/Subscribe(게시/구독) 기반의 메시지 송수신 프로토콜이다.

MQTT 구조 및 구성 요소

Pub/Sub Architecture

MQTT는 Pub/Sub 아키텍처를 기반으로 동작한다.

• 메시지를 보내는 클라이언트(Publisher)와 메시지를 받는 클라이언트(Subscriber)를 분리(Decoupling)한다. 
• Publisher와 Subscriber는 서로 직접적으로 통신하지 않고, 제 3자인 Broker를 통해 연결된다.
• Broker는 모든 들어오는 메시지들을 필터링해서 Subscriber들에게 분배한다.
• 3가지의 Decoupling이 존재한다. 
  • Space decoupling: Publisher와 Subscriber는 서로 알 필요가 없다. 즉, IP주소와 포트를 공유하지 않는다. 
  • Time decoupling: Publisher와 Subscriber는 동시에 실행할 필요도 없다. 
  • Synchronization decoupling: 두 구성 요소의 작업을 게시하거나 수신하는 동안 중단할 필요도 없다. 
• Pub/Sub 패턴은 기존의 Client-Server 접근 방식보다 더 잘 확장된다.
  • Broker의 운영은 고도로 병렬화될 수 있고, 메시지를 이벤트 중심 방식으로 처리할 수 있기 때문이다. 
• Broker는 각 Subscriber가 관심있는 메시지만 받을 수 있도록 필터링 옵션들을 제공한다. 
  • Subject-based filtering
  • Content-based filtering
  • Type-based filtering

Pub/Sub VS MQ(Message Queue)

MQTT는 IBM에서 나온 MQ 시리즈를 나타내는 것이지 "Message Queue"와는 관련이 없다. 

• MQ모델에서 게시자는 각 Subscriber가 리슨하고 있는 특정 Queue로 메시지를 게시한다. 
• Pub/Sub모델에서 게시자가 여러 구독자가 리슨할 수 있는 Topic으로 메시지를 게시한다. 
• 즉, 전통적인 MQ에서는 하나의 메세지를 한 명의 소비자만 처리할 수 있지만, MQTT에서는 하나의 메시지를 다수의 소비자를 처리할 수 있다.

Client and Broker

Client

• Client는 Publisher와 Subscriber 둘 다를 나타낸다. 
• Publisher와 Subscriber는 현재 메세지를 게시하고 있는지 혹은 메세지를 구독하고 있는지에 따라 구별된다.

Broker  

• Broker는 모든 메시지를 수신하고, 메시지를 필터링하며, 각 메시지에 구독한 클라이언트를 확인하고, 해당 구독 클라이언들에게 메시지를 전송할 책임이 있다. 
• 또한, 구독 정보와 클라이언트가 접속하지 못한 동안 누락된 메시지를 포함한 지속성이 설정된 클라이언트들의 세션을 관리한다. 
• 클라이언트를 인증하고, 해당 클라이언트가 권한이 있는지를 확인한다. 

MQTT Connection

MQTT 프로토콜은 TCP/IP 기반이다. MQTT 연결은 항상 하나의 클라이언트와 브로커 사이에서 존재한다. 클라이언트들은 절대 서로 직접적으로 연결되지 않는다. 

Topics

• MQTT의 Topic은 UTF-8 문자열로 표현되고, Broker는 이 문자열을 사용하여 연결된 각 클라이언트가 받을 메시지를 필터링한다.
• 또한, Topic은 Message Queue와 비교하여, MQTT Topic들은 매우 가볍다. 
• 클라이언트는 Topic을 미리 생성할 필요 없이 원하는 Topic에 대해 발행(Publish)하거나 구독(Subscribe)할 수 있다. 
• Broker는 유효한 Topic이라면, 별도의 초기화 없이 모든 Topic을 수락한다. 

Whildcards

와일드카드는 클라이언트가 한 번에 여러 토픽을 구독할 수 있도록 도와주는 기능이다.

• 클라이언트는 특정 토픽만 구독할 수 있고, 와일드카드를 사용해 여러 토픽을 동시에 구독할 수도 있다. 
• 하지만, 와일드카드는 메시지 발행에는 사용할 수 없고, 구독에서만 사용할 수 있다.

와일드카드의 종류는 다음과 같다. 

Single-level Wildcard (+): 토픽 계층(Topic level) 한 단계를 대체한다. 

 

Multi-level Wildcard (#): 토픽 계층의 여러 단계를 대체한다. 

Topics Beginning with $

특수 목적으로 사용되는 토픽으로, 일반적인 구독/발행 용도가 아니다. 

• $로 시작하는 토픽은 멀티레벨 와일드카드(#) 구독에 포함되지 않는다. 
• $ 토픽은 MQTT 브로커의 내부 통계 정보(브로커 상태 정보, 연결 상태 등)에 예약되어 있다.
• 그렇기 때문에 클라이언트는 $ 토픽에 메시지를 발행할 수 없다. 

토픽 작성 권장 사항

토픽을 작성할 때 다음 규칙을 따르면 혼란을 줄일 수 있다. 

• 앞에 /(슬래시)를 붙이면 불필요한 빈 계층을 생성하기 때문에 리딩 슬래시(/)를 사용하지 말자.
  • 잘못된 예) /myhome/groundfloor/livingroom
• 토픽에 공백을 사용하면 프로그래밍에서 오류를 유발할 수 있기 때문에 사용하지 말자.
• 토픽은 짧고 간결하게 작성하고, 아스키 문자만 사용하자. 

QoS (Quality of Service) Levels

QoS는 메시지 발신자와 수신자 간의 메시지 전달 보장을 정의하는 MQTT의 중요한 기능이다.

QoS 전달 경로

• Publisher Client -> Broker
• Broker -> Subscriber Client

QoS Levels

• 0 (At most once): 최대 한 번 전달
• 1 (At least once): 최소 한 번 전달
• 2 (Exactly once): 정확히 한 번 전달

QoS 중요성

• Client가 네트워크 신뢰성 및 애플리케이션 요구사항에 맞는 Service Level을 선택할 수 있다.
• MQTT는 메시지 재전송과 전달 보장을 관리하기 때문에 신뢰성이 낮은 네트워크에서도 통신이 용이하다.  

QoS 수준별 동작

• QoS 0 -> "Fire and forget" (보내고 잊어버리기)
  • 최소 보장 수준으로, 최선의 노력(best effort)으로 메시지를 전달한다.
  • 전달 보장 없기 때문에 수신자가 메시지를 받지 못할 가능성이 있다. 
  • 메시지를 저장하거나 재전송하지 않는다.
  • 사용 예) 센서 데이터와 같이 메시지 일부 손실되어도 무방한 경우 

• QoS 1 
  • 메시지가 최소 한 번 전달되도록 보장한다. 
  • 발신자는 PUBACK 패킷(수신 확인 응답)을 받을 때까지 메시지를 저장한다. 
  • 네트워크 상태에 따라 중복 메시지가 전달될 수 있다. 
  • 패킷 식별자(Packet Identifier)를 사용하여 PUBLISH와 PUBACK 패킷을 매칭한다. 
  • 사용 예) 데이터 중복이 허용되지만, 누락은 허용되지 않는 경우

• QoS 2
  • 메시지가 정확히 한 번만 전달되도록 보장한다. 
  • 가장 안전하지만 느린 서비스 수준
  • 발신자와 수신자 간의 최소 2회의 Request/Response 흐름(Four-part Handshake)를 통해 보장한다. 
  • 패킷 식별자를 사용해 원본 메시지를 추적한다. 
  • 사용 예) 메시지 중복과 손실이 절대 허용되지 않는 중요한 데이터 

Reference

https://mqtt.org/mqtt-specification/  

MQTT Specification

https://cloud.google.com/solutions/event-driven-architecture-pubsub

Pub/Sub를 사용한 이벤트 기반 아키텍처  |  Solutions  |  Google Cloud

https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/

MQTT Topics, Wildcards, & Best Practices – MQTT Essentials: Part 5

https://www.hivemq.com/resources/download-mqtt-ebook/

A Comprehensive Guide to MQTT and MQTT 5