物聯網協議漫談 05
好久沒有更新了，今天咱們來聊一下MQTT協議的具體內容。
1 MQTT 協議簡介
MQTT 協議通過交換預定義的 MQTT 控制報文來實現通信。MQTT 控制報文由：
固定報頭 Fixed Header（所有控制報文都包括）+可變報頭（部分控制報文包括）+消息體（即負載，也是僅有部分控制報文包括），這三部分組成。
1.1 固定報頭的的構造如下：
1.2 MQTT 控制報文類型 Message Type
MQTT擁有 14 種不同的消息類型：
（1）CONNECT：客戶端連接到 MQTT 代理
（2）CONNACK：連接確認
（3）PUBLISH：新發布消息
（4）PUBACK：新發布消息確認，是 QoS 1 給 PUBLISH 消息的回復
（5）PUBREC：QoS 2 消息流的第一部分，表示消息發布已記錄
（6）PUBREL：QoS 2 消息流的第二部分，表示消息發布已釋放
（7）PUBCOMP：QoS 2 消息流的第三部分，表示消息發布完成
（8）SUBSCRIBE：客戶端訂閱某個主題
（9）SUBACK：對於 SUBSCRIBE 消息的確認
（10）UNSUBSCRIBE：客戶端終止訂閱的消息
（11）UNSUBACK：對於 UNSUBSCRIBE 消息的確認
（12）PINGREQ：心跳
（13）PINGRESP：確認心跳
（14）DISCONNECT：客戶端終止連接前優雅地通知 MQTT 代理
其中第 0 和第 15 位是保留位，禁止報文流動。
1.3 DUP flag 標誌位
是用來在保證消息傳輸可靠的，如果設置為 1，則在下面的變長頭部里多加 MessageId，並需要回復確認，保證消息傳輸完成，但不能用於檢測消息重複發送。
1.4 QoS Level 服務質量等級
我們在第一部分講過了。
1.5 Retain
主要用於 PUBLISH（發布態）的消息，表示伺服器要保留這次推送的信息，如果有新的訂閱者出現，就把這消息推送給它。如果不設那麼推送至當前訂閱的就釋放了。
1.6Remaining Length 剩餘長度
表示當前報文剩餘部分的位元組數，包括可變報頭和負載的數據。剩餘長度不包括用於編碼剩餘長度欄位本身的位元組數。但是不是並不是直接保存的，同樣也是可以擴展的，其機制是，前 7 位用於保存長度，後一部用做標識。下表歸納了剩餘欄位的大小。
例如：十進位數 64 會被編碼為一個位元組，數值是 64，十六進位表示為 0x40。十進位數字321（= 65+2*128）被編碼為兩個位元組，最低有效位在前。第一個位元組是 65+128 = 193。注意最高位為 1 表示後面至少還有一個位元組。第二個位元組是 2。同理還可以加第 3 個位元組，最多可以加至第 4 個位元組。故 MQTT 協議最多可以實現 268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)將近 256M 的數據。可謂能伸能縮。
1.7 Variable header 可變報頭
它在固定報頭和負載之間。可變報頭的內容根據報文類型的不同而不同。可變報頭的報文標識符（Packet Identifier）欄位存在於在多個類型的報文里。客戶端和服務端彼此獨立地分配報文標識符。因此，客戶端服務端組合使用相同的報文標識符可以實現並發的消息交換。
可變報頭結構如下：
（1）首先最上面的 8 個位元組是 Protocol Name（協議名），UTF 編碼的字元「MQIsdp」，頭兩個是編碼名提長為 6。
這裡多說一些，接下去的協議多採用這種方式組合，即頭兩個位元組表示下一部分的長，然後後面跟上內容。這裡頭兩個位元組長為 6，下面跟 6 個字元「MQIsdp」。
（2）Protocol Version，協議版本號，v3 也是固定的。
（3）Connect Flag，連接標識，有點像固定頭部的。8 位分別代表不同的標誌。第 1 個位元組保留。
Clean Session，Will flag，Will Qos, Will Retain 都是相對於 CONNECT 消息來說的。
— Clean Session：0表示如果訂閱的客戶機斷線了，那麼要保存其要推送的消息，如果其重新連接時，則將這些消息推送。
— Clean Session：1表示消除，表示客戶機是第一次連接，消息所以以前的連接信息。
— Will Flag，表示如果客戶機在不是在發送 DISCONNECT 消息中斷，比如 I/O 錯誤等，將些置為 1，要求重傳。並且下且的 WillQos 和 WillRetain 也要設置，消息體中的 Topic 和 MessageID 也要設置，就是表示發生了錯誤，要重傳。
— Will Qos，在 CONNECT 非正常情況下設置，一般如果標識了 WillFlag，那麼這個位置也要標識。
— Will RETAIN：同樣在 CONNECT 中，如果標識了 WillFlag，那麼些位也一定要標識。
— Usename flag 和 passwordflag，用來標識是否在消息體中傳遞用戶和密碼，只有標識了，消息體中的用戶名和密碼才用效，只標記密碼而不標記用戶名是不合法的。
（4）Keep Alive，表示響應時間，如果這個時間內，連接或發送操作未完成，則斷開 tcp 連接，表示離線。
（5）Connect Return Code，通常於 CONNACK 消息中，表示返回的連接情況，我可以通過此檢驗連接情況。
1.8 Topic Name
即訂閱消息標識，由於 MQTT 是基於訂閱/發布的消息，那麼這個就是消息訂閱的標識，像新聞客戶端里的訂閱不同的欄目一樣。用於區別消息的推送類別。
主要用於 PUBLISH 和 SUBSCRIBE 中。最大可支持 32767 個字元，即 4 個位元組。
1.9 消息負載 PayLoad
只有 3 種消息有消息負載，即 CONNECT，SUBSCRIBE 和 SUBACK。
（1）CONNECT主要是客戶機的 ClientID，訂閱的 Topic 和 Message 以及用戶名和密碼，其於變長頭部中的 will 是對應的。
（2）SUBSCRIBE包含了一系列的要訂閱的主題以及 QoS。
（3）SUBACK是用伺服器對於 SUBSCRIBE 所申請的主題及 QoS 進行確認和回復。
而 PUBLISH 是消息體中則保存推送的消息，以二進位形式，當然這裡的編輯可自定義。
1.10 Message Identifier
包含於 PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE 和 UNSUBACK 消息中。
其為 16 位字元表示，用於在 Qos 為 1 或 2 時標識 Message 的，保證 Message 傳輸的可靠性。
————————— 我叫隔離帶寬 —————————
2 MQTT 安全機制
關於安全機制的解決方案，需要考慮很多風險。例如：
（1）設備可能會被盜用
（2）客戶端和服務端的靜態數據可能是可訪問的（可能會被修改）
（3）協議行為可能有副作用（如計時器攻擊）
（4）拒絕服務攻擊
（5）通信可能會被攔截、修改、重定向或者泄露
（6）虛假控制報文注入
由於 MQTT 協議通常部署在不安全的通信環境中。在這種情況下，協議實現通常需要提供這些安全機制：
（1）用戶和設備身份認證
（2）服務端資源訪問授權
（3）MQTT 控制報文和內嵌應用數據的完整性校驗
（4）MQTT 控制報文和內嵌應用數據的隱私控制
2.1 MQTT 安全解決方案：安全和認證
（1）輕量級的加密與受限設備
廣泛採用高級加密標準（AES）數據加密標準（DES）。推薦使用為受限的低端設備特別優化過的輕量級加密國際標準 ISO 29192 。
（2）客戶端身份驗證 Authentication of Clients by the Server
CONNECT 報文包含用戶名和密碼欄位。實現可以決定如何使用這些欄位的內容。實現者可以提供自己的身份驗證機制，或者使用外部的認證系統如 LDAP 或 OAuth ，還可以利用操作系統的認證機制。
實現可以明文傳遞認證數據，混淆那些數據，或者不要求任何認證數據，但應該意識到這會增加中間人攻擊和重放攻擊的風險。
在客戶端和服務端之間使用虛擬專用網（VPN）可以確保數據只被授權的客戶端收到。
使用 TLS 時，服務端可以使用客戶端發送的 SSL 證書驗證客戶端的身份。
實現可以允許客戶端通過應用消息給服務端發送憑證用於身份驗證。
（3）客戶端授權 Authorization of Clients by the Server
基於客戶端提供的信息如用戶名、客戶端標識符（ClientId）、客戶端的主機名或 IP 地址，或者身份認證的結果，服務端可以限制對某些服務端資源的訪問。
（4）服務端身份驗證 Authentication of the Server by the Client
由於 MQTT 協議不是雙向信任的，它沒有提供客戶端驗證服務端身份的機制。
但是使用 TLS 時，客戶端可以使用服務端發送的 SSL 證書驗證服務端的身份。從單 IP 多域名提供 MQTT 服務的實現應該考慮 TLS 的 SNI 擴展。SNI 允許客戶端告訴服務端它要連接的服務端主機名。
實現可以允許服務端通過應用消息給客戶端發送憑證用於身份驗證。
在客戶端和服務端之間使用虛擬專用網（VPN）可以確保客戶端連接的是預期的伺服器。
（5）控制報文和應用消息的完整性 Integrity of Application Messages and Control Packets
應用可以在應用消息中單獨包含哈希值。這樣做可以為 PUBLISH 控制報文的網路傳輸和靜態數據提供內容的完整性檢查。
TLS 提供了對網路傳輸的數據做完整性校驗的哈希演算法。
在客戶端和服務端之間使用虛擬專用網（VPN）連接可以在 VPN 覆蓋的網路段提供數據完整性檢查。
（6）控制報文和應用消息的保密性 Privacy of Application Messages and Control Packets
TLS 可以對網路傳輸的數據加密。如果有效的 TLS 密碼組合包含的加密演算法為 NULL，那麼它不會加密數據。要確保客戶端和服務端的保密，應避免使用這些密碼組合。
應用可以單獨加密應用消息的內容。這可以提供應用消息傳輸途中和靜態數據的私密性。但不能給應用消息的其它屬性如主題名加密。
客戶端和服務端實現可以加密存儲靜態數據，例如可以將應用消息作為會話的一部分存儲。
在客戶端和服務端之間使用虛擬專用網（VPN）連接可以在 VPN 覆蓋的網路段保證數據的私密性。
（7）消息傳輸的不可抵賴性 Non-repudiation of message transmission
應用設計者可能需要考慮適當的策略，以實現端到端的不可抵賴性（non-repudiation）。
（8）檢測客戶端和服務端的盜用 Detecting compromise of Clients and Servers
使用 TLS 的客戶端和服務端實現應該能夠確保，初始化 TLS 連接時提供的 SSL 證書是與主機名（客戶端要連接的或服務端將被連接的）關聯的。
使用 TLS 的客戶端和服務端實現，可以選擇提供檢查證書吊銷列表 CRLs 和在線證書狀態協議 OSCP 的功能，拒絕使用被吊銷的證書。
物理部署可以將防篡改硬體與應用消息的特殊數據傳輸結合。例如，一個儀錶可能會內置一個 GPS 以確保沒有在未授權的地區使用。IEEE 安全設備認證 IEEE 802.1AR 就是用於實現這個機制的一個標準，它使用加密綁定標識符驗證設備身份。
（9）檢測異常行為 Detecting abnormal behaviors
服務端實現可以監視客戶端的行為，檢測潛在的安全風險。例如：
— 重複的連接請求
—重複的身份驗證請求
—連接的異常終止
—主題掃描（請求發送或訂閱大量主題）
—發送無法送達的消息（沒有訂閱者的主題）
—客戶端連接但是不發送數據
一旦發現違反安全規則的行為，服務端實現可以斷開客戶端連接。
服務端實現檢測不受歡迎的行為，可以基於 IP 地址或客戶端標識符實現一個動態黑名單列表。
服務部署可以使用網路層次控制（如果可用）實現基於 IP 地址或其它信息的速率限制或黑名單。
關於安全解決方案的話題，我們就不在這裡繼續展開了，各位可以自行深入研究。
後續我們將繼續選取應用較為廣泛的幾個應用層協議，具體來聊，請大家關注！
圖片授權基於：CC0協議
TAG:聽泉Rit |