CoAP 與 AMQP 物聯網通訊協定應用與比較

– 16 分鐘閱讀

在資源受限的物聯網裝置中，選擇合適的通訊協定至關重要。本文將深入探討 CoAP 和 AMQP 兩種協定，分析其特性、應用場景以及與其他協定的比較，為物聯網開發者提供參考。CoAP 適合低功耗、低延遲的應用，而 AMQP 則更適用於需要可靠訊息傳遞的場景。理解這些協定的差異，才能根據專案需求做出最佳選擇。此外，我們也將探討 MQTT、STOMP 等其他物聯網通訊協定，並分析各種網路安全協定的特性，最後討論雲端與霧計算拓樸，以及雲端架構模型與服務優點，提供更全面的物聯網通訊架構的理解。

客戶端實現

客戶端使用 aiocoap 庫傳送 CoAP 請求。以下是客戶端的實現：

import asyncio
import aiocoap

# 設定 CoAP 請求的 URI
request = aiocoap.Message(code=aiocoap.Code.GET)
request.opt.uri_host = '127.0.0.1'
request.opt.uri_path = ('temp', 'celcius')

# 傳送 CoAP 請求
response = await asyncio.get_event_loop().create_future()
async def main():
    global response
    response = await context.request(request).response

asyncio.get_event_loop().run_until_complete(main())

伺服器實現

伺服器使用 aiocoap 庫實現 CoAP 的 GET 和 PUT 方法。以下是伺服器的實現：

import asyncio
import aiocoap
from aiocoap import resource

class GetPutResource(resource.Resource):
    def __init__(self):
        super().__init__()
        self.set_content(b"Default Data (padded) ")

    def set_content(self, content):
        # Apply padding
        self.content = content

    async def render_get(self, request):
        # GET handler
        return aiocoap.Message(code=aiocoap.Code.CONTENT, payload=self.content)

    async def render_put(self, request):
        # PUT handler
        print('PUT payload: %s' % request.payload)
        self.set_content(request.payload)
        return aiocoap.Message(code=aiocoap.Code.CHANGED)

def main():
    # Root element that contains all resources found on server
    root = resource.Site()
    # This is the typical .well-known/core and resource list for well-known/core
    root.add_resource(('.well-known', 'core'), resource.WKCResource(root.get_resources_as_linkheader))
    # Adds the resource /tmp/celcius
    root.add_resource(('temp', 'celcius'), GetPutResource())

    asyncio.get_event_loop().run_until_complete(aiocoap.Context.create_server_context(root, ('::', 5683)))

if __name__ == "__main__":
    main()

Mermaid 圖表

  sequenceDiagram
    participant Client as CoAP Client
    participant Server as CoAP Server
    Note over Client,Server: CoAP 通訊協定
    Client->>Server: CoAP GET 請求
    Server->>Client: CoAP GET 回應
    Client->>Server: CoAP PUT 請求
    Server->>Client: CoAP PUT 回應

圖表翻譯：

此圖表描述了 CoAP 客戶端和伺服器之間的通訊過程。客戶端傳送 CoAP GET 請求給伺服器，伺服器回應 CoAP GET 回應。客戶端也可以傳送 CoAP PUT 請求給伺服器，伺服器回應 CoAP PUT 回應。這個過程展示了 CoAP 通訊協定的基本工作原理。

其他協定

在物聯網（IoT）和機對機（M2M）部署中，存在許多訊息協定。以下幾節將探討一些替代協定，以滿足特定的使用案例。

STOMP

STOMP（Simple或Streaming Text Message-Oriented Middleware Protocol）是一種根據文字的協定，設計用於簡化訊息傳遞。它允許使用不同程式語言開發的客戶端和伺服器之間進行通訊。STOMP的架構包括框架標頭和框架主體，類似於HTTP協定。目前的STOMP規範為1.2版，發布於2012年10月22日，採用免費授權。

STOMP與本章中介紹的其他協定不同，它不涉及訂閱主題或佇列。相反，它使用類似HTTP的語法，例如SEND命令，包含目的地字串。代理伺服器必須解析訊息並將其對映到適當的主題或佇列。資料的消費者將訂閱代理伺服器提供的目的地。

