MQTT Broker Client (2)

wldbs._.·2024년 9월 9일

mqtt 스터디 정리

MQTT

목록 보기

2/7

주요 용어

Server: Application Message를 발행하는 client와 구독한 client 간의 중재자 역할을 하는 프로그램 또는 디바이스, broker라고도 한다.
Application Message: MQTT 프로토콜을 통해 네트워크를 통해 전달되는 메시지, QoS 및 Topic과 연관되어 처리된다.
Subscription: Topic Filter와 Maximum QoS를 포함하여 Server에 요청하게 되며, 구독 시 특정 Topic name을 가진 Application Message를 전달받을 수 있다.

"Quality of Service" (QoS)는 메시지 전달의 신뢰성 수준
"Maximum QoS"는 MQTT 브로커나 클라이언트가 처리할 수 있는 최대 QoS 수준 (상한선, 주로 정책이나 설정에 의해 결정)
- 예를 들어, 클라이언트가 QoS 2로 메시지를 보내려고 하지만 브로커의 최대 QoS 설정이 1이라면, 브로커는 이 메시지를 QoS 1 수준으로만 처리한다!

Topic name: Application Message에 붙여진 일종의 라벨, Server는 일치하는 Topic을 Subscription한 Client에게 Application Message를 전달한다.
Topic Filter: Subscription 요청 시 포함되는 일종의 표현식, 하나 또는 여러 개의 Topic을 구독할 수 있다. Topic Filter는 wildcard 문자가 포함될 수 있다.
MQTT Control Packet: 네트워크를 통해 전달되는 정보 Packet, MQTT 규격에서는 총 14개의 타입으로 Control Packet을 생성하여 전달할 수 있다

1. 클라이언트의 발행과 구독의 선후관계

MQTT 프로토콜에서 메시지를 발행하고 구독하는 과정은 독립적으로 작동할 수 있어, 발행(publish)와 구독(subscribe) 사이에 엄격한 선후 관계는 존재하지 않는다.

메시지 발행

클라이언트는 언제든지 주제(topic)에 메시지를 발행할 수 있다.

발행된 메시지는 해당 주제를 구독하는 모든 클라이언트에게 전달된다.
주제에 대한 구독자가 없다면, 발행된 메시지는 폐기되거나, 브로커 설정에 따라 일정 시간 저장 후 폐기될 수 있다.

메시지 구독

클라이언트는 관심 있는 주제를 구독하여 해당 주제의 메시지를 받을 수 있다.

구독이 성공적으로 이루어진 후에 발행된 모든 메시지는 실시간으로 구독자에게 전달된다.
구독한 후에 발행된 메시지만 받을 수 있으므로, 구독하기 전에 발행된 메시지는 받지 못한다.

선후 관계

1. 메시지를 발행하기 위해 먼저 주제를 구독할 필요는 없다!

발행자는 자신의 메시지를 원하는 모든 주제에 자유롭게 발행할 수 있으며, 이는 구독자가 있든 없든 상관없이 가능하다.

2. 메시지를 받기 위해서는 해당 주제에 대한 구독이 필요하다!

구독 과정을 통해 클라이언트는 특정 주제에 대한 모든 신규 메시지를 수신할 수 있다.

주제에 대해 구독한 클라이언트만이 그 주제의 메시지를 받을 수 있으며, 구독하지 않은 클라이언트는 메시지를 수신하지 않는다.

구독 프로세스:
1. 구독 요청: 구독자가 MQTT 브로커에 'A' 주제를 구독하겠다고 요청
2. 서버 처리: MQTT 브로커는 이 구독 요청을 받아들이고, 구독자의 정보를 해당 주제에 등록, 이 시점에서 'A' 주제에 대한 메시지가 없어도 구독은 성공적으로 등록됨
3. 메시지 대기: 구독자는 'A' 주제에 메시지가 발행되기를 대기, 'A' 주제에 대한 첫 메시지가 발행되는 순간, 구독자에게 해당 메시지가 전송됨

