iOS开发中，关于MQTT的三方库主要有两种。

基于C实现的Mosquitto库。当然直接去调用C的接口并不是特别的舒服，所以用一个ObjC的类作为桥接。比如MQTTKit。
使用ObjC或者Swift的原生实现。包括ObjC实现的MQTT-Client ，Swift实现的 CocoaMQTT。

最近花时间分析了一下Mosquitto库的源码。我尝试按照MQTT协议的流程来依次拆分mosquitto库并逐步的模仿实现出一个客户端可用的网络库（有关Broker的实现还需要处理订阅/取消订阅和一些额外的操作处理，暂时先不考虑这些）。具体的代码我放在了Github MQTTService上，之后的文章我会分篇依次描述过程。

这里是MQTT文档-中文版。要实现一个可靠的MQTT网络库，实际上我们需要做的就是将文档第三章中各种控制报文的逻辑用编程语言实现出来。在后续的文章里，我会参考各种控制报文的简易程度而不是文档介绍的报文顺序来实现这个库。大致的流程是：

socket通讯的建立
Connect Command的发送
解析接收的消息，依据首字节高四位命令区分消息类型。
PINGREQ/PINGRESP的处理（连接的keep alive）
SUBSCRIBE/UNSUBSCRIBE的处理（消息的订阅与取消订阅）
PUBLISH的实现
异步的支持
TLS/SSL的支持
细节的完善

PUBLISH涉及不同Qos的处理。而且与上面的消息类型有所不同的是，PUBLISH是Broker和Client互推，需要针对每一种send以及ack都做出对应的处理。这一部分细分为以下几块不同Qos的PUBLISH的发送

Qos = 0：发送成功即可
Qos = 1：需要接收到PUBACK
Qos = 2：需要处理PUBREC/PUBREL/PUBCOMP三种情况

MQTT是一个基于TCP/IP协议簇实现的应用层协议（UDP版本的是MQTT-SN），在Mosquitto中底层的通讯是基于socket实现的。当然，你也可以使用Websocket。这里我不做赘述，虽然两者名字类似但就像Java和Javascript一样实际这是两个完全不同的概念。有关socket的内容可以参考我翻译的Python官网的一份文档How to socket。

MQTT协议本身是明文传输的。之所以会关心到这个问题是因为之前项目在公司测试没有问题，但是在HK的公共wifi环境下一直出现用户名和密码错误的问题。虽然最后问题解决不是因为数据报被篡改，但MQTT作为应用层协议，MQTT仅关注消息传输，提供合适的安全功能是我们实现者的责任。使用TLS [RFC5246] 是比较普遍的选择。这里多说一点，有计算机网络基础的读者应该知道，TCP/IP协议五层模型。当然，也有七层的说法，多出的两层是将会话层、表示层从应用层中独立出来，让多个应用程序能够共享着两层的代码。但是因为各个应用程序之间会话和表达的需求差异很大，所以这两个网络层算是只存在我们的书本里实际中并没有实现。但是无心插柳柳成荫，一个提供安全加密服务层出现了，它为我们应用层的协议提供了安全服务。这就是TLS/SSL，但是并没有在实际的模型中单独为它划出一层来。我们熟知的HTPPS就是有了安全保护的HTTP协议。类似HTTP/SMTP/FTP包括我们今天所说的MQTT这些应用层的协议都可以使用TLS/SSL来为我们的网络服务提供安全保障。

在MQTT协议中有一个非常重要的概念Qos。如果Qos为0，就是普通的消息发送，成功与否完全依靠底层也就是TCP/IP协议簇；Qos为1确保消息至少送达一次这个就是消息的送达确认和TCP的ack类似；Qos为2确保消息只送到一次也就是TCP的保证唯一性。MQTT作为上层协议部分机制是和TCP重复的。原因很简单，ack的确认只是确认了数据包进入了tcp栈，但上层应用是否接收处理并不能保证，所以我们需要在应用层做一个应答。但既然MQTT协议实现了数据报确认和重传这部分的逻辑，底层协议的选择上TCP协议相对UDP协议还会有什么较大的优势吗（流量控制以及有序的传输），甚至在弱网络环境下TCP连接的建立以及消息的确认都会成为网络沉重的负担。

做一个简单的讨论：如果网络状况一切良好，那么所有数据包确认的操作在TCP都已经得到了保证，每一条消息都只成功发送一次，那么应用层MQTT协议的确认是否还有必要。如果是弱网络环境下，TCP连接不停的中断和重连，那么就会给本身压力就很大网络增添更多的麻烦。TCP在网络层实现了消息的超时重传，应用层的MQTT也会有重传的机制，会不会造成一条消息重复发送多次的情况。

实现一个能够通讯的网络库逻辑并不复杂，主要的问题在于需要你对照文档去挨个解析传输的数据的含义。作为一名应用层的开发人员，日常情况下我们使用HTTP等通讯协议，拿到的是json或者XML格式的数据，这是非常容易阅读和解析的数据。但在实现网络库的过程中，对于报文的信息你需要精确到每一个字节的每一个bit。简单的1和0我们按照协议赋予了他们各种不同的含义。如何从这一串数据中读取到我们想要的内容，非常的考验细心和耐心。

如果你对MQTT协议是什么，用来做什么，优缺点是什么还有疑问，可以参考官方文档 - 中文版。我在这里也为大家做一个网上知识的总结。具体的细节你可以先放开不去关心，在后面的文章里我们会一一的用代码去实现。

有兴趣的朋友可以关注一下，之后的文章会分篇详细解答 :)

一· 什么是MQTT

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，该协议支持所有平台，也就是说不论什么平台都可以使用集成此协议，网上大多说该协议用于物联网，，有可能成为物联网的重要组成部分。几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。

二· MQTT有什么特点

MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性：

1、使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合； 2、对负载内容屏蔽的消息传输； 3、使用 TCP/IP 提供网络连接； 4、有三种消息发布服务质量： 至多一次，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。 至少一次，确保消息到达，但消息重复可能会发生。 只有一次，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。 5、小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量；

三· MQTT实现方式

四· MQTT中常见的概念

MQTT客户端 一个使用MQTT协议的应用程序或者设备，它总是建立到服务器的网络连接。客户端可以：发布其他客户端可能会订阅的信息

订阅其它客户端发布的消息
退订或删除应用程序的消息
断开与服务器连接

MQTT服务器 MQTT服务器以称为“消息代理”（Broker），可以是一个应用程序或一台设备。它是位于消息发布者和订阅者之间，它可以：

接受来自客户的网络连接
接受客户发布的应用信息
处理来自客户端的订阅和退订请求
向订阅的客户转发应用程序消息

MQTT协议中的订阅、主题、会话

订阅（Subscription）订阅包含主题筛选器（Topic Filter）和最大服务质量（QoS）。订阅会与一个会话（Session）关联。一个会话可以包含多个订阅。每一个会话中的每个订阅都有一个不同的主题筛选器。
会话（Session）每个客户端与服务器建立连接后就是一个会话，客户端和服务器之间有状态交互。会话存在于一个网络之间，也可能在客户端和服务器之间跨越多个连续的网络连接。
主题名（Topic Name）连接到一个应用程序消息的标签，该标签与服务器的订阅相匹配。服务器会将消息发送给订阅所匹配标签的每个客户端。
主题筛选器（Topic Filter）一个对主题名通配符筛选器，在订阅表达式中使用，表示订阅所匹配到的多个主题。
负载（Payload）消息订阅者所具体接收的内容