1. MQTT란?
- Message Queueing Telemetry Transport
- Publish-Subscribe 기반의 메시지 송수신 프로토콜.
- 작은 코드 공간이 필요하거나, 네트워크 대역폭이 제한되는 원격 통신을 위해, 즉 IoT와 같은 제한된, 혹은 대규모 트래픽 전송을 위해 만들어진 프로토콜.
- TCP/IP 프로토콜 위에서 동작하고, 굉장히 가벼우며, 많은 통신 제약들을 해결해줌.
- WiFi 등 기타 방법의 인터넷을 통해 TCP/IP 기반의 메시지 송수신을 한다는 것을 의미.
- 메시지가 가벼운 만큼 메시지 유형이나 QoS(Quality of Service, 서비스 품질)에는 제약이 가해짐.
2. MQTT 특징
- 연결 지향적
- MQTT 브로커와 연결을 요청하는 클라이언트는 TCP/IP 소켓 연결을 한 후 명시적으로 연결을 끊거나, 네트워크 사정에 의해 연결이 끊어질 때까지 상태를 유지함.
- Live라는 하트 비트와, Topic에 발행되는 메시지를 통해 연결을 유지하고, 메시지 송수신을 함.
- 연결이 끊어지면 재접속 가능.
- 브로커를 통한 통신
- MQTT 발행-구독 메시징 패턴은 오로지 브로커를 통해서만 통신할 수 있음.
- 개설된 Topic에 메시지를 발행하면, 해당 Topic을 구독하는 클라이언트들에게 메시지를 발행할 수 있음.
- 따라서 일대일 혹은 일대다 통신이 모두 가능함.
- Qos
- 0: 최대 1회 전송. Topic을 통해 메시지를 전송할 뿐, 보장은 하지 않음. (보낸 다음 잊어버림)
- 1: 최대 1회 전송. 하지만 구독하는 클라이언트가 메시지를 받았는지 불확실하면, 정해진 횟수만큼 재전송. 메시지의 핸드셰이킹 과정을 엄밀하게 추적하지는 않으므로, 중복의 위험성 존재.
- 2: 구독하는 클라이언트가 요구된 메시지를 정확히 한 번 수신할 수 있도록 보장. 메시지의 핸드셰이킹 과정을 추적하기 때문에, 높은 품질을 보장하지만, 성능의 희생이 따름.
- Qos 필드는 TCP/IP 데이터 전송의 처리에 영향을 주지 않고, MQTT 송신자와 수신자 사이에서만 사용.
- 메시지는 글자 수 제한이 없으므로, JSON 포맷 또는 파일 전송이 가능함.
- 0에 가까울수록 메시지 처리에 대한 부하가 줄어들고, 메시지 손실의 위험이 높아짐.
- 반대로 2에 가까울수록 메시지 손실 위험이 줄어들지만, 메시지 처리 부하가 급격히 늘어남.
- 0 ~ 1 정도의 QoS를 사용하여, 메시지 손실의 위험은 상위 어플리케이션 차원에서 관리하는 방법이 널리 쓰이고 있음.
- 토픽
- 메시지를 발행-구독하는 행위는 채널 단위로 일어남.
- 이를 MQTT에서는 토픽이라고 부름.
- 토픽은 슬래시(/)로 구분되는 계층 구조를 가짐.
company / firstFloor / SWoffice / temp - 각 토픽 레벨은 슬래시로 구분됨. 즉 위의 토픽은 회사 1층의 SW 부서 온도를 체크하는 토픽.
- + 문자는 One-Level 와일드 카드로, 여러 개의 토픽을 한 번에 지정할 수 있음.
conpany / firstFloor / + / temp - 위 토픽은 회사 1층에 있는 모든 부서의 온도를 체크할 수 있는 토픽.
- # 문자는 Multi-Level 와일드 카드로, 여러 레벨의 토픽을 대체할 수 있음.
company / firstFloor / # - 위 토픽은 회사 1층 모든 부서의 모든 조건(온도, 습도 등)을 체크할 수 있는 토픽.
$SYS/ - $ 문자는 시스템에 의해 사용되는 특수한 토픽. 주로 브로커의 내부 메시지를 위해 사용됨.
출처
https://underflow101.tistory.com/22
https://medium.com/@jspark141515/mqtt%EB%9E%80-314472c246ee
handsome