Proven by Intelligence

지난 1편에 이어 이번 시간에는 MQTT 프로토콜의 운영 동작과 관련된 규격을 알아보도록 하겠습니다.

Connect Flags

'CONNECT' 타입의 MQTT 제어 패킷의 경우, 지난 시간에 잠깐 언급한 'Connect Flags' 라는 8bit(1Byte)의 정보가 Variable header에 포함되어 있습니다. 이 부분에 대해 좀더 자세히 알아보겠습니다. 8bit로 구성된 Flags정보 내에는 아래와 같이 MQTT 연결과 관련된 각종 설정 값들이 기록되어 있습니다.

1) Clean Session

 Server와 Client는 안정적인 메시지 송/수신을 위해 Session 상태를 저장하고 있습니다. Clean Session은 재 연결 시, 이전 Session(Persistence session)을 사용할지를 설정하는 것입니다. Server는 Client가 Clean Session Flag를 '0'으로 설정하여 연결 요청을 하면 저장되어 있는 Session을 찾아 재활용하고, '1' 로 설정하여 요청하면 신규 Session을 생성하여 사용합니다. 

 또한 Clean Session 설정은 메시지 재전송(Message delivery retry)과도 연관되어 있습니다. QoS 레벨이 1, 2 인 상황에서 Client가 Clean Session '0'으로 Server와 재연결 되면, Client 와 Server는 각각 응답을 받지 못한 Packet을 동일한 Packer ID로 재전송해야 합니다.

2) Will Flag, Will QoS, Will Retain

 MQTT에서 Client는 자신이 접속 종료되었을 때 특정 Topic을 발송하라고 Server에 등록할 수 있습니다. 이것을 Will Message라고 합니다. Will Message를 사용하기 위해서는 Will Flag를 ‘1’로 설정하여 Server에 연결하여야 합니다. 이렇게 하면 Server는 해당 Client가 연결 종료되었을 때 모든 구독자들에게 Will Message를 발행하여 해당 Client의 연결 상태를 전달합니다.

 Will 메시지 전송 시에도 QoS 레벨과 Retain 설정을 할 수 있으며 이 값은 Connect Flags내의 Will QoS, Will Retain에 설정됩니다. Will Message 전송을 위한 Topic 과 Message는 Payload에 포함됩니다.

3) User Name Flag, Password Flag

 "1"로 설정될 경우, Payload에 User Name, Password 필드를 사용합니다. User Name Flag가 '0'이면 Password Flag 도 '0'입니다. Payload의 User Name 과 Password는 인증 및 권한 부여(Authentication and Authorization)를 위해 서버에서 사용될 수 있습니다.



Keep Alive

 'CONNECT' 타입의 MQTT 제어 패킷에 포함되어 전달되는 정보이며 16bit를 사용합니다. MQTT 프로토콜은 이 Keep Alive 필드를 이용하여 Keep Alive Interval을 설정합니다. 기본적으로 Client는 Keep Alive Interval이 지나기 전의 메시지 전송을 보장해야 합니다. 전송할 메시지가 없는 경우에도 Client는 Connection 연장을 위하여 메시지를 전달해야 하며 이때 사용되는 제어 패킷이 PINGREQ, PINGRESP 입니다.

 Server는 Keep Alive 시간의 1.5배 내에 아무런 패킷이 들어오지 않으면 Client와의 연결을 끊겼다고 판단하고 Will 메시지 전송 등의 절차를 수행할 수 있습니다.

 Keep Alive 설정의 최대값은 65535초, 즉 18시간 12분 15초입니다.

QoS