STOMP有多種客戶端實現，包括Python（Stomp.py）、TCL（tStomp）和Erlang（stomp.erl）。許多伺服器支援STOMP，例如RabbitMQ（透過外掛）和其他以特定語言設計的伺服器（Ruby、Perl或OCaml）。STOMP優先考慮人類可讀性、容錯性和自我描述性，但它在網路和通訊協定中並不高效，尤其是在考慮每條訊息的位元數時。

Edge to Cloud協定

AMQP

AMQP（Advanced Message Queuing Protocol）是一種成熟的訊息佇列協定，廣泛應用於金融和信用交易行業，也適用於IoT應用。AMQP最初由JP Morgan Chase在2003年設計，後來在2006年成立了一個由23家公司組成的工作組，負責協定的架構和治理。2011年，工作組併入OASIS組織，目前仍由OASIS主持。AMQP有兩個版本：0.9和1.0，分別在不同部署中使用。

AMQP協定根據TCP堆疊，使用5672埠進行通訊。資料在AMQP中進行序列化，意味著訊息以單元框架進行廣播。框架在虛擬通道中傳輸，虛擬通道由唯一的channel_id標識。框架由標頭、channel_id、有效載荷資訊和尾部組成。然而，虛擬通道只能與單一主機相關聯。訊息被指派一個唯一的全域識別符號。

AMQP是一種流控制、面向訊息的通訊系統。它是一種線級協定和低階介面。線級API允許不同的訊息服務（如.NET和Java）之間進行通訊。AMQP嘗試解耦發布者和訂閱者。與MQTT不同，AMQP具有負載均衡和正式佇列的機制。根據AMQP的流行協定包括RabbitMQ，它是一個用Erlang編寫的AMQP訊息代理。還有許多AMQP客戶端可用，例如用Java、C#、JavaScript和Erlang編寫的RabbitMQ客戶端，以及用Python、C++、C#、Java和Ruby編寫的Apache Qpid。

一個或多個虛擬主機及其自己的名稱空間、交換器和訊息佇列將駐留在中央伺服器上。生產者和消費者訂閱交換器服務。交換器服務從發布者接收訊息並將資料路由到相關的佇列。這種關係被稱為繫結，可以是直接到一個佇列或分發到多個佇列（如廣播）。或者，繫結可以使用路由鍵將一個交換器與一個佇列關聯，這被正式稱為直接交換器。另一種交換器型別是主題交換器。

AMQP 架構與應用

在 AMQP（Advanced Message Queuing Protocol）中，節點（node）和連結（link）是兩個重要的概念。節點可以是訊息的來源或目的地，而連結則是節點之間的單向通道。當訊息透過節點時，其全球識別碼保持不變，但如果節點對訊息進行任何轉換，則會分配新的識別碼。

AMQP 支援三種不同的訊息模式：

  • 非同步定向訊息：訊息在不需要接收者確認的情況下傳輸。
  • 請求/回應或釋出/訂閱：這與 MQTT 類似，中央伺服器充當釋出/訂閱服務。
  • 儲存和轉發：這用於中繼轉發，訊息先傳送到中間中繼站，然後再傳送到目的地。

以下是使用 Python 和 RabbitMQ 實現的基本定向交換示例：

import pika

# 初始化連線
connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

# 宣告定向交換
channel.exchange_declare(exchange='Idaho', type='direct')

# 宣告佇列
channel.queue_declare(queue='weather')

# 繫結交換和佇列
channel.queue_bind(exchange='Idaho', queue='weather', routing_key='Idaho')

# 生產訊息
channel.basic_publish(exchange='Idaho', routing_key='Idaho', body='new important task')

# 消費訊息
method_frame, header_frame, body = channel.basic_get('weather')

# 確認訊息
channel.basic_ack(method_frame.delivery_tag)

在這個示例中，我們建立了一個名為 “Idaho” 的定向交換，並將其繫結到一個名為 “weather” 的佇列。然後，我們生產了一條訊息並傳送到交換，最後從佇列中消費這條訊息。

