物聯網核心協議—訊息推送技術演化

標籤：

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

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

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

      在上一篇《一張圖讀懂基於硬體平台的物聯網架構》博文中，筆者曾用一張大圖詳細描述了基於硬體平台的物聯網架構的組成要素、關鍵情境、和通訊協定（應用程式層和TCP/IP層）。本文則重點描述物聯網各部分之間的通訊技術實現。

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

 

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

 

可見，核心組成就是物聯裝置things、網關和雲端。物聯裝置分為兩類，一類是其自身天然支援TCP/IP而能直接接入物聯網，如wifi、GPRS/3G/4G等裝置；另一類是其未能支援IP協議而需要網關（協議轉換）來接入物聯網，如Zigbee、藍芽等裝置。對於藍牙裝置而言，手機其實是一個網關。手機通過自身的藍芽跟外設藍牙裝置通訊，並將訊息通過手機的wifi或者3G/4G模組與雲端服務端通訊。

 

從情境的角度來分析，物聯網最終是給人類服務的，而手機是人類體驗的最直接入口。因此在中可以單獨添加手機組成部分，並將其與一般意義上的網關區分出來。這樣物聯網核心組成就是：裝置端—網關—雲端—手機。

 

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

 

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

 

二、移動互連網通訊模式

      互連網有B/S和C/S兩種通訊模式。在移動互連網領域，APP是以C/S的方式以client的角色跟伺服器server進行通訊；而是一個超級APP，其是通過內建瀏覽器讓使用者進行H5編程以獲得操控硬體裝置的能力，因此硬體平台的通訊模組是B/S模式。

      移動互連網B/S技術跟傳統互連網沒有區別，內建瀏覽器支援H5，因此可以獲得很好的平台擴充性。我們近期重點關注基於硬體平台的物聯網，因此就圍繞B/S模式的訊息推送技術講述其演化。

      HTTP協議是B/S的基礎，HTTP有GET和POST兩種方式。不知道的請百度，然後再往下看:-)

 

三、訊息推送技術演化

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協議的頭內容的長度可不小。二是即時性差。一般裝置端都是周期性地輪詢伺服器是否有新的訊息，輪詢的方式是不能獲得好的即時性的。三、瀏覽器端每次發出請求是以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語言類比過，就不展開了。

物聯網核心協議—訊息推送技術演化