"Quality of Service"의 약자로 전달되는 Application Message의 신뢰성을 보장하는 레벨입니다. 0, 1, 2 총 3단계로 구분되며 숫자가 커질수록 높은 신뢰성을 보장하지만 그만큼의 리소스를 소모합니다. 

 ‘PUBLISH’ 제어 패킷에 포함되어 전송되며, MQTT는 이 규격을 사용하여 반드시 전달되어야 하는 메시지의 전달을 보장합니다. Client 와 Server(Broker)는 각각 자신이 처리할 수 있는 최대 QoS 레벨을 가지고 있습니다. 우선시 되는 것은 당연할 수도 있지만 중심에 있는 Server의 QoS 레벨입니다. Client는 연결 시 자신이 처리 가능한 최대 QoS 레벨을 전송하며 Server는 전송된 Client의 QoS 레벨 중 자신이 수용 가능한 최대의 QoS 레벨을 선택하여 해당 Client와의 메시지 송/수신을 수행합니다.

 각 QoS 레벨은 아래와 같은 내용의 규격을 가집니다.

 1) QoS 0: At most once delivery

[그림 2]  Qos Level 1

 다만 PUBACK 단계에서 Network 이슈 등으로 지연이 발생되었을 때, 발신자(Publisher)는 응답이 없기에 메시지를 재전송 할 수 있습니다. 이때 수신자가 메시지를 구독자에게 이미 발생하고 삭제한 상태라면 수신자는 메시지 중복여부를 판별할 수 없기에 구독자에게 동일한 메시지를 다시 보낼 수 있습니다. 이렇기에 QoS 1은 메시지가 미 전송되는 상황은 막을 수 있으나 메시지가 중복으로 전달될 가능성이 존재합니다.

3) QoS 2: Exactly once delivery

[그림 3] QoS Level 2

 가장 높은 QoS 레벨입니다. QoS 1에서와 같이 발신자(Publisher)는 메시지 전송 후 응답을 받아 메시지 전송성공 여부를 판단합니다. 다만 QoS 2에서는 4-way handshaking 를 사용하여 정확히 한번의 메시지 전송을 보장합니다. 

 QoS 2에서 수신자는(Broker)는 자신이 가지고 있는 메시지를 삭제하기 전에 구독자에게 메시지를 전달했음을 발신자에게 알려줍니다. 이후 발신자에게 확인 메시지를 다시 받고 나서야 수신자는 자신이 저장하고 있는 메시지를 삭제합니다. PUBREC 단계에게 지연이 발생되어 발신자가 메시지를 재전송한다 하더라도 수신자는 이전에 받은 메시지를 가지고 있기에 메시지를 구독자에게 재전송하지 않습니다. 또한 PUBCOMP 단계에서 지연이 발생되었다 하더라도 이미 이전에 PUBREC를 받음으로써 메시지를 구독자에게 보냈음을 확인되었기에 구독자에게 메시지가 재전송되는 상황은 없게 됩니다.

 

 QoS 2는 처리에 소모되는 리소스가 크지만 이러한 방식으로 정확히 1번 구독자가 메시지를 받게 되는 것을 보장합니다. 메시지 중복 전달 시 문제가 발생되는 데이터의 경우에 사용할 수 있습니다.

Topic Names and Topic Filters

MQTT 메시지의 발행과 구독은 Topic을 기준으로 이루어집니다. Topic은 Level Separator (‘/’)를 이용하여 아래와 같은 형태로 계층적으로 구성 가능합니다. 

─

"sport/tennis/player1"
"sport/tennis/player1/ranking
"sport/tennis/player1/score/wimbledon"

─

1) Topic Filter에서의 wildcard 사용

구독자는 Topic Filter를 사용하여 Topic을 구독합니다. Topic Filter에는 wildcard 문자가 포함될 수 있으며 구독자는 이 wildcard 문자를 이용하여 다수의 Topic을 한번에 Subscribe할 수 있습니다. 사용 가능한 wildcard 문자와 의미는 아래와 같습니다. 

▶ “#”: Multi level wildcard.

여러 단계의 Topic Level을 대체할 수 있습니다.

Multi level wildcard는 단독으로 쓰이거나 Topic Filter의 마지막 Level에 위치 가능합니다.