IoT-connected embedded devices almost universally need to communicate with a cloud or edge backend. Three protocols dominate this layer: MQTT, HTTP/2, and gRPC. Each has a distinct design philosophy, communication model, and resource profile — and each is optimally suited to a different subset of IoT use cases. Selecting the wrong protocol creates problems expensive to change after hardware is in production.
| Dimension | MQTT | HTTP/2 | gRPC |
|---|---|---|---|
| Communication model | Publish-subscribe | Request-response | RPC with streaming |
| Connection | Persistent TCP to broker | Connection per server | Persistent HTTP/2 |
| Broker required | Yes | No | No |
| Message format | Binary payload (any) | Text or binary | Protocol Buffers |
| Code generation | No | No | Yes — stub generation |
| Embedded library size | Small (<50 KB) | Moderate | Larger (protobuf + gRPC) |
| Fan-out to consumers | Built-in via broker | Manual | Manual |
When to Choose MQTT
MQTT is the right choice when the device publishes data to multiple consumers that may not all be known at design time, when network connectivity is unreliable and persistent connection resumption with QoS message buffering is valuable, when devices are battery-powered and the low protocol overhead conserves energy, or when message fan-out to many subscribers is a fundamental architectural requirement. Typical MQTT use cases: industrial sensor telemetry, vehicle fleet telematics, smart meter reading, and agricultural IoT sensor arrays.
When to Choose HTTP/2
HTTP/2 is appropriate when the device must integrate with existing web infrastructure — REST APIs, web portals, content delivery networks — that are already HTTP-based. Its broad compatibility with standard web tools makes integration straightforward. HTTP/2 is also appropriate when the request-response model naturally fits the use case — firmware download, configuration retrieval, certificate update. Typical HTTP/2 use cases: OTA firmware download, device registration, periodic report submission, and REST API integration.
When to Choose gRPC
gRPC is the right choice when strong typing and interface contracts between device and backend are valuable. Protobuf schema files become the contract between teams, and stub code generation eliminates manual serialisation. gRPC's bidirectional streaming suits devices needing both continuous telemetry upload and real-time command reception over the same connection. Typical gRPC use cases: cloud-connected domain controllers, AI inference request-response, microservice-based IoT backends, and high-throughput data collection from capable embedded platforms.
Resource Requirements on Embedded Platforms
For resource-constrained embedded devices — Cortex-M class MCUs with 256 KB to 2 MB flash - library footprint is a meaningful selection criterion. MQTT client libraries add under 50 KB of flash. A minimal HTTP/2 client adds 100–200 KB. gRPC with protobuf adds 200–500 KB depending on stub complexity. For 8-bit or 16-bit MCUs, MQTT is typically the only viable option. For more capable embedded platforms — Cortex-A class or high-end Cortex-M7 — all three are practical and selection should be driven primarily by communication architecture requirements rather than resource constraints.
Implementing MQTT, HTTP/2, and gRPC with RAPIDSEA
RAPIDSEA provides embedded implementations of all three protocols as independently licensable stack modules. The MQTT stack supports QoS 0, 1, and 2 with TLS integration, persistent session management, and configurable topic hierarchy mapping. The HTTP/2 stack supports REST-style request-response and server push with TLS and connection management. The gRPC stack provides protobuf serialisation, service stub integration, and bidirectional streaming support. All three stacks operate with or without RTOS, are delivered in MISRA-C compliant ANSI C source, and share common socket and TLS abstraction layers.
Conclusion
MQTT, HTTP/2, and gRPC each address a distinct set of IoT communication requirements. MQTT's publish - subscribe model and low overhead make it optimal for sensor telemetry and battery - powered devices. HTTP/2's web infrastructure compatibility makes it optimal for OTA and REST integration. gRPC's typed interface model makes it optimal for capable platforms in microservice IoT architectures. RAPIDSEA provides validated embedded implementations of all three - enabling teams to select the right protocol for each use case without rebuilding foundational communication infrastructure.
Ready to choose the right IoT protocol? Contact our team to request an evaluation build or book a technical demo.