人脸识别系统通信协议调研

MQTT协议

简介

消息队列遥测传输（MQTT）。采用发布/订阅模式，所有的物联网终端都通过TCP连接到云端，云端通过主题的方式管理各个设备关注的通讯内容，负责将设备与设备之间消息的转发。
优点：

• a.由于采用发布/订阅的消息模式，可以提供一对多的消息发布
• b.轻量级，网络开销小
• c.对负载内容会有屏蔽的消息传输
• d.有三种消息发布质量（Qos）：
  qos=0：“至多一次”，这一级别会发生消息丢失或重复，消息发布依赖于TCP/IP网络
  qos=1：“至少一次”，确保消息到达，但消息重复可能会发生
  qos=2：“只有一次”，确保消息到达一次
• e.通知机制，异常中断时会通知双方

缺点：
实时性差，延时在秒级。

原理

任何一个MQTT协议的系统都有两个组成部分：代理（broker）和客户（client）。
客户端既可以发布消息也可以订阅消息。客户端发布的消息会首先传递给代理，每个消息都对应一个主题，代理向订阅了某主题的客户端推送这个主题的消息。
主题详情：
MQTT消息按主题分类，主题是编码到每个消息中的字符串。客户端订阅主题，当代理收到消息时，它会将其传输给订阅它的任何客户端。MQTT主题具有与文件系统类似的结构，并使用/字符作为分隔符。一些示例主题是：
home/kitchen/light
home/lounge/lamp
home/lounge/light
通配符（＃）可用于订阅级别上的所有消息。例如，订阅home/lounge/＃的客户将收到‘家庭/休息室/灯’ 和 ‘家庭/休息室/灯光’消息。订阅home/＃的客户将收到以上所有订阅。

支持MQTT协议消息的代理服务器产品

• Websphere
• MQ Telemetry
• IBM MessageSight
• Mosquitto
• Eclipse Paho
• emqttd Xively
• m2m.io
• webMethods
• Nirvana Messaging
• RabbitMQ
• Apache ActiveMQ
• Apache Apollo
• Moquette
• HiveMQ
• Mosca
• Litmus Automation Loop
• JoramMQ
• ThingMQ
• VerneMQ

MQTT客户端的语言支持

• Java
• Javascript
• C/C++
• Python
• Ruby
• Objective-C

DDS

DDS: data distribution service数据分发服务。 DDS信息发布中间件是一种轻便的、能够提供实时信息传送的中间件技术。

DDS采用发布/订阅体系架构，以数据为中心，提供丰富的Qos服务质量策略。

DDS主要优点

• 以数据为中心，数据吞吐量大，数据传输实时性好：在众多的通信中间件中，DDS是唯一一个以数据为中心的标准。
• 采用全局数据空间技术，大大地提高通信效率：DDS把所有的本地存储的数据称作全局数据空间。对于应用来说，全局数据空间看上去像通过api来访问内存一样。你使用时，就像使用本地存储一样。事实上，DDS发送消息来更新远端节点的相应存储值。这样，在使用时，如同本地存储。
• 引入服务质量策略（QoS），增加了通信灵活性：DDS提供基于Qos控制的共享数据。应有通过发布和订阅主题来实现，主题用他们的主题名来标识。订阅方可以规定时间和内容过滤器，这样可以获得该主题发布数据的一个子集。
• 具有丰富的线上协议，支持真实设备接入
• 通讯实时性好，能够支持低时延仿真
• 应用可以使用各种语言编写：全局数据空间可以在嵌入式系统、移动和云应用之间共享数据，采用任意的传输方式，无论语言和系统，而且延迟极低。

DDS通信基本要素

• 主题（Topic）：这是一个包含可在进程之间交换的数据的消息。数据表示为可以包含不同数据类型的结构，如整数，字符串等;
• 数据编写器（Data Writer）：这是该过程用于发送数据的组件。进程写入必须发送到数据写入器的数据;
• 数据读取器（Data Reader）：这是接收数据并使其可用于流程的组件;
• 发布者（Publisher）：这是控制消息的网络流的组件，应用即QoS策略（我们将在后面介绍）;
• 订阅者（Subscriber）：这是控制输入流的组件。

DDS通信模型

DDS发布/订阅模型详解

DDS以数据为中心的发布-订阅模型为所有的分布式节点之间创建了一个虚拟共享的全局数据空间。

