物聯網基本框架及關鍵技術

消息觸達能力是物聯網（internet ofthings, IOT）的重要支撐，而物聯網不少技術都源於移動互聯網。本文闡述移動互聯網消息推送技術在物聯網中的應用和演進。

1、物聯網架構和關鍵技術

IP互聯架構已經是物聯網的事實標準（有關物聯網TCP/IP層關鍵技術將另文闡述，敬請關注）。本文所講的消息推送技術是基於TCP/IP協議的應用層協議技術。

咱們先進一步抽象基於IP架構的物聯網組成，以下圖（忽略internet和路由等基礎技術）：

可見，核心組成就是物聯設備things、網關和雲端。物聯設備分爲兩類，一類是其自身自然支持TCP/IP而能直接接入物聯網，如wifi、GPRS/3G/4G等設備；另外一類是其未能支持IP協議而須要網關（協議轉換）來接入物聯網，如Zigbee、藍牙等設備。對於藍牙設備而言，手機實際上是一個網關。

手機經過自身的藍牙跟外設藍牙設備通訊，並將消息經過手機的wifi或者3G/4G模塊與雲服務端通訊。

• 從場景的角度來分析，物聯網最終是給人類服務的，而手機是人類體驗的最直接入口。所以在上圖中能夠單獨添加手機組成部分，並將其與通常意義上的網關區分出來。這樣物聯網核心組成就是：設備端—網關—雲端—手機。

• 從應用層開發技術的角度來看，物聯網應用是基於TCP/IP架構創建，在屏蔽底層的網關協議轉換的基礎上，物聯網應用的組成部分就是：設備端—雲端—手機。

OK，有了以上的介紹，咱們就從物聯網應用的角度來分析設備、雲端、手機直接的消息推送技術，它包括雲端和設備端的雙向通訊技術、手機和雲端的雙向通訊技術。

2、移動互聯網通訊模式

互聯網有B/S和C/S兩種通訊模式。在移動互聯網領域，APP是以C/S的方式以client的角色跟服務器server進行通訊；而微信是一個超級APP，其是經過內置瀏覽器讓用戶進行H5編程以得到操控硬件設備的能力，所以微信硬件平臺的通訊模塊是B/S模式。

移動互聯網B/S技術跟傳統互聯網沒有區別，微信內置瀏覽器支持H5，所以能夠得到很好的平臺擴展性。咱們近期重點關注基於微信硬件平臺的物聯網，所以就圍繞B/S模式的消息推送技術講述其演進。

HTTP協議是B/S的基礎，HTTP有GET和POST兩種方式。

3、消息推送技術演進

1.HTTP單向通訊

瀏覽器使用HTML文本標記語言，即瀏覽器經過HTTP協議向服務器發起請求(請求內容包括URL，即咱們常說的網址)，服務器將URL對應的HTML內容經過HTTP協議做爲響應傳送回給瀏覽器。

• 1）手機端。微信端由於有內置瀏覽器，其自然支持前端頁面。

• 2） 雲端對手機端推送。雲端使用JSP/PHP等技術開發設計前端網頁和簡單的邏輯便可。

• 3）設備端。設備端上線時或者訪問服務端參數等內容時須要模擬HTTP協議（C語言）向服務器發起請求，而請求的格式通常不使用HTML，而是使用較爲簡單的XML或者JSON協議格式。

• 4）雲端對設備端推送。雲端使用HttpServlet（即便用http協議的servlet）對設備的HTTP請求進行響應，回覆XML或者JSON格式的消息。

• 5）缺點。這種方式通訊方式的特色就是一請求一響應，老是要客戶端向服務器發出請求，服務器纔給予響應。服務器歷來都不會主動給客戶端發消息，並且在客戶端發出請求後，服務器也只是回覆一次。這種HTTP單向通訊方式在互聯網領域發揮巨大的做用，就是服務器端能夠是無狀態的，極大地簡化了服務器的服務流程，提升效率。但在物聯網領域，咱們要求的是雙向的通訊能力。服務端要能主動給設備端或者手機發出消息。

在這種模式下，咱們怎麼作雙向通訊呢？惟一的作法就是客戶端不斷地發出請求（或者週期性），服務器不斷地給予回覆。這種模式下的缺點顯而易見：一是網絡負載重，服務器每次響應後都會關閉鏈接，因此每次通訊都得從新握手。HTTP協議的頭內容的長度可不小。二是實時性差。通常設備端都是週期性地輪詢服務器是否有新的消息，輪詢的方式是不能得到好的實時性的。3、瀏覽器端每次發出請求是以HTML所有內容來響應的，消息長度過大，在這種狀況下，會發現瀏覽器頁面不斷地刷新。

2.Ajax輪詢

