金秋十月，[NanoMQ](https://www.emqx.com/zh/products/nanomq) 繼續保持穩步更新，最新的 0.13 版本將於近日正式釋出。此版本的更新繼續聚焦於橋接功能部分：為原來的 MQTT over QUIC 橋接功能增加了多路橋接和更豐富的 QUIC 傳輸層配置引數，新增了內建的 Azure 橋接功能。另外新增了規則引擎訊息重發布功能。

## 更完善的 MQTT over QUIC 橋接

在 0.12 版本中推出的 MQTT over QUIC 橋接功能與 EMQX 5.0 配合使用得到了使用者的熱烈反響。在 0.13 版本中，我們為此功能進行了多項加強：

### 多路橋接

原先的 MQTT over QUIC 橋接功能只能支援連線一個服務端，這無法滿足多路資料同步和傳輸的要求。與傳統的基於 TCP 的 MQTT 連線相同，NanoMQ 也為基於 QUIC 的橋接功能的傳輸層做了最佳化，使其能夠支援同時建立多個 MQTT over QUIC 連線。使用者只需要和使用標準 MQTT 橋接功能一樣，在配置檔案中設定多個橋接目標配置(只摘錄部分相關)：

```clean
## Bridge via both TCP & QUIC ##
## 以同時橋接到EMQX公共伺服器和EMQX Cloud為例，配置橋接URL ##
bridge.mqtt.emqx1.address=mqtt-quic://broker.emqx.io:14567
bridge.mqtt.emqx2.address=mqtt-quic://54.75.171.11:14567
bridge.mqtt.emqx3.address=mqtt-tcp://broker.emqx.io:1883

......
```

多路橋接時，橋接資料是會同時釋出給每個橋接物件的。NanoMQ 也支援同時進行基於 TCP 和 QUIC 的 MQTT 橋接。

### QUIC & TCP 自動切換

MQTT over QUIC 能夠幫助 IoT 應用極大改善弱網狀態下的資料傳輸和地址遷移問題。但由於 QUIC 是基於 UDP 的，目前許多運營商仍然對 UDP 包有特殊的路由策略，這往往導致 QUIC 連線無法成功建立或一直被丟包。NanoMQ 也考慮到需要應對複雜的中間網路問題，特地推出了 QUIC 連線失敗時自動切換至標準 MQTT over TCP 橋接的功能。

[![](http://img.blog.itpub.net/blog/2022/11/10/f29acbeb6e2ed883.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/nanomq-newsletter-202210)

使用時只需要在配置檔案中設定新增的 `bridge.mqtt.emqx.hybrid_bridging` 選項為 `true` 來開啟這一模式。注意目前並不能自動切換回 QUIC，後續再備用橋接目標功能中會支援這一需求。另外，因為此過程不計為連線通斷，所以也不會發出橋接斷開/連線的上下線事件訊息。

### 更豐富細緻的配置選項

QUIC 作為新晉的網路標準，而且具有一定的設計自由度，所以往往需要針對不同的網路環境和場景修改其內部引數，為此 NanoMQ 暴露了一些常用的配置選項，以下是對它們的詳細解釋：

```clean
## Newly added config params for QUIC ##
##--------------------------------------------------------------------

## Ping: QUIC 傳輸層傳送Ping包的時間間隔
##
## Value: Duration
## Default: 120 seconds
bridge.mqtt.emqx.quic_keepalive=120

## Idle Timeout: 保持QUIC連線的最大空閒時間，超過此設定時間長度的無活動連線將會被主動關閉。
設定為0的話就不偵測無活動連線，若MQTT層keepalive設定的過大，這會造成殭屍連線的風險
## Value: Duration
## Default: 120 seconds
bridge.mqtt.emqx.quic_idle_timeout=120

## Disconnect Timeout: QUIC Stream 最大等待對端ACK的時間，超過此時間未收到回應的Stream
會被認為無效並斷開。
## Value: Duration
## Default: 20 seconds
bridge.mqtt.emqx.quic_discon_timeout=20

## Handshake Timeout: NanoMQ建立QUIC連線時的最大等待時間 
## Value: Duration
## Default: 60 seconds
bridge.mqtt.emqx.quic_handshake_timeout=60

## Hybrid bridging: 混合橋接模式的開關，若開啟會根據QUIC連結的建立情況自動退回 MQTT over
 TCP 橋接模式
## Value: true/false
## Default: false
bridge.mqtt.emqx.hybrid_bridging=false
##
##--------------------------------------------------------------------
```

### QUIC 橋接支援 SQLite 資料快取

NanoMQ 的橋接功能一大特色是橋接能夠支援斷網資料本地快取，網路恢復自動重傳。之前此項功能只對標準的 MQTT over TCP 有效。從 0.13 版本開始，當開啟 SQLite 自動快取功能時，此功能對 QUIC 橋接也同樣有效。

### 自動化釋出包含 QUIC 功能的安裝包

在 0.12 版本，使用者如果想要使用 NanoMQ 的 QUIC 相關功能，需要自行下載原始碼編譯安裝，過程較為複雜。為了方便使用者使用，從 0.13 版本開始，NanoMQ 新增了自動化編譯打包流程，每次都會自動編譯出包含 QUIC 庫在內的二進位制包供使用者直接安裝使用。希望以此來降低專案中引入 QUIC 功能的上手門檻，使用者只需簡單安裝 EMQX 5.0 + NanoMQ 並做相應配置即可。

## Azure IoT Hub 橋接

微軟的 Azure 雲服務有提供一個相容部分 MQTT 協議的物聯網服務：IoT Hub，詳情可參閱微軟官方文件（[瞭解 Azure IoT 中心 MQTT 支援](https://learn.microsoft.com/zh-cn/azure/iot-hub/iot-hub-mqtt-support) ）。NanoMQ 也內建支援了與其的橋接功能，具體使用方式如下：

Azure 強制要求必須使用 TLS 加密連線，且使用的 Topic 和認證用的使用者名稱密碼必須在其控制檯預先建立裝置來配置使用。

[![](http://img.blog.itpub.net/blog/2022/11/10/4521fa33d03186a3.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/nanomq-newsletter-202210)

目前 NanoMQ 只支援使用對稱秘鑰加密和使用者名稱+密碼的方式認證連結 Azure IoT Hub。

配置後的頁面如圖：

[![](http://img.blog.itpub.net/blog/2022/11/10/a3766db8a51a1699.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/nanomq-newsletter-202210)

之後修改橋接配置檔案，其中需要特殊對待的配置有：

```routeros
bridge.mqtt.azure.address=tls+mqtt-tcp://azure-iot-hub.net:8883 (使用Azure提供的主機名)
bridge.mqtt.azure.clientid=device01 (使用在Azure控制檯建立的裝置名)
bridge.mqtt.azuer.username= {iothubhostname}/{device_id}/?api-version=datetime
(主機名+裝置名+API版本日期拼接而成)
bridge.mqtt.azuer.password=***** （ 使用SAS令牌，需要用Azure提供的工具本地生成 ）
bridge.mqtt.azuer.tls.enable=true (必須使用TLS加密)
bridge.mqtt.azuer.forwards=devices/{device_id}/messages/events/
bridge.mqtt.azuer.subscriptions.1.topic=devices/{device_id}/messages/devicebound/#
（訂閱和釋出的主題必須按照Azure規則配置）
```

[![](http://img.blog.itpub.net/blog/2022/11/10/863e7259820fddaf.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/nanomq-newsletter-202210)

如此啟動 NanoMQ 就能夠完成將本地標準 MQTT 客戶端的訊息轉換橋接至 Azure IoT Hub。

## 規則引擎訊息重發布

規則引擎訊息重發布功能在 v0.13 中測試完成正式釋出。支援根據使用者編寫的 SQL 語句將本機 NanoMQ 裡命中的訊息修改後重新發布到目標 MQTT 服務的主題。簡單示例如下：

```ini
## 重新發布訊息到此目標主機：
rule.repub.1.address=mqtt-tcp://broker.emqx.io:1883
## 重新發布到此目標主題：
rule.repub.1.topic=topic/repub1
## 根據如下規則過濾本機NanoMQ的訊息：
rule.event.publish.1.sql="SELECT topic, payload FROM "abc""
```

如此就能將本地 NanoMQ 的”abc”主題中的訊息和主題名一起組合成新的訊息轉發給雲端公有的 EMQX MQTT 服務。

同時，這一版本開始規則引擎也能夠支援使用 HTTP API 來對部分規則進行熱更新。

## 即將到來

目前 NanoMQ 正計劃將配置檔案格式更新為更易讀的 HOCON（*Human-Optimized* *Configuration Object* *Notation*）。關於配置檔案使用體驗，歡迎使用者在 Github 提出寶貴建議。同時 NanoMQ 還將增加 Reload 命令和 HTTP API 來支援部分配置選項的熱更新，並增加 ACL 支援等功能。

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/nanomq-newsletter-202210](https://www.emqx.com/zh/blog/nanomq-newsletter-202210)

更強大的 MQTT over QUIC 橋接 & Azure 橋接

相關文章