https://www.emqx.com/en/blog/the-easiest-guide-to-getting-started-with-mqtt
https://www.emqx.com/en/blog/mqtt-5-introduction-to-publish-subscribe-model
위 문서들을 보고 정리한 글입니다.
1) MQTT
MQTT(Message Queuung Telemetry Transport):
리소스가 제한된 디바이스, 낮은 대역폭(Low Bandwidth), 높은 지연시간, 불안정한 네트워크 환경을 고려한
Lightweight한 Publish-Subscribe 기반 메세징 프로토콜
2) MQTT가 IoT에 적합한 프로토콜인 이유
1. Lightweight: 패킷 크기가 작음
2. Reliability: QoS(Quality of Service) 지원, 세션 지속(Session Awareness), 영속적 연결(Persistent Connection) 제공
3. Security: TLS/SSL 암호화 및 인증, 사용자 이름 비번 인증, 클라이언트 인증서
4. Bi-directionality(양방향 통신)
5. Stateful Sessions: 연결이 끊어져도 메세지 저장, 재전송 가능
6. Scalability
7. Language Support: Python, Golang, Node.js, Java 연동 쉬움
3) MQTT의 동작
MQTT client: MQTT protocol을 실행하는 모든 장치
MQTT Broker: client 간 메세지 중간 연결
Publish: client가 메세지 전송
Subscribe: client의 메세지 수신
Topic: 메세지 분류 주소
Publisher -> Broker -> Subscriber
Publisher: 메세지를 특정 Topic으로 전송
Broker: publisher가 보낸 메세지를 subscriber에게 전송
Subscriber: 특정 Topic 구독, 메시지 수신
4) MQTT의 주요 기능
1. QoS(Quality of Service)
메세지 손실 가능성 | 중복 가능성 | ||
QoS 0 | At most once | O | X |
QoS 1 | At least once | X | O |
Qos 2 | Exactly once | X | X |
2. Persistent Session
client가 오프라인 상태일 때도, session 유지
`Clean Session = false` : client 재연결 시 이전의 구독 정보 및 수신 받지 못한 메세지 수신
3. Last Will (마지막 유언)
client가 비정상적으로 종료 시, 특정 메세지를 특정 Topic에 발행
4. Retained Message
new subscriber가 바로 최근 메세지를 받을 수 있도록 MQTT broker가 보관하는 메세지
5) MQTT VS ???
MQTT | HTTP | |
통신 방식 | Pub/Sub | Request-Response |
연결 상태 | 항상 연결 유지 | 요청 마다 연결 생성 |
데이터 전달 | subscriber가 자동으로 메세지 수식 | client가 request시 서버 response |
네트워크 부하 | 낮음 | 높음 |
비정상 종료 처리 | 지속 세션 유지 | server는 client 상태 모름 |
MQTT | Message Queue (Kafka, RabbitMQ ...) | |
유즈케이스 | IoT, 실시간 메시징 | 대용량 데이터 처리 |
목적 | 디바이스 간 연결 | 서버 간 대량 데이터 전달 |
토픽 | 미리 생성할 필요 없음 | 사전에 생성해야함 |
'Server' 카테고리의 다른 글
MQTT - telegraf - InfluxDB (0) | 2025.02.03 |
---|---|
Web Server & Web Application Server 그리고 Reverse Proxy (0) | 2024.08.24 |
RTMP server 만들고 HLS로 웹 상에 실시간 비디오 스트리밍 (0) | 2024.07.30 |