MQTT, MQTT Protocol ?

ony·2023년 2월 8일

공부

기초

목록 보기

5/6

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 / # 의 형식으로 사용

토픽 구조 구성 시 주의점

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

MQTT 브로커

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

WebSocket VS. MQTT

WebSocket의 장점

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

MQTT의 장점

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

WebSocket vs MQTT ?

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

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

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

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