MQTT

현재 내가 프로젝트 iot 시스템을 구현 중인데 이 프로젝트에서 mqtt 통신이 핵심이 돼 내가 공부할 겸 mqtt 프로토콜에 대해서 이해한 내용들을 간략하게 정리해봤다...!

Message Queuing Telemetry Transport

MQTT란?

• M2M(Machine-to-Machine)를 기반으로 하는 IoT(사물 인터넷) 개방형 프로토콜이다.
• 경량의 메시징 프로토콜 또는 규칙 세트이다.
  • 최소한의 전력과 리소스로 마이크로컨트롤러와 같은 iot와 모바일 어플리케이션 등 통신에 적합하다.
• 애플리케이션 Layer 프로토콜이다.
  • 일반적인 http와 같은 프로토콜과 달리 클라이언트-서버 모델이 아닌 Broker, Publisher, Subscriber 모델로 이루어진다.

python과 같은 다양한 언어에서 MQTT 프로토콜 라이브러리를 지원한다. 따라서 최소한의 코드 작업으로 MQTT 프로토콜을 사용하는 애플리케이션을 구현할 수 있다.

→ 이러한 이유로 Iot 데이터 전송 표준으로 사용된다.

MQTT 프로토콜

게시/구독 모델의 원칙을 기반으로 작동한다. 전통적으로 사용한 네트워크 통신의 모델인 클라이언트-서버 모델은 클라이언트에서 서버 측으로 요청하면 서버는 이를 응답하고 요청을 처리하는 방식으로 서로 데이터를 직접 주고 받는다.

하지만 MQTT의 통신에서는 Publisher(게시자), Subscriber(구독자)를 분리한 대신 Broker 라는 매개자를 도입해 메세지를 대신 전달해주는 역할을 한다. Broker는 게시자로부터 수신되는 모든 메세지를 필터링하고 구독자에게 직접 배포하는 중재 역할을 한다.

→ 하나의 토픽에 대해서 여러 구독자가 구독할 수 있게 하므로 1:N 통신에도 효과적이다.

공간 분리
• 게시자와 구독자는 서로의 네트워크 위치를 모르며 IP 주소 or Port 번호와 같은 데이터 교환 X

시간분리
• 게시자와 구독자는 동시에 실행되거나 네트워크를 통해 연결 X

동기화 분리
• 게시자와 구독자는 서로를 중단시키지 않고 메시지를 전송하거나 수신 가능
(ex, 구독자는 게시자가 메세지를 전송할 때까지 기다리지 않아도 됨)

MQTT 용어

• Broker: MQTT 프로토콜의 핵심으로 게시자가 전송하는 모든 메세지를 수신, 필터링하고 해당 토픽을 구독한 클라이언트(구독자) 모두에게 메세지는 전송하는 역할로 Server 와 역할이 유사
• 클라이언트: 메세지를 게시하거나 특정 토픽을 구독한 사용자로 브로커에 연결하는 모든 장치
• Application Message: MQTT 프로토콜을 통해 클라이언트들에게 전달되는 메세지로, QoS 및 Topic 과 연관되어 처리
  • Payload: 메시지의 실제 내용으로 바이트 배열로 표현될 수 있는 모든 데이터를 포함
  • Topic: 일종의 라벨, 메시지의 “제목” 역할로 메세지를 필터링하는 데 사용하는 UTF-8 문자열
    (아래에서 더 자세히 설명)
• Qos(Quality of Service): broker-client가 메세지 수신을 보장하기 위해 어느 정도로 일할지 정의하는 설정? 규칙
  (아래에서 더 자세히 설명)

MQTT 원리

아래는 mqtt 프로토콜을 통해 broker와 client가 서로 연결하고 작동하는 방식에 대한 간단한 설명이다.

