[MQTT] MQTT broker 종류

1. [MQTT란?]

MQTT는 사물 통신(M2M), 사물 인터넷(IoT)과 같이 대역폭이 제한된 통신 환경에 최적화하여 TCP 기반으로 개발된 푸시 기술(push technology), 최소한의 전력과 패킷량으로 통신하는 프로토콜입니다. 따라서 IOT와 모바일 어플리케이션 등의 통신에 매우 적합한 프로토콜입니다.

 

MQTT는 HTTP, TCP등의 통신과 같이 클라이언트-서버 구조로 이루어지는 것이 아닌, Broker, Publisher, Subscriber 구조로 이루어집니다.

 

* Push기법: 푸시 기법은 서버 관점에서 사용자가 일일이 요청하지 않아도 사용자에게 자동으로 뉴스나 사용자가 원하는 특별한 정보, 매일 아침 우유나 신문이 집 앞에 배달되듯이, 이미 등록이 되어있는 서버에서 원하는 시간에 원하는 내용을 자신의 컴퓨터로 정기적으로 배달되도록 하는 방식의 기술을 말한다.

발행자(Publisher) - Broker - 구독자(Subscriber) 관계도

2. [MQTT 기능]

• 클라이언트끼리 연결: 
  - 메시지 전송하는 클라이언트(발행자)와 메시지 수신하는 클라이언트(구독자)를 연결시키는 브로커 역할
• 데이터 필터링: Topic을 통해서 원하지 않는 데이터를 필터링 가능

* 토픽은 슬래시(/)를 이용해서 계층적으로 구성할 수 있어서 대량의 센서 기기들을 효율적으로 관리 할 수 있다

계층적 Topic 예시

 

MQTT 통신의 예를 들어본다면

 

발행자(Publisher)

• 온도센서: 온도에 대한 값을 발행
• 습도센서: 습도에 대한 값을 발행

Broker

• MQTT Broker

구독자(Subscriber)

• PC: 습도 값을 구독 신청하고, 습도 값을 받는다
• 모바일: 온도 값을 구독 신청하고, 온도 값을 받는다

이런 구조가 될 수 있다.

 

3. [MQTT 서비스 품질]

신뢰성 있는 메시징을 위한 QoS(Quality of Service) 옵션 제공

- 구독 클라이언트가 게시 클라이언트보다 낮은 QoS를 정의하면 브로커는 낮은 서비스 품질로 메시지를 전송한다.

 

• Level 0 (At most Once)
  - 메시지는 한 번만 전달되며 전달의 성공여부는 확인하지 않음
  - 메시지 확인 응답을 하는 수신자나 전송을 재시도하는 송신자가 없는 최선 노력 전송 과정
• Level 1 (At least Once)
  - 메시지는 최소 한 번 이상 전달되며 Publisher에게 PUBACK을 전달하여 성공 여부를 알린다
  - 한 번 이상 전송되는 경우도 있으므로 수신자는 PUBACK 응답으로 확인 응답을 다시 전송
• Level 2 (Exactly Once)
  - 메시지는 반드시 한 번만 전달된다.
  - 메시지가 제대로 전송되었음을 보증하고 송신자와 수신자 모두에게 알린다
  - 이 모드는 송신자와 수신자 간의 다단계 핸드쉐이킹으로 더 많은 트래픽을 발생시킨다
  - 수신자가 메시지를 수신하면 PUBREC 메시지로 송신자에게 응답하게 되고, 송신자는 PUBREL 메시지로 응답..
  - 수신자는 PUBCOMP로 PUBREL의 확인 응답을 수행하고 PUBCOMP 메시지가 전송될 때까지 원래 메시지를 캐싱한다.

 

QOS level 2의 개념이 다소 생소하여 조금 더 설명을 하자면

QoS 2 흐름도

QoS LV2 진행 과정

1. Publisher가 메시지를 보낸다
2. Broker가 메시지를 전달한다 (Subscriber 1회 전달 받음)
3. Broker가 Publisher에게 PUB Received를 보낸다
4. PUBREC이 분실되어 Publisher가 다시 메시지를 보내도, Broker는 메시지를 이미 갖고 있기 때문에 Subscriber에게 다시 메시지를   보내지 않고 PUBREC를 다시 보낸다
5. Publisher는 PUBREC를 받으면, 이제서야Publish Release 메시지를 보낸다.
6. PUBREL이 loss되는 것은 문제 없다. 브로커는 이미 보냈다는 사실을 알고 있기 때문에 새로 보내지 않는다.
7. PUBREL을 받으면 Broker는 메시지를 삭제
8. 메시지를 정상 종료하였으므로 PUBCOMPLETE를 보낸다.

QoS 0,1,2가 사용되는 경우를 살펴보자면

QoS 0:

