Protocol selection for connected systems should begin with the decision the system must support, not a popularity contest between names. A sensor fleet sending periodic readings, a controller needing bounded request-response, a gateway bridging a plant protocol, and a web application serving user actions have different timing, payload, security, and failure needs. MQTT, CoAP, HTTP, and industrial protocols can each be right at a particular boundary. None supplies the whole product contract. Define data meaning, delivery expectation, identity, retry rule, and user-visible failure before comparing libraries. NIST OT guidance is a useful reminder that availability and safety can outweigh convenience when software touches physical processes.
Start with the operating decision
Describe who produces the message, who consumes it, what action follows, how late it may be, whether it may duplicate, and what happens when it is lost. A temperature trend tolerates different behavior from a command that changes machine state. A service reporting asset health may need store-and-forward, while a local controller needs bounded latency and deterministic failure. Write normal, delayed, and unavailable scenarios and score each candidate. This prevents selection because a benchmark looks fast or a vendor already has a connector.
| Factor | Question | Evidence |
|---|---|---|
| Interaction | Stream, request-response, or command? | Message examples |
| Timing | Maximum useful age? | Observed and received times |
| Delivery | Can loss or duplicates be tolerated? | Replay test |
| Recovery | How does user know failure? | Visible state and runbook |
Compare protocol shapes, not slogans
MQTT provides broker-mediated publish-subscribe, useful when many consumers need decoupling and devices have variable connectivity. CoAP is designed for constrained environments with web-like request-response and observation patterns. HTTP is often the simplest service and gateway boundary where existing controls fit. Industrial protocols may carry equipment semantics that should not be erased by translation. Compare session continuity, retained state, expiry, discovery, payload size, ordering, authorization, and observability. Read MQTT 5.0 and CoAP RFC 7252 for wire semantics, then write application rules separately.
Preserve semantics through the boundary
A protocol can deliver a payload while the product misunderstands it. Define units, ranges, timestamps, source identity, quality, schema version, and whether a record is measured, derived, corrected, or replayed. Keep command intent separate from command outcome: an accepted request is not proof of physical completion. Distinguish event time from ingestion time and use an idempotency key when delivery may repeat. If a gateway translates protocols, retain original context and transformation version. These details matter to support and safety more than whether a wire format is compact.
| Contract field | Example | Why it matters |
|---|---|---|
| Identity | site-3/line-2/pump-07 | Avoids wrong asset |
| Quality | good, stale, estimated | Stops false confidence |
| Outcome | accepted, applied, rejected | Separates request from effect |
| Version | schema-4, rule-2 | Explains changes |
Treat transport security and authorization separately
TLS can protect a connection, but it does not decide which device may publish, which user may subscribe, or which command is allowed. RFC 8446 describes TLS 1.3; your product still needs identity, authorization, rotation, revocation, secure defaults, and audit. A telemetry producer should not automatically receive control commands. For OT, align protocol boundaries with network zones and local safety controls. NIST OT security keeps physical consequence in view. Test expired certificates, revoked devices, mis-scoped subscriptions, and compromised clients.
Design failure, retry, and backpressure
Document timeout, broker refusal, connection loss, malformed payload, rate limit, full queue, and unknown schema. Retrying an observation can be safe with stable event identity; retrying a command may require idempotency and state checks. Decide ordering scope, catch-up behavior, and expiry. Sampling, aggregation, and backpressure can be healthy when resources are bounded, but silent dropping is not. The operator needs to know whether state is live, delayed, estimated, or unavailable.
Test selection with representative traffic
Use real payloads and failure cases: normal reading, burst, slow consumer, duplicate, out-of-order event, revoked identity, schema change, restart, and network partition. Measure end-to-end age, loss, duplicate handling, CPU, storage, recovery, and operator comprehension. A clean lab can hide production behavior. Keep fixtures as acceptance criteria for vendor changes and regression checks when adapters upgrade.
Choose for the whole lifecycle
Consider who operates brokers, proxies, gateways, certificates, schemas, and client libraries for years. Ask whether implementations, diagnostic tooling, versioning, and support are maintainable. A greenfield protocol can become costly if every site needs a custom patch; a universal protocol can force a translation that loses equipment meaning. Use adapters only when mapping is explicit and tested. See MQTT brokers in production and edge gateways.
Key takeaways
- Choose protocol behavior against a real operating decision.
- Separate wire delivery from data meaning and physical outcome.
- Test loss, duplication, delay, overload, identity, and schema change.
- Treat TLS as transport protection, not complete authorization.
- Choose what the operating team can support and migrate.
The TLS 1.3 specification describes transport protection, while the NIST IoT cybersecurity activities helps frame device and customer responsibilities. Pair those references with the MQTT 5.0 specification and CoAP RFC 7252 when testing session, delivery, and constrained-device behavior. The choice remains accountable to the operating consequence and application contract.
Frequently asked questions
Which protocol is best for IoT?
There is no universal best choice. Select against interaction shape, constraints, delivery semantics, security, support, and consequence of failure.
When should teams compare MQTT and CoAP?
Compare them when constrained devices, intermittent networks, and different interaction models matter. Use measured traffic and recovery tests.
When is HTTP unsuitable for connected systems?
No. HTTP is practical when latency, connection, payload, and retry behavior fit the decision and the team can secure it.
Conclusion
Protocol selection should end with a defensible choice for a real operating decision, not a list of fashionable transports. Begin by naming the actor, the consequence of delay or duplication, the expected device and network conditions, and the safe fallback. A telemetry reading, a command, a configuration update, and a delivery notification have different semantics. The protocol can support those semantics, but it cannot invent them after the fact. Write the message contract before comparing features. Define identity, source time, receipt time, units, quality, sequence, correlation, payload size, sensitivity, and version compatibility. Say whether a message is an observation, an intent, an attempt, or an outcome. Decide whether the receiver may act immediately, must wait for validation, or may only present the information to a human. This language exposes a common mistake: treating transport acknowledgment as proof that the physical or business action completed. Then compare protocol shapes against the field conditions. Request-response may be easier to reason about for a small synchronous job. Publish-subscribe can separate producers from independent consumers, but it adds subscription ownership, replay, and delivery interpretation. A constrained device may favor a compact exchange, while a browser-facing service may need a different boundary. Evaluate connection churn, power budget, message size, intermediary behavior, ordering scope, retry behavior, and debugging tools with representative traffic rather than a benchmark detached from the intended workflow. Security needs its own decision record. Transport encryption protects a channel; it does not decide which device, service, or operator may publish, subscribe, read, or command. Bind identities to the allowed action and resource, rotate credentials, restrict topics or routes, and log policy changes. For security testing, exercise an expired certificate, a revoked device, an unauthorized subscription, and a compromised client. A protocol choice that looks efficient in the happy path is incomplete if the team cannot contain a bad identity without stopping every legitimate device. Failure behavior is where the choice becomes operational. Exercise packet loss, delayed delivery, duplicate messages, broker or server restart, consumer overload, clock skew, malformed payloads, and partial acknowledgment. Define whether the producer retries, drops, persists, or sends to an exception path. Make backpressure bounded and visible. For a consequential workflow, reconcile the final business state instead of assuming that a successful send or receipt means that a person, machine, or billing system completed the requested action. Choose a test slice that makes the trade-offs visible. Use a small set of representative devices, an ordinary network, a constrained network, and a recovery scenario. Measure time to useful result, duplicate side effects, battery or connection cost, diagnostic effort, policy violations, and migration work. Ask an operator and a support engineer to interpret the resulting evidence. Their questions often reveal that a theoretically strong protocol creates an impractical operational burden at the boundary. Lifecycle cost should carry as much weight as wire efficiency. Identify who maintains client libraries, broker or server configuration, certificate policy, schemas, dashboards, and incident procedures. Record version support, deprecation signals, test fixtures, and the escape route if the chosen implementation becomes unavailable. Keep protocol-specific concerns behind a stable product contract where possible, so a future migration changes transport without changing the meaning of the decision. A sound selection review produces four concrete outputs: a message contract, a permission model, a failure matrix, and an acceptance test tied to an outcome. It also records what was rejected and why. Revisit the choice when the device population, consequence, network, or ownership model changes. The best protocol is the one the team can explain, secure, test, support, and replace while preserving the meaning of the work it carries. Use edge gateway design, production protocol operations, and SCADA integration boundaries as comparison points. Each adjacent decision exposes a different protocol risk: a gateway adds buffering and replacement, production operations add ownership and migration, and SCADA adds physical consequence. Read them together before accepting a benchmark as evidence. The review is complete when an operator, security owner, and support engineer can describe the selected semantics, deny an unsafe action, diagnose a late or duplicate message, and explain the migration path.
For the selection record, also capture the cost of translation, the diagnostic tools available at each site, the oldest client that must remain compatible, and the person who can approve a protocol exception. Revisit the choice after a real outage, not only after a successful benchmark. A protocol is earning its place when operators can explain delayed data, engineers can reproduce a failed exchange, and product owners can change the workflow without rewriting every device integration.
Good protocol selection makes failure understandable and change manageable. Start from the decision, preserve semantics, secure identity, test disruption, and choose what the team can operate.