MQTT比TCP協(xié)議好在哪兒？

MQTT比TCP協(xié)議好在哪兒？就好比汽車底盤上有四個(gè)輪胎就能跑了，但是想要大家開車更舒服，我們還是得給底盤加個(gè)殼。

為什么要在 TCP 協(xié)議之上再封裝一層 MQTT 協(xié)議呢？

舉個(gè)例子，如果你要用 TCP 協(xié)議做一個(gè)即時(shí)聊天室，那么你：

1. 首先寫一個(gè)服務(wù)器程序，監(jiān)聽某個(gè)端口，這樣客戶端就能連接上來了。然后大家就能向自己的服務(wù)器發(fā)送數(shù)據(jù)了。
2. 但是你不希望隨便誰都能連接你的服務(wù)器并且往你的服務(wù)器里發(fā)東西，于是你寫了一個(gè)注冊頁面，讓別人先去注冊賬號，然后他們在客戶端創(chuàng)建連接時(shí)發(fā)送的第一個(gè)TCP報(bào)文必須包含了賬號密碼。這樣當(dāng)你收到第一個(gè)報(bào)文之后，你就能判斷這個(gè)連接是否合法了。
3. 但是發(fā)過來的賬號密碼，具體擺在報(bào)文什么位置，也得事先約定好吧，不然怎么知道哪幾位是賬號哪幾位是密碼，于是你要求：第一個(gè)字節(jié)為1，用來告訴你這是一個(gè)請求連接的報(bào)文。然后第二個(gè)字節(jié)是報(bào)文剩下的長度（這個(gè)沒啥異議，粘包處理必備），然后是“餅干熊最帥”這樣一個(gè)固定的字符串（沒啥意思，就是開心），后面緊跟著就是賬號，然后是密碼。但是賬號有多長呢，所以賬號第一個(gè)字節(jié)是賬號的長度，剩下才是賬號內(nèi)容，這樣就解決了“賬號有多長”的問題了，密碼同理。
4. 如果賬號密碼不匹配就斷開連接并且返回一句“xxxx off”，如果創(chuàng)建連接后半天不發(fā)送任何東西也斷開連接。
5. 現(xiàn)在大家的客戶端都連接上來了，你在服務(wù)器保存了一個(gè)`賬號:socket`的map，能通過任何一個(gè)賬號找到這個(gè)人的socket并向他發(fā)送信息。接下來大家就要開始聊天了。
6. 在聊天室中，一個(gè)人發(fā)送的消息其他人都能收到，所以你添加了聊天室的概念，用戶首先去你的web頁面創(chuàng)建聊天室，然后會(huì)得到一個(gè)聊天室的ID。然后用戶要加入聊天室，必須先發(fā)送一個(gè)加入聊天室的報(bào)文。然后你要求報(bào)文第一個(gè)字節(jié)為2代表加入聊天室的請求報(bào)文，然后是報(bào)文剩余長度，然后是聊天室ID，聊天室ID有多長？我們還是用第一個(gè)字節(jié)代表長度，剩下的內(nèi)容為具體ID的形式來搞定。
7. 現(xiàn)在有多個(gè)用戶加入了聊天室，其中每個(gè)用戶又都加入了多個(gè)聊天室。假設(shè)現(xiàn)在大家在聊天室A中開始聊天。用戶甲向服務(wù)器發(fā)送消息，然后你發(fā)現(xiàn)你不知道這條消息是請求連接還是要加入聊天室還是干啥，所以發(fā)送消息也應(yīng)該定義一種報(bào)文類型。于是你要求發(fā)送消息的報(bào)文的第一個(gè)字節(jié)為3，那么這個(gè)報(bào)文是發(fā)送到哪個(gè)聊天室的呢？于是你要求報(bào)文后面跟上聊天室ID，最后是具體的消息內(nèi)容。
8. 服務(wù)器收到第一個(gè)字節(jié)為3的消息，就知道這是一個(gè)聊天消息。然后根據(jù)上面帶的聊天室ID以及你在服務(wù)器存儲(chǔ)的用戶和聊天室的關(guān)系，找到了這個(gè)聊天室里的所有人，然后你就把消息發(fā)給這里面的所有人了。