• 节点可同时是发布者和订阅者
• 各节点无主从关系
• 通信方式可以是点对点，点对多，多对多
• 网络中的数据对象用主题做标识
  
  DDS规范有两层：
• DLRL层（数据本地重构）：DLRL层将DCPS层提供的服务进行了抽象，在DLRL层建立了与底层服务的映射关系
• DCPS层（以数据为中心发布订阅）：DCPS层是DDS的核心和基础，提供了通信的基本服务
  
  DDS基本结构是域domain，由域号唯一标识。domain将各个应用程序绑定在一起进行通信，只有在同一个域内的通信实体才能通信，不同域内的实体间无任何逻辑关系。
  
  DDS内所有的成员都是entity，DDS中任两个entity通信都必须在同一个domain内进行交互。domain内的domainparticipant是服务的入口点，任何DDS应用都需首先获取domain participant，然后通过domain participant获取其他服务，如publisher，subscriber，topic等。
  数据发布者通过调用datawriter的write函数发布数据，但数据不会立刻被送出，实际的消息产生是通过publisher和Qos综合控制的。datareader负责订阅数据，订阅方式可采用异步方式（listener），同步方式和非阻塞三种。

局限

DDS在服务质量（QoS）上提供非常多的保障途径，这也是它适用于国防军事、工业控制这些高可靠性、可安全性应用领域的原因。但这些应用都工作在有线网络下，在无线网络，特别是资源受限的情况下，没有见到过实施案例。

DDS产品：OpenDDS

OpenDDS是使用C++语言针对OMG数据分发服务(DDS)的一种开源实现。由OCI公司设计和维护，可从OpenDDS社区门户中获得帮助。

OpenDDS的安装可以从这篇博文(OpenDDS系列(2) —— OpenDDS 安装)参考。

AMQP

AMQP（Advanced Message Queuing Protocol，高级消息队列协议）是一个提供统一消息服务的应用层标准协议，基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。

前提知识

消息队列(Message queue)

• 服务之间最常见的通信方式是直接调用彼此来通信，消息从一端发出后立即就可以达到另一端，称为即时消息通讯（同步通信)；
• 消息从某一端发出后，首先进入一个容器进行临时存储，当达到某种条件后，再由这个容器发送给另一端，称为延迟消息通讯 （异步通信）

工作过程

一个Virtual Host可持有一些Exchange和Message queue。它是一个虚拟概念可以是一台服务器，也可以是多个服务器组成的集群。

Message的产生者和消费者可能是同一个应用。整个AMQP定义的就是Client application与Broker之间的交互。

• 发布者（Publisher）发布消息（Message），经由交换机（Exchange）。

• 交换机根据路由规则将收到的消息分发给与该交换机绑定的队列（Queue）。

• 最后 AMQP 代理会将消息投递给订阅了此队列的消费者，或者消费者按照需求自行获取。

协议分层

AMQP协议是一种二进制协议，提供客户端应用与消息中间件之间异步、安全、高效地交互。从整体来看，AMQP协议可划分为三层：

这种分层架构类似于OSI网络协议，可替换各层实现而不影响与其它层的交互。AMQP定义了合适的服务器端域模型，用于规范服务器的行为(AMQP服务器端可称为broker)。在这里Model层决定这些基本域模型所产生的行为，这种行为在AMQP中用”command”表示。Session层定义客户端与broker之间的通信(通信双方都是一个peer，可互称做partner)，为command的可靠传输提供保障。Transport层专注于数据传送，并与Session保持交互，接受上层的数据，组装成二进制流，传送到receiver后再解析数据，交付给Session层。Session层需要Transport层完成网络异常情况的汇报，顺序传送command等工作。

AMQP产品：RabbitMQ

RabbitMQ是基于AMQP协议实现的开源消息代理软件。广为使用。
这个链接 是知乎上对RabbitMQ的一个不错的讲解。
这个链接 是RabbitMQ的中文文档
RabbitMQ（官网）不但支持AMQP协议，还有各种协议插件:
例如MQTT插件

XMPP

XMPP来源于Jabber开源社区，基于XML，提供准实时的传递消息、在线状态和请求/响应服务。XMPP使用客户/服务模式，服务器之间能够相互连接，建立在面向连接的协议上，通常是TCP。

前提知识

XML数据传输协议

