Насколько MQTT легкий, когда он транспортируется по TCP/IP

#mqtt #iot

Вопрос:

В большинстве платформ интернета вещей MQTT используется в качестве M2M-связи, одной из причин этого является легкий вес.

Устройство —N/W—> Брокер MQTT —>> другое устройство

Устройство взаимодействует с брокером MQTT по протоколу TCP/IP, что означает, что в рамках уровня TCP/IP будет добавлена полезная нагрузка.

Это мое начало путаницы: если MQTT работает по протоколу TCP/IP, то почему это легкий протокол?

Комментарии:

1. чтобы обратить ваш вопрос против вас, что заставляет вас думать, что tcp/ip не может быть легким?

2. @DanielFarrell: Я не ставлю под сомнение TCP/IP, я пытаюсь понять, что именно делает его легким, когда он должен использовать базовый стек протоколов; поэтому, даже если MQTT легкий, для каждого сообщения необходимо добавлять дополнительные заголовки TCP/IP?

3. С чем вы сравниваете MQTT? Поскольку он работает поверх TCP/IP, это недопустимое сравнение, попробуйте сравнить его с HTTP (с его ОГРОМНЫМ заголовком), который также работает по TCP/IP

Ответ №1:

С чем вы сравниваете MQTT?

Проблема с вашим вопросом заключается в исходной предпосылке для сравнения MQTT с базовым TCP/IP, который он использует в качестве базового транспорта.

Поскольку MQTT работает поверх TCP/IP, это недопустимое сравнение, попробуйте сравнить его, скажем, с HTTP (с ОГРОМНЫМ заголовком), который также работает по TCP/IP.

Настройка подключения MQTT и последующая подписка на тему обрабатываются в нескольких байтах имя темы, и соединение сохраняется. Когда сообщение отправляется, оно снова содержит пару байтов заголовка темы и полезной нагрузки.

По сравнению с HTTP-запросами, начинающимися с URL-адреса заголовков запросов, ответ включает в себя еще кучу заголовков ответов (заголовков может быть легко 100 байт, поскольку все они закодированы в виде текста), прежде чем мы перейдем к полезной нагрузке, и в целом соединение закрывается после полезной нагрузки.

Если вы добавите в TLS/SSL накладные расходы на запуск нового соединения для каждого HTTP полезной нагрузки, станет еще хуже.