What is MQTT, MQTT Protocol ?

MQTT 공식 로고

MQTT란?

MQTT(Message Queueing Telemetry Transport)

2016년 국제 표준화 된 (ISO 표준 ISO/IEC PRF 20922) 발행-구독(Publish-Subscribe) 기반의 메시지 송·수신 프로토콜

• 작은 코드 공간이 필요하거나 네트워크 대역폭이 제한되는 원격 통신을 위하여 만들어진 프로토콜
• 즉, IoT와 같은 제한 된 혹은 대규모 트래픽 전송을 위해 만들어진 프로토콜
  • TCP/IP 프로토콜 위에서 동작하지만 동시에 굉장히 가벼우며, 많은 통신 제약들을 해결해줌
• 단, 메세지가 가벼운 만큼 메세지 유형이나 QoS(서비스 품질)에는 제약이 존재

MQTT 특징

1. 연결지향적(Connection Oriented)

• 연결이 끊어지면 재접속 가능
• Live 라는 하트비트와 Topic 에 발행되는 메세지를 통해 연결을 유지하고 메세지 송수신을 하게 됨

2. 브로커를 통한 통신

• MQTT의 발행-구독 메시징 패턴은 오로지 브로커를 통해서만 통신할 수 있으며 개설된 Topic에 메세지를 발행하면 해당 Topic을 구독하는 클라이언트들에게 메세지를 발행할 수 있음.
• 1:1, 多:多 통신 모두 가능

3. QoS (Quality of Service)

• 0 : 최대 1회 전송. Topic을 통해 메세지를 전송할 뿐 보장은 하지 않음. (보낸 다음 잊어버림)
• 1 : 최소 1회 전송. 구독하는 클라이언트가 메세지를 받았는지 불확실하면 정해진 횟수만큼 재전송.
  • 메세지의 핸드셰이킹 과정을 엄밀하게 추적하지는 않으므로 중복의 위험성 존재 (확인 응답을 거치는 전달)
• 2 : 구독하는 클라이언트가 요구된 메세지를 정확히 한 번 수신할 수 있도록 보장. 메시지의 핸드셰이킹 과정을 추적.
  • 높은 품질을 보장하지만 성능의 희생이 따른다. 보장된 전달
• 이 필드는 기반이 되는 TCP/IP 데이터 전송의 처리에 영향을 주지 않으며, MQTT 송신자와 수신자 간에만 사용됨
• 메세지는 글자 수 제한이 없으므로, 긴 메세지나 JSON 포맷 또는 파일도 전송이 가능함.

→ 0~1 정도의 QoS 를 사용하며 메세지 손실의 위험은 상위 어플리케이션 차원에서 관리하는 방법이 널리 쓰임

4. 메세지 유형

연결하기

: 서버와의 연결을 기다린 다음, 노드 간 링크를 생성한다.

연결끊기

: MQTT 클라이언트가 해야 할 일을 기다리고 인터넷 프로토콜 스위트 세션의 연결이 끊어지기를 기다림

발행하기

: MQTT 클라이언트에 요청이 전달된 직후 어플리케이션 스레드에 즉시 반환

5. 다양한 개발 언어의 다양한 클라이언트 지원

C/C++/Java/Node.js/Python/Arduino 등 여러 종류로 브로커와 라이브러리가 존재

MQTT 동작 구조

Topic Wildcard

• Single-Level Wildcard : +
  - myhome / groundfloor / + / temperature 의 형식으로 사용
• Multi-Level Wildcard : #
  - myhome / groundfloor / # 의 형식으로 사용

토픽 구조 구성 시 주의점

1. 최상위 토픽이 [/] 문자로 시작하지 않도록 : [/home/sensor/humid] 이렇게 사용할 수는 있지만 최상위 토픽이 이름이 없는 토픽이 되므로 사용하지 않는 것을 권장
2. 토픽 이름에 공백을 사용하지 않습니다.
3. 토픽 이름은 ASCII 문자 만 사용. (임베디드 장치와의 호환성을 위해 주의)
4. [#] 을 이용하여 토픽 전체를 구독하지 않도록. 오버헤드가 심할 경우 브로커/클라이언트 프로세스가 중단될 수 있음.

MQTT 브로커

MQTT 프로토콜 분석과 테스트 글 참조

WebSocket VS. MQTT

WebSocket의 장점

1. 웹소켓은 HTML5 와 함께 Web 기반 환경에서 사용하는 것을 주목적으로 나왔기 때문에 현재 대부분의 브라우저가 웹소켓을 지원하고 있음. 
2. 최초 연결에 HTTP/S를 사용하여 통신 환경 등에 영향 없이 안정적인 연결을 수립할 수 있다.
3. Server-Client 구조를 사용하기 때문에 Connection에 대한 직접적 관리 가능

MQTT의 장점

1. 발행/구독 구조를 사용해 다대다 전송이 용이
2. QoS(Quality of Service)를 통해 메시지 전송을 보증
3. 메세지 전송 후 전송한 메시지를 바로 삭제하지 않고 메시지 전송이 완료되었다는 패킷을 기다리기 때문에(PUBACK) 전송에 실패한 메세지를 주기적으로 재전송 할 수 있음
4. 작은 패킷 크기로 인해 오버헤드가 적고 저전력 환경에서도 동작이 가능

WebSocket vs MQTT ?

WebSocket은 더 낮은 레벨의 통신 프로토콜이며, MQTT는 더 높은 레벨의 통신 방법론이기 때문에 사실은 비교할 수 없는 대상이다.
→ 웹 기반 환경에서 WebSocket 대신 MQTT를 사용한다는 것은 특별한 이유가 있을 때만 필요한 것이며, 그것이 아니라면 대부분은 WebSocket 하나만 사용하는 것이 더 가벼울 것

MQTT 는 사물인터넷(IoT)를 위한 프로토콜 ... 수백만 개의 IoT 장치와 연결하도록 확장할 수 있음

MQTT 는 디바이스의 리소스를 적게 사용하도록 설계되어 있고, 단방향 통신이 아니라, device와 cloud 간 송수신을 하는 양방향 통신을 지원한다.
→ HTTP 통신은 요청-응답 기반이어서 클라이언트가 먼저 요청을 보내야 서버와 통신이 가능함. 반면에 MQTT는 클라이언트 혹은 서버 둘 중 누구나 통신을 시작할 수 있음

다양한 사용자 + 디바이스 환경을 고려하면서 성능을 목표로 하는 경우.. MQTT의 Publish/Subscribe 구조를 고려해보는 듯 ? 

도입 사례: Facebook Messenger

도입 사례 : 우아한 형제들

MQTT 적용을 통한 중계시스템 개선

우아한 형제들의 'MQTT 적용을 통하 중계시스템 개선' 글에서 적용 효과 부분을 살펴보면 간결, 정확성, API 서버 부하 및 트래픽 방지 등을 위해 소켓통신 대신 MQTT 를 채택하는 듯 하다.

---

웹 개발에서는 MQTT가 굳이 필요하지 않지만 서비스 개발에서도
'웹과 앱에서 모두 서비스 시키고 싶은 데.. 서비스 규모가 큰 경우' 채택을 많이 하는 듯 하다.
'+ 채팅 같은 양방향 소통이 필요한 서비스의 경우에

MES에도 이게 필요할 정도로 데이터가 쌓이나 싶기는 하지만,
조금 더 서버에 부하와 작업 시간을 줄이기 위해 MQTT를 도입하는 것 같다는 약간의 생각과 함께 MQTT 정리글을 마치도록 하겠다.