圖表翻譯：

  flowchart TD
    A[節點] --> B[連結]
    B --> C[訊息]
    C --> D[交換]
    D --> E[佇列]
    E --> F[消費者]

這個圖表展示了 AMQP 中的節點、連結、訊息、交換、佇列和消費者的關係。節點可以是訊息的來源或目的地，連結是節點之間的單向通道，訊息透過連結傳輸，交換負責路由訊息到正確的佇列，佇列是訊息的緩衝區，消費者從佇列中消費訊息。

通訊協定摘要與比較

在評估各種通訊協定的過程中，瞭解每種協定的特點和限制是非常重要的。以下是對 MQTT、MQTT-SN、CoAP、AMQP、STOMP 和 HTTP/RESTful 等協定的摘要和比較。需要注意的是，這些協定中有些可能有例外情況，例如 MQTT 本身不提供內建的安全性配置，但可以在應用層面實現。

通訊模型

  • MQTT 和 MQTT-SN：這兩種協定都使用發布/訂閱（pub/sub）模型，允許裝置之間進行即時通訊。
  • CoAP：根據 RESTful 架構，提供了一種輕量級的機器對機器通訊方式。
  • AMQP：是一種訊息導向的中介軟體協定，支援多種通訊模型，包括點對點、發布/訂閱等。
  • STOMP：是一種簡單的文字基礎的訊息協定，支援多種通訊模型。
  • HTTP/RESTful：根據 HTTP 協定的 RESTful 架構，提供了一種標準化的網路服務通訊方式。

自動發現

  • MQTT：不提供內建的自動發現機制。
  • MQTT-SN：可以透過閘道器（gateways）實現自動發現。
  • CoAP：支援自動發現機制。
  • AMQP、STOMP 和 HTTP/RESTful：不提供內建的自動發現機制。

資源需求

  • MQTT 和 MQTT-SN：資源需求相對較低，特別適合於資源有限的嵌入式裝置。
  • CoAP：設計為輕量級協定，對資源的需求也很低。
  • AMQP 和 STOMP：這兩種協定相對複雜，可能需要更多的資源。
  • HTTP/RESTful：由於根據 HTTP，可能需要更多的資源，特別是當處理大量請求時。

安全性

  • MQTT：本身不提供內建的安全性配置，但可以透過 TLS/SSL 等方式加強安全性。
  • MQTT-SN：同樣需要透過外部機制實現安全性。
  • CoAP、AMQP、STOMP 和 HTTP/RESTful：這些協定可能提供內建的安全機制或需要透過其他方式加強安全性。

網路安全協定比較

在網路安全中，選擇合適的安全協定是非常重要的。不同的協定有不同的特點和應用場景。以下是幾種常見的安全協定的比較：

協定概覽

協定Header Size (bytes)平均功耗身分驗證
SSL/TLS2低否
DTLS2低否
TLS4中是
高階TLS8高是

協定詳細比較

  • SSL/TLS：是一種廣泛使用的安全協定，提供了基本的加密和身份驗證功能。其header size相對較小，平均功耗也較低。但是，它不提供身份驗證功能。
  • DTLS：是一種根據UDP的安全協定，與SSL/TLS相比，其header size相同，但平均功耗略高。它也沒有提供身份驗證功能。
  • TLS：是一種高階的安全協定，提供了加密、身份驗證和完整性檢查等功能。其header size較大，平均功耗也較高。但是，它提供了身份驗證功能。
  • 高階TLS：是一種高階的安全協定，提供了高階的加密、身份驗證和完整性檢查等功能。其header size最大，平均功耗也最高。但是，它提供了最高階的安全性和身份驗證功能。
內容解密：

上述比較表格中，我們可以看到不同的安全協定有不同的特點和應用場景。SSL/TLS和DTLS適合於低功耗和低header size的應用，而TLS和高階TLS適合於高安全性和高階身份驗證的應用。這些協定都有其優缺點，需要根據具體的需求和限制進行評估和比較。

