消息觸達能力是物(wù)聯網（internet ofthings, IOT）的(de)重要支撐，而物(wù)聯網很多(duō)技術都源于移動互聯網。柳貓将闡述移動互聯網消息推送技術在物(wù)聯網中的(de)應用(yòng)和(hé)演進。

一、物(wù)聯網架構和(hé)關鍵技術

從開發的(de)角度，無線接入是物(wù)聯網設備端的(de)核心技術，身份設備管理(lǐ)和(hé)消息推送技術是物(wù)聯網雲端的(de)核心技術。而從場(chǎng)景體驗的(de)角度，除了(le)前者，還(hái)要包括手機的(de)前端開發技術。

IP互聯架構已是物(wù)聯網的(de)事實标準（有關物(wù)聯網TCP/IP層關鍵技術将另文闡述，敬請關注）。本文所講的(de)消息推送技術是基于TCP/IP協議(yì)的(de)應用(yòng)層協議(yì)技術。

我們先進一步抽象基于IP架構的(de)物(wù)聯網組成，如下(xià)圖（忽略internet和(hé)路由等基礎技術）：

可(kě)見，核心組成就是物(wù)聯設備、網關和(hé)雲端。物(wù)聯設備分(fēn)爲兩類，一類是其自身天然支持TCP/IP而能直接接入物(wù)聯網，如wifi、GPRS/3G/4G（當然，還(hái)有即将到來(lái)的(de)5G）等設備；另一類是其未能支持IP協議(yì)而需要網關（協議(yì)轉換）來(lái)接入物(wù)聯網，如Zigbee、藍牙等設備。對(duì)于藍牙設備而言，手機其實是一個(gè)網關。

手機通(tōng)過自身的(de)藍牙跟外設藍牙設備通(tōng)信，并将消息通(tōng)過手機的(de)wifi或者3G/4G模塊與雲服務端通(tōng)信。

• 從場(chǎng)景的(de)角度來(lái)分(fēn)析，物(wù)聯網最終是給人(rén)類服務的(de)，而手機是人(rén)類體驗的(de)最直接入口。因此在上圖中可(kě)以單獨添加手機組成部分(fēn)，并将其與一般意義上的(de)網關區(qū)分(fēn)出來(lái)。這(zhè)樣物(wù)聯網核心組成就是：設備端—網關—雲端—手機。

• 從應用(yòng)層開發技術的(de)角度來(lái)看，物(wù)聯網應用(yòng)是基于TCP/IP架構建立，在屏蔽底層的(de)網關協議(yì)轉換的(de)基礎上，物(wù)聯網應用(yòng)的(de)組成部分(fēn)就是：設備端—雲端—手機。

OK，有了(le)以上的(de)介紹，我們就從物(wù)聯網應用(yòng)的(de)角度來(lái)分(fēn)析設備、雲端、手機直接的(de)消息推送技術，它包括雲端和(hé)設備端的(de)雙向通(tōng)信技術、手機和(hé)雲端的(de)雙向通(tōng)信技術。

二、移動互聯網通(tōng)信模式

互聯網有B/S和(hé)C/S兩種通(tōng)信模式。在移動互聯網領域，APP是以C/S的(de)方式以client的(de)角色跟服務器server進行通(tōng)信；而微信是一個(gè)超級APP，其是通(tōng)過内置浏覽器讓用(yòng)戶進行H5編程以獲得(de)操控硬件設備的(de)能力，因此微信硬件平台的(de)通(tōng)信模塊是B/S模式。

移動互聯網B/S技術跟傳統互聯網沒有區(qū)别，微信内置浏覽器支持H5，因此可(kě)以獲得(de)很好的(de)平台擴展性。我們近期重點關注基于微信硬件平台的(de)物(wù)聯網，因此就圍繞B/S模式的(de)消息推送技術講述其演進。

HTTP協議(yì)是B/S的(de)基礎，HTTP有GET和(hé)POST兩種方式。

三、消息推送技術演進