1. client와 broker가 연결을 위해 클라이언트는 브로커의 ip address와 port 번호를 사전에 알고 있어야 하며 TCP/IP 연결이 되면 프로세스가 시작된다.

   클라이언트와 브로커가 TCP/IP 연결이 완료되면 클라이언트는 CONNECT 패킷을 보내고 브로커는 이에 대한 대답으로 CONNACK 패킷을 전송한다.
   (CONNACK 패킷에는 연결이 수락되었는지 or 거부되었는지를 나타내는 반환 코드가 포함)

2. 연결이 완료되면 클라이언트는 mqtt 브로커에 메시지를 게시하거나 특정 topic에 대한 구독을 하거나 둘 다 수행이 가능하다.
3. 브로커는 클라이언트로부터 게시된 메세지를 해당 topic을 구독한 모든 클라이언트들에게 메세지를 배포한다.

Topic

topic은 게시한 메세지의 라벨과 같은 제목(UTF-9 문자열)으로 해당 토픽을 구독한 클라인어트 모두에게 해당 토픽 메세지를 브로커가 배포한다.

토픽은 우리가 친숙한 url 구조의 Path 부분처럼 주소 지정 형식을 사용하는데 슬래시(/)로 각 토픽들을 계층화하고 구분할 수 있다.

Mqtt Topic의 여러가지 사항들이 있는데 간단하게 정리하면 다음과 같다.

• 계층 구조
  계층 구조의 수준은 슬래시(/)를 사용하며 파일 시스템과 유사하게 유사한 토픽들을 계층화 가능
• 와일드카드 구독
  ”+”, “#” 두 가지의 와일드카드로 topic에 특별한 기능을 추가 가능
• 대소문자 구분
  home/temperature 와 home/Temperature 는 서로 다른 주제
• 빈 레벨 없음
  /hoem//temperature 와 같이 빈 레벨이 있는 topic은 유효하지 않음

QoS

QoS는 Quality of Service의 약자로 mqtt 프로토콜만 아니라 다양한 네트워크 및 통신의 영역(ISP, VoIP 등)에서 사용되는 말 그대로 메세지의 quality를 보장하는 서비스이다.

무선 네트워크 통신 망은 아무래도 유선 네트워크 망과 비교해 방해 요소도 다양하고 불안정 할 수 밖에 없다. 하지만 메세지의 타입과 구현하는 시스템의 성격에 따라 무선 네트워크 망에서 항상 완벽한 수준으로 데이터를 전송할 필요가 없는 케이스도 존재한다.

QoS는 이러한 각기 다른 요구 사항에 따라 메세지 전송 퀄리티에 대해 “얼만큼 보장해야 하나?” 에 대해서 차등을 준 서비스의 수준으로 mqtt에서는 3개의 레벨로 구분한다.

1. QoS-0 (”최대 한 번”)
   가장 낮은 수준의 보장 서비스로 메세지는 딱 한번 전송되며 클라이언트에게 전달 여부를 확인하지 않고 바로 잊어버린다.
   “Fire and Forget” 타입이라고도 하며, 전달 여부를 확인하지 않고 딱 한번 메세지를 전송하므로 전송 퀄리티 보장 정도는 낮지만 가장 빠른 전송 레벨이다.
2. Qos-1 (”적어도 한 번”)
   중간 수준의 서비스로 메세지가 적어도 한 번은 클라이언트 측으로 전달되도록 보장한다. 이는 전달 여부를 확인해 메세지가 정상적으로 전달되지 못 했으면 다시 메세지를 보내기 위해 시도한다.
   하지만 메세지가 중복될 수 있으며 메세지가 도착한다는 보장은 있지만 한 번만 도착한다는 보장은 없다.
3. Qos-2 (:”정확히 한 번”)
   가장 높은 수준의 보장 서비스로 각 메세지가 의도한 클라이언트에게 한 번만 정확히 수신되도록 한다. 메세지의 핸드셰이킹 과정을 추적하며 가장 안전하고 퀄리티를 보장하지만 반대로 가장 느린 전송 레벨이다.

