Feb 10, 2026

物聯網設備通訊協定選型：從系統架構觀點看 MQTT、HTTP 與 CoAP

在 IoT / AIoT 專案中，通訊協定往往被視為實作細節，實際上卻是系統層級的關鍵設計決策。協定的選擇將直接影響：

 

  •  系統可擴展性（Scalability）
  • 裝置功耗與生命週期
  • 邊緣與雲端的責任邊界
  • 長期維運與系統演進成本

 

錯誤的通訊架構，問題通常不會立即出現，而是在系統擴張、功能增加或跨平台整合時，逐步累積成無法回頭的技術債。

 

一、通訊協定選型的四個系統決策維度

在討論 MQTT、HTTP 或 CoAP 之前，專業的做法應先回答以下四個問題：

 

1. 資料流模型（Data Flow Pattern）

●      裝置到雲端的即時回傳？

●      雲端是否需要主動下發指令？

●      是否存在多個系統同時消費同一筆資料？

 

2. 資料特性（Data Characteristics）

●      傳輸頻率：毫秒級 / 秒級 / 分鐘級

●      封包大小：bytes / KB / MB

●      是否可容忍延遲或丟包？

 

3. 裝置資源模型（Device Resource Model）

 

●      常電或電池供電

●      MCU / MPU / Android

●      記憶體與運算能力限制

 

4. 系統責任邊界（System Ownership）

●      雲端是否自建或使用公有雲？

●      是否需整合 ERP / MES / POS 等既有 IT 系統？

●      未來是否需要跨平台擴展？

 

這四個維度沒有定義清楚之前，任何「選協定」的討論都只是技術偏好，而非架構設計。

 

二、三種主流協定的系統層定位

 

以下比較不是從功能面，而是從「在整個系統中扮演的角色」來看。

 

IoT 通訊協定系統層比較總覽

 

協定

系統層定位

通訊拓樸模型

核心通訊模型

頻寬效率

功耗模型

即時性

可維運性

典型應用場景

MQTT

Event Bus / Telemetry Layer

多對多（Pub/Sub）

Publish / Subscribe

高

中低

高

高

工業設備、遠端監控、即時告警、群組控制

HTTP

Control Plane / API Layer

一對一（Client/Server）

Request / Response

低

高

低

最高

設備管理、OTA、帳號系統、企業系統整合

CoAP

Ultra-light Device Fabric

一對一（Point-to-Point）

UDP + REST-like

最高

最低

中

低

電池感測器、大規模節點

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

三、真正的核心差異：通訊拓樸模型

 

多數技術文章會強調 TCP vs UDP，但在實務架構中，更關鍵的是通訊拓樸模型。

 

MQTT：多對多的事件流架構

 

MQTT 採用 Publish/Subscribe 模型，設備只負責「發佈事件」，不需要知道資料會被誰消費。

這代表：

 

●      同一筆資料可同時被 Dashboard、AI 模型、告警系統、資料倉儲消費

●      新增系統時，不需修改設備韌體

●      天然支援數位分身（Digital Twin）與事件驅動架構

 

本質上，MQTT 是整個 IoT 系統的「資料匯流排」。

 

CoAP / HTTP：一對一的點對點架構

 

CoAP 與 HTTP 都屬於 Client/Server 模型：

  • 每個功能都需要設備明確知道對象
  • 沒有天然廣播機制
  • 無事件流概念

 

這種架構的優點是簡單、直接、好實作，但系統功能天花板極低，一旦需求增加，通常只能重構整個系統。

 

四、成熟 IoT 架構的實務模式：分層而非單選

 

實際可長期維運的系統幾乎不會只使用單一協定，而是分層設計：

 

Device Layer

  ├─ MQTT：即時事件與狀態

  ├─ CoAP：低功耗感測

  └─ HTTP：控制與設定

 

Edge Layer

  ├─ MQTT Broker

  ├─ Rule Engine

  └─ Local Cache

 

Cloud Layer

  ├─ HTTP API Gateway

  ├─ MQTT Ingestion

  └─ Data Pipeline

 

重點不是「支援哪些協定」，而是：

 

每一層使用最符合其責任模型的通訊方式。

 

五、最常見的三個結構性錯誤

 

1. 全系統只用 HTTP

結果：

  • 即時性靠輪詢硬撐
  • 頻寬與功耗失控
  • 無法支援事件驅動功能

 

2. 為了省電全面使用 CoAP

結果：

  • 系統可觀測性極低
  • Debug 困難
  • 後期功能擴充成本爆炸

 

3. 未定義 Edge 與 Cloud 邊界

結果：

  • 所有邏輯丟雲端
  • 延遲不可控
  • 網路成本持續上升

 

六、工程決策總結

 

真正成熟的 IoT 架構設計原則只有三句話：

  • 事件用 MQTT，控制用 HTTP，極端省電才用 CoAP。
  • 協定選擇前，先定義系統責任邊界與資料流模型。
  • 任何無法被監控、分析與 Debug 的架構，都是技術債。

 

結語：協定決定的不只是通訊方式，而是系統上限

 

通訊協定的本質差異不在封包大小，而在系統拓樸模型與資料流設計。

  • 一對一架構決定功能邊界
  • 多對多架構決定系統上限
  •  

選對協定，代表系統可以持續演進；選錯協定，代表每一次需求變更都將付出指數級的重構成本。

這也是為什麼，真正專業的 IoT 系統設計，從來不是問「支援哪些協定」，而是先問：

 

這個系統未來五年會長成什麼樣子？