圖表翻譯：

  graph LR
    A[SSL/TLS] -->|低功耗|> B[DTLS]
    B -->|高功耗|> C[TLS]
    C -->|高安全性|> D[高階TLS]
    D -->|高階身份驗證|> E[最終選擇]

上述圖表展示了不同安全協定的關係和應用場景。SSL/TLS和DTLS適合於低功耗和低header size的應用，而TLS和高階TLS適合於高安全性和高階身份驗證的應用。最終，選擇哪種協定需要根據具體的需求和限制進行評估和比較。

網路安全協議比較

在網路安全中，使用適當的加密和安全協議是保護資料和防止未經授權存取的關鍵。以下是幾種常見的安全協議及其特點的比較。

SSL/TLS

SSL（Secure Sockets Layer）和TLS（Transport Layer Security）是兩種最常用的加密協議，廣泛用於網路通訊中。它們提供了加密和身份驗證，確保資料在傳輸過程中保持機密和完整。

  • 加密: 是
  • 存取控制: 否
  • 通訊開銷: 低

DTLS

DTLS（Datagram Transport Layer Security）是一種根據UDP的TLS版本，設計用於需要低延遲和實時通訊的應用。它提供了類似於TLS的加密和身份驗證功能，但針對UDP的特點進行了最佳化。

  • 加密: 是
  • 存取控制: 否
  • 通訊開銷: 很低

TLS

TLS是一種廣泛使用的加密協議，提供了高階別的安全性和互操作性。它支援多種加密演算法和模式，能夠適應不同的應用需求。

  • 加密: 是
  • 存取控制: 否
  • 通訊開銷: 低

Proxy

代理伺服器（Proxy）可以用於控制和過濾網路流量，提供了一種間接存取網路資源的方式。它們可以用於實現存取控制和內容過濾，但也可能引入額外的通訊開銷。

  • 加密: 否
  • 存取控制: 是
  • 通訊開銷: 高
圖表翻譯：
  flowchart TD
    A[網路安全需求] --> B[選擇協議]
    B --> C{SSL/TLS}
    B --> D{DTLS}
    B --> E{Proxy}
    C --> F[加密和身份驗證]
    D --> G[低延遲和實時通訊]
    E --> H[存取控制和內容過濾]
    F --> I[高安全性]
    G --> J[低通訊開銷]
    H --> K[高通訊開銷]

內容解密：

以上圖表展示了網路安全需求到選擇協議的過程。根據不同的需求，可以選擇SSL/TLS、DTLS或Proxy等協議。SSL/TLS提供了加密和身份驗證，DTLS則針對低延遲和實時通訊進行了最佳化，Proxy可以用於實現存取控制和內容過濾。每種協議都有其優缺點和特點，需要根據具體的應用需求進行選擇。

網路傳輸協定分析

在網路傳輸中，協定（Protocol）扮演著至關重要的角色。不同的協定具有不同的特性和應用場景。以下將探討幾種常見的網路傳輸協定，包括TCP、UDP、TCP/UDP、UDP、TCP/UDP和TCP。

TCP（Transmission Control Protocol）

TCP是一種面向連線的傳輸協定，確保資料的可靠傳輸。它提供了錯誤檢測和糾正機制，保證資料的完整性和順序性。TCP適合於需要可靠傳輸的應用，例如檔案傳輸、電子郵件等。

UDP（User Datagram Protocol）

UDP是一種面向無連線的傳輸協定，優先考慮速度和效率。它不提供錯誤檢測和糾正機制，可能導致資料丟失或錯誤。UDP適合於需要高速傳輸的應用，例如影片直播、遊戲等。

TCP/UDP混合協定

一些應用需要同時具備TCP和UDP的特性，例如需要可靠傳輸的同時也需要高速傳輸。這種情況下，可以使用TCP/UDP混合協定，結合兩者的優點。

Broadcasting和Quality of Service

Broadcasting是指將資料傳輸到多個接收者，TCP和UDP都支援Broadcasting。Quality of Service（QoS）是指網路傳輸的服務質量，包括延遲、吞吐量、錯誤率等。TCP和UDP都支援QoS，保證資料傳輸的質量。

複雜度和安全性