• 때때로 메시지 손실이 허용될 때
• 동일한 서브넷의 내부 서비스 또는 다른 클라이언트와 서버의 네트워크 간의 메시지 상호 작용이 매우 안정적일 때

QoS 1:

• 시스템 리소스 소비에 집중하고 최적화 된 성능을 원할 때
• 메시지를 잃을 수는 없지만 중복 메시지를 수락하고 처리 할 때

QoS 2:

• 메시지 손실 (메시지 손실로 인명 또는 재산 손실이 발생할 수 있음)은 용납 할 수 없으며 중복 메시지 수신을 원하지 않을 때
• 높은 데이터 완전성과 적시성을 요구하는 은행, 소방, 항공 등과 같은 일부 산업의 경우

4. [LWT]

lwt(Last Will and Testament)

• 연결 끊김, 배터리 방전 또는 기타 여러 가지 이유로 인해 비정상적인 연결 해제가 발생할 수 있고, 클라이언트가 정상적으로 연결이 끊어졌는지 (MQTT Disconnect 메시지 사용) 또는 비정상적으로 (연결 해제 메시지 없이) 연결이 끊어졌는지 알면 올바른 응답이 가능.
• MQTT는 클라이언트(Publisher)가 예기치 않게 네트워크로부터 연결이 끊어지는 경우 클라이언트(Subscriber)에게 예기치 않게 종료 되었음을 알리는 유언(LWT. Last Will and Testament)이라는 메시지를 MQTT 브로커에 저장한다.
• LWT는 클라이언트가 연결 단계 중에 지정하는 메시지로, 여기에는 Last Will 토픽, Qos그리고 실제 메시지가 담기게 된다.

예시의 경우를 들면

 

1. Client1 은 Offline을 페이로드(실제 메시지)로, lastWillRetain을 true로 설정하고 lastWillTopic을 client1/status로 설정한 lastWillMessage를 사용하여 브로커에 CONNET 메시지를 보냄
2. 클라이언트(client1)는 동일한 주제 (client1/status)에 대해 online 페이로드 및 유지 플래그가 true로 설정된 PUBLISH 메시지를 보낸다
3. Client1이 연결 상태를 유지하는 한 client1/status 토픽에 새로 구독하는 클라이언트는 online이라는 메시지를 보관
4. Client1이 예기치 않게 연결이 끊어지면 브로커는 새로운 유지 메시지로 페이로드 Offline을 사용하여 LWT 메시지를 게시
5. Client1이 오프라인인 동안 topic을 구독하는 클라이언트는 브로커로부터 LWT 보유 메시지 OFFLINE을 수신한다

5. [Keep Alive]

 

• MQTT가 TCP기반이지만 연결이 유실될 가능성은 있다 ex) 무선 센서 환경
  -> 장치가 전원이나 신호 강도를 유실하거나 현장에서 충돌하면 세션은 하프 오프 상태로 전환.
  -> 서버는 연결이 여전히 안정적이라고 간주하고 데이터 기다림
• 클라이언트는 PINGREQ 패킷을 중개자에게 전송하고, PINGRESP가 포함된 메시지로 수신 확인.
• 타이머가 클라이언트와 브로커 쪽에 사전 설정 되어있어서 메시지가 사전 지정된 제한 시간 내에 전송되지 않을 경우,  keep-alive 패킷이 전송된다.  PINGREQ 또는 메시지는 모두 keep-alive 타이머를 재설정함
• Keep-alive가 수신되지 않고 타이머가 만료된 경우, 브로커는 연결을 닫고 모든 클라이언트로 LWT 패킷을 전송한다.

6. [MQTT Library]

후에 JAVA에서 MQTT 통신하는 예제 코드를 올리도록하겠다.

우선 Paho라는 라이브러리를 사용한다.

 

7. [MQTT Broker]

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

 

• mosquitto
  - 무료에 사용법도 간단하고 가장 많이 사용되지만 클러스터링은 지원하지 못한다.
• HiveMQ
  - 유로라서 사용해보지 못했다....
• Rabbit MQ
  - Rabbit MQ는 MQTT지원보다는 AMQP 통신에 더 최적화되어있다는 글은 본 기억이 있다.
• IBM MQ
• Vertx
• VerneMQ
  - 예시가 별로 없어서 TCP 통신 쪽으로는 구현을 했지만 SSL은 아직 적용 실패 상태이다. 지원은 된다고 한다
  - mosquitto와 같이 무료로 제공하고 있으며 클러스터링도 지원된다고 되어있다.
  - LevelDB 코드 때문에 window에서는 지원이 안되고, linux나 MAC OS X에서는 지원이 된다.

저는 mosquitto와 VerneMQ로 개발해보았지만 일단은 mosquitto로 개발한 내용만 추후에 설명하겠습니다 ㅜ