XML基于HTTP， 客户端与服务器之间使用HTTP数据传输协议进行信息交互，客户端以HTTP协议中的POST请求方式将XML数据提交至服务器，服务器响应客户端同样也以POST数据流方式传输XML数据。客户端和服务器端发送和解析XML数据时要遵循数据传输协议。
每一个请求、响应消息包都是一个XML字符串，包含消息头和消息体两部分，对于不同类型的请求、响应，消息头的格式都相同的，而消息体会携带具体类型的请求、响应信息。

XMPP协议内容

XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。服务器同时承担了客户端信息记录，连接管理和信息的 路由功能。网关承担着与异构即时通信系统的互联互通，异构系统可以包括SMS（短信），MSN，ICQ等。基本的网络形式是单客户端通过 TCP/IP连接到单服务器，然后在之上传输XML。

工作原理

Xmpp协议优点

• 分布式：XMPP网络的架构和电子邮件十分相像；XMPP核心协议通信方式是先创建一个stream，XMPP以TCP传递XML数据流，没有中央主服务器。任何人都可以运行自己的XMPP服务器，使个人及组织能够掌控他们的实时传讯体验
• 安全：任何XMPP协议的服务器可以独立于公众XMPP网络（例如在企业内部网络中），而使用SASL（1）及TLS（2）等技术的可靠安全性，已自带于核心XMPP技术规格中。
  XMPP–>SASL–>TLS–>TCP–>IP
  注 ：（1）SASL：SASL全称Simple Authentication and Security Layer，是一种用来扩充C/S模式验证能力的机制。在Postfix可以利用SASL来判断用户是否有权使用转发服务，或是辨认谁在使用你的服务器。SASL提供了一个通用的方法为基于连接的协议增加验证支持，而XMPP使用了一个普通的XML名字空间来满足SASL的需要
  （2）TLS：安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。
• 可扩展：XMPP协议，继承了在XML灵活的扩展性，通过扩展发送扩展信息、或者在原有的信息中增加扩展节点来处理用户需求
• 弹性佳：XMPP除了可用在实时通信的应用程序，还能用在网络管理、内容供稿、协同工具、文件共享、游戏、远程系统监控等，应用范围相当广泛
• 多样性：用XMPP协议来建造及布署实时应用程序及服务的公司及开放源代码计划分布在各种领域；用XMPP技术开发软件，资源及支持的来源是多样的，使得使你不会陷于被“绑架”的困境

XMPP产品：Openfire

是免费的、开源的、基于可拓展通讯和表示协议(XMPP)、采用Java编程语言开发的实时协作服务器。 Openfire安装和使用都非常简单，并利用Web进行管理。单台服务器甚至可支持上万并发用户。
Openfire官网
安装使用参考教程

CoAP协议

Coap（Constrained Application Protocol）是一种在物联网世界的类web协议，它的详细规范定义在 RFC 7252。COAP名字翻译来就是“受限应用协议”，顾名思义，使用在资源受限的物联网设备上。比如物联网设备的ram，rom非常小，运行TCP和HTTP是不可以接受的，就可以使用CoAP协议。CoAP协议可以视为HTTP协议的简化版。但是由于很多物联网设备隐藏在局域网内部，coap设备作为服务器无法被外部设备寻址，但是在ipv6没有普及之前，coap只能适用于局域网内部（如wifi）通信，这也很大限制了它的发展。

协议特点

• 基于消息模型
• 请求/响应模型
• 双向通信
• 轻量、低功耗
• 支持可靠传输
• 支持IP多播
• 非长连接通信，支持受限设备
• 支持观察模式
• 支持异步通信
  CoAP是一个完整的二进制应用层协议，消息格式紧凑，默认运行在UDP上。

CoAP与MQTT对比

• MQTT协议使用发布/订阅模型，CoAP协议使用请求/响应模型；
• MQTT是长连接，CoAP协议是无连接；
• MQTT通过中间代理传递消息的多对多协议，CoAP协议是Server和Client之间消息传递的单对单协议；
• MQTT不支持带有类型或者其它帮助Clients理解的标签消息，CoAP内置内容协商和发现支持，允许设备彼此窥测以找到交换数据的方式。

使用Coap协议

可使用消息服务器EMQ X，支持MQTT、CoAP等协议。
EMQ的开源版也提供了一个Generic CoAP的实现
EMQ X官方文档

HTTP和websocket

HTTP

HTTP协议是典型的CS通讯模式，由客户端主动发起连接，向服务器请求XML或JSON数据。该协议最早是为了适用web浏览器的上网浏览场景和设计的，目前在PC、手机、pad等终端上都应用广泛，但并不适用于物联网场景。
在物联网场景中其有三大弊端：