(실용적인 예)
예를 들어, 홈 오토메이션 시스템에서 여러 센서가 온도, 습도 등의 데이터를 발행할 수 있다.

중앙 관리 시스템이나 다른 장치들은 이러한 정보가 필요할 때 해당 주제를 구독한다.

센서는 주제에 대한 구독 여부와 관계없이 데이터를 지속적으로 발행할 수 있다.

2. MQTT control packet

1) 기본 구조

: MQTT Control Packet은 위와 같이 2~5byte의 Fixed Header를 시작으로 가변 헤더와 페이로드가 붙어서 구성된다.
Fixed Header는 필수요소이며 가변 헤더와 페이로드는 명령 타입에 따라 추가된다.

2) Control Packet type

: Byte 1의 7~4bit 내용으로, packet의 타입을 표현한다.

총 4bit이므로 2^4, 총 16개의 타입이 정의되어 있으며 각 타입은 위와 같은 기능을 수행한다.

3) Flags

: byte 1의 0~3bit 부분으로 Control Packet Type에 따른 추가 Flags가 정의된다.

다만 현재 규격에서는 PUBLISH Packet을 제외하고는 예약된 고정 값을 사용한다.

4) Remaining Length

: Fixed Header 부분을 제외한 현재 Packet의 전체 길이를 나타낸다 (변수 헤더와 페이로드 포함)

1~4 byte까지 사용 가능하다.
각 byte의 bit 0 ~ bit 6, 총 7 bit를 가지고 길이를 표현하며 bit 7은 "continuation bit" 라고 하여 다음 byte를 Length 계산에 포함할지를 정의하는데 사용한다.

-> 패킷 파싱 용이성: Remainder Length는 MQTT 브로커나 클라이언트가 패킷을 수신할 때 전체 패킷의 크기를 미리 알 수 있게 해주어, 네트워크 스트림에서 다음 패킷을 어디서 시작해야 할지 결정할 수 있도록 돕는다.

-> 가변 길이 인코딩: Remainder Length 필드는 1~4 바이트의 가변 길이를 가진다. 이는 패킷의 크기에 따라 필드 길이가 달라지기 때문에, 매우 작은 패킷과 큰 패킷 모두 효율적으로 처리할 수 있다.

Remainder Length는 각 바이트에서 최상위 비트(Most Significant Bit, MSB)가 연속적인 데이터 길이 정보로 사용되는 가변 길이 인코딩 방식을 사용한다:

각 바이트의 하위 7비트는 길이 정보를 나타낸다.
각 바이트의 최상위 비트는 연속 플래그로 사용되며, 이 비트가 1이면 다음 바이트도 길이 정보의 일부임을 의미하고, 0이면 그 바이트가 마지막 바이트임을 의미한다.

5) Variable Header & Payload

: 특정 타입의 MQTT Control Packet의 경우 Variable Header 또는 Payload 필드를 포함하고 있다.

특정 타입의 Packet들이 이 필드들을 사용하며, 여기에는 요청과 관련된 추가 정보들이 들어간다.

▶ Packet ID : 일부 MQTT 패킷의 경우 Non-Zero 2byte의 Packet ID(=Message ID)가 Variable Header에 기록되어 있는 경우가 있다.

이 ID를 이용하여 동일 요청에 의한 Packet임을 표현

reserved 필드는 특정 컨트롤 패킷의 헤더에서 일부 비트를 예약해두는 것
: 이 예약된 비트들은 프로토콜의 특정 버전에서는 사용되지 않을 수도 있지만, 미래의 확장성을 위해 미리 고려되어 설정된 공간
-> 예약된 필드를 사용하는 주된 목적은 프로토콜의 호환성과 확장성을 유지하는 것

CONNECT 패킷: MQTT의 CONNECT 패킷에서는 일부 플래그가 예약되어 있으며, 이러한 플래그는 반드시 0으로 설정되어야 한다
PUBLISH 패킷: PUBLISH 패킷의 경우, QoS 레벨에 따라 일부 플래그가 사용되거나 예약될 수 있다. 예를 들어, QoS 0에서는 DUP 플래그가 사용되지 않으며, 그 자리는 예약되어 있다.