不同的協定具有不同的複雜度和安全性。TCP的複雜度較高，需要更多的資源和計算；UDP的複雜度較低，需要較少的資源和計算。從安全性方面來看，TCP和UDP都有自己的安全機制，例如TCP的三次握手和UDP的校驗和。

內容解密：
  • 網路傳輸協定是網路傳輸的基礎，選擇合適的協定可以保證資料傳輸的質量和效率。
  • TCP和UDP是兩種常見的協定，具有不同的特性和應用場景。
  • 混合協定和Broadcasting可以滿足特定的需求。
  • 選擇合適的協定需要考慮應用的具體需求和網路環境。
import socket

# 建立一個TCP socket
tcp_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# 建立一個UDP socket
udp_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

# TCP socket連線到伺服器
tcp_socket.connect(("www.example.com", 80))

# UDP socket傳送資料到伺服器
udp_socket.sendto(b"Hello, server!", ("www.example.com", 80))

圖表翻譯：

  flowchart TD
    A[網路傳輸] --> B[協定選擇]
    B --> C[TCP]
    B --> D[UDP]
    C --> E[可靠傳輸]
    D --> F[高速傳輸]
    E --> G[錯誤檢測和糾正]
    F --> H[無錯誤檢測和糾正]
    G --> I[保證資料完整性和順序性]
    H --> J[可能導致資料丟失或錯誤]

圖表翻譯：

  • 網路傳輸需要選擇合適的協定。
  • TCP和UDP是兩種常見的協定，具有不同的特性和應用場景。
  • TCP提供可靠傳輸，包括錯誤檢測和糾正機制。
  • UDP提供高速傳輸，但可能導致資料丟失或錯誤。

雲端與霧計算拓樸

隨著物聯網（IoT）的快速發展，雲端計算已成為一個不可或缺的基礎設施。雲端計算提供了一種可擴充套件、靈活和高效的方式來處理和分析大量的物聯網資料。在本章中，我們將探討雲端和霧計算的拓樸，包括其定義、架構和應用。

雲端計算的定義和特點

雲端計算是一種根據網際網路的計算模式，提供了一種按需的計算資源和服務。雲端計算的特點包括：

  • 按需計算：使用者可以根據需要申請計算資源和服務。
  • 可擴充套件性：雲端計算可以根據使用者的需求自動擴充套件或縮減計算資源。
  • 虛擬化：雲端計算使用虛擬化技術將物理計算資源虛擬化，提供給使用者使用。
  • 高可用性：雲端計算提供高可用性和可靠性的計算服務。

雲端計算的服務模型

雲端計算提供了一種多樣化的服務模型，包括：

  • 基礎設施即服務（IaaS）：提供計算資源、儲存和網路等基礎設施。
  • 平臺即服務（PaaS）：提供軟體開發和部署的平臺。
  • 軟體即服務（SaaS）：提供軟體應用的服務。

霧計算的定義和特點

霧計算是一種根據物聯網的計算模式，提供了一種分散式和可擴充套件的計算方式。霧計算的特點包括：

  • 分散式計算：霧計算使用分散式計算方式處理資料。
  • 可擴充套件性：霧計算可以根據使用者的需求自動擴充套件或縮減計算資源。
  • 低延遲：霧計算提供低延遲的計算服務。

霧計算的應用

霧計算的應用包括：

  • 智慧城市：霧計算可以用於智慧城市的資料處理和分析。
  • 工業物聯網：霧計算可以用於工業物聯網的資料處理和分析。
  • 車聯網：霧計算可以用於車聯網的資料處理和分析。
內容解密：

在本章中，我們探討了雲端和霧計算的拓樸，包括其定義、架構和應用。雲端計算提供了一種可擴充套件、靈活和高效的計算方式，而霧計算提供了一種分散式和可擴充套件的計算方式。兩種計算模式都可以用於物聯網的資料處理和分析，提供了不同的優勢和應用。

  graph LR
    A[雲端計算] --> B[基礎設施即服務]
    A --> C[平臺即服務]
    A --> D[軟體即服務]
    E[霧計算] --> F[分散式計算]
    E --> G[低延遲]
    E --> H[可擴充套件性]

