目錄
第一節 本文探討的內容
第二節 環境搭建
第三節 MQTT控制報文格式
第四節 CONNEC報文
第五節 訂閱和取消訂閱
第六節 接收訊息和發布訊息
第七節 網路除錯助手直連阿里云極速體驗
第一節 本文探討的內容
本文討論MQTT協議底層資料收發的程序,直接通過網路除錯助手與阿里云連接進行實驗驗證,本文不講述阿里云的基礎知識與創建阿里云設備,建議先初步學習MQTT協議API函式的使用和阿里云的簡單操作再看本文,入門教程可參考正點原子推出的“STM32F1 lwIP開發手冊.docx”的第12章,在本文第七節,我書寫了一個網路除錯助手直連阿里云的極速體驗,想快速體驗的小伙伴,可以先看一下第七節哇!
第二節 環境搭建
- 準備阿里云已注冊賬號及設備,得到如圖2.1所示的設備證書

圖2.1 設備證書
2.NetAssist網路除錯助手 V5.0,下載地址如下,軟體啟動界面如圖2.2所示,
下載地址:http://www.cmsoft.cn/resource/102.html

圖2.2 網路除錯助手啟動界面
3.我們現有以下資訊(獲取方式參考“STM32F1 lwIP開發手冊.docx”的第12章):
服務器地址:a1Dm4VEK8BR.iot-as-mqtt.cn-shanghai.aliyuncs.com
埠:1883
客戶端ID:aliyun_dev|securemode=3,signmethod=hmacsha1|
用戶名:aliyun_dev&a1Dm4VEK8BR
計算登錄密碼:clientIdaliyun_devdeviceNamealiyun_devproductKeya1Dm4VEK8BR
Password::8bdc84f9963105d65bdc79b6cb3ac0cec9ce1aa9
("Password "為hmacsha1加密后的密碼,加密網站為:http://encode.chahuo.com 獲取方式如圖2.3所示,)
注意!由于你注冊的阿里云和我的設備證書是不一樣的,故得到的資訊也不一樣!

圖2.3 網站上使用hmacsha1加密得到Password
第三節 MQTT控制報文格式
為了進一步理解MQTT底層的原理,我們要先了解MTQQ控制報文的格式,
MQTT控制報文由固定報頭(Fixed header)、可變報頭(Variable header)、有效載荷(Payload)三部分組成,
首先講解MQTT固定報文,該報文是所有控制報文都包含的,固定報文至少2位元組(byte1一定要有,剩余長度至少要一個位元組表示),最多為5位元組(因為剩余長度最多4位元組),其格式如表3.1所示,MQTT控制報文型別如圖3.2所示,控制報文標志如圖3.3所示,根據下面的描述,我們可以得知不同型別報文的固定報頭內容,
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| byte 1 | MQTT 控制報文的型別 | 用于指定控制報文型別的標志位 | ||||||
| byte 2… | 剩余長度 | |||||||
表3.1 固定報文格式
| 名字 | 值 | 報文流動方向 | 描述 |
| Reserved | 0 | 禁止 | 保留 |
| CONNECT | 1 | 客戶端到服務端 | 客戶端請求連接服務端 |
| CONNACK | 2 | 服務端到客戶端 | 連接報文確認 |
| PUBLISH | 3 | 兩個方向都允許 | 發布訊息 |
| PUBACK | 4 | 兩個方向都允許 | QoS 1 訊息發布收到確認 |
| PUBREC | 5 | 兩個方向都允許 | 發布收到(保證交付第一步) |
| PUBREL | 6 | 兩個方向都允許 | 發布釋放(保證交付第二步) |
| PUBCOMP | 7 | 兩個方向都允許 | QoS 2 訊息發布完成(保證互動第三步) |
| SUBSCRIBE | 8 | 客戶端到服務端 | 客戶端訂閱請求 |
| SUBACK | 9 | 服務端到客戶端 | 訂閱請求報文確認 |
| UNSUBSCRIBE | 10 | 客戶端到服務端 | 客戶端取消訂閱請求 |
| UNSUBACK | 11 | 服務端到客戶端 | 取消訂閱報文確認 |
| PINGREQ | 12 | 客戶端到服務端 | 心跳請求 |
| PINGRESP | 13 | 服務端到客戶端 | 心跳回應 |
| DISCONNECT | 14 | 客戶端到服務端 | 客戶端斷開連接 |
| Reserved | 15 | 禁止 | 保留 |
圖3.2 MQTT控制報文型別
| 控制報文 | 固定報頭標志 | Bit 3 | Bit 2 | Bit 1 | Bit 0 |
| CONNECT | Reserved | 0 | 0 | 0 | 0 |
| CONNACK | Reserved | 0 | 0 | 0 | 0 |
| PUBLISH | Used in MQTT 3.1.1 | DUP1 | QoS2 | QoS2 | RETAIN3 |
| PUBACK | Reserved | 0 | 0 | 0 | 0 |
| PUBREC | Reserved | 0 | 0 | 0 | 0 |
| PUBREL | Reserved | 0 | 0 | 1 | 0 |
| PUBCOMP | Reserved | 0 | 0 | 0 | 0 |
| SUBSCRIBE | Reserved | 0 | 0 | 1 | 0 |
| SUBACK | Reserved | 0 | 0 | 0 | 0 |
| UNSUBSCRIBE | Reserved | 0 | 0 | 1 | 0 |
| UNSUBACK | Reserved | 0 | 0 | 0 | 0 |
| PINGREQ | Reserved | 0 | 0 | 0 | 0 |
| PINGRESP | Reserved | 0 | 0 | 0 | 0 |
| DISCONNECT | Reserved | 0 | 0 | 0 | 0 |
圖3.3 MQTT控制報文標志
報文的第二部分是可變報頭,MQTT 控制報文包含一個可變報頭部分,它在固定報頭和可變負載之間,可變報頭的內容根據報文型別的不同而不同,此處我們在具體的報文中作講解,
報文的最后一個部分是可變負載,通俗來講,這部分就是應用訊息,因此也是具體的報文再作講解,
下面簡介MQTT底層中需要了解的知識:
1.UTF-8編碼字串
MQTT的報文的格式是UTF-8編碼的,因此需要了解該編碼的格式才能進行MQTT通訊,
UTF-8編碼格式的要求為:每一個字串都有一個兩位元組的長度欄位作為前綴,它給出這個字串 UTF-8 編碼的位元組數,因此,可以傳送的 UTF-8 編碼的字串大小有一個限制,不能超過65535 位元組,
例如字串“123456”的UTF-8編碼,可以將“123456”轉換成ASCII碼表示:31 32 33 34 35 36(十六進制),位元組數大小為:6,因此需要添加前綴 0x00,0x06,綜合原字串ASCII碼可得到該字串最終的UTF-8編碼為00 06 31 32 33 34 35 36(十六進制),
2.剩余長度
剩余長度(Remaining Length)表示當前報文剩余部分的位元組數,包括可變報頭和負載的資料,剩余長度不包括用于編碼剩余長度欄位本身的位元組數,
剩余長度欄位使用一個變長度編碼方案,對小于 128 的值它使用單位元組編碼,更大的值按下面的方式處理,低 7 位有效位用于編碼資料,最高有效位用于指示是否有更多的位元組,因此每個位元組可以編碼 128 個數值和一個 延續位( continuation bit ) ,剩余長度欄位最大 4 個位元組,MQTT中剩余長度為低位元組在前,高位元組在后,例如(x為剩余長度,所有數都為十六進制) x 01 02 03 04 05 06,則剩余長度為后面的位元組數,由于x<128,則x=06,再例如 x 01 02 03 …(等等) c8,則剩余長度為后面位元組數,但c8換算成十進制為200>128,則x=01 c8,但注意,在MQTT中剩余長度為低位元組在前,高位元組在后,x應該為 c8 01,
3.服務質量QOS
MQTT 按照這里定義的服務質量 (QoS) 等級分發應用訊息,QOS等級分為三個等級,
QoS 0: 最多分發一次,訊息的分發依賴于底層網路的能力,接收者不會發送回應,發送者也不會重試,
QoS 1: 至少分發一次,服務質量確保訊息至少送達一次,
QoS 2: 僅僅分發一次,這是最高等級的服務質量,訊息丟失和重復都是不可接受的,使用這個服務質量等級會有額外的開銷,
本文是為了理解MQTT低層的作業原理,規定本文的所有QOS等級都為0,
4.JSON 創建物件格式
JSON 物件使用在大括號中書寫,物件可以包含多個 key/value(鍵/值)對兩個"鍵:值"對以逗號分隔,例如,定義名為people物件:
"people":{
"ID": 1001,
"name": "張三",
"age": 24
}
或
var people={
"ID": 1001,
"name": "張三",
"age": 24
}
key必須是字串,value可以是合法的JSON資料型別(字串,數字,物件,陣列,布林值或者null);key和value中適用冒號(:)分割;每個鍵值對適用逗號(,)分割,
JSON 是一種純資料格式,它只包含屬性,沒有方法,
6.字串與ASCII碼之間的轉換和獲取字符長度的簡易方法
字符和ASCII的關系如圖3.4所示,例如要知道字符’1’的ASCII碼值可查找字元‘1’,然后對應行的左邊的值就是ASCII碼值,查找圖2.4可知:字符‘1‘的ASCII碼值為0x31或49(十進制),字串的ASCII碼值是所有字符的ASCII碼值組合,例如字串“123456”的ASCII值為0x31 0x32 0x33 0x34 0x35 0x36,相反操作可以獲取對應ASCII碼值對應的字符,例如ASCII碼值為0x31,表示的字符為‘1’,
但是遇到字符串比較長的情況,查表找字串的值較為繁瑣,可通過網路除錯助手進行轉換,如圖3.5所示,我們使用了127回播地址進行數值的回傳,接收區設定為HEX(意為16進制顯示),發送區選擇ASCII發送,我們發送字串后,將會回傳對應的ASCII碼值,如圖3.6所示將發送區設定為HEX(意為16進制顯示)發送,接收區設定為ASCII,便可將ASCII碼值轉換為字串,值得注意的是網路除錯助手的右下角還會顯示發送(TX)與接收(RX)的位元組數,右下角的復位計數可以重新計算發送、接收區的字符總數,

圖3.4 字符和ASCII碼值的關系

圖3.5 利用網路除錯助手獲取字串的ASCII碼值

圖3.5 利用網路除錯助手獲取ASCII碼值對應的字串
第四節 CONNEC報文
客戶端到服務端的網路連接建立后,客戶端發送給服務端的第一個報文必須是 CONNECT報文,服務端收到CONNECT報文后,將發送 CONNACK 報文回應從客戶端收到的 CONNECT 報文,服務端發送給客戶端的第一個報文也必須是CONNACK報文,下面講解CONNECT報文的內容,
CONNEC固定報頭可由第三節得出,為0x10+(剩余長度),
CONNEC可變報頭由協議名、協議級別、連接標志、保持連接四部分組成,協議名為字串“MQTT”,由于規定為6位元組,故其UTF-8編碼格式的表示為:00 04 4D 51 54 54(十六進制),協議級別為4,即0x04,連接標志由1個位元組組成,其含義表4.1所示,我們需要驗證User Name、Password,并且Clean Session,這樣服務器每次session 都要重新建立,這也是大多數的場景使用情況,因此連接標志配置為0xC2,保持連接由兩個位元組組成,表示服務器和客戶端保持連接的時間,此處設定為100s,也就是0x0064,綜上所述,我們配置的CONNEC可變報文為00 04 4D 51 54 54 04 C2 00 64(十六進制),
CONNEC報文的可變負載由三個字串組成,分別為客戶端ID、用戶名、Password組成,此處注意字串需要使用UTF-8格式的,
綜合上面CONNEC報文的三大部分,我們計算出剩余長度為0x7A,可以最終得到CONNEC報文發送的內容為:10 7A 00 04 4D 51 54 54 04 C2 00 64 00 2c 63 6F 61 70 5F 74 65 78 74 31 7C 73 65 63 75 72 65 6D 6F 64 65 3D 33 2C 73 69 67 6E 6D 65 74 68 6F 64 3D 68 6D 61 63 73 68 61 31 7C 00 16 63 6F 61 70 5F 74 65 78 74 31 26 61 31 31 36 6E 37 4D 77 53 78 67 00 28 61 32 38 31 62 38 38 38 63 66 66 64 30 37 63 35 34 30 32 31 36 31 37 64 30 39 63 37 63 65 37 61 35 34 37 33 65 39 38 64(十六進制,不同設備的CONNEC報文負載是不同的),
我們實驗驗證上訴理論的可行性,如圖4.2所示,接收和發送設定都設定為HEX,將服務器地址和埠輸入進去,然后在發送區發送CONNEC報文,此時阿里云端顯示已經連接,并且服務區回傳資料:20 02 00 00(十六進制),這串資料為CONNACK – 確認連接請求報文,其固定報頭為0x20、0x02,其中0x02表示剩余長度,后面兩個資料0x00、0x00為可變報文,CONNACK報文無可變負載報文,第三個資料0x00為確定連接標志,這個在MQTT中固定為0x00,第四個資料含義如表4.3所示,我們接收到的第四個資料為0x00就表示連接已接受了,
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| User Name Flag | Password Flag | Will Retain | Will QoS | Will Flag | Clean Session | Reserved | ||
| byte 8 | X | X | X | X | X | X | X | 0 |
表4.1 連接標志含義

圖4.2 實驗驗證
| 值 | 回傳碼回應 | 描述 |
| 0 | 0x00 連接已接受 | 連接已被服務端接受 |
| 1 | 0x01 連接已拒絕,不支持的協議版本 | 服務端不支持客戶端請求的 MQTT 協議級別 |
| 2 | 0x02 連接已拒絕,不合格的客戶端識別符號 | 客戶端識別符號是正確的 UTF-8 編碼,但服務端不允許使用 |
| 3 | 0x03 連接已拒絕,服務端不可用 | 網路連接已建立,但 MQTT 服務不可用 |
| 4 | 0x04 連接已拒絕,無效的用戶名或密碼 | 用戶名或密碼的資料格式無效 |
表4.3 連接回傳碼的值
第五節 訂閱和取消訂閱
首先講解一下如何訂閱主題,客戶端向服務端發送 SUBSCRIBE 報文用于創建訂閱,每個訂閱注冊客戶端關心的主題,然后服務器將會回傳一個SUBACK 報文,用于確認它已收到并且正在處理 SUBSCRIBE 報文,
SUBSCRIBE固定報頭可由第三節得出,為0x82+(剩余長度),
SUBSCRIBE可變報頭是客戶端識別符號,此處我們使用的識別符號號為0x00 0x0a,
SUBSCRIBE報文的可變負載由主題過濾器(UTF-8字串)和服務質量等級組成,我們的服務質量等級為0,主題過濾器其實就是Toic串列中的主題,我選取我阿里云上的主題“/a1Dm4VEK8BR/aliyun_dev/user/LED”,綜合可得SUBSCRIBE報文的可變負載的可變負載內容為00 20 2F 61 31 44 6D 34 56 45 4B 38 42 52 2F 61 6C 69 79 75 6E 5F 64 65 76 2F 75 73 65 72 2F 4C 45 44 00(十六進制)
綜上,我們的SUBSCRIBE 報文的內容為82 25 00 0a 00 20 2F 61 31 44 6D 34 56 45 4B 38 42 52 2F 61 6C 69 79 75 6E 5F 64 65 76 2F 75 73 65 72 2F 4C 45 44 00(十六進制),如圖4.1,我們連接阿里云服務器后,再發送SUBSCRIBE 報文的內容,
發送上面的訊息后,我們將會收到訂閱確認報文—SUBACK報文,該報文的固定報文為0x90 +可變長度(大小一般固定為03),可變報文為客戶端發送的識別符號,有效負載為一個位元組,內容和含義為:0x00 - 最大 QoS 0;0x01 - 成功 – 最大 QoS 1;0x02 - 成功 – 最大 QoS 2;0x80 - Failure 失敗,如圖4.1,我們的回傳值為90 03 00 0A 01,訂閱成功!這里值得注意的是,我們雖然設定了QoS為0,但是SUBACK報文的有效負載為01,這并不是服務器出問題,而是我們成功后,等級應該會默認設定為最大QoS 1,
以上是訂閱主題的操作,那么如果我們要取消訂閱,就要使用UNSUBSCRIBE 報文,其格式和SUBSCRIBE 報文類似,當我們發送了UNSUBSCRIBE 報文后,服務器也會回傳UNSUBACK 報文給客戶端用于確認收到 UNSUBSCRIBE 報文,
下面講解一下UNSUBSCRIBE 報文,該報文的固定報頭由第三節得出,為0x a2+(剩余長度),可變報頭為SUBSCRIBE可變報頭的客戶端識別符號,我的UNSUBSCRIBE可變報頭為0x00 0x0a,UNSUBSCRIBE 報文的有效載荷由要取消訂閱的主題和QOS等級組成,當QOS等級=0時,可以省略QOS等級,我們要取消訂閱的主題為“/a1Dm4VEK8BR/aliyun_dev/user/LED”,綜合本段的內容,我們可以得出完整的UNSUBSCRIBE 報文為:a2 24 00 0a 00 20 2F 61 31 44 6D 34 56 45 4B 38 42 52 2F 61 6C 69 79 75 6E 5F 64 65 76 2F 75 73 65 72 2F 4C 45 44(十六進制)
我們連接阿里云服務器,發送上述的UNSUBSCRIBE 報文,如圖4.1,服務端回傳了 UNSUBACK 報文給客戶端用于確認收到 UNSUBSCRIBE 報文,從圖中可見到回傳值為0xB0,0x02,0x00,0x0a,如果掌握了前述報文的內容,這個報文并不難分析,資料0xB0,0x02為固定報頭,資料0x00,0x0a為可變報頭,內容與SUBSCRIBE可變報頭的客戶端識別符號一樣,UNSUBACK 報文無有效負載部分,如圖5.1所示,我們成功取消了訂閱,

圖5.1 訂閱和取消訂閱
第六節 接收訊息和發布訊息
經過前面幾節的學習,我們已經初步了解MQTT底層的作業原理,本節先講解設備如何接收阿里云的訊息再講解如何發布訊息,我們在網路除錯助手連接阿里云如圖6.1所示,然后按照圖示的六個步驟發送訊息給網路助手,我們在網路除錯助手的回傳資訊分析,可知固定報頭為30 ,剩余長度為0x9b,此處不做累述,固定報頭的格式可參考第一節,可變報頭中,將00 36 2F 73 79 73 2F 61 31 44 6D 34 56 45 4B 38 42 52 2F 61 6C 69 79 75 6E 5F 64 65 76 2F 74 68 69 6E 67 2F 73 65 72 76 69 63 65 2F 70 72 6F 70 65 72 74 79 2F 73 65 74(十六進制,UTF-8編碼)翻譯后的意思為“/sys/a1Dm4VEK8BR/aliyun_dev/thing/service/property/set”,可以判斷可變報頭的內容為Topic名稱,剩下的資料即為有效載荷:7B 22 6D 65 74 68 6F 64 22 3A 22 74 68 69 6E 67 2E 73 65 72 76 69 63 65 2E 70 72 6F 70 65 72 74 79 2E 73 65 74 22 2C 22 69 64 22 3A 22 37 35 31 34 31 33 35 37 30 22 2C 22 70 61 72 61 6D 73 22 3A 7B 22 4C 45 44 53 77 69 74 63 68 22 3A 30 7D 2C 22 76 65 72 73 69 6F 6E 22 3A 22 31 2E 30 2E 30 22 7D(十六進制,ASCII編碼),翻譯后的意思如下:
“{"method":"thing.service.property.set","id":"751413570","params":{"LEDSwitch":0},"version":"1.0.0"}”這個明顯為JSON運算式,JSON格式參考第三節“MQTT底層中需要了解的知識”,
綜上所述,我們可以MQTT中發布訊息的格式為:
①固定報頭:0x30+剩余長度
②可變報頭:Topic名稱(UTF-8編碼)
③報文負載:應用訊息(JSON格式,ASCII編碼)
下面我們按照上面的格式也嘗試發訊息給阿里云,我們先創建好了阿里云的設備LEDSwitch,并且打開自定義功能并發布上線(此處可參考正點原子推出的“STM32F1 lwIP開發手冊.docx”的第十二章),我們發布訊息給物理模型,需要訂閱主題“/sys/(ProductKey)/ (DeviceName)/thing/event/property/set”(”ProductKey”和“DeviceName”根據自己設備填寫,我最終訂閱的主題內容為“/sys/a1Dm4VEK8BR/aliyun_dev/thing/event/property/set”,訂閱方法參考本文第五節),然后在發送訊息中,我們寫入如下內容:
①固定報頭0x30+剩余長度
②可變報頭:“/sys/a1Dm4VEK8BR/aliyun_dev/thing/event/property/post” (UTF-8編碼)
③報文負載如下:
{"method":"thing.event.property.post","id":"00000001","params":{"LEDSwitch":0},"version":"1.0.0"},注意此處method中的內容不同于阿里云服務器發送訊息的method內容,ID我們填寫00000001,內容是使LED的狀態為0(也可以設定為1),版本號填寫“1.0.0”便可,
綜上3點我們最終的報文為:30 98 01 00 35 2F 73 79 73 2F 61 31 44 6D 34 56 45 4B 38 42 52 2F 61 6C 69 79 75 6E 5F 64 65 76 2F 74 68 69 6E 67 2F 65 76 65 6E 74 2F 70 72 6F 70 65 72 74 79 2F 70 6F 73 74 7B 22 6D 65 74 68 6F 64 22 3A 22 74 68 69 6E 67 2E 65 76 65 6E 74 2E 70 72 6F 70 65 72 74 79 2E 70 6F 73 74 22 2C 22 69 64 22 3A 22 30 30 30 30 30 30 30 31 22 2C 22 70 61 72 61 6D 73 22 3A 7B 22 4C 45 44 53 77 69 74 63 68 22 3A 30 7D 2C 22 76 65 72 73 69 6F 6E 22 3A 22 31 2E 30 2E 30 22 7D
連接阿里云后,我們發送上述最終報文,結果如圖6.2所示,我們成功使LEDSwitch的狀態變為0,

圖6.1 網路除錯助手接收阿里云的訊息

圖6.2 網路除錯助手向阿里云發送訊息
第七節 網路除錯助手直連阿里云極速體驗
第一步,如圖7.1打開網路除錯助手 V5.0,選擇協議型別為“TCP Client”,接收區設定為HEX,發送區設定為HEX,將遠程主機地址填寫為“a1Dm4VEK8BR.iot-as-mqtt.cn-shanghai.aliyuncs.com”,埠填寫“1883”,在點擊連接前先將資料“10 7A 00 04 4D 51 54 54 04 C2 00 64 00 2c 61 6C 69 79 75 6E 5F 64 65 76 7C 73 65 63 75 72 65 6D 6F 64 65 3D 33 2C 73 69 67 6E 6D 65 74 68 6F 64 3D 68 6D 61 63 73 68 61 31 7C 00 16 61 6C 69 79 75 6E 5F 64 65 76 26 61 31 44 6D 34 56 45 4B 38 42 52 00 28 38 62 64 63 38 34 66 39 39 36 33 31 30 35 64 36 35 62 64 63 37 39 62 36 63 62 33 61 63 30 63 65 63 39 63 65 31 61 61 39”復制入資料發送框!然后點擊連接,再點擊發送,云端回傳“20 02 00 00”!表示阿里云連接成功了!注意!100秒內將第二步的資料發給阿里云,否則阿里云將會自動斷開連接的,
第二步,我們嘗試在阿里云訂閱,發送和接收設定一定要為HEX,發送的資料為“82 25 00 0a 00 20 2F 61 31 44 6D 34 56 45 4B 38 42 52 2F 61 6C 69 79 75 6E 5F 64 65 76 2F 75 73 65 72 2F 4C 45 44 00”,如圖7.2所示我們點擊發送資料,云端回傳“90 03 00 0A 01”!表示訂閱成功了!注意!100秒內將第三步的資料發給阿里云,否則阿里云將會自動斷開連接的,
第三步,我們嘗試取消第二步的訂閱,發送和接收設定一定要為HEX,發送的資料為“a2 24 00 0a 00 20 2F 61 31 44 6D 34 56 45 4B 38 42 52 2F 61 6C 69 79 75 6E 5F 64 65 76 2F 75 73 65 72 2F 4C 45 44”,如圖7.3所示我們點擊發送資料,云端回傳“B0 02 00 0A”,表示我們取消了第二步的訂閱!注意!100秒內將第四步的資料發給阿里云,否則阿里云將會自動斷開連接的,
第四步,我們嘗試發送訊息給阿里云,發送和接收設定一定要為HEX,發送的資料為“30 98 01 00 35 2F 73 79 73 2F 61 31 44 6D 34 56 45 4B 38 42 52 2F 61 6C 69 79 75 6E 5F 64 65 76 2F 74 68 69 6E 67 2F 65 76 65 6E 74 2F 70 72 6F 70 65 72 74 79 2F 70 6F 73 74 7B 22 6D 65 74 68 6F 64 22 3A 22 74 68 69 6E 67 2E 65 76 65 6E 74 2E 70 72 6F 70 65 72 74 79 2E 70 6F 73 74 22 2C 22 69 64 22 3A 22 30 30 30 30 30 30 30 31 22 2C 22 70 61 72 61 6D 73 22 3A 7B 22 4C 45 44 53 77 69 74 63 68 22 3A 31 7D 2C 22 76 65 72 73 69 6F 6E 22 3A 22 31 2E 30 2E 30 22 7D”如圖7.4所示發送成功!(阿里云不會回傳資料的)
至此,極速體驗完成,如果想知道上述發送資料的含義和回傳資料的含義,或者連接自己的阿里云,請看本文其它章節,上述操作的阿里云是作者本人的阿里云,將會長期有效,但并不一定永久有效的!

圖7.1 連接阿里云

圖7.2 阿里云訂閱

圖7.3 取消阿里云訂閱

圖7.4 發送訊息給阿里云
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/293811.html
標籤:其他
