从零开始实现一个MQTT客户端---开篇漫谈

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

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

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

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

  1. socket通讯的建立
  2. Connect Command的发送
  3. 解析接收的消息,依据首字节高四位命令区分消息类型。
  4. PINGREQ/PINGRESP的处理(连接的keep alive)
  5. SUBSCRIBE/UNSUBSCRIBE的处理 (消息的订阅与取消订阅)
  6. PUBLISH的实现
  7. 异步的支持
  8. TLS/SSL的支持
  9. 细节的完善

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来为我们的网络服务提供安全保障。

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)
    消息订阅者所具体接收的内容
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,324评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,303评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,192评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,555评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,569评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,566评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,927评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,583评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,827评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,590评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,669评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,365评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,941评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,928评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,159评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,880评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,399评论 2 342

推荐阅读更多精彩内容