1.HTTP單向通(tōng)信

浏覽器使用(yòng)HTML文本标記語言，即浏覽器通(tōng)過HTTP協議(yì)向服務器發起請求(請求内容包括URL，即我們常說的(de)網址)，服務器将URL對(duì)應的(de)HTML内容通(tōng)過HTTP協議(yì)作爲響應傳送回給浏覽器。

• 1）手機端：微信端因爲有内置浏覽器，其天然支持前端頁面。

• 2） 雲端對(duì)手機端推送：雲端使用(yòng)JSP/PHP等技術開發設計前端網頁和(hé)簡單的(de)邏輯即可(kě)。

• 3）設備端：設備端上線時(shí)或者訪問服務端參數等内容時(shí)需要模拟HTTP協議(yì)（C語言）向服務器發起請求，而請求的(de)格式一般不使用(yòng)HTML，而是使用(yòng)較爲簡單的(de)XML或者JSON協議(yì)格式。

• 4）雲端對(duì)設備端推送：雲端使用(yòng)HttpServlet（即使用(yòng)http協議(yì)的(de)servlet）對(duì)設備的(de)HTTP請求進行響應，回複XML或者JSON格式的(de)消息。

• 5）缺點：這(zhè)種方式通(tōng)信方式的(de)特點就是一請求一響應，總是要客戶端向服務器發出請求，服務器才給予響應。服務器從來(lái)都不會主動給客戶端發消息，而且在客戶端發出請求後，服務器也(yě)隻是回複一次。這(zhè)種HTTP單向通(tōng)信方式在互聯網領域發揮巨大(dà)的(de)作用(yòng)，就是服務器端可(kě)以是無狀态的(de)，極大(dà)地簡化(huà)了(le)服務器的(de)服務流程，提高(gāo)效率。但在物(wù)聯網領域，我們要求的(de)是雙向的(de)通(tōng)信能力。服務端要能主動給設備端或者手機發出消息。

在這(zhè)種模式下(xià)，我們怎麽做(zuò)雙向通(tōng)信呢(ne)？唯一的(de)做(zuò)法就是客戶端不斷地發出請求（或者周期性），服務器不斷地給予回複。這(zhè)種模式下(xià)的(de)缺點顯而易見：

• 一是網絡負載重，服務器每次響應後都會關閉連接，所以每次通(tōng)信都得(de)重新握手。HTTP協議(yì)的(de)頭内容的(de)長(cháng)度可(kě)不小。

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

• 三、浏覽器端每次發出請求是以HTML全部内容來(lái)響應的(de)，消息長(cháng)度過大(dà)，在這(zhè)種情況下(xià)，會發現浏覽器頁面不斷地刷新。

2.Ajax輪詢

Ajax技術是浏覽器支持的(de)一種JavaScript技術。其能夠局部改善用(yòng)戶體驗技術，讓用(yòng)戶在不察覺浏覽器頁面刷新的(de)情況向服務器發出請求，并獲得(de)響應。其原理(lǐ)是：

• 1）微信浏覽器發出URL頁面請求，服務器響應HTML頁面内容。

• 2）HTML頁面使用(yòng)js調用(yòng)XMLHttpRequest來(lái)向服務器發出異步通(tōng)信請求。

• 3）服務器響應XML格式數據給浏覽器頁面。

• 4）HTML頁面使用(yòng)DOM模型來(lái)動态刷新頁面元素。

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

3.Websocket

Websocket是HTML5支持的(de)一種新的(de)協議(yì)，它能夠真正支持浏覽器和(hé)服務器之間進行雙向通(tōng)信。Tomcat7及以上版本也(yě)已經支持Websocket API。

• 1）爲了(le)能夠兼容浏覽器HTTP協議(yì)，Websocket規定在第一次發起請求時(shí)依然要發出符合HTTP協議(yì)規範的(de)Header，但其Connection域的(de)值是Upgrade，并增加Upgrade域，值是socket，即告知服務器，即将建立的(de)通(tōng)信是Websocket雙向通(tōng)信。服務器如果接受，會返回101給客戶端進行協議(yì)切換。

