实现物联网的核心技术为(简述物联网的核心技术)

约翰先生

JSON中文的全名是Javascript对象标记语言，在该语言中全部为对象。 因此，所有支持的类型(如字符串、数字、对象和数组)都可以用JSON表示。 其语法规则如下

对象表示为键值对； 数据由逗号分隔； 中括号保存对象； 方括号用于保存数组。 JSON的层次结构简洁、清晰、易读、便于书写，同时也便于机器的分析和生成，有效地提高了网络的传输效率。

对于单片机开发者来说，主流的微控制器软件开发工具Keil提供了JSON库，可以用于STC、STM32等微控制器开发，因此可以用微控制器分析JSON

如果使用JSON库生成或解析JSON字符串很麻烦，也可以直接使用c语言sprintf生成JSON字符串，如下所示：

sprintf(buf，() (字符串() : ) %s )，()值) ) :%d )，)赫鲁罗世界！ ) )。12345；

1现在生成了“字符串”:“问候世界”。 ”、“值”:12345 }现在是JSON字符串。

XML

MQTT协议只负责通信部分，用户协议可以自己选择，当然也可以选择复杂冗长的XML格式。 但是，如果选择MQTT XML，为什么不考虑更改为XMPP呢？

总结

综上所述，MQTT JSON是目前最好的方案。 还考虑了服务器端开发人员和设备端开发人员的开发成本，包括协议简洁、清晰、易读、分析和生成等。

有关MQTT的云平台和工具

支持MQTT的云平台

目前，百度、阿里、腾讯的云平台逐渐拥有了物联网开发套件。 腾讯物联平台内测中，AlibabaCloud物联网套件内测中，两者都需要进行申请试用，但百度云物联网套件支持MQTT，暂时免费除了BAT三先生之外，我们还将介绍支持MQTT的其他物品的互联网云平台。

OneNET云平台： OneNET是由中国移动打造的PaaS物联网开放平台。 平台可以帮助开发者轻松访问设备和连接设备，快速完成产品开发部署，为智能硬件、智能家居产品提供完美的物联网解决方案。 OneNET云平台于2014年10月正式上线。 云：云总线是一种跨平台双向实时通信系统，为物联网、APP、Web提供实时通信服务。 云基于MQTT，并支持Socket.IO协议和rest风格的应用程序。 qtt服务器

如果不想使用云平台，只想纯粹玩MQTT，或者在内部网监视设备，可以自己在本地部署MQTT服务。 介绍几种MQTT服务器。

ache-Apollo :以ActiveMQ为基础开发的代理服务器。 支持STOMP、AMQP、MQTT、Openwire、SSL、WebSockets等各种协议，提供后台管理页面供开发人员管理和调试。 EMQ:EMQ 2.0被称为兆级开源MQTT消息传递服务器，是基于Erlang/OTP语言平台开发的，支持大规模连接和分布式集群，是订阅模型的开源MQTT HiveMQ :主要用于企业和新兴的机械到机械的M2M通信和内部传输，最大限度地满足可扩展性、易管理性、安全特性，提供免费个人版的企业级MQTT代理。 HiveMQ提供了开源插件开发软件包。 Mosquitto :是实现消息推送协议MQTT v3.1的开源消息代理软件，提供轻量级、可发布/可订阅的消息推送模式。 MQTT调试工具

在知道各平台的MQTT的同时，也可以自己在内部网部署MQTT服务器。 那么，接下来如果没有调试工具该怎么办呢？ 用喜欢的语言写一个吗？ 当然不需要。 MQTT调试工具应考虑使用基于web套接字的浏览器MQTT客户端HiveMQ的MQTT客户端—— hive MQ web套接字客户端，以支持主题的订阅和发布。

MQTT和其他协议

现在各平台都开始支持MQTT协议，那么MQTT与其他协议相比有什么好处呢？ 物联网设备可以使用其他协议吗？ 以下是MQTT与其他部分协议的比较，仅供参考。

MQTT和TCP套接字

虽然MQTT在TCP层上运行，两者之间看起来没有可比性，但我认为有必要进行描述，因为大多数从事硬件和嵌入式开发的工程师都是在TCP层直接通信的。 从事嵌入式开发的人应该知道面向嵌入式的开源TCP/IP协议栈LwIP。 LwIP在嵌入式设备具有完整的TCP/IP功能的同时，保证了协议栈对处理器资源的有限消耗。 通常在几十KB的RAM和40KB左右的ROM上工作。

也就是说，只要嵌入式产品使用的是LwIP，就可以支持TCP/IP协议栈，进而使用MQTT协议。

由于TCP协议存在数据包粘贴和分包问题，因此数据传输需要自定义协议。 如果传输的数据报超过最大分组长度(MSS )，则必须在协议中定义消息长度字段，以便接收方可以完全通过缓冲区接收消息。 简单的协议定义：消息头的消息长度消息正文。

当然，使用MQTT协议时，不需要考虑这个问题。 这些MQTT已经处理完毕，MQTT可以一次发送多达256MB的数据，无需考虑数据包的分包问题。