1. 由于必须由设备主动向服务器发送数据，难以主动向设备推送数据。对于单单的数据采集等场景还勉强适用，但是对于频繁的操控场景，只能推过设备定期主动拉取的的方式，实现成本和实时性都大打折扣。

2. 安全性不高。web的不安全都是妇孺皆知，HTTP是明文协议，在很多要求高安全性的物联网场景，如果不做很多安全准备工作（如采用https等），后果不堪设想…

3. 不同于用户交互终端如pc、手机，物联网场景中的设备多样化，对于运算和存储资源都十分受限的设备，http协议实现、XML/JSON数据格式的解析，都是“mission impossible”

Websocket

在设备资源允许的情况下，可以使用websocket避免数据推送实时性低和单向通信的问题。

• WebSocket 是基于TCP/IP协议，独立于HTTP协议的通信协议。
• WebSocket 是双向通讯，有状态，客户端一（多）个与服务端一（多）双向实时响应（客户端 ⇄ 服务端）。
  WebSocket在建立握手连接时，数据是通过http协议传输的，但是在建立连接之后，真正的数据传输阶段是不需要http协议参与的。具体关系如下：
  

Websocket使用

Websocket是HTML5新出的一种协议，属于应用层协议，使用简单。
知乎上Ubuntu系统上Websocket的使用教程

JMS

JMS (Java Message Service)，即消息服务，这是JAVA平台中著名的消息队列协议。

Java消息服务应用程序接口，是一个Java平台中关于面向消息中间件(MOM)的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。

主流物联网协议对比

总结

从易于实现的角度来讲，HTTP和websocket不需要搭建消息中间件，客户端直接和服务器通信，但是HTTP是单向通信，这两者推荐使用WebSocket。由于物联网设备资源受限和低功耗的需求，出现了CoAP协议，基于UDP的，但是其常常和NB-IoT搭配（见补充知识），咱们采用4G无线网络的话发挥不出低功耗的优势，而且咱们的设备计算资源应该还是够的，这个协议我认为优先级不高。
剩下的几种协议都是需要中间服务器的，XMPP用于即时的消息传递，缺点是这个协议比较老，存在流量冗余、重复转发的问题，对网络可靠性要求高。
AMQP和MQTT定位相似，相比之下AMQP功能更加完善，安全性更好；MQTT适用于小型设备，轻量级，内存和网络带宽占用小。二者都支持设备间相互的信息传递。
DDS实时性最好，数据分发的实时效率非常高，能做到秒级内同时分发百万条消息到众多设备，而且QoS具有丰富的保障，常用于国防军事、工业控制这些高可靠性、可安全性应用领域的，但是在无线网络特别是资源受限的情况下基本没见到实施案例。

补充知识

• 按网络四层协议分类：
  NB-IoT，LORA，WIFI，蓝牙，zigbee，4G都是物理层的，这几个都需要芯片模组支持（硬件支持）
  而MQTT，COAP，HTTP都是应用层协议，这些需要开发服务器，或者对接云平台厂商（软件支持）
  所以（MQTT，COAP，HTTP）是居于（NB-IoT，LORA，WIFI，蓝牙，zigbee，4G）的上层协议物理层中
  4G和NB-IoT属于同层次的协议。
• NB-IoT，4G对比：
  NB-IoT低功耗，传输小数据，传输速度底，芯片模组和套餐便宜
  4G：传输速度快和可以传输大的数据，但是功耗高，价格贵

进一步细化：边缘计算或者人脸识别的协议

专利：一种基于WebSocket协议的动态人脸识别方法

查找到的一个专利，在人脸识别系统中实际使用的边云协同方法。链接：https://www.ixueshu.com/document/4eb5d095a73dae36e01a4aedd1c119fa318947a18e7f9386.html。这里使用的消息服务软件是Apache-apollo

流程图

系统组成示意图

理解

这个结构里的算法分析服务器可以换成我们的RK3399PRO人脸识别终端，这个结构里的人脸库存储在web服务器上，这点不用变。这个结构里算法分析服务器直接传输人脸图片给消息服务器，在我们的项目中可以替换为人脸ID，并且算法分析服务器不需要存储人脸图片，存储特征即可。这里是使用websocket先建立长连接，然后使用STOMP协议进行消息转发，这里的STOMP可以替换为MQTT（即使用MQTT over websocket的方式），支持3种QOS和加密服务。