Протокол Интернета вещей MQTT

Протокол Интернета вещей MQTT

1. Введение в MQTT

  MQTT (Message Queuing Telemetry Transport) — это протокол обмена сообщениями, основанный на парадигме публикации/подписки в соответствии со стандартом ISO (ISO/IEC PRF 20922) . Он работает на семействе протоколов TCP/IP и представляет собой протокол сообщений публикации/подписки, разработанный для удаленных устройств с низкой производительностью оборудования и плохими условиями сети, поэтому для него требуется промежуточное программное обеспечение для сообщений.
  MQTT — это клиент-серверный транспортный протокол публикации/подписки сообщений . Выпущен IBM в 1999 году. Протокол MQTT легкий, простой, открытый и простой в реализации, что делает его широко применимым. Во многих случаях, в том числе в ограниченных средах, в качестве протокола обмена мгновенными сообщениями с низкой нагрузкой и низкой пропускной способностью он имеет более широкое применение в Интернете вещей, небольших устройствах, мобильных приложениях и т. д. Например: межмашинное (M2M) взаимодействие и Интернет вещей (IoT). Он широко используется в датчиках, обменивающихся данными через спутниковую связь, в медицинских устройствах, которые время от времени набирают номер, в умных домах и в некоторых миниатюрных устройствах.
  Самым большим преимуществом MQTT является то, что он предоставляет надежные службы сообщений в режиме реального времени для подключенных удаленных устройств с очень небольшим количеством кода и ограниченной пропускной способностью.

2. Возможности MQTT

  Этот протокол работает по протоколу TCP/IP или другим сетевым соединениям, обеспечивающим упорядоченные, надежные двунаправленные соединения. MQTT относится к протоколу прикладного уровня , который имеет следующие характеристики:

• Используя шаблон сообщений публикации/подписки, он обеспечивает распространение сообщений «один ко многим» и разделение между приложениями.
• Для передачи сообщения не требуется знать содержимое полезной нагрузки.
• Предусмотрено три уровня качества обслуживания: .
• QS0: «Не более одного раза» , сообщение распространяется так хорошо, как может обеспечить операционная среда. Сообщения могут быть потеряны. Например, этот уровень можно использовать для данных датчиков окружающей среды, где единичная потеря данных не представляет опасности, поскольку вскоре после этого они будут отправлены снова.
• QS1: «По крайней мере один раз» , сообщение гарантированно придет, но может быть повторено.
• QS2: «Только один раз» гарантирует, что сообщение придет только один раз. Например, этот уровень можно использовать в биллинговой системе, где дублирование или отсутствие сообщений приведет к неправильному выставлению счетов. Небольшое потребление при передаче и обмен данными по протоколу минимизируют сетевой трафик.

3. Управляющее сообщение MQTT

  Протокол MQTT взаимодействует путем обмена предопределенными управляющими сообщениями MQTT. Управляющее сообщение MQTT состоит из трех частей: фиксированный заголовок, переменный заголовок и полезная нагрузка.

Фиксированный заголовок Фиксированный заголовок , все управляющие пакеты содержат
Заголовок переменной Заголовок переменной , часть управляющего сообщения содержит
Полезная нагрузка , часть управляющего сообщения содержит

3.1 Фиксированный формат заголовка

• Тип управляющего сообщения
  

3.2 Флаг установки типа управляющего сообщения MQTT

Старшие 4 бита (4 ~ 7)   первого байта фиксированного заголовка — это тип управляющего сообщения, всего 14, а младшие 4 бита (0 ~ 3) содержат определенные флаги каждого типа управляющего сообщения MQTT, см. таблицу ниже. Любые флаги, помеченные как «зарезервированные» в таблице, зарезервированы для использования в будущем и должны быть установлены на значения, указанные в таблице. Если получен недопустимый флаг, получатель ДОЛЖЕН закрыть сетевое соединение.

  DUP1 = Двойной флаг распределения для управляющих пакетов.
  QoS2 = класс качества обслуживания для пакетов PUBLISH.
  RETAIN3 = флаг сохранения для сообщения PUBLISH.
  Флаги DUP, QoS и RETAIN в управляющем сообщении PUBLISH.
  Подробнее см. в протоколе MQTT3.1.