也就是说，TCP和MQTT本身并不矛盾，但需要基于套接字开发处理更多的事情

，而且大多数嵌入式开发模块本身也只会提供Socket接口供厂家自定义协议。

MQTT与HTTP

HTTP最初的目的是提供一种发布和接收HTML页面的方法，主要用于Web。HTTP是典型的C/S通讯模式：请求从客户端发出，服务端只能被动接收，一条连接只能发送一次请求，获取响应后就断开连接。该协议最早是为了适用Web浏览器的上网浏览场景而设计的，目前在PC、手机、Pad等终端上都应用广泛。由于这样的通信特点，HTTP技术在物联网设备中很难实现设备的反向控制，不过非要实现也不是不行，下面看一下Web端的例子。

目前，在微博等SNS网站上有海量用户公开发布的内容，当发布者发布消息，数据传到服务器更新时，就需要给关注者尽可能的实时更新内容。Web网站基于HTTP协议，使用HTTP协议探测服务器上是否有内容更新，就必须频繁地让客户端请求服务器进行确认。在浏览器中要实现这种效果，可以使用Comet技术，Comet是基于HTTP长连接的“服务器推”技术，主要有两种实现模型：基于AJAX的长轮询（long-polling）方式和基于Iframe及htmlfile的流（streaming）方式。这两种技术模型在这里不详细展开，有兴趣的读者可以查阅相关资料。

如果要实现设备的反向控制，可能就要用到前面提到的Comet技术。由于需要不断的请求服务器，会导致通信开销非常大，加上HTTP冗长的报文头，在节省流量上实在没有优势。

当然，如果只是单纯地让设备定时上报数据而不做控制，也是可以使用HTTP协议的。

MQTT与XMPP

最有可能与MQTT竞争的是XMPP协议。XMPP（可扩展通讯与表示协议）是一项用于实时通讯的开放技术，它使用可扩展标记语言（XML）作为交换信息的基本格式。其优点是协议成熟、强大、可扩展性强。目前主要应用于许多聊天系统中，在消息推送领域，MQTT和XMPP互相竞争。下面列举MQTT与XMPP各自的特性：

XMPP协议基于繁重的XML，报文体积大且交互繁琐；而MQTT协议固定报头只有两个字节，报文体积小、编解码容易；XMPP基于JID的点对点消息传输；MQTT协议基于主题(Topic)发布\订阅模式，消息路由更为灵活；XMPP协议采用XML承载报文，二进制必须进行Base64编码或其他方式处理；MQTT协议未定义报文内容格式，可以承载JSON、二进制等不同类型报文，开发者可以针对性的定义报文格式；MQTT协议支持消息收发确认和QoS保证，有更好的消息可靠性保证；而XMPP主协议并未定义类似机制；在嵌入式设备开发中大多使用的是C语言开发，C语言解析XML是非常困难的。MQTT基于二进制实现且未定义报文内容格式，可以很好的兼顾嵌入式C语言开发者；而XMPP基于XML，开发者需要配合协议格式，不能灵活开发。 综上所述，在嵌入式设备中，由于需要一个灵巧简洁，对设备开发者和服务端开发者都友好的协议，MQTT比XMPP更具有优势。

MQTT与CoAP

CoAP也是一个能与MQTT竞争的协议。其模仿HTTP的REST模型，服务端以URI方式创建资源，客户端可以通过GET、PUT、POST、DELETE方式访问这些资源，并且协议风格也和HTTP极为相似，例如一个设备有温度数据，那么这个温度可以被描述为：

CoAP://:/sensors/temperature

其中为设备的IP，为端口。

不过，如果使用CoAP可能会让物联网后台的情况变得复杂，比如MQTT可以实现一个最简单的IoT架构：Device + MQTT服务器 + APP，手机端或Web端可以直接从MQTT服务器订阅想要的主题。而CoAP可能需要这样的架构：CoAP + Web + DataBase + App，使用CoAP必须经过DataBase才能转给第三方。

至于CoAP和MQTT孰优孰劣，这里不作定论。不过目前来说，CoAP资料还是略少。而且，MQTT除了可以应用于物联网领域，在手机消息推送、在线聊天等领域都可以有所作为。

小结

经过以上的比较，我们可以得出如下结论：MQTT基于异步发布/订阅的实现解耦了消息发布者和订阅者，基于二进制的实现节省了存储空间及流量，同时MQTT拥有更好的消息处理机制，可以替代TCP Socket一部分应用场景。相对于HTTP和XMPP，MQTT可以选择用户数据格式，解析复杂度低，同时MQTT也可用于手机推送等领域。手机作为与人连接的入口，正好建立了人与物的连接，可谓一箭双雕。当然，其他协议也可以作为一个辅助的存在，HTTP可以为只需定时上传数据的设备服务，CoAP则更适用于非常受限的移动通信网络，表3直观地展示了上文提到的几种协议之间的优劣异同。