按照OSI網路分層模型，IP是網路層協議，TCP是傳輸層協議，而HTTP和MQTT是應用層的協議。在這三者之間， TCP是HTTP和MQTT底層的協議。大家對HTTP很熟悉，這裡簡要介紹下MQTT。MQTT（Message Queuing Telemetry Transport，訊息佇列遙測傳輸）是IBM開發的一個即時通訊協議，有可能成為物聯網的重要組成部分。該協議支援所有平臺，幾乎可以把所有聯網物品和外部連線起來，被用來當做感測器的通訊協議。

1. HTTP的不足 

   HTTP協議經過多年的使用，發現了一些不足，主要是效能方面的，包括： 

   HTTP的連線問題，HTTP客戶端和伺服器之間的互動是採用請求/應答模式，在客戶端請求時，會建立一個HTTP連線，然後傳送請求訊息，服務端給出應答訊息，然後連線就關閉了。（後來的HTTP1.1支援持久連線）
   因為TCP連線的建立過程是有開銷的，如果使用了SSL/TLS開銷就更大。

   在瀏覽器裡，一個網頁包含許多資源，包括HTML，CSS，JavaScript，圖片等等，這樣在載入一個網頁時要同時開啟連線到同一伺服器的多個連線。

   HTTP訊息頭問題，現在的客戶端會發送大量的HTTP訊息頭，由於一個網頁可能需要50-100個請求，就會有相當大的訊息頭的資料量。

   HTTP通訊方式問題，HTTP的請求/應答方式的會話都是客戶端發起的，缺乏伺服器通知客戶端的機制，在需要通知的場景，如聊天室，遊戲，客戶端應用需要不斷地輪詢伺服器。

   而 WebSocket是從不同的角度來解決這些不足中的一部分。還有其他技術也在針對這些不足提出改進。

2. WebSocket
   WebSocket則提供使用一個TCP連線進行雙向通訊的機制，包括網路協議和API，以取代網頁和伺服器採用HTTP輪詢進行雙向通訊的機制。

   本質上來說，WebSocket是不限於HTTP協議的，但是由於現存大量的HTTP基礎設施，代理，過濾，身份認證等等，WebSocket借用HTTP和HTTPS的埠。由於使用HTTP的埠，因此TCP連線建立後的握手訊息是基於HTTP的，由伺服器判斷這是一個HTTP協議，還是WebSocket協議。 WebSocket連線除了建立和關閉時的握手，資料傳輸和HTTP沒丁點關係了。

歷時11年，WebSocket終於被批准成為IETF的建議標準：RFC6455.其前身是WHATWG （Web Hypertext Application Technology Working Group）的工作。而Web Socket

WebSocket可以只打開一個到伺服器的連結，並且在此連結上交換資訊。其優勢在於減少了傳統方法的複雜性，提高了可靠性和降低了瀏覽器和客戶端之間的負載。這樣做的一個重要原因是，很多防火牆遮蔽80以外的埠，迫使越來越多的應用遷移到HTTP上來了。

11年的websocket草案的變遷中，有的瀏覽器支援的是舊版本的websocket，比如iPhone4上的safari使用的WebSocket是舊版的握手協議,那麼就要使用就的握手協議來製做伺服器端。如今只有Safari支援舊版本的協議，Chrome和Firefox最新版都已升級至Hybi-10（協議地址）。因此，我們再來看一下WebSocket新版協議Hybi-10。這次協議變更非常大，主要集中在握手協議和資料傳輸的格式上。

握手協議

我們先來看一下大致的區別：

1. 最老的websocket草案標準中是沒有安全key，草案7.5、7.6中有兩個安全key，而現在的草案10中只有一個安全key，即將 7.5、7.6中http頭中的"Sec-WebSocket-Key1″與"Sec-WebSocket-Key2″合併為了一個"Sec- WebSocket-Key"
2. 把http頭中Upgrade的值由"WebSocket"修改為了"websocket"；http頭中的"-Origin"修改為了"Sec-WebSocket-Origin";
3. 增加了http頭"Sec-WebSocket-Accept"，用來返回原來草案7.5、7.6伺服器返回給客戶端的握手驗證，原來是以內容的形式返回，現在是放到了http頭中；另外伺服器返回客戶端的驗證方式也有變化。

伺服器生成驗證的方式變化較大，我們來做一介紹。

舊版：