Requested QoS (요청된 QoS)

정의: 구독 요청 시 클라이언트가 해당 주제에 대해 요청하는 QoS 레벨, 클라이언트가 메시지를 받고자 하는 신뢰성 수준

예를 들어, 중요한 메시지의 경우 QoS 2를 요청하여 메시지 전달이 정확히 한 번만 이루어지도록 요구할 수 있다

Granted QoS (부여된 QoS)

정의: 브로커가 구독 요청을 처리한 후, 실제로 구독이 설정된 QoS 레벨, 브로커가 클라이언트의 요청을 받아들이고, 구독 처리 결과를 나타내는 QoS 레벨

예를 들어, 브로커가 QoS 2를 지원하지 않을 경우, 클라이언트가 QoS 2를 요청하더라도 QoS 1이 부여될 수 있다

=> requested QoS는 클라이언트의 이상적인 설정을 나타내며, granted QoS는 브로커의 실제 지원 범위와 운영 정책을 반영

3. MQTT flag

Flags: 패킷 유형에 따라 다양한 동작을 지시하거나 추가 정보를 제공하는 데 사용된다.

이 플래그는 패킷 유형에 따라 의미가 다르며, 4비트 필드로 구성된다.
주로 패킷의 세부 행동을 지정하는 데 사용되며, 각 패킷 유형에 따라 그 의미와 사용 방법이 다르다.

Fixed Header의 byte 1의 0~3bit 부분으로, Control Packet Type에 따른 추가 Flags가 정의된다.

다만 현재 규격에서는 PUBLISH Packet을 제외하고는 예약된 고정 값을 사용한다.

1.PUBLISH Packet은 아래와 같이 Flags field를 사용한다.

▶ DUP(Duplicate flag, bit 3) : 메시지가 이전에 전송되었으나 아직 확인되지 않은 경우에 설정

  - 주로 QoS 1 또는 2에서 사용
  0일 경우, 첫번째 전달 시도임을 의미하며, 
  1일 경우에는 이전에 전달된 Packet이 재전송 Packet이라는 것을 의미한다. (QoS > 0)

▶ QoS(bit 1~2) : 메시지 전달의 품질 수준을 0, 1, 또는 2로 설정

▶ RETAIN(bit 0) : 이 플래그가 설정되면 브로커는 해당 메시지를 보관하고, 새로운 구독자에게도 이 메시지를 전달
: 보존된 메시지는 해당 주제를 새로 구독하는 모든 클라이언트에게 가장 최신의 메시지로서 전달된다.
-> 이는 새 구독자가 연결될 때 과거의 중요한 상태나 정보를 즉시 받아볼 수 있도록 해준다.

1일 경우, 서버는 해당 Topic의 최종 내용을 저장하고 있다가 향후 구독하는 Client에게 이를 전달한다.
- 이 메시지는 브로커 내에 저장되며, 나중에 같은 주제를 구독하는 새 클라이언트가 연결될 때 해당 메시지가 즉시 전달된다!

1) 보존 메시지 업데이트: 같은 주제에 대해 새로운 메시지가 RETAIN 플래그와 함께 발행되면 이전에 보존된 메시지는 새 메시지로 대체된다.
=> 각 주제(Topic)에 대해서 하나의 메시지만 보존!
=> 이후 이 주제를 구독하는 모든 새 클라이언트는 가장 최근의 보존 메시지를 받게 된다.

2) 보존 메시지 삭제: 주제에 대해 빈 메시지를 RETAIN 플래그와 함께 발행하면 해당 주제의 보존 메시지를 삭제할 수 있다.
=> 브로커는 해당 주제에 대해 보존된 메시지를 더 이상 가지고 있지 않게 된다!

2.SUBSCRIBE 패킷의 Flags field

: SUBSCRIBE 패킷에서는 플래그 필드가 항상 0010으로 설정되어 있어야 한다.

