导读：本篇文章首席CTO笔记来给大家介绍有关物联网通讯协议哪个好用的相关内容，希望对大家有所帮助，一起来看看吧。
SSL或IPsec：哪个更适合物联网安全
SSL VPN与IPSEC VPN适用于不同场景，而不是简单地比较谁好谁不好。 SSL VPN用于个人通过IE安全访问公司内网的应用。IPSEC VPN主要用于总公司与异地分公司之间的通讯加密。
从安全性比较，两者差不多。SSL VPN安全性稍好一点，因为如果用IPSEC VPN，有一台电脑中毒，会感染整个网络，而SSL VPN更细粒度的控制都避免这种情况。
SSL 是基于应用层的安全协议
IPSEC 是基于网络层的安全协议
SSL被大部分浏览器集成，用户不要再安装客户端软件，IPsec则必须安装客户端。
但是，不装客户端的SSL VPN只能实现简单的应用，如http等，若需要其他的应用，如邮件、远程桌面、某些软件，就必须安装SSL VPN的客户端。但这样就丧失了SSL VPN易安装、易维护的特点。
IPsec VPN则是现在比较广泛使用的VPN产品，它功能全面、强大，缺点是部署、维护比较麻烦，经常容易和其他软件冲突。
物联网有哪七大通信协议?
物联网七大通信协议是：REST/HTTP(松耦合服务调用）、CoAP协议、JMS、XMPP协议（即时通信）、AMQP协议（互操作性）、DDS协议（高可靠性、实时）、MQTT协议（低带宽）。
特点：
1、REST即表述性状态传递，是基于HTTP协议开发的一种通信风格。主要为了简化互联网中的系统架构，快速实现客户端和服务器之间交互的松耦合，降低了客户端和服务器之间的交互延迟。
2、CoAP (Constrained Application Protocol)，受限应用协议，应用于无线传感网中协议。它适用于在资源受限的通信的IP网络。
3、JMS (Java Message Service)，即消息服务，这是JAVA平台中著名的消息队列协议。Java消息服务应用程序接口，是一个Java平台中关于面向消息中间件（MOM)的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
4、XMPP(Extensible Messaging and Presence Protocol)可扩展通讯和表示协议，一个开源形式组织产生的网络即时通信协议。
5、AMQP(Advanced Message Queuing Protocol)，先进消息队列协议，用于业务系统例如PLM，ERP，MES等进行数据交换。
6、DDS(Data Distribution Service for Real-Time Systems)，面向实时系统的数据分布服务。
7、MQTT (Message Queuing Telemetry Transport )，消息队列遥测传输，由IBM开发的即时通讯协议，相比来说比较适合物联网场景的通讯协议。
MQTT和CoAP哪个最可能成为未来物联网通信标准协议
MQTT是非常流行的设备的接入协议，包括IBM、亚马逊、微软的IoT托管服务都有支持，而CoAP在这方面几乎没有露面的机会。感觉以下几点是MQTT优于CoAP的主要原因：
MQTT基于TCP，在做反控设备的时候比UDP更可靠，比如CoAP走3G、4G的时候甚至需要实现CoAP over TCP，否则反控很不稳定甚至无法联通。
MQTT异步Pub/Sub实现，好比发个微信，无需等待对方确认便可以继续，而不像CoAP那样必须等待对方应答才能返回的同步模式。
MQTT为物联网提供了许多体贴的设计，比如QoS，比如“遗言”的设计。
篇幅有限，无法完全枚举MQTT的优越性，建议参考以下文章：
MQTT入门篇
MQTT进阶篇
MQTT安全篇
MQTT实战篇
当然，CoAP在功耗方面有优势，不过随着物联网设备特别是网管的计算能力加强，这点应该不是主要矛盾。
MQTT协议和TCP协议有什么区别？为什么人们推荐MQTT协议?
MQTT协议是Message Queuing Telemetry Transport的缩写，中文名叫作消息队列遥测传输。是一个即时通讯协议，该协议支持所有平台，可以当作传感器来使用，举个例子，你仅仅在家通过此协议制造一个“传感器”，家里有医疗设备和装置并且安上了无线发射器，这样很适合那些有旧疾而且需要定期检查的病人们，在家就可以用设备自我检查之后通过无线MQTT协议将检查结果发送给负责你的医生，医生可以随时查看你的健康状况，并给出合理的建议，这样极大地方便了用户和医生的交流，非常便利。所以在推送信息和快速即时方面MQTT协议发展前景很是可观。
而TCP协议是学过计算机的人都比较熟悉的协议，分了四层，面向连接又可靠，可以用于文件传输、远程登陆、发送邮件等，但传输速度较慢，要求也比较多。这两个协议中大多数人都会推荐MQTT协议，因为MQTT是建立在TCP基础之上的，光实时性这一点就符合许多人的要求，现在信息高速时代大家要的第一点就是快速，让生活方便，并且比TCP有过之而无不及。
我也相信在未来MQTT协议会出现在我们的生活各个方面，这样灵活便捷的协议如果我们很好地利用，对我们信息技术的发展一定有着很大的帮助，这也是移动互联网发展的特色了吧。其实也不能绝对性地说MQTT比TCP好，只能说它功能更加全面，适应时代发展的要求，所以推荐选择它。
现在MQTT协议国内外也在逐渐应用，相信它会发展得越来越好的。
【内部分享】MQTT协议解读及使用经验
时间：2018-07-26
Q: 什么是网络连接？
A: 网络连接是传输层定义的概念，在传输层以下只存在网络数据包的相互交换。
所谓连接，其实也不是在网络上有一条真实存在的数据通道。只要通信双方在一段时间内持续保持数据包交换，就可以视为双方建立的连接并没有断开。
连接的建立是依托于TCP协议的三次握手，一旦连接已经建立完毕，通信双方就可以复用这条虚拟通道进行数据交换。如果连接保持长时间工作一直没有被中断，那么这样的TCP连接就俗称为长连接。
Message Queue Telemetry Transport ，中文直译： 消息队列遥测传输协议 。
在MQTT协议被设计出来的年代，还没有物联网这么时髦的词汇，当年叫做 遥测设备 。
MQTT协议真正开始声名鹊起的原因，是其正好恰恰踩中移动互联网发展的节拍，为消息推送场景提供了一个既简便又具有良好扩展性的现成解决方案。
可以看出，MQTT对消息头的规定十分精简， 固定头部占用空间大小仅为1个字节 ，一个最小的报文占用的空间也 只有两个字节 （带一字节的长度标识位）。
这也是MQTT协议针对不稳定及带宽低下的网络环境做出的特定设计 - - - - 尽可能地节省一切不必要的网络开销 。
Q：为什么MQTT协议需要心跳报文(PINGREQ, PINGRESP)来维护连接状态，只监控该TCP的连接状态是否可以实现目的？
A: TCP数据传输默认的超时时间过长，不符合应用层上细粒度的要求。
TCP数据传输超时的情况可分成三种： 服务端断开 、 客户端断开 、 中间网络断开 。
在前两种场景下，若断开操作是一方主动发起的，即表示为TCP连接正常结束，双方走四次挥手流程；若程序异常结束，则会触发被动断开事件，通信另一方也能立刻感知到本次连接所打开的 Socket 出现中断异常。
唯独中间网络的状态是通信双方不能掌握的。 在Linux系统下 ，TCP的连接超时由内核参数来控制，如果通信中的一方没有得到及时回复，默认会主动再尝试 6次 。如果还没有得到及时回应，那么其才会认定本次数据超时。
连带首次发包与六次重试，Linux系统下这7次发包的超时时间分别为 2的0次方 至 2的6次方 ，即1秒、2秒、4秒、8秒、16秒、32秒、64秒，一共127秒。MQTT协议认为如此长的超时时间对应用层而言粒度太大，因此其在应用层上还单独设计属于自身的心跳响应控制。常见的MQTT连接超时多被设定为 60秒 。
扩展知识 - TCP的KeepAlive机制：
由通信中的 报文标识符 ( Packet Identifier )传达。
Q：仅Publish与Pubrec能保证消息只被投递一次吗？
A： 业务上可以实现，但MQTT协议并没有如此设计，原因如下：
每个消息都会拥有属于自己的报文标识符，但如果需要两次数据交换就实现消息仅只收到一次，就需要通信双方记录下每次使用的报文标识符，并且在处理每一条消息时都需要去重处理，以防消息被重复消费。
但MQTT协议最初被设计的工作对象是轻量级物联设备，为此在协议的设计中报文标识符被约定为 可重用 ，以减少对设备性能的消耗，换回的代价不得不使用四次网络数据交换，才能确保消息正好被消费一次。
Q：两个不同客户端在发布与订阅同一Topic下的消息时，都可以提出通信Qos要求，此时以哪项为基准？
A： 伪命题，故意在分享时埋下坑，等人来踩。
两个不同客户端的通信是需要 Broker 进行中转，而不是直连。因此，通信中存在两个不同的会话，双方的Qos要求仅仅作用于它们与 Broker 之间的会话，最终的Qos基准只会向最低要求方看齐。
例：遗嘱消息的正确使用方式可参考此篇文章：
虽然可以借助 Retain Message 实现绑定一条消息至某个Topic，以达到消息的暂时保留目的。
但首先 Retain Message 并不是为存储场景而设计的，再次MQTT协议并没有对消息的持久化作出规定，也就是说Broker重启后，现有保留消息也将丢失。
Q：两种特殊消息的使用场景？
A： 遗嘱消息，多用于客户端间获取互相之间异常断线的消息通知；
保留消息，可保存 最近一条 广播通知，多用于公告栏信息的发布。
Eclipse Mosquitto ：MQTT协议的最小集实现
有 EMQ , HiveMQ , RabbitMQ MQTT Adapter 等。
Qos=2 消息保障的网络I/O次数过多，如果不是必需，尽少在程序里使用此类消息。
毕竟当初其设计的目的是为了减少设备的性能占用，但若应用场景并不是物联网，而是用于手机、电脑或浏览器端等现在已不缺性能的设备上，最好在报文体中，使用UUID生成全局唯一的消息ID，然后自行在业务解析中判断此报文是否被消费过。
或者，业务方在处理消息时保证其被消费的幂等性，也可消除重复消息对系统带来的影响。
正如MQTT协议并没有依赖TCP连接状态，自己在应用层协议上实现心跳报文来控制连接状态，业务方作为MQTT协议的使用者，也不要完全依赖协议的工作状态，而是依托MQTT协议建立属于业务本身的信息汇报机制，以加强系统的稳健性。
Retain Message 可视为客户端主动拉取的行为。如果业务系统采用 HTTP+MQTT 双协议描述业务过程，主动拉取的操作也可使用 HTTP 请求替代。
作为一个长连接型的应用，上线前需要根据业务量级，评估对操作系统 端口数 与 文件描述符 的占用要求，以防服务器资源被打满。
在服务端的配置文件和客户端的连接参数中，都拥有 max_inflight_messages 此项配置，来维护 Qos=1 or 2 消息是否被成功消费的状态。
MQTT 最初被设计为物联网级的通信协议，因此此参数的默认配额较小（大多数情况下被限制到10至20）。
但如果将MQTT协议应用至手机、PC或Web端的推送场景时，硬件性能已不在是瓶颈，在实际使用中推荐把此参数调大。
Mosquitto提供Bridge功能，需要我们自己配置。
Bridge 意为桥接，当我们把两台Broker桥接在一起时，只需要修改一台Broker的配置，填上另一台Broker的运行地址。前一台Broker将作为客户端发布与订阅后一台Broker的所有Topic，实现消息互通的目的。
桥接带来的问题有以下几点：
我的建议：
Websockets协议被设计的目的是为浏览器提供一个全双工的通信协议，方便实现消息推送功能。
在Websockets协议被设计出来前，受限于HTTP协议的一问一答模型，消息的推送只能靠轮询来实现，在资源消耗与时效性保障上，均难以达到令人满意的效果。
Websockets协议复用了HTTP协议的头部信息，告知浏览器接下来的操作将触发协议升级，然后通信双方继续复用HTTP的Header，但报文内容已转变为双方均接受的新协议的格式。
Websockets协议改进了网页浏览中的消息推送的方式，因此被广泛应用在聊天、支付通知等实时性要求比较高的场合下。
MQTT协议重点在于 消息队列的实现，其对消息投递的方式作出约定，并提供一些额外的通信保障 。
MQTT可采取原生的TCP实现，也有基于Websockets的实现版本。当然后者在网络字节的利用率上，不如前者那么精简。但浏览器端无法直接使用TCP协议，所以就只能基于Websockets协议开发。
不过基于Websockets的应用也有方便之处：一是证书不需要额外配置，直接与网站共用一套基础设施；二是可使用 Nginx 等工具管理流量，与普通HTTP流量可共用一套配置方法。
MQTT非常适合入门，原因如下：
实际的应用场景远比理想中的复杂，无法一招走遍天下，必须做好取舍。
MQTT协议在这方面做得很优秀，以后工作中可以作为参考，设计好自己负责的业务系统。
结语：以上就是首席CTO笔记为大家整理的关于物联网通讯协议哪个好用的相关内容解答汇总了，希望对您有所帮助！如果解决了您的问题欢迎分享给更多关注此问题的朋友喔～