1 GET / HTTP/1.1
2 Upgrade: WebSocket
3 Connection: Upgrade
4 Host: 127.0.0.1:1337
5 Origin: http://127.0.0.1:8000
6 Cookie: sessionid=xxxx; calView=day; dayCurrentDate=1314288000000
7 Sec-WebSocket-Key1: cV`p1* 42#7  ^9}_ 647  08{
8 Sec-WebSocket-Key2: O8 415 8x37R A8   4
9 ;"######

舊版生成Token的方法如下：

取出Sec-WebSocket-Key1中的所有數字字元形成一個數值，這裡是1427964708，然後除以Key1中的空格數目，得到一個數值，保留該數值整數位，得到數值N1；對Sec-WebSocket-Key2採取同樣的演算法，得到第二個整數N2；把N1和N2按照Big- Endian字元序列連線起來，然後再與另外一個Key3連線，得到一個原始序列ser_key。Key3是指在握手請求最後，有一個8位元組的奇怪的字元串";"######"，這個就是Key3。然後對ser_key進行一次md5運算得出一個16位元組長的digest，這就是老版本協議需要的token，然後將這個token附在握手訊息的最後傳送回Client，即可完成握手。

新版：

1 GET / HTTP/1.1
2 Upgrade: websocket
3 Connection: Upgrade
4 Host: 127.0.0.1:1337
5 Sec-WebSocket-Origin: http://127.0.0.1:8000
6 Sec-WebSocket-Key: erWJbDVAlYnHvHNulgrW8Q==
7 Sec-WebSocket-Version: 8
8 Cookie: csrftoken=xxxxxx; sessionid=xxxxx

新版生成Token的方法如下：

首先伺服器將key（長度24）截取出來，如4tAjitqO9So2Wu8lkrsq3w==，用它和自定義的一個字串（長度 36）258EAFA5-E914-47DA-95CA-C5AB0DC85B11連線起來，然後把這一字串進行SHA-1演算法加密，得到長度為20字節的二進位制資料，再將這些資料經過Base64編碼，最終得到服務端的金鑰，也就是ser_key。伺服器將ser_key附在返回值Sec- WebSocket-Accept後，至此握手成功。

WebSocket也有自己一套幀協議。資料報文格式如下：

FIN：1位，用來表明這是一個訊息的最後的訊息片斷，當然第一個訊息片斷也可能是最後的一個訊息片斷；

RSV1, RSV2, RSV3: 分別都是1位，如果雙方之間沒有約定自定義協議，那麼這幾位的值都必須為0,否則必須斷掉WebSocket連線；

Opcode:4位操作碼，定義有效負載資料，如果收到了一個未知的操作碼，連線也必須斷掉，以下是定義的操作碼：

• %x0 表示連續訊息片斷
• %x1 表示文字訊息片斷
• %x2 表未二進位制訊息片斷
• %x3-7 為將來的非控制訊息片斷保留的操作碼
• %x8 表示連線關閉
• %x9 表示心跳檢查的ping
• %xA 表示心跳檢查的pong
• %xB-F 為將來的控制訊息片斷的保留操作碼

Mask:1位，定義傳輸的資料是否有加掩碼,如果設定為1,掩碼鍵必須放在masking-key區域，客戶端傳送給服務端的所有訊息，此位的值都是1；

Payload length: 傳輸資料的長度，以位元組的形式表示：7位、7+16位、或者7+64位。如果這個值以位元組表示是0-125這個範圍，那這個值就表示傳輸資料的長度；如果這個值是126，則隨後的兩個位元組表示的是一個16進位制無符號數，用來表示傳輸資料的長度；如果這個值是127,則隨後的是8個位元組表示的一個64位無符合數，這個數用來表示傳輸資料的長度。多位元組長度的數量是以網路位元組的順序表示。負載資料的長度為擴充套件資料及應用資料之和，擴充套件資料的長度可能為0,因而此時負載資料的長度就為應用資料的長度。

Masking-key:0或4個位元組，客戶端傳送給服務端的資料，都是通過內嵌的一個32位值作為掩碼的；掩碼鍵只有在掩碼位設定為1的時候存在。
Payload data:  (x+y)位，負載資料為擴充套件資料及應用資料長度之和。
Extension data:x位，如果客戶端與服務端之間沒有特殊約定，那麼擴充套件資料的長度始終為0，任何的擴充套件都必須指定擴充套件資料的長度，或者長度的計算方式，以及在握手時如何確定正確的握手方式。如果存在擴充套件資料，則擴充套件資料就會包括在負載資料的長度之內。
Application data:y位，任意的應用資料，放在擴充套件資料之後，應用資料的長度=負載資料的長度-擴充套件資料的長度。

三、 MQTT（Message Queuing Telemetry Transport，訊息佇列遙測傳輸）是輕量級基於代理的釋出/訂閱的訊息傳輸協議，設計思想是開放、簡單、輕量、易於實現。這些特點使它適用於受限環境。例如，但不僅限於此：

• 網路代價昂貴，頻寬低、不可靠。 
• 在嵌入裝置中執行，處理器和記憶體資源有限。

該協議的特點有：

• 使用釋出/訂閱訊息模式，提供一對多的訊息釋出，解除應用程式耦合。 
• 對負載內容遮蔽的訊息傳輸。 
• 使用 TCP/IP 提供網路連線。 
• 有三種訊息釋出服務質量： 
• "至多一次"，訊息釋出完全依賴底層 TCP/IP 網路。會發生訊息丟失或重複。這一級別可用於如下情況，環境感測器資料，丟失一次讀記錄無所謂，因為不久後還會有第二次傳送。 
• "至少一次"，確保訊息到達，但訊息重複可能會發生。 
• "只有一次"，確保訊息到達一次。這一級別可用於如下情況，在計費系統中，訊息重複或丟失會導致不正確的結果。
• 小型傳輸，開銷很小（固定長度的頭部是 2 位元組），協議交換最小化，以降低網路流量。 
• 使用 Last Will 和 Testament 特性通知有關各方客戶端異常中斷的機制。

早在1999年，IBM的Andy Stanford-Clark博士以及Arcom公司ArlenNipper博士發明了MQTT（Message Queuing Telemetry Transport，訊息佇列遙測傳輸）技術。BM和St. Jude醫療中心通過MQTT開發了一套Merlin系統，該系統使用了用於家庭保健的感測器。St. Jude醫療中心設計了一個叫做[email protected]的心臟裝置，這種無限發射器可以用來監控那些已經植入復律-除顫器和起搏器（兩者都是基本的感測器）的心臟病人。

該產品利用MQTT把病人的即時更新資訊傳給醫生/醫院，然後醫院進行儲存。這樣的話，病人就不用親自去醫院檢查心臟儀器了，醫生可以隨時檢視病人的資料，給出建議，病人在家裡就可以自行檢查。

IBM稱該發射器包括一個大型觸控式螢幕，一個嵌入式鍵盤平臺，以及一個Linux作業系統。

在未來幾年，MQTT的應用會越來越廣，值得關注。

通過MQTT協議，目前已經擴展出了數十個MQTT伺服器端程式，可以通過PHP，JAVA，Python，C，C#等系統語言來向MQTT傳送相關訊息。

此外，國內很多企業都廣泛使用MQTT作為Android手機客戶端與伺服器端推送訊息的協議。其中Sohu，Cmstop手機客戶端中均有使用到MQTT作為訊息推送訊息。據Cmstop主要負責訊息推送的高階研發工程師李文凱稱，隨著移動網際網路的發展，MQTT由於開放原始碼，耗電量小等特點，將會在移動訊息推送領域會有更多的貢獻，在物聯網領域，感測器與伺服器的通訊，資訊的收集，MQTT都可以作為考慮的方案之一。在未來MQTT會進入到我們生活的各各方面。

如果需要下載MQTT伺服器端，可以直接去MQTT官方網站點選software進行下載MQTT協議衍生出來的各個不同版本。

MQTT和TCP、WebSocket的關係可以用下圖一目瞭然:

MQTT協議專注於網路、資源受限環境，建立之初不曾考慮WEB環境。HTML5 Websocket是建立在TCP基礎上的雙通道通訊，和TCP通訊方式很類似，適用於WEB瀏覽器環境。雖然MQTT基因層面選擇了TCP作為通訊通道，但我們添加個編解碼方式，MQTT over Websocket也可以的。這樣做的好處，MQTT的使用範疇被擴充套件到HTML5、桌面端瀏覽器、移動端WebApp、Hybrid等，多了一些想像空間。這樣看來，無論是移動端，還是WEB端，MQTT都會有自己的使用空間。

MQ 遙測傳輸 (MQTT) V3.1 協議規範基於WebSocket 的MQTT 移動推送方案