上面這個(gè)例子，在連接服務(wù)器（檢查合法性、斷開連接）、訂閱主題（加入聊天室）、發(fā)布消息這些過程中，你約定的報(bào)文格式和設(shè)計(jì)的服務(wù)器處理邏輯就是 MQTT 協(xié)議的內(nèi)容，當(dāng)然我舉的例子非常粗糙。

MQTT是一個(gè)客戶端服務(wù)端架構(gòu)的發(fā)布/訂閱模式的消息傳輸協(xié)議。它的設(shè)計(jì)思想是輕巧、開放、簡單、規(guī)范，因此易于實(shí)現(xiàn)。這些特點(diǎn)使得它對很多場景來說都是很好的選擇，包括受限的環(huán)境：如機(jī)器與機(jī)器的通信（M2M）以及物聯(lián)網(wǎng)環(huán)境（IoT），這些場景要求很小的代碼封裝或者網(wǎng)絡(luò)帶寬非常昂貴。

MQTT的優(yōu)點(diǎn)是：

1）具備實(shí)時(shí)性，設(shè)備控制速度可以在200ms以內(nèi)；

2）設(shè)計(jì)簡單、輕巧、便于實(shí)現(xiàn)；

3）占用資源少，非常適合在資源受限的物聯(lián)網(wǎng)芯片上運(yùn)行

當(dāng)然，它的缺點(diǎn)也很明顯：

1）基于TCP/IP，對網(wǎng)絡(luò)環(huán)境要求相對較高；

2）TCP存在RST攻擊，容易被運(yùn)營商攔截；

3）TCP資源相對UDP消耗大，需要建立連接、維護(hù)連接、釋放連接

首先TCP是傳輸層協(xié)議，實(shí)現(xiàn)了一個(gè)雙向的通信鏈路。

MQTT是基于TCP的應(yīng)用層協(xié)議。（當(dāng)然中間可能多一層，websocket）

兩者不在一個(gè)層級，比較誰比誰好是沒有意義的。

TCP 也可以實(shí)現(xiàn)數(shù)據(jù)通信，比如發(fā)送傳感器數(shù)據(jù)到服務(wù)器。為什么要用到MQTT呢 ？

假設(shè)現(xiàn)在有一個(gè)物聯(lián)網(wǎng)的應(yīng)用，當(dāng)然可以直接用TCP socket 做通信，實(shí)際上不少人也是這么做的。然后你就會(huì)發(fā)現(xiàn)：

* 需要自己寫確認(rèn)重傳的機(jī)制，因?yàn)門CP 連接說不定就斷了。

* 如果有很多個(gè)傳感器（生產(chǎn)者），又要寫代碼管理這么多TCP連接呢。

* 如果同時(shí)又有多個(gè)地方需要用到這些數(shù)據(jù)，還得寫一個(gè)轉(zhuǎn)發(fā)的邏輯。

* 如果系統(tǒng)很復(fù)雜，參與人或公司很多，那通信格式要怎么定，怎么改，溝通成本就很大了。

這些東西這么麻煩，又不想加班寫代碼，那有沒有辦法簡便地解決呢？當(dāng)然有，就是用現(xiàn)成的協(xié)議啦，比如MQTT。

MQTT 提供兩個(gè)核心功能：

* 三個(gè)級別的QOS

*基于訂閱/發(fā)布的消息轉(zhuǎn)發(fā)服務(wù)。

用了MQTT, 上面提到的這些問題就都被優(yōu)雅地解決掉啦。

其實(shí)，同類應(yīng)用的很多問題，都是有一定共性的。這時(shí)候就會(huì)有一些人提出一般性的解決方式，這樣大家就不用重復(fù)造輪子，同時(shí)又保證了互操作性。這就是協(xié)議存在的意義啦。

所以一句話總結(jié)，MQTT 和其他的應(yīng)用層協(xié)議，比如 HTPP, FTP, BitTorrent 協(xié)議一樣，都是為了解決特定問題而生的一套方案，可以幫我們省好多事。

真正的MQTT協(xié)議要求的處理邏輯和報(bào)文格式都完善很多，但是協(xié)議本身還是很簡單的，具體內(nèi)容去看 MQTT 的文檔吧。