消息觸達(dá)能力是物聯(lián)網(wǎng)(internet ofthings, IOT)的重要支撐，而物聯(lián)網(wǎng)很多技術(shù)都源于移動(dòng)互聯(lián)網(wǎng)。本文將闡述移動(dòng)互聯(lián)網(wǎng)消息推送技術(shù)在物聯(lián)網(wǎng)中的應(yīng)用和演進(jìn)。

一、物聯(lián)網(wǎng)架構(gòu)和關(guān)鍵技術(shù)

從開發(fā)的角度，無(wú)線接入是物聯(lián)網(wǎng)設(shè)備端的核心技術(shù)，身份設(shè)備管理和消息推送技術(shù)是物聯(lián)網(wǎng)云端的核心技術(shù)。而從場(chǎng)景體驗(yàn)的角度，除了前者，還要包括手機(jī)的前端開發(fā)技術(shù)。

IP互聯(lián)架構(gòu)已是物聯(lián)網(wǎng)的事實(shí)標(biāo)準(zhǔn)(有關(guān)物聯(lián)網(wǎng)TCP/IP層關(guān)鍵技術(shù)將另文闡述，敬請(qǐng)關(guān)注)。本文所講的消息推送技術(shù)是基于TCP/IP協(xié)議的應(yīng)用層協(xié)議技術(shù)。

我們先進(jìn)一步抽象基于IP架構(gòu)的物聯(lián)網(wǎng)組成，如下圖(忽略internet和路由等基礎(chǔ)技術(shù))：

可見，核心組成就是物聯(lián)設(shè)備、網(wǎng)關(guān)和云端。物聯(lián)設(shè)備分為兩類，一類是其自身天然支持TCP/IP而能直接接入物聯(lián)網(wǎng)，如wifi、GPRS/3G/4G(當(dāng)然，還有即將到來(lái)的5G)等設(shè)備;另一類是其未能支持IP協(xié)議而需要網(wǎng)關(guān)(協(xié)議轉(zhuǎn)換)來(lái)接入物聯(lián)網(wǎng)，如Zigbee、藍(lán)牙等設(shè)備。對(duì)于藍(lán)牙設(shè)備而言，手機(jī)其實(shí)是一個(gè)網(wǎng)關(guān)。

手機(jī)通過(guò)自身的藍(lán)牙跟外設(shè)藍(lán)牙設(shè)備通信，并將消息通過(guò)手機(jī)的wifi或者3G/4G模塊與云服務(wù)端通信。

從場(chǎng)景的角度來(lái)分析，物聯(lián)網(wǎng)最終是給人類服務(wù)的，而手機(jī)是人類體驗(yàn)的最直接入口。因此在上圖中可以單獨(dú)添加手機(jī)組成部分，并將其與一般意義上的網(wǎng)關(guān)區(qū)分出來(lái)。這樣物聯(lián)網(wǎng)核心組成就是：設(shè)備端—網(wǎng)關(guān)—云端—手機(jī)。

從應(yīng)用層開發(fā)技術(shù)的角度來(lái)看，物聯(lián)網(wǎng)應(yīng)用是基于TCP/IP架構(gòu)建立，在屏蔽底層的網(wǎng)關(guān)協(xié)議轉(zhuǎn)換的基礎(chǔ)上，物聯(lián)網(wǎng)應(yīng)用的組成部分就是：設(shè)備端—云端—手機(jī)。

OK，有了以上的介紹，我們就從物聯(lián)網(wǎng)應(yīng)用的角度來(lái)分析設(shè)備、云端、手機(jī)直接的消息推送技術(shù)，它包括云端和設(shè)備端的雙向通信技術(shù)、手機(jī)和云端的雙向通信技術(shù)。

二、移動(dòng)互聯(lián)網(wǎng)通信模式

互聯(lián)網(wǎng)有B/S和C/S兩種通信模式。在移動(dòng)互聯(lián)網(wǎng)領(lǐng)域，APP是以C/S的方式以client的角色跟服務(wù)器server進(jìn)行通信;而微信是一個(gè)超級(jí)APP，其是通過(guò)內(nèi)置瀏覽器讓用戶進(jìn)行H5編程以獲得操控硬件設(shè)備的能力，因此微信硬件平臺(tái)的通信模塊是B/S模式。

移動(dòng)互聯(lián)網(wǎng)B/S技術(shù)跟傳統(tǒng)互聯(lián)網(wǎng)沒有區(qū)別，微信內(nèi)置瀏覽器支持H5，因此可以獲得很好的平臺(tái)擴(kuò)展性。我們近期重點(diǎn)關(guān)注基于微信硬件平臺(tái)的物聯(lián)網(wǎng)，因此就圍繞B/S模式的消息推送技術(shù)講述其演進(jìn)。

HTTP協(xié)議是B/S的基礎(chǔ)，HTTP有GET和POST兩種方式。

三、消息推送技術(shù)演進(jìn)

1. HTTP單向通信

