MQTT versus HTTP for file transfer with AWS IoT Over the Air (OTA) updates

4 minute read
Content level: Advanced
1

Will your IoT device use AWS IoT OTA to manage software or firmware updates? Perhaps you’re aware that OTA updates support both MQTT and HTTP for file transfer, but you’re unsure which one to use. This article explains the advantages of each protocol, helping you choose the better option for your device.

Introduction

AWS IoT OTA update is a feature built on top of AWS IoT Jobs that specifically implements a software/firmware update operation. OTA updates allow you to send your software or firmware binaries to your device using either MQTT or HTTP.

These two protocols offer different advantages and it may not be immediately apparent which protocol is the better choice for your device. As explained below, MQTT is better suited to resource-constrained devices with smaller software/firmware binary files.

Summary of the advantages

The key advantages of each protocol are summarized in Table 1.

MQTTHTTP
Smaller Flash footprint because your device can have just an MQTT client and no HTTP client.Cheaper because you can avoid MQTT messaging costs.
Smaller RAM footprint because your device can have just a single TCP connection to the cloud.Can be used to transfer much larger files if you use jobs directly, instead of OTA updates.
Smaller attack surface because your device may use only one protocol, one endpoint and one TCP port.

Table 1: Advantages of each protocol

MQTT

AWS IoT OTA updates are built on AWS IoT Jobs and this means your device will publish and subscribe to the jobs MQTT reserved topics to manage OTA updates. Additionally, your device will likely have other MQTT needs such as publishing telemetry data, interacting with AWS IoT Device Shadows and more. If MQTT is also used for the OTA update file transfer, it may be possible for your device to meet all of its cloud communication needs over a single MQTT connection to AWS IoT Core.

If HTTP were used for the file transfer, your device would need to include or implement an HTTP client and it would need sufficient memory to support a TCP connection for the HTTP transfer in addition to the TCP connection to the AWS IoT Core MQTT broker.

In this regard, MQTT is generally a better choice for constrained devices as it can help you to minimize your device’s memory requirements, and this can be important when trying to meet a price point. Additionally, your device would only require a single port to be opened in firewalls, with it only ever connecting to a single endpoint, and this can help you to more easily deploy your devices in environments with high security posture.

HTTP

AWS IoT Core meters MQTT messages in (up to) 5KB increments. The chief advantage of HTTP is it avoids this MQTT messaging cost.

Resource-constrained devices typically have small firmware or software binary files, perhaps in the order of 256KB or 512KB. If your devices have files of this kind of size, the benefits of MQTT probably outweigh the relatively small MQTT messaging costs.

For resource-rich devices however, the firmware or software file size is typically larger, often multiple Megabytes. In this case, the MQTT messaging costs can be significant, particularly if you’re deploying updates to a large fleet of devices. Since these devices have more resources, the additional footprint required to support HTTP is perhaps of little concern and therefore HTTP file transfer would often be the better choice.

AWS IoT OTA updates are limited to 16MB file size, for either MQTT or HTTP. Should you need to support larger file sizes, you can move from AWS IoT OTA updates to AWS IoT Jobs. MQTT file streams are limited to 24MB, so using MQTT file streams with jobs only enables marginally larger files. However, should you use HTTP file transfer with presigned URLs in custom job documents, you can have much larger files.

Related questions

profile pictureAWS
EXPERT
Greg_B
published 7 months ago1472 views