Ajax技術是瀏覽器支持的一種JavaScript技術。其可以局部改善用戶體驗技術，讓用戶在不察覺瀏覽器頁面刷新的狀況向服務器發出請求，並得到響應。其原理是：

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

• 2）HTML頁面使用js調用XMLHttpRequest來向服務器發出異步通訊請求。

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

• 4）HTML頁面使用DOM模型來動態刷新頁面元素。

Ajax技術是微信硬件平臺框架中推薦的頁面交互技術，但其本質仍是遵照HTTP單向通訊的規則，只是頁面交互時不須要刷新整個頁面。其雙向通訊實時性問題依然未能解決。

3.Websocket

Websocket是HTML5支持的一種新的協議，它可以真正支持瀏覽器和服務器之間進行雙向通訊。Tomcat7及以上版本也已經支持Websocket API。

• 1）爲了可以兼容瀏覽器HTTP協議，Websocket規定在第一次發起請求時依然要發出符合HTTP協議規範的Header，但其Connection域的值是Upgrade，並增長Upgrade域，值是socket，即告知服務器，即將創建的通訊是Websocket雙向通訊。服務器若是接受，會返回101給客戶端進行協議切換。

• 2）接下來的通訊將再也不以HTTP做爲傳輸協議，而是使用Websocket規定的數據格式進行通訊，其分爲控制幀和數據幀。控制幀是發出心跳幀（ping），而服務器響應pong，還有結束幀；數據幀就是真實數據格式，其格式頭只有6個字節（2個字節頭和4個字節的掩碼），後面就是真實的數據（通過掩碼轉換）。比HTTP格式頭的長度要小多了。

• 3）客戶端和服務器之間是一直保持鏈接，直到close，當前期間要發發2個字節的3字節的ping幀。

可見Websocket比ajax有了極大的改進。其不只省掉常常要鏈接握手，還簡化的協議的格式，最重要的是實時性獲得保證，由於雙方是真正的全雙工通訊。

微信瀏覽器客戶端支持Websocket，服務器使用Tomcat7以上的WebsocketServlet類，設備端要根據Websocket協議用C語言來模擬通訊。

咱們在用設備端模擬Websocket通訊協議時通常會先看協議，再用HttpWatch等工具來抓包，抓到的頭是GET ws://ip:port/path，若是在C語言也是這樣模擬發包則會報400 bad request。由於C語言利用socket創建通訊時已經利用了IP和port了，其發的第一個包的頭是GET/path便可，不能在其前面加上ws://ip:port/。

4.MQTT

以上的分析都是將移動互聯網的技術運用到物聯網，其都有一個特定就是創建鏈接時會傳送URL地址，由兩個角色是客戶端和服務器，這種架構咱們通常稱爲是RESTful架構（另外，還有SOAP 面向應用的web services架構）。RESTful架構在互聯網獲得愈來愈普遍的運用，但物聯網除了互聯以外，還有其獨有的特徵，就是其終端設備的資源有限、低功耗運用場景、網絡鏈接環境差（時不時斷開鏈接）等。用C語言模擬的方式來使用RESTful架構（如Websocket）會使得終端的負荷較重，並且服務器發給終端設備的消息有可能由於斷開鏈接而收不到。

MQTT是IBM針對物聯網退出的一種輕量級協議，創建於TCP/IP層協議之上。其是物聯網的重要組成部分，可能會成爲物聯網的事實標準。其具備QoS，可以緩衝消息，並經過重傳機制保證終端設備收到消息；其消息格式極其簡化，最短是兩個字節；其提供訂閱和發佈模式，高效推送消息。

MQTT有三個角色，包括服務器代理、訂閱者和發佈者。

• 1）啓動服務器代理。

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

• 3）發佈者向服務器代理髮布主題信息。

• 4）服務器代理想全部訂閱該主題的訂閱者推送消息。

MQTT有C/C++語言和JAVA包實現。須要明確的是，MQTT更適用於設備終端和手機APP socket通訊，而不能支持瀏覽器使用。若是要支持微信瀏覽器應用，還須要增長相似WebsocketServlet技術給瀏覽器提供支持，這時MQTT以JS接口進行封裝，並被調用完成消息推送。

5.CoAP

CoAP是受限制的應用協議(ConstrainedApplication Protocol)的代名詞。其基於UDP協議，也就是在設備終端上只須要底層實現UDP協議，而不須要實現較爲複雜的TCP協議。這種協議用得比較小。筆者也沒有用C語言模擬過，就不展開了。

從開發的角度，無線接入是物聯網設備端的核心技術，身份設備管理和消息推送技術是物聯網雲端的核心技術。而從場景體驗的角度，除了前者，還要包括手機的前端開發技術。