前言
在接觸到MQTT之後，總是會有疑問，爲什麼用MQTT不用TCP長連接透傳？看起來【TCP長連接+私有協議透傳】和【MQTT+業務主題】似乎都能達到同樣的目的，甚至用MQTT會使得設備端邏輯實現、APP端邏輯實現、雲端架構實現更加複雜。那麼爲什麼物聯網還要使用MQTT協議呢？
一、MQTT相比於TCP長連接的優勢
1、協議更標準
MQTT是標準的RFC協議，相比於私有協議而言更加標準。好處在於：
（1）協議非常完整，能夠馬上用於生產。各端實現同一套協議之後，就能進行通信；私有協議還需要進行大量的驗證，看有無缺陷或欠考慮的地方等。
（2）協議的標準化帶來大量的開源組件，降低開發難度。隨着物聯網+5G生態越來越好，開源組件越來越多，可以減少重複編碼量。
（3）標準協議利於第三方接入。當第三方設備、平臺想要對接的時候，拿出一套標準的MQTT協議拍在他們臉上，再也沒人有理由要求改接口了。
2、MQTT協議制定好了很多利於物聯網的功能
當然TCP自己開發協議也能做到，但MQTT都已經把功能做好了，自己開發協議反而增加難度。有利的功能包括：
（1）心跳機制。不需要自己做業務協議層的心跳了。
（2）遺囑消息。這對於經常掉線的物聯網設備而言非常有用。
（3）QoS質量等級+離線消息。持久會話離線的消息也能接收到，對於網絡不穩定但要求必須送達的物聯網場景很有用。
（4）異步機制。MQTT將消息以QoS1/2發送出去後，設備端就不需要再管了，一切由雲端負責失敗重傳。
（5）訂閱發佈機制。一次發佈，多個客戶端訂閱，這對於M2M場景很省電、省流量。
（6）主題和安全。可以用主題來方便地控制客戶端權限。
以上的功能基於TCP自己開發也能做到，如果自己都開發了，不就是實現了應用層的MQTT協議了嗎
3、理解數據內容，用數據產生價值
IoT目前主流設計有兩部分：
（1）設備影子價值
微軟Azure叫設備孿生（Device Twins），亞馬遜AWS叫設備影子（Device Shadow），阿里雲叫設備影子（Device Shadow），騰訊雲叫設備影子（Device Shadow），百度雲叫物影子（Shadow）。爲什麼這麼多大廠都要開發這個概念呢，設備影子包含了設備的狀態，不用一個一個透傳查詢設備，直接在雲端訪問設備影子就能夠得到當前所有設備的狀態數據，這蘊含着巨大的利益，比如統計數據用於引導開發新產品和功能、統計數據用於修復bug等等。
（2）規則引擎價值
AWS、阿里雲、騰訊雲、百度雲，都叫規則引擎（Rule Engine）。由於MQTT細分了具體的主題，當業務以主題區別的時候，直接將對應主題的數據通過規則引擎配置的規則自動分發給其他的數據接收者，比如阿里雲可以發送給：
- 關係數據庫RDS，進行普通存儲
- 時序數據庫TSDB，可用於時序分析
- 存儲桶Bucket，當文件存儲
- 消息隊列MQ，可以轉發給多個其他服務
- 函數計算，無服務器地處理某項工作
- 實時流，實時地發送給某些對時間敏感的服務
- 另一個主題，可以實現M2M通信
這些都可以有很多操作空間，隨便舉個例子，把所有的天貓精靈的語音數據發送到MQ，然後用後端服務慢慢分析，利用機器學習算法研究出什麼樣的用戶羣體喜歡使用什麼樣的功能，好針對性地賣產品，比如閹割一些功能，賣“青春版”天貓精靈，或者增加一些高端功能，賣“商務版”天貓精靈。
這些都是TCP透傳這種雲不理解業務數據內容做不到的（不要說TCP也可以解包然後分析業務數據然後轉發，這樣不就是變相地實現了MQTT了嗎）。
二、選擇MQTT還是TCP長連接透傳
這需要看具體的業務場景。
1、原始的業務場景
MQTT之所以叫做“消息隊列遙測傳輸”協議，就是因爲最開始是用來將無人看管的石油天然氣管道數據通過衛星鏈路上報給數據中心，當時的需求在於：
（1）石油天然氣管道大多處於無人區，更不可能有基站了，只能通過偶爾覆蓋的衛星來通信。衛星通信極其不穩定，很容易頻繁斷開連接。
（2）數據採集頻率不高，且數據量小。
（3）有的消息很重要，需要有質量保證，比如石油泄漏，即使想發送的時候斷網了，也應該在斷網後能夠傳出去，且傳出去必須要保證送達。
（4）採集設備都是嵌入式設備，要求低功耗。
這不就是MQTT的“會話機制”、“異步機制”、“QoS機制”等功能的體現嗎。
2、端對端M2M場景——無人汽車
有的業務是不需要APP的，只有雲和設備端，並且消息從一個設備端發到另一個設備端，這個時候用MQTT再合適不過了，因爲一個設備如果想要發給多個設備消息，考慮到嵌入式資源有限一次只能保持一條TCP SSL連接，採用TCP透傳必然要頻繁建立TCP連接，這對低功耗的設備是致命的；而用MQTT，由雲端負責轉發就非常方便。
3、APP控制設備端場景——智能家居、智能快遞櫃
其實採用TCP透傳和MQTT都可以，如果MQTT只訂閱一個主題，只發佈一個主題，payload填業務數據，不就退化成TCP長連接透傳了嗎。有的可能已經有私有協議了，如果想要把IoT做大，可以考慮MQTT協議；如果想減少成本儘快上線，用TCP透傳也可以。
4、其他場景
MQTT還可以用於其他場景，比如APP消息推送（知乎網關），遊戲數據長連接，網絡聊天等等，都存在真實案例。他們不用TCP長連接的理由會有很多，比如知乎是爲了複用同一套長連接系統，解耦業務數據，保證消息質量等。
總結
當別人問爲什麼要用MQTT不用TCP長連接透傳的時候，要先體會MQTT的好處，然後結合自己的業務分析是否真的有必要上MQTT（畢竟MQTT整套下來成本比TCP高不少）。當然還有其他協議，比如室外的智能路燈由於只能通過基站上網，因此可以用插SIM卡的CoAP協議；一些總是插電的資源很多的設備如路由器，甚至可以用HTTP協議。在糾結MQTT協議的時候，這些都是可以考慮的方向。