• 2）接下(xià)來(lái)的(de)通(tōng)信将不再以HTTP作爲傳輸協議(yì)，而是使用(yòng)Websocket規定的(de)數據格式進行通(tōng)信，其分(fēn)爲控制幀和(hé)數據幀。控制幀是發出心跳幀（ping），而服務器響應pong，還(hái)有結束幀；數據幀就是真實數據格式，其格式頭隻有6個(gè)字節（2個(gè)字節頭和(hé)4個(gè)字節的(de)掩碼），後面就是真實的(de)數據（經過掩碼轉換）。比HTTP格式頭的(de)長(cháng)度要小多(duō)了(le)。

• 3）客戶端和(hé)服務器之間是一直保持連接，直到close，當前期間要發發2個(gè)字節的(de)3字節的(de)ping幀。

可(kě)見Websocket比ajax有了(le)極大(dà)的(de)改進。其不僅省掉經常要連接握手，還(hái)簡化(huà)的(de)協議(yì)的(de)格式，最重要的(de)是實時(shí)性得(de)到保證，因爲雙方是真正的(de)全雙工通(tōng)信。

微信浏覽器客戶端支持Websocket，服務器使用(yòng)Tomcat7以上的(de)WebsocketServlet類，設備端要根據Websocket協議(yì)用(yòng)C語言來(lái)模拟通(tōng)信。

我們在用(yòng)設備端模拟Websocket通(tōng)信協議(yì)時(shí)一般會先看協議(yì)，再用(yòng)HttpWatch等工具來(lái)抓包，抓到的(de)頭是GET ws://ip:port/path，如果在C語言也(yě)是這(zhè)樣模拟發包則會報400 bad request。因爲C語言利用(yòng)socket建立通(tōng)信時(shí)已經利用(yòng)了(le)IP和(hé)port了(le)，其發的(de)第一個(gè)包的(de)頭是GET/path即可(kě)，不能在其前面加上ws://ip:port/。

4.MQTT

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

MQTT是IBM針對(duì)物(wù)聯網退出的(de)一種輕量級協議(yì)，建立于TCP/IP層協議(yì)之上。其是物(wù)聯網的(de)重要組成部分(fēn)，可(kě)能會成爲物(wù)聯網的(de)事實标準。其具有QoS，能夠緩沖消息，并通(tōng)過重傳機制保證終端設備收到消息；其消息格式極其簡化(huà)，最短是兩個(gè)字節；其提供訂閱和(hé)發布模式，高(gāo)效推送消息。

MQTT有三個(gè)角色，包括服務器代理(lǐ)、訂閱者和(hé)發布者。

• 1）啓動服務器代理(lǐ)。

• 2）訂閱者向服務器代理(lǐ)訂閱相關主題。

• 3）發布者向服務器代理(lǐ)發布主題信息。

• 4）服務器代理(lǐ)想所有訂閱該主題的(de)訂閱者推送消息。

MQTT有C/C++語言和(hé)JAVA包實現。需要明(míng)确的(de)是，MQTT更适用(yòng)于設備終端和(hé)手機APP socket通(tōng)信，而不能支持浏覽器使用(yòng)。如果要支持微信浏覽器應用(yòng)，還(hái)需要增加類似WebsocketServlet技術給浏覽器提供支持，這(zhè)時(shí)MQTT以JS接口進行封裝，并被調用(yòng)完成消息推送。

5.CoAP

CoAP是受限制的(de)應用(yòng)協議(yì)(ConstrainedApplication Protocol)的(de)代名詞。其基于UDP協議(yì)，也(yě)就是在設備終端上隻需要底層實現UDP協議(yì)，而不需要實現較爲複雜(zá)的(de)TCP協議(yì)。這(zhè)種協議(yì)用(yòng)得(de)比較小。筆者也(yě)沒有用(yòng)C語言模拟過，就不展開了(le)。