8 月，NanoMQ 繼續保持穩步更新。最新的 0.11.0 版本已於 8月底正式釋出（https://github.com/emqx/nanomq/releases/tag/0.11.0 ）。此版本繼續增強了橋接功能，增加了 MQTT 5.0 + MQTT over QUIC 橋接模式，新增和修復了對已連線客戶端狀態進行監控和查詢的 HTTP API。此外各項效能最佳化和缺陷修復也在持續進行中。

## 橋接功能更新

作為 NanoMQ 最為廣泛使用的功能之一，橋接功能本月得到重大更新升級，新增了 2 種橋接模式：MQTT over QUIC 橋接和 MQTT 5.0 協議橋接。

### MQTT over QUIC 橋接

繼 EMQX 5.0 全球率先發布 MQTT over QUIC 支援後，NanoMQ 專案也為了降低此功能的使用門檻在 0.11 版本推出了 MQTT over QUIC 橋接功能。目前 NanoSDK 已支援以 QUIC 協議作為 MQTT 的傳輸層，因此與其相容的 NanoMQ 專案的橋接功能也一併得到了無縫升級。使用者可以使用 QUIC 作為 MQTT 協議的傳輸層來與 EMQX 5.0 訊息服務建立橋接進行資料同步，從而為無法整合或找到合適的 MQTT over QUIC SDK 的端側裝置和難以修改韌體的嵌入式裝置提供在 IoT 場景利用 QUIC 協議優勢的捷徑。