QoS 레벨은 게시자가 브로커에게 메세지를 게시할 때 지정되며 브로커는 지정된 QoS 레벨을 사용해 구독한 클라이언트들에게 일정 퀄리티의 서비스를 보장하며 메세지를 배포한다.

Advance

Header

MQTT 프로토콜은 TCP/IP을 기반으로 한 Application Layer의 프로토콜로 명령 및 응답 메세지 형식을 사용한다. MQTT packet은 고정 헤더, 가변 헤더, 페이로드로 최대 세 부분으로 구성된다. 각 필드의 타입과 사이즈는 아래의 표를 참고하면 된다.

1. 고정 헤더(Fixed Header)
   항상 존재하며 패킷의 첫 부분으로 Control Packet Type과 Flags 필드와 Remaining Length 총 세 필드로 구성된다.
2. 가변 헤더(Variable Header)
   패킷 명령의 타입에 따라 존재하며 관련된 추가적인 데이터를 제공한다.
3. 페이로드(Payload)
   수신받을 클라이언트로 최종적으로 전송될 메세지의 실제 내용을 포함한다.

위의 패킷 구조 table을 참고하면 알 수 있듯이 MQTT 프로토콜의 가장 작은 패킷의 사이즈는 2byte로 경량화 메시징 프로토콜로 저전력/낮은 리소스로 다양한 서비스 구현이 가능하다.

MQTT Broker 종류

시중에 라이브러리 형식으로 사용 가능한 MQTT Broker들이 다수 존재한다. 각각의 broker 들마다 고유한 기능과 특징이 존재하며 다음은 그 중 몇 가지 예와 간단한 설명이다.

1. Mosquitto: Mosquitto는 가장 인기 있는 MQTT 브로커 중 하나로 오픈 소스이며 Eclipse Foundation의 일부이다. Mosquitto는 가볍고 임베디드 시스템을 포함한 모든 유형의 시스템에 적합합니다. MQTT 버전 3.1 및 3.1.1을 지원한다.
2. HiveMQ: HiveMQ는 엔터프라이즈 배포에 적합한 고성능 MQTT 브로커로 MQTT 버전 3.1, 3.1.1 및 5.0을 지원한다. HiveMQ는 고가용성 및 확장성을 위한 클러스터링과 같은 기능을 제공하며 문제 모니터링 및 진단을 위한 제어 센터도 포함한다.
3. RabbitMQ: RabbitMQ는 MQTT를 포함한 여러 메시징 프로토콜을 지원하는 강력한 범용 메시지 브로커로 분산 및 연합 구성에 대한 지원을 포함하여 광범위한 기능 세트로 유명하다.
4. VerneMQ: VerneMQ는 MQTT 버전 3.1, 3.1.1 및 5.0을 지원하는 오픈 소스 고성능 MQTT 브로커로 대량의 동시 클라이언트를 처리하도록 구축되었으며 확장성이 뛰어나고 내결함성이 있다.
5. EMQ X: EMQ X는 확장성이 뛰어나고 가벼운 MQTT 브로커로 MQTT 버전 3.1, 3.1.1 및 5.0을 지원하며 IoT 애플리케이션용으로 설계되었으며 수백만 개의 동시 MQTT 연결을 처리할 수 있다.
6. Mosca: Mosca는 독립 실행형으로 사용하거나 다른 node.js 애플리케이션에 내장할 수 있는 node.js MQTT 브로커이다.
7. Aedes: Aedes는 모든 스트림 서버인 node.js MQTT 브로커에서 실행할 수 있는 베어본 MQTT 서버이다.

💡 MQTT Broker 실습은 나중에 기회가 되면 다른 post로 소개하겠다.

Reference

MQTT란 무엇인가요? - MQTT 프로토콜 설명 - AWS

MQTT 소개

MQTT란?

MQTT 프로토콜 분석 (1) – 개요 및 패킷 구조 분석