圖表翻譯：

本圖表展示了雲端和霧計算的不同服務模型和特點。雲端計算提供了基礎設施即服務、平臺即服務和軟體即服務，而霧計算提供了分散式計算、低延遲和可擴充套件性。這兩種計算模式都可以用於物聯網的資料處理和分析，提供了不同的優勢和應用。

雲端架構模型

雲端計算的核心是提供按需的計算資源和服務。雲端架構模型可以分為幾種不同的型別，包括NaaS、IaaS、PaaS和SaaS。

NaaS（Network as a Service）

NaaS是一種雲端服務，提供軟體定義的網路（SDN）和軟體定義的周界（SDP）等服務。這些服務可以幫助企業建立虛擬網路和安全的周界。

IaaS（Infrastructure as a Service）

IaaS是一種雲端服務，提供硬體系統和儲存資源。使用者可以使用這些資源建立自己的虛擬機器和應用程式。

PaaS（Platform as a Service）

PaaS是一種雲端服務，提供了基礎設施、作業系統和中介軟體等資源。使用者可以使用這些資源建立自己的應用程式和服務。

SaaS（Software as a Service）

SaaS是一種雲端服務，提供了應用程式和服務。使用者可以透過客戶端訪問這些應用程式和服務。

雲端拓撲

雲端拓撲可以分為幾種不同的型別，包括公有雲、 私有雲和混合雲。

私有雲

私有雲是一種雲端架構，為單一組織或企業提供服務。私有雲可以提供更好的安全性和控制性，但也需要更多的投資和維護。

公有雲

公有雲是一種雲端架構，為多個客戶提供服務。公有雲可以提供更好的可擴充套件性和成本效益，但也需要更好的安全性和控制性。

混合雲

混合雲是一種雲端架構，結合了私有雲和公有雲的優點。混合雲可以提供更好的安全性、控制性和可擴充套件性。

雲端服務的優點

雲端服務可以提供多種優點，包括：

  • 可擴充套件性：雲端服務可以根據需求擴充套件或縮減。
  • 成本效益：雲端服務可以減少資本支出和運營成本。
  • 簡單性：雲端服務可以簡化IT管理和維護。
  • 安全性：雲端服務可以提供更好的安全性和控制性。

雲端架構概覽

在現代的雲端計算中，OpenStack是一個開源的框架，廣泛用於建構雲端平臺。作為一個基礎設施即服務（IaaS）的提供者，OpenStack自2010年開始就在開發者社群中被廣泛使用。OpenStack基金會負責管理這個軟體，並得到了包括Intel、IBM、Red Hat和Ericsson在內的500多家公司的支援。

OpenStack的架構包含了計算、負載平衡、儲存、備份和恢復、網路、儀表盤、安全和身份、資料和分析包、部署工具、監控和計量以及應用服務等主要元件。這些元件為雲端服務提供了全面性的功能。

物聯網通訊協定正經歷百花齊放的階段，從輕量級的 CoAP 到功能豐富的 AMQP，各種協定都在尋求最佳的應用場景。本文深入探討了 CoAP、MQTT、STOMP、AMQP 等協定的核心特性、應用場景以及它們之間的權衡取捨，並分析了不同安全協定如 SSL/TLS 和 DTLS 的效能差異。技術棧的各層級協同運作中體現，選擇合適的協定需要考量諸多因素，例如裝置資源限制、安全性需求、資料傳輸可靠性以及 QoS 等。此外，文章也點出了邊緣計算和雲端架構的重要性，例如霧計算的低延遲特性以及 OpenStack 等雲端平臺的架構模型。對於資源受限的物聯網裝置，CoAP 和 MQTT-SN 是理想的選擇；而對於需要高可靠性和安全性的應用，AMQP 和 TLS 則更為適合。技術團隊應著重於評估不同協定在其特定應用場景下的優劣，才能最大化物聯網應用的效能和價值。未來，隨著物聯網應用場景日益多元化，我們預見會有更多客製化的通訊協定和混合架構出現，以滿足不同垂直領域的需求。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。