[![](http://img.blog.itpub.net/blog/2022/09/06/38fa720b44f04900.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/nanomq-newsletter-202208)

在需要與雲端 MQTT 服務進行資料同步的各種物聯網場景中，透過 NanoMQ 的多協議接入能力，可以將其作為邊緣訊息匯流排和統一的資料空間，統一匯聚諸如 HTTP、MQTT 3.1.1/5.0、WebSocket、nanomsg/nng 和 ZeroMQ 等常用的 broker/brokerless 訊息協議，再由 NanoMQ 內部強大的 Actor 訊息處理模型轉化成標準的 MQTT 訊息後，透過 QUIC 傳輸層的 0RTT 快速重連和被動地址切換等功能來克服網際漫遊、弱網傳輸和 TCP 隊頭阻塞等各類常見的物聯網連線問題。還可以透過 NanoMQ 的規則引擎對資料做重定向、本地快取或持久化。依靠 EMQX+NanoMQ 的雲邊一體化的訊息架構，使用者能夠快速且低成本的在泛物聯網場景中完成跨時空地域的資料採集和同步需求。

**如何使用 MQTT over QUIC 橋接功能**

目前 NanoMQ 的 QUIC 模組處於預設關閉狀態，使用者如需使用需透過編譯選項開啟後安裝使用，完整的下載和編譯安裝命令可以參考：

```jboss-cli
git clone https://github.com/emqx/nanomq.git
cd nanomq ; git submodule update --init --recursive (同步submodule時可能耗時較久)

mkdir build && cd build
cmake -G Ninja -DNNG_ENABLE_QUIC=ON ..
sudo ninja install
```

開啟 QUIC 橋接功能的 NanoMQ 編譯安裝完成後，可以在配置檔案`/etc/nanomq_bridge.conf`中配置 MQTT over QUIC 橋接功能和對應的主題，使用 `mqtt-quic` 作為 URL 字首即是採用 QUIC 作為 MQTT 的傳輸層：

```clean
## Bridge address: host:port .
##
## Value: String
## Example: ## Example: mqtt-tcp://broker.emqx.io:1883 （這是標準MQTT over TCP）
bridge.mqtt.emqx.address=mqtt-quic://54.75.171.11:14567

## Protocol version of the bridge. （注意：QUIC橋接目前只支援V4即MQTT 3.1.1版本）
bridge.mqtt.emqx.proto_ver=4

## Whether to enable bridge mode for mqtt bridge
## Value: boolean
bridge.mqtt.emqx.bridge_mode=true

## The ClientId of a remote bridge.
## Default random string.
## Value: String
#bridge.mqtt.emqx.clientid=bridge_client

## Ping interval of a down bridge.
## Value: Duration
## Default: 10 seconds
bridge.mqtt.emqx.keepalive=60

## The Clean start flag of a remote bridge.
##
## Value: boolean
## Default: true
bridge.mqtt.emqx.clean_start=true

## The username for a remote bridge.
bridge.mqtt.emqx.username=username

## The password for a remote bridge.
bridge.mqtt.emqx.password=passwd

## Topics that need to be forward to IoTHUB
##
## Value: String
## Example: topic1/#,topic2/#
bridge.mqtt.emqx.forwards=topic1/#,topic2/#

## Need to subscribe to remote broker topics
##
## Value: String
bridge.mqtt.emqx.subscription.1.topic=cmd/topic1
```

然後啟動 NanoMQ 即可：

```dos
nanomq start --bridge <path of="" nanomq_bridge.conf="">
```

驗證 QUIC 橋接是否成功，只需往橋接的上下行主題傳送資料即可，也可以使用 NanoMQ 自帶的 nanomq_cli 工具中的 QUIC 客戶端來與 EMQX 5.0 測試驗證。

### MQTT 5.0 橋接

除了 QUIC 橋接，0.11 版本也支援使用 MQTT 5.0 進行橋接，使用者只需在配置檔案中修改橋接的協議版本即可：

```ini
## Protocol version of the bridge. （注意：MQTT 5.0 只適用於 Vanila MQTT）
bridge.mqtt.emqx.proto_ver=5
```

之後使用者就可以透過橋接連線轉發 MQTT 5.0 訊息了，享受諸如自定義屬性等新特性。

## HTTP API 更新

透過 HTTP REST API 來對邊緣服務進行監控和運維一直是廣大普通使用者的需求之一，NanoMQ 0.11 也新增了對當前連線的 MQTT 客戶端資訊的查詢 API，方便第三方應用快速準確的獲取所有客戶端的線上情況，或查詢某個特定客戶端的健康狀態。

獲取所有線上客戶端的情況：

```vbscript
$ curl -i --basic -u admin:public -X GET "http://localhost:8081/api/v4/clients"

{"code":0,"data":[{"client_id":"nanomq-f6d6fbfb","username":"alvin","keepalive":60,"conn_state":"connected","clean_start":true,"proto_name":"MQTT","proto_ver":5,"recv_msg":3},{"client_id":"nanomq-bdf61d9b","username":"nanomq","keepalive":60,"conn_state":"connected","clean_start":true,"proto_name":"MQTT","proto_ver":5,"recv_msg":0}]}
```

透過客戶端 ID 查詢指定客戶端的線上情況

```stylus
$ curl -i --basic -u admin:public -X GET "http://localhost:8081/api/v4/clients/nanomq-29978ec1"

{"code":0,"data":[{"client_id":"nanomq-29978ec1","username":"","keepalive":60,"conn_state":"connected","clean_start":true,"proto_name":"MQTT","proto_ver":5}]}
```

關於 API 的請求和返回引數詳情，請參閱 NanoMQ Docs（https://nanomq.io/docs/zh/latest/http-api/v4.html#客戶端 ）。

## 其他功能更新

同時，NanoMQ 0.11 還響應使用者和社群要求更新和最佳化了如下功能：

### 退避時間設定 （Backoff timer）

在 MQTT 協議中規定 Broker 要在 1.5 倍於客戶端設定的 [Keep Alive](https://www.emqx.com/zh/blog/mqtt-keep-alive) 時間後踢出沒有活動的連線。但是實際場景中許多使用者希望能夠自由靈活調節這一時間長度以適應不同的網路環境。所以新增了這一配置選項，使用者透過配置該選項來調整 NanoMQ 處理非活動客戶端的最大時間上限。

例如，如果按照以下設定，如果一個客戶端的 Keep Alive 時間設定為 60s，且一直沒有活動，NanoMQ 將會在 1.25 * 60 = 75s 後關閉此客戶端的連線。

```shell
## The backoff for MQTT keepalive timeout.
## broker will discolse client when there is no activity for
## 'Keepalive * backoff * timeout.
##
## Value: Float > 0.5
keepalive_backoff=1.25
```

### MQTT over QUIC CLI 工具

如果透過`-DNNG_ENABLE_QUIC=ON` 開啟了 QUIC 模組，那麼會自動編譯 nanomq_cli 中的 MQTT over QUIC 客戶端工具：

```gherkin
nanomq_cli quic --help
Usage: quic conn <url>
       quic sub  <url> <qos> <topic>
       quic pub  <url> <qos> <topic> <data>

## subscribe example
nanomq_cli quic sub mqtt-quic://54.75.171.11:14567 2 msg
```

## Bug 修復及最佳化

1. 為 NanoMQ 增加了自動化 CI 測試框架，以保證測試覆蓋率。
2. 修復了 WebSocket&TLS 的傳輸層。
3. 增加了 nanomq_cli 工具的幫助資訊。
4. 修復了一個使用共享訂閱時可能導致主題匹配不正確的問題。
5. 修復了客戶端使用持久會話後斷開連線，會話總是比設定時間更早過期的問題。
6. 修復了橋接連線使用非非同步訂閱方式可能造成的執行緒阻塞問題。

## 即將到來

下個版本中，NanoMQ 將為大家帶來規則引擎的重發布和熱更新功能，並且增加橋接連線的狀態管理能力。未來 NanoMQ 還將繼續設計和規劃利用 QUIC 的 Multi-Stream 特性來應對物聯網場景裡的多種傳輸媒介共用帶來的連結複用問題，也會在 QUIC 的 Flow Control 基礎上完成多種型別資料流統一排程的本地資料閘道器代理功能。

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

NanoMQ Newsletter 2022-08｜v0.11：新增MQTT 5.0+MQTT over QUIC橋接模式

相關文章