瀏覽器使用HTML文本標(biāo)記語(yǔ)言，即瀏覽器通過(guò)HTTP協(xié)議向服務(wù)器發(fā)起請(qǐng)求(請(qǐng)求內(nèi)容包括URL，即我們常說(shuō)的網(wǎng)址)，服務(wù)器將URL對(duì)應(yīng)的HTML內(nèi)容通過(guò)HTTP協(xié)議作為響應(yīng)傳送回給瀏覽器。

手機(jī)端：微信端因?yàn)橛袃?nèi)置瀏覽器，其天然支持前端頁(yè)面。

云端對(duì)手機(jī)端推送：云端使用JSP/PHP等技術(shù)開發(fā)設(shè)計(jì)前端網(wǎng)頁(yè)和簡(jiǎn)單的邏輯即可。

設(shè)備端：設(shè)備端上線時(shí)或者訪問服務(wù)端參數(shù)等內(nèi)容時(shí)需要模擬HTTP協(xié)議(C語(yǔ)言)向服務(wù)器發(fā)起請(qǐng)求，而請(qǐng)求的格式一般不使用HTML，而是使用較為簡(jiǎn)單的XML或者JSON協(xié)議格式。

云端對(duì)設(shè)備端推送：云端使用HttpServlet(即使用http協(xié)議的servlet)對(duì)設(shè)備的HTTP請(qǐng)求進(jìn)行響應(yīng)，回復(fù)XML或者JSON格式的消息。

缺點(diǎn)：這種方式通信方式的特點(diǎn)就是一請(qǐng)求一響應(yīng)，總是要客戶端向服務(wù)器發(fā)出請(qǐng)求，服務(wù)器才給予響應(yīng)。服務(wù)器從來(lái)都不會(huì)主動(dòng)給客戶端發(fā)消息，而且在客戶端發(fā)出請(qǐng)求后，服務(wù)器也只是回復(fù)一次。這種HTTP單向通信方式在互聯(lián)網(wǎng)領(lǐng)域發(fā)揮巨大的作用，就是服務(wù)器端可以是無(wú)狀態(tài)的，極大地簡(jiǎn)化了服務(wù)器的服務(wù)流程，提高效率。但在物聯(lián)網(wǎng)領(lǐng)域，我們要求的是雙向的通信能力。服務(wù)端要能主動(dòng)給設(shè)備端或者手機(jī)發(fā)出消息。

在這種模式下，我們?cè)趺醋鲭p向通信呢?唯一的做法就是客戶端不斷地發(fā)出請(qǐng)求(或者周期性)，服務(wù)器不斷地給予回復(fù)。這種模式下的缺點(diǎn)顯而易見：

是網(wǎng)絡(luò)負(fù)載重，服務(wù)器每次響應(yīng)后都會(huì)關(guān)閉連接，所以每次通信都得重新握手。HTTP協(xié)議的頭內(nèi)容的長(zhǎng)度可不小。

是實(shí)時(shí)性差。一般設(shè)備端都是周期性地輪詢服務(wù)器是否有新的消息，輪詢的方式是不能獲得好的實(shí)時(shí)性的。

瀏覽器端每次發(fā)出請(qǐng)求是以HTML全部?jī)?nèi)容來(lái)響應(yīng)的，消息長(zhǎng)度過(guò)大，在這種情況下，會(huì)發(fā)現(xiàn)瀏覽器頁(yè)面不斷地刷新。

2. Ajax輪詢

Ajax技術(shù)是瀏覽器支持的一種Java技術(shù)。其能夠局部改善用戶體驗(yàn)技術(shù)，讓用戶在不察覺瀏覽器頁(yè)面刷新的情況向服務(wù)器發(fā)出請(qǐng)求，并獲得響應(yīng)。其原理是：

微信瀏覽器發(fā)出URL頁(yè)面請(qǐng)求，服務(wù)器響應(yīng)HTML頁(yè)面內(nèi)容。

HTML頁(yè)面使用js調(diào)用來(lái)向服務(wù)器發(fā)出異步通信請(qǐng)求。

服務(wù)器響應(yīng)XML格式數(shù)據(jù)給瀏覽器頁(yè)面。

HTML頁(yè)面使用DOM模型來(lái)動(dòng)態(tài)刷新頁(yè)面元素。

Ajax技術(shù)是微信硬件平臺(tái)框架中推薦的頁(yè)面交互技術(shù)，但其本質(zhì)還是遵守HTTP單向通信的規(guī)則，只是頁(yè)面交互時(shí)不需要刷新整個(gè)頁(yè)面。其雙向通信實(shí)時(shí)性問題依然未能解決。

3. Websocket

Websocket是HTML5支持的一種新的協(xié)議，它能夠真正支持瀏覽器和服務(wù)器之間進(jìn)行雙向通信。Tomcat7及以上版本也已經(jīng)支持Websocket API。

為了能夠兼容瀏覽器HTTP協(xié)議，Websocket規(guī)定在第一次發(fā)起請(qǐng)求時(shí)依然要發(fā)出符合HTTP協(xié)議規(guī)范的Header，但其Connection域的值是Upgrade，并增加Upgrade域，值是socket，即告知服務(wù)器，即將建立的通信是Websocket雙向通信。服務(wù)器如果接受，會(huì)返回101給客戶端進(jìn)行協(xié)議切換。

