MQTT는 경량의 Pub/Sub 메시지 프로토콜로 M2M, IoT에서 사용하기위해 낮은 전력, 낮은 대역폭 환경에서 사용될 수 있도록 설계되었고 TCP/IP프로토콜 위에서 동작하지만 가볍고 많은 통신 제약을 해결해준다.
하지만 메세지가 가벼운만큼 메세지 유형이나 서비스품질(QoS)에는 제약이 따른다.
장점
1. 효율적이면서 가벼움
IoT 디바이스에서 구현할 때는 최소한의 리소스가 필요하다. 마이크로컨트롤러에서도 사용될 수 있어야해서 가장 작은 MQTT 메시진 데이터 2byte정도로 작다. MQTT 메시지 헤더도 작기때문에 네트워크 대역폭을 최적화할 수 있다.
2. 연결성
MQTT 브로커와 연결을 요청하는 클라이언트는 TCP/IP 소켓연결을 하고 네트워크 사정에 의해 연결을 끊어지거나 명시적으로 연결을 끊을 때까지 상태를 유지한다.
MQTT에는 IoT 디바이스에서 클라우드에 다시 연결하는 데 소요되는 시간을 줄여주는 기능이 기본적으로 탑재되어 있다. 최대 1회(0), 최소 1회(1) 및 정확히 1회(2)라는 3가지 서비스 품질 수준을 정의하여 IoT 사용 사례에 필요한 신뢰성을 보장한다.
연결성에 3가지 서비스 품질 수준으로 정의한다했다.
0 : 최대 1회 전송으로. Topic을 통해 메시지를 전송할 뿐 보장하지않는다.
1: 최소 1회 전송으로 클라이언트가 메시지를 받았는지 불확실하면 정해진 횟수만큼 재전송한다.(중복발송이 될 수 있다.)
2: 구독하는 클라이언트가 요구된 메시지를 정확히 한 번 수신할 수 있도록 보장한다. 메시지의 핸드셰이킹 과정을 추적한다. (성능이 떨어질 수 있다.)
3. 일대일, 일대다 통신가능
MQTT의 발행-구독 메시징 패턴은 오로지 브로커를 통해서만 통신할 수 있으며 개설된 Topic에 메시지를 발행하면 해당 Topic을 구독하는 클라이언트들에게 메시지를 발행할 수 있다.
구조
MQTT는 HTTP, TCP등의 통신과 같이 클라이언트-서버 구조로 이뤄진게 아니라 Broker, Publisher, Subscriber 구조로 이뤄져있다.
MQTT 서버라 하지 않고 브로커라 하는 이유는 MQTT가 PUB와 SUB가 메세지를 주고 받을 수 있도록 다리를 놔주는 역할만을 하기 때문이다.
Publisher과 Subscriber은 모두 Broker에 대한 클라이언트로 작동한다. Publisher는 토픽을 발행하기 위한 목적으로 Subscriber은 토픽을 구독하기 위한 목적으로 Broker 서버에 연결한다. 하나 이상의 Pub와 Sub가 브로커에 연결해서 토픽을 발행 하거나 구독할 수 있다. 또한 다수의 클라이언트가 하나의 주제를 구독할 수도 있다.
토픽
PUB와 SUB는 토픽을 기준으로 작동하는데 토픽은 "/"를 이용해서 계층적으로 구성할 수 있어서 대량의 센서 기기들을 효율적으로 관리할 수 있다. 예를 들어 컴퓨터의 다양한 상태를 측정하는 센서가 있다면 위와 같이 구성할 수 있다.
참고
https://aws.amazon.com/ko/what-is/mqtt/
https://underflow101.tistory.com/22