3.3 Расчет остаточной длины

  Оставшаяся длина Указывает количество байтов в оставшейся части текущего сообщения, включая переменный заголовок и данные полезной нагрузки. Оставшаяся длина не включает количество байтов, используемых для кодирования самого поля оставшейся длины.
  Поле оставшейся длины использует схему кодирования переменной длины , а для значений меньше 128 — однобайтовое кодирование. Большие значения обрабатываются следующим образом. Младшие 7 бит используются для кодирования данных8, а старший бит используется для указания наличия дополнительных байтов. То есть оставшаяся длина считается в системе 128, а максимальная оставшаяся длина поля составляет 4 байта .

• Значение поля оставшейся длины следующее:
  
    оставшаяся длина считается в шестнадцатеричном формате и выражается в шестнадцатеричном формате, начиная с младшего байта. Пример кодирования оставшейся длины:
    ① Например, 64: (64/128) округление = 0, что указывает на то, что 64 не нужно переносить, и можно представить 1 байт, то есть: 0x40;
    ② Например, 456: ( 456/128) округление = 3 , (3/128) округление = 0, что указывает на то, что для представления 456 требуется 2 байта.
     Первый байт бит7=1, (бит0~бит6)=456%128=72=0x48, то есть первый байт выражается как: 0xc8, второй байт бит7=3/128=0, (бит0~ бит6)
     = 3%128=3, то есть второй байт представляет собой бит: 0x3;
     в итоге 456 представлен двумя байтами: 0xc8 0x3; ③Например
    , 100000: (100000/128)=781, (781/128)= 6, что указывает на то, что для 100000 требуется 3 байта, чтобы указать, что
     первый байт бит7=1, (бит0~бит6)=100000%128=0x20, то есть первый байт равен 0xa0, второй байт бит7=
     1, (бит0~бит6) =781%128=0x0d, то есть второй байт 0x8d; третий байт
     bit7=0, (bit0~bit6)=6%128=6, то есть третий байт 0x6;
     итого 100000 представлен 3 байтами: 0xa0 0x8d 0x6;

3.4 Пример реализации языка C для вычисления оставшейся длины

• кодирование оставшейся длины

int MQTT_RemainSum(int data,u8 buff[])
{
    
    
	int cnt=0;//记录编码的字节数
	do
	{
    
    
		u8 encodedByte = data % 128;
		data/=128;
		if(data>0)
		{
    
    
			//若data超过128，则将最最高位置1
			encodedByte=encodedByte|=0x80;
		}
		buff[cnt++]=encodedByte;
		
	}while(data>0);
	return cnt;//返回需要编码的字节数个数
}

• Декодирование остаточной длины

int MQTT_remainGet(u8 buff[],int cnt)
{
    
    
	int data=0;
	int i=0;
	int count=1;
	for(;i<cnt;i++)
	{
    
    
		data+=(buff[i]&0x7f)*count;
		count<<=7;
	}
	return data;
}

• Пример теста:

int main(int argc,char *argv[])
{
    
    
	if(argc!=2)
	{
    
    
		printf("格式:./a.out <剩余长度>\n");
		return 0;
	}
	int data=atoi(argv[1]);
	u8 buff[4];
	int cnt=MQTT_RemainSum(data,buff);
	for(int i=0;i<cnt;i++)
	{
    
    
		printf("%#x ",buff[i]);
	}
	printf("\n");
	printf("data=%d\n", MQTT_remainGet(buff,cnt));
}
[wbyq@wbyq work]$ ./a.out 64
0x40 
data=64
[wbyq@wbyq work]$ ./a.out 456
0xc8 0x3 
data=456
[wbyq@wbyq work]$ ./a.out 100000
0xa0 0x8d 0x6 
data=100000
[wbyq@wbyq work]$ ./a.out 268435455
0xff 0xff 0xff 0x7f 
data=268435455

4. Уровень сообщения MQTT

• MQTT обеспечивает три уровня качества обслуживания
• QS0: «Не более одного раза» , сообщение распространяется так хорошо, как может обеспечить операционная среда. Сообщения могут быть потеряны. Например,
  этот уровень можно использовать для данных датчиков окружающей среды, где единичная потеря данных не представляет опасности, поскольку вскоре после этого они будут отправлены снова.