接下來(lái)的通信將不再以HTTP作為傳輸協(xié)議，而是使用Websocket規(guī)定的數(shù)據(jù)格式進(jìn)行通信，其分為控制幀和數(shù)據(jù)幀?？刂茙前l(fā)出心跳幀(ping)，而服務(wù)器響應(yīng)pong，還有結(jié)束幀;數(shù)據(jù)幀就是真實(shí)數(shù)據(jù)格式，其格式頭只有6個(gè)字節(jié)(2個(gè)字節(jié)頭和4個(gè)字節(jié)的掩碼)，后面就是真實(shí)的數(shù)據(jù)(經(jīng)過(guò)掩碼轉(zhuǎn)換)。比HTTP格式頭的長(zhǎng)度要小多了。

客戶端和服務(wù)器之間是一直保持連接，直到close，當(dāng)前期間要發(fā)發(fā)2個(gè)字節(jié)的3字節(jié)的ping幀。

可見Websocket比ajax有了極大的改進(jìn)。其不僅省掉經(jīng)常要連接握手，還簡(jiǎn)化的協(xié)議的格式，最重要的是實(shí)時(shí)性得到保證，因?yàn)殡p方是真正的全雙工通信。

微信瀏覽器客戶端支持Websocket，服務(wù)器使用Tomcat7以上的WebsocketServlet類，設(shè)備端要根據(jù)Websocket協(xié)議用C語(yǔ)言來(lái)模擬通信。

我們?cè)谟迷O(shè)備端模擬Websocket通信協(xié)議時(shí)一般會(huì)先看協(xié)議，再用HttpWatch等工具來(lái)抓包，抓到的頭是GET ws://ip:port/path，如果在C語(yǔ)言也是這樣模擬發(fā)包則會(huì)報(bào)400 bad request。因?yàn)镃語(yǔ)言利用socket建立通信時(shí)已經(jīng)利用了IP和port了，其發(fā)的第一個(gè)包的頭是GET/path即可，不能在其前面加上ws://ip:port/。

4. MQTT

以上的分析都是將移動(dòng)互聯(lián)網(wǎng)的技術(shù)運(yùn)用到物聯(lián)網(wǎng)，其都有一個(gè)特定就是建立連接時(shí)會(huì)傳送URL地址，由兩個(gè)角色是客戶端和服務(wù)器，這種架構(gòu)我們一般稱為是RESTful架構(gòu)(另外，還有SOAP 面向應(yīng)用的web services架構(gòu))。RESTful架構(gòu)在互聯(lián)網(wǎng)得到越來(lái)越廣泛的運(yùn)用，但物聯(lián)網(wǎng)除了互聯(lián)之外，還有其獨(dú)有的特征，就是其終端設(shè)備的資源有限、低功耗運(yùn)用場(chǎng)景、網(wǎng)絡(luò)連接環(huán)境差(時(shí)不時(shí)斷開連接)等。用C語(yǔ)言模擬的方式來(lái)使用RESTful架構(gòu)(如Websocket)會(huì)使得終端的負(fù)荷較重，而且服務(wù)器發(fā)給終端設(shè)備的消息有可能因?yàn)閿嚅_連接而收不到。

MQTT是IBM針對(duì)物聯(lián)網(wǎng)退出的一種輕量級(jí)協(xié)議，建立于TCP/IP層協(xié)議之上。其是物聯(lián)網(wǎng)的重要組成部分，可能會(huì)成為物聯(lián)網(wǎng)的事實(shí)標(biāo)準(zhǔn)。其具有QoS，能夠緩沖消息，并通過(guò)重傳機(jī)制保證終端設(shè)備收到消息;其消息格式極其簡(jiǎn)化，最短是兩個(gè)字節(jié);其提供訂閱和發(fā)布模式，高效推送消息。

MQTT有三個(gè)角色，包括服務(wù)器代理、訂閱者和發(fā)布者。

啟動(dòng)服務(wù)器代理。

發(fā)布者向服務(wù)器代理發(fā)布主題信息。

MQTT有C/C++語(yǔ)言和JAVA包實(shí)現(xiàn)。需要明確的是，MQTT更適用于設(shè)備終端和手機(jī)APP socket通信，而不能支持瀏覽器使用。如果要支持微信瀏覽器應(yīng)用，還需要增加類似WebsocketServlet技術(shù)給瀏覽器提供支持，這時(shí)MQTT以JS接口進(jìn)行封裝，并被調(diào)用完成消息推送。

5. CoAP

CoAP是受限制的應(yīng)用協(xié)議(ConstrainedApplication Protocol)的代名詞。其基于UDP協(xié)議，也就是在設(shè)備終端上只需要底層實(shí)現(xiàn)UDP協(xié)議，而不需要實(shí)現(xiàn)較為復(fù)雜的TCP協(xié)議。這種協(xié)議用得比較小。筆者也沒有用C語(yǔ)言模擬過(guò)，就不展開了。