이는 패킷이 구독 요청임을 나타내며, 이외의 설정은 프로토콜 위반으로 간주된다.

3 CONNECT 패킷의 Flags field

: CONNECT 패킷의 플래그 필드는 특별한 목적이 없으며, 항상 0000으로 설정되어 있다. (0000: 플래그 없음"이나 "기본 설정"을 의미)

4.DISCONNECT, PINGREQ, PINGRESP 등

: 이러한 패킷 유형들에서는 플래그 필드가 또한 특별한 목적이 없으며, 항상 0000으로 설정된다.

[해석]

0010 플래그는 일반적으로 SUBSCRIBE 패킷에서 사용되는 플래그

첫 번째 비트(DUP): 0으로 설정되어 있다.
두 번째 비트와 세 번째 비트(QoS): 01로 설정되어 있어, 이는 QoS 레벨 1을 나타낸다. 하지만 SUBSCRIBE 패킷에서 이 비트 패턴은 "구독 요청"을 의미하는 고정된 값이다.
네 번째 비트(RETAIN): 0으로 설정되어 있다.

PUBLISH 패킷에서는 각 비트가 다음과 같이 설정될 수 있다

0000: QoS 0, DUP 0, RETAIN 0 (기본 설정, 메시지는 한 번만 전송되며 보존되지 않음)
0001: QoS 0, DUP 0, RETAIN 1 (메시지는 보존됨)
0010: QoS 1, DUP 0, RETAIN 0 (메시지는 적어도 한 번 전송됨)
0011: QoS 1, DUP 0, RETAIN 1 (메시지는 보존되며 적어도 한 번 전송됨)
0101: 메시지가 중복 전송되지 않고 (DUP = 0), QoS 레벨 2 (QoS = 2)로 전송되며, 주제를 새로 구독하는 클라이언트에게도 전송될 (RETAIN = 1) 메시지임을 지시
그리고 이어지는 다른 조합들...

4. QoS 3단계

QoS는 Quality of Service의 약자로 mqtt 프로토콜만 아니라 다양한 네트워크 및 통신의 영역(ISP, VoIP 등)에서 사용되는 말 그대로 메세지의 quality를 보장하는 서비스이다.

QoS는 이러한 각기 다른 요구 사항에 따라 메세지 전송 퀄리티에 대해 “얼만큼 보장해야 하나?” 에 대해서 차등을 준 서비스의 수준으로 mqtt에서는 3개의 레벨로 구분한다.

1. QoS-0 (”최대 한 번”)
가장 낮은 수준의 보장 서비스로 메세지는 딱 한번 전송되며 클라이언트에게 전달 여부를 확인하지 않고 바로 잊어버린다.

“Fire and Forget” 타입이라고도 하며, 전달 여부를 확인하지 않고 딱 한번 메세지를 전송하므로 전송 퀄리티 보장 정도는 낮지만 가장 빠른 전송 레벨이다.

2. Qos-1 (”적어도 한 번”)
중간 수준의 서비스로 메세지가 적어도 한 번은 클라이언트 측으로 전달되도록 보장한다.

이는 전달 여부를 확인해 메세지가 정상적으로 전달되지 못했으면 다시 메세지를 보내기 위해 시도한다.
하지만 메세지가 중복될 수 있으며 메세지가 도착한다는 보장은 있지만 한 번만 도착한다는 보장은 없다.

3. Qos-2 (”정확히 한 번”)
가장 높은 수준의 보장 서비스로 각 메세지가 의도한 클라이언트에게 한 번만 정확히 수신되도록 한다.

메세지의 핸드셰이킹 과정을 추적하며 가장 안전하고 퀄리티를 보장하지만 반대로 가장 느린 전송 레벨이다.

QoS 레벨은 게시자가 브로커에게 메세지를 게시할 때 지정되며, 브로커는 지정된 QoS 레벨을 사용해 구독한 클라이언트들에게 일정 퀄리티의 서비스를 보장하며 메세지를 배포한다.

5. MQTT 메시징

MQTT 프로토콜은 경량의 메시지 전달 시스템으로서, 특히 IoT 환경에서 유용하게 사용된다.
MQTT는 기본적으로 메시지를 교환하기 위한 몇 가지 기본 메시지 유형을 제공한다.
각 메시지 유형의 기능과 작동 방식을 아래와 같이 자세히 알아보자:

1. 연결하기 (Connect)

목적: MQTT 클라이언트가 서버(브로커)에 처음 연결을 시도할 때 사용하는 메시지
기능: 클라이언트는 서버에 CONNECT 메시지를 보내 서버와의 연결을 요청한다. 이 메시지에는 클라이언트의 식별자(ID), 사용할 네트워크 연결 설정, 필요한 경우 인증 데이터(사용자 이름과 비밀번호)가 포함된다.
프로세스: 서버는 CONNECT 메시지를 받고, 요청된 설정과 인증 정보를 검토한 후 연결을 수락하거나 거절한다. 연결이 성공하면, 서버는 CONNACK 메시지를 클라이언트에게 보내 연결이 성공적으로 수립되었음을 알린다.

2. 연결 끊기 (Disconnect)

목적: 활성 MQTT 세션을 종료할 때 사용
기능: 클라이언트는 작업을 완료한 후 서버에 DISCONNECT 메시지를 보내 세션 종료를 알린다. 이것은 클라이언트가 더 이상 메시지를 받거나 보낼 의사가 없음을 나타낸다.
프로세스: DISCONNECT 메시지를 받은 서버는 해당 클라이언트와의 연결을 종료하고 모든 필요한 청소 작업을 수행한다.

3. 발행하기 (Publish)

목적: 클라이언트가 특정 주제에 대한 메시지를 발행할 때 사용
기능: PUBLISH 메시지는 클라이언트로부터 서버로 전송되며, 서버는 이 메시지를 해당 주제를 구독하고 있는 다른 클라이언트에게 전달한다.
프로세스: 메시지는 주제 이름과 함께 보내지며, 서버는 이 주제를 구독하는 모든 클라이언트에게 메시지를 전달한다. 이 과정은 비동기적으로 이루어지며, 클라이언트는 발행 명령 후 바로 다른 작업을 계속할 수 있다.
- "비동기적(asynchronous) 처리" : 특정 작업이 완료될 때까지 기다리지 않고 다른 작업을 동시에 수행할 수 있는 실행 방식
- -> 작업들이 서로의 완료 시점에 영향을 받지 않고 독립적으로 진행될 수 있음
- => 하나의 작업이 진행되는 동안 다른 작업도 병렬적으로 진행될 수 있다!

MQTT에서 비동기적인 통신은 클라이언트가 메시지를 발행(PUBLISH)하거나 서버로부터 메시지를 수신할 때 적용된다.

클라이언트는 메시지를 서버에 보내고, 메시지 처리가 완료되길 기다리지 않고 즉시 다음 작업을 계속할 수 있다.

또한, 서버는 메시지를 비동기적으로 처리하고, 필요한 경우 클라이언트에게 응답을 반환한다.

6. Application Message와 Control Packet

Application Message는 클라이언트가 MQTT 브로커를 통해 다른 클라이언트에게 전달하려는 실제 데이터를 포함한다.

예를 들어, IoT 디바이스에서 센서 데이터를 전송할 때, 이 데이터가 Application Message에 해당
이 메시지는 주제(Topic)에 따라 분류되어 발행(Publish)되며, 해당 주제를 구독하는 클라이언트들에게 전달된다.

Control Packet은 MQTT 프로토콜의 규정에 따라 정의된 특정 형식의 패킷이다.

그 자체로 명령이나 정보의 전달 목적을 가지고 있으며, 통신 프로세스를 위한 헤더, 페이로드(데이터), 그리고 필요한 메타데이터를 포함한다.
이 패킷은 클라이언트와 브로커 간의 통신을 조정하고 관리하는 데 사용된다.
예를 들어, CONNECT, PUBLISH, SUBSCRIBE, PINGREQ 등이 Control Packet에 해당한다.

[관계 및 구조]

Application Message는 특정한 Control Packet (예: PUBLISH 패킷)의 일부로서 포함될 수 있다.

PUBLISH 패킷의 구조는 다음과 같다:

Fixed header: 모든 Control Packet에 공통적인 구성 요소로, 패킷의 유형과 플래그 정보를 포함
Variable header: PUBLISH 패킷의 경우, 이 부분에는 주제 이름(Topic Name)과 메시지 식별자(Message ID, QoS가 1 또는 2일 때 사용)가 포함될 수 있다.
Payload: Application Message가 이 부분에 포함된다. 실제로 전달하려는 데이터(예: 센서의 온도 데이터)가 여기에 위치한다.

따라서, Control Packet 안에 Application Message가 포함될 수 있지만, 모든 Control Packet이 Application Message를 포함하는 것은 아니다!

예를 들어, CONNECT, PINGREQ, SUBSCRIBE 등의 패킷은 네트워크 관리나 상태 확인 등의 목적으로 사용되며, 이들 패킷은 Application Message를 포함하지 않는다.

[사용 시점 및 목적]

Control Packet은 MQTT 프로토콜의 기반 구조를 이루며, 통신 과정에서 필수적인 역할을 수행한다.
반면, Application Message는 클라이언트 간에 실제로 교환되는 데이터를 담고 있으며, 이 데이터는 사용자 또는 응용 프로그램에 의해 정의된다.

따라서 Control Packet은 MQTT 세션의 모든 단계에서 활용되며, Application Message는 주로 데이터 발행의 맥락에서 사용된다.

Control Packet
Control Packet은 MQTT 프로토콜을 통해 클라이언트와 브로커 간의 모든 통신을 관리하고 조정하는 데 사용된다.
이 패킷들은 MQTT 세션의 시작, 유지, 종료 등과 관련된 모든 상호작용에 필수적이다.

사용 시점 및 목적:
- 연결 수립 (CONNECT): 클라이언트가 브로커에 처음 연결을 요청할 때 사용
- 연결 확인 (CONNACK): 브로커가 클라이언트의 연결 요청을 수락하거나 거절했을 때 응답으로 사용
- 메시지 발행 (PUBLISH): 클라이언트가 특정 주제에 대한 메시지를 브로커에 보낼 때 사용, 이 패킷에는 Application Message가 포함된다.
- 구독 요청 (SUBSCRIBE): 클라이언트가 하나 이상의 주제를 구독하고자 할 때 사용
- 구독 응답 (SUBACK): 구독 요청에 대한 브로커의 응답
- 핑 요청 (PINGREQ): 클라이언트가 네트워크 연결을 유지하고자 할 때 주기적으로 보냄
- 핑 응답 (PINGRESP): 핑 요청에 대한 브로커의 응답
- 연결 해제 (DISCONNECT): 클라이언트가 MQTT 세션을 명시적으로 종료하고자 할 때 사용

Application Message
Application Message는 MQTT 클라이언트가 다른 클라이언트나 시스템에 전달하고자 하는 실제 데이터를 포함한다.

사용 시점:
- 메시지 발행시 (PUBLISH 패킷의 Payload): 클라이언트가 특정 주제에 대해 데이터를 발행하고자 할 때, 그 데이터는 PUBLISH 컨트롤 패킷의 Payload 부분에 Application Message로 포함되어 브로커로 전송된다.
- 이후 브로커는 이 메시지를 해당 주제를 구독하는 다른 클라이언트들에게 전달한다.

출처: 블로그 + ChatGPT
MQTT란?
MQTT란 무엇인가?
HiveMQ
OSI 7계층
MQTT 프로토콜이란
MQTT 프로토콜 분석 (1)
MQTT 프로토콜 분석 (2)

wldbs._.

공부 기록용 24.08.05~ #LLM #RAG

이전 포스트