MQTT比TCP协议好在哪儿？

　　MQTT比TCP协议好在哪儿？就好比汽车底盘上有四个轮胎就能跑了，但是想要大家开车更舒服，我们还是得给底盘加个壳。
　　简单对比
　　为什么要在 TCP 协议之上再封装一层 MQTT 协议呢？
　　举个例子，如果你要用 TCP 协议做一个即时聊天室，那么你：首先写一个服务器程序，监听某个端口，这样客户端就能连接上来了。然后大家就能向自己的服务器发送数据了。但是你不希望随便谁都能连接你的服务器并且往你的服务器里发东西，于是你写了一个注册页面，让别人先去注册账号，然后他们在客户端创建连接时发送的第一个TCP报文必须包含了账号密码。这样当你收到第一个报文之后，你就能判断这个连接是否合法了。但是发过来的账号密码，具体摆在报文什么位置，也得事先约定好吧，不然怎么知道哪几位是账号哪几位是密码，于是你要求：第一个字节为1，用来告诉你这是一个请求连接的报文。然后第二个字节是报文剩下的长度（这个没啥异议，粘包处理必备），然后是＂饼干熊最帅＂这样一个固定的字符串（没啥意思，就是开心），后面紧跟着就是账号，然后是密码。但是账号有多长呢，所以账号第一个字节是账号的长度，剩下才是账号内容，这样就解决了＂账号有多长＂的问题了，密码同理。如果账号密码不匹配就断开连接并且返回一句＂xxxx off＂，如果创建连接后半天不发送任何东西也断开连接。现在大家的客户端都连接上来了，你在服务器保存了一个`账号:socket`的map，能通过任何一个账号找到这个人的socket并向他发送信息。接下来大家就要开始聊天了。在聊天室中，一个人发送的消息其他人都能收到，所以你添加了聊天室的概念，用户首先去你的web页面创建聊天室，然后会得到一个聊天室的ID。然后用户要加入聊天室，必须先发送一个加入聊天室的报文。然后你要求报文第一个字节为2代表加入聊天室的请求报文，然后是报文剩余长度，然后是聊天室ID，聊天室ID有多长？我们还是用第一个字节代表长度，剩下的内容为具体ID的形式来搞定。现在有多个用户加入了聊天室，其中每个用户又都加入了多个聊天室。假设现在大家在聊天室A中开始聊天。用户甲向服务器发送消息，然后你发现你不知道这条消息是请求连接还是要加入聊天室还是干啥，所以发送消息也应该定义一种报文类型。于是你要求发送消息的报文的第一个字节为3，那么这个报文是发送到哪个聊天室的呢？于是你要求报文后面跟上聊天室ID，最后是具体的消息内容。服务器收到第一个字节为3的消息，就知道这是一个聊天消息。然后根据上面带的聊天室ID以及你在服务器存储的用户和聊天室的关系，找到了这个聊天室里的所有人，然后你就把消息发给这里面的所有人了。
　　上面这个例子，在连接服务器（检查合法性、断开连接）、订阅主题（加入聊天室）、发布消息这些过程中，你约定的报文格式和设计的服务器处理逻辑就是 MQTT 协议的内容，当然我举的例子非常粗糙。
　　MQTT是一个客户端服务端架构的发布/订阅模式的消息传输协议。它的设计思想是轻巧、开放、简单、规范，因此易于实现。这些特点使得它对很多场景来说都是很好的选择，包括受限的环境：如机器与机器的通信（M2M）以及物联网环境（IoT），这些场景要求很小的代码封装或者网络带宽非常昂贵。
　　MQTT的优点是：
　　1）具备实时性，设备控制速度可以在200ms以内；
　　2）设计简单、轻巧、便于实现；
　　3）占用资源少，非常适合在资源受限的物联网芯片上运行
　　当然，它的缺点也很明显：
　　1）基于TCP/IP，对网络环境要求相对较高；
　　2）TCP存在RST攻击，容易被运营商拦截；
　　3）TCP资源相对UDP消耗大，需要建立连接、维护连接、释放连接
　　首先TCP是传输层协议，实现了一个双向的通信链路。
　　MQTT是基于TCP的应用层协议。（当然中间可能多一层，websocket）
　　两者不在一个层级，比较谁比谁好是没有意义的。
　　TCP 也可以实现数据通信，比如发送传感器数据到服务器。为什么要用到MQTT呢 ？
　　假设现在有一个物联网的应用，当然可以直接用TCP socket 做通信，实际上不少人也是这么做的。然后你就会发现：
　　* 需要自己写确认重传的机制，因为TCP 连接说不定就断了。
　　* 如果有很多个传感器（生产者），又要写代码管理这么多TCP连接呢。
　　* 如果同时又有多个地方需要用到这些数据，还得写一个转发的逻辑。
　　* 如果系统很复杂，参与人或公司很多，那通信格式要怎么定，怎么改，沟通成本就很大了。
　　这些东西这么麻烦，又不想加班写代码，那有没有办法简便地解决呢？当然有，就是用现成的协议啦，比如MQTT。
　　MQTT 提供两个核心功能：
　　* 三个级别的QOS
　　*基于订阅/发布的消息转发服务。
　　用了MQTT, 上面提到的这些问题就都被优雅地解决掉啦。
　　其实，同类应用的很多问题，都是有一定共性的。这时候就会有一些人提出一般性的解决方式，这样大家就不用重复造轮子，同时又保证了互操作性。这就是协议存在的意义啦。
　　所以一句话总结，MQTT 和其他的应用层协议，比如 HTPP, FTP, BitTorrent 协议一样，都是为了解决特定问题而生的一套方案，可以帮我们省好多事。
　　真正的MQTT协议要求的处理逻辑和报文格式都完善很多，但是协议本身还是很简单的，具体内容去看 MQTT 的文档吧。