• QS1: «По крайней мере один раз» , сообщение гарантированно придет, но может быть повторено.
• QS2: «Только один раз» гарантирует, что сообщение придет только один раз. Например, этот уровень можно использовать в биллинговой системе, где дублирование или отсутствие сообщений приведет к неправильному выставлению счетов. Небольшое потребление при передаче и обмен данными по протоколу минимизируют сетевой трафик.
  
    Пакеты PUBLISH не могут устанавливать все биты QoS в 1. Если сервер или клиент получает пакет PUBLISH со всеми битами QoS, установленными в 1, он ДОЛЖЕН закрыть сетевое соединение.
• Qos0 не более одного раза

  Отправитель отправляет сообщение только один раз, без повторной попытки . Семантика повторных передач также не определена в протоколе. Сообщение может дойти до сервера 1 раз, а может и не дойти вообще.

• Qos1 хотя бы раз

  Получение сообщения сервером подтверждается передачей сообщения PUBACK. Если есть идентифицируемый сбой передачи, будь то канал связи или отправляющее устройство, или если сообщение подтверждения не было получено через определенный период времени, отправитель установит бит DUP заголовка сообщения в 1, а затем отправить сообщение еще раз. Сообщения приходят на сервер хотя бы один раз.
  Если клиент не получает сообщение PUBACK (будь то время ожидания, определенное приложением, или обнаружен сбой и сеанс связи перезапускается), клиент снова отправит сообщение PUBLISH и установит бит DUP в 1.
  Когда он получает повторяющиеся данные от клиента, сервер повторно отправляет сообщение подписчику и отправляет еще одно сообщение PUBACK.

  Как показано на рисунке выше, чтобы гарантировать, что сообщение уровня Qos1 будет доставлено хотя бы один раз , издатель будет временно хранить отправленное сообщение локально и время от времени отправлять его повторно, пока получатель не вернет ответ. Получив ответ, мы можем удалить временное сообщение и остановить повторную передачу.
  Для получателя вам нужно отвечать каждый раз, когда вы получаете сообщение. На приведенном выше рисунке издатель (издатель) для брокера (агента, сервера) и брокер (агент, сервер) для подписчика (подписчика) эквивалентны, и оба взаимодействия должны быть реализованы, как обсуждалось выше.

• Qos2 только один раз
  
    Уровень сообщения QS2 гарантирует, что сообщение должно прийти один раз , издатель (издатель) для брокера (агента, сервера) и брокер (агент, сервер) для подписчика (подписчика) равны, и два сообщения одинаковы. оценка. Конкретный процесс передачи сообщения выглядит следующим образом:
    1. Издатель отправляет сообщение и временно сохраняет содержимое сообщения локально.
    2. После получения содержимого сообщения получатель временно сохраняет содержимое сообщения локально и отвечает отправителю ответом (PUBREC). Издатель будет время от времени повторно отправлять сообщение перед получением PUBREC, чтобы гарантировать согласованность сообщения. .можно доставить.
    3. Когда издатель получает PUBREC, он прекращает повторную отправку сообщения и отправляет содержимое сообщения о выпуске (PUBREL) получателю.После получения PUBREL получатель может подтвердить, что передача сообщения прошла успешно.
    4. Удалите временно сохраненное сообщение, после чего отправитель будет напрямую отправлять PUBREL-сообщение получателю каждый раз, когда он получает PUBREC.
    5. После получения сообщения PUBREL принимающая сторона изменяет временно сохраненный статус сообщения на завершение публикации, прекращает отправку PUBREC, а затем отправляет сообщение о завершении публикации (PUBCOM) отправляющей стороне. В это время принимающая сторона удалит временно сохраненное сообщение, а затем ответит напрямую PUBCOM каждый раз, когда получает PUBREL.
    6. Когда отправляющая сторона получает PUBCOM, если она обнаружит, что временно сохраненное сообщение все еще удаляется каждый раз, она удалит временно сохраненное сообщение, а если оно было удалено, оно будет проигнорировано.
    Уведомление:Во время этого процесса функция сообщения локального временного хранилища состоит в том, чтобы добиться дедупликации при получении дублирующегося контента.После получения PUBREL можно определить, что отправитель больше не будет отправлять это сообщение, поэтому сообщение временного хранилища может быть удалено в это время. ., аналогично, после получения PUBREC отправляющая сторона знает, что принимающая сторона получила сообщение, поэтому нет необходимости отправлять сообщение, а временное хранилище можно удалить.