手机APP与服务器通讯用什么协议？MQTT Server哪家强？

Posted 2022-06-18 encoderlee

手机APP与服务器通讯协议选择

开发手机APP相关项目，手机APP通常大量使用HTTP协议与服务器通信，这样手机可以主动从服务器获取所需要的数据，但是如果要让服务器主动与手机通信，让手机去做一件事情该怎么办呢？假设一个需求：服务器在需要的时候会向手机发送一个指令，手机接到指令后利用摄像头拍一张照片上传到服务器，那么可以考虑几种方法来实现：

1.手机进行HTTP轮询，轮询间隔若干秒，服务器没有什么指令就返回空内容，如果有指令就返回指令内容。这样虽然写起来很简单，但是轮询间隔设置多大比较好呢，轮询的太频繁了，占用系统、网络资源，轮询的频率降低的话，指令没法及时送达，时效性不好。

2.由于HTTP轮询有占用资源多，时效性不好的缺点，看来还是得基于TCP长连接来实现才能解决问题。

早年间websocket还未出现的时候，基于网页的即时通讯应用，为了解决消息接收的及时性，在HTTP协议上做文章，使用长轮询（long polling）来解决普通短轮询的缺点，即客户端发起一个HTTP请求，服务端Hold住该请求，并不及时返回数据，比如持续Hold住该请求1分钟，在1分钟内，如果有消息要发给客户端，立刻返回HTTP正文，如果超过1分钟还没有任何消息需要发给客户端，则断开连接或者返回空的内容，客户端发现连接断开或者收到空的内容，立马重新发起一个HTTP请求，服务端继续Hold住，如此往复。至于每次请求最多Hold住几分钟，可以根据情况来决定，客户端和服务端只要调高超时值即可，但也不宜设置的太久，因为HTTP连接被Hold住期间，是没有心跳包机制的，如果设置的太长，比如10分钟，到第2分钟的时候，网络不好断开了，客户端浑然不知，依然在傻傻的等待到第10分钟才重连。后来这种长轮询模式被用到了手机APP上，也能使得服务器与手机实现更及时的通讯。

不过服务端这边实现起来比较麻烦，很多传统的HTTP服务端和WEB框架，设计之初都没有考虑到需要长时间Hold住HTTP请求，一般每个HTTP请求都要占用一个线程来处理，如果该连接被Hold住，该线程就被Hold住了，无法处理其它请求，当客户端数量较多达到几百个几千个的时候，为了同时Hold住那么多连接，就要配置服务端的工作线程数为数百个数千个，导致效率低下，性能下降。虽然使用node.js这样的异步服务端可以解决该问题，但很多时候我们因为团队技术方向、历史项目兼容原因，没法换用服务端技术方案。

3.直接基于TCP开发自定义协议，和很多游戏一样，客户端创建一个socket连接上服务器，保持TCP长连接，即可与服务器实时交换数据，当然服务器也能及时下发命令。自定义协议的缺点是客户端和服务端，还有很多事情要自己做，制定协议规则，处理错误和异常，比如发送的数据只发了一半，网络断开了怎么办，收到的数据是否完整，该怎么校验，收到了和协议规定不一样的异常数据怎么办，如何确认客户端已经收到了数据，错误重发，断线重连，身份验证，权限管理，等等功能，都要自己去实现，增加开发时间成本。

有没有一种现成的协议、服务、库已经帮我们做好这些事情了呢，当然有，那就是在手机等移动设备上非常常用的MQTT协议：

4.使用MQTT的优点在于，已经有大量的第三方客户端和服务端实现了该协议，他们已经做好了保持TCP长连接、处理网络错误等工作，并且提供了很多丰富的功能，我们只需要关心业务上的数据传输即可，最简单的方法就是客户端和服务端通过MQTT互相扔json来通讯，再结合HTTP协议，已经可以实现绝大部分的业务需求。

MQTT Broker的选择

其实没有MQTT Server这个说法，标题为了使得seo效果更好才这么写，一般刚听说MQTT的同学到网上搜索一般是以mqtt server为关键词，后来才知道应该叫mqtt broker，这个实现mqtt协议的服务端，确实应该叫做broker（中间人），因为他并没有提供具体的服务，他只是让服务端和手机方便通讯的中间人，服务还是由你的具体业务服务端来实现。那么mqtt broker那么多，该怎么选呢，这里讲几个我用过的：

1.Mosquitto (https://mosquitto.org)
正如其名，这个是超轻量的mqtt broker，只有300多kb，如果你只需要使用mqtt进行客户端与服务端的基本通信功能，这个broker已经完全够用了，如果要实现更多高级功能，比如最重要的身份认证和访问控制，Mosquitto 默认只能使用配置文件来配置，同时不能在运行过程中修改配置，如果要在运行过程中增删用户，修改密码，修改ACL规则，则需要修改配置文件并重启Mosquitto 服务才能生效，没法基于mysql等数据库来储存和实时修改这些规则，虽然有很多第三方插件可以实现这些需求，但是这些第三方插件很多都是个人开发者开发的，有的已经没有在维护，有的没有经过严谨的测试和商用考验，在复杂业务场合不是很推荐。

2.mosca (http://www.mosca.io)
正如它的定义“MQTT broker as a module”那样，mosca和其它大多数mqtt broker不一样，其它大多数mqtt broker都像redis、mysql那样是一个独立的可执行程序，启动后读取配置文件，监听指定的网络端口提供服务，而mosca是nodejs的一个模块（库），它可以嵌入到你的nodejs程序中，在你的进程中运行以提供mqtt服务。所以你需要写一段js代码，调用mosca这个库的API函数，传入相应的参数以启动mqtt服务，同时可以向mosca注册回调函数，干预mqtt服务的每个环节，高度可定制，对于上面提到的身份验证和访问控制，都可以在代码中实现，无论你要借助mysql数据库还是redis来管理规则，都可以自己写。
mosca的优势在于，如果你想要的高级功能mqtt broker本身并没有提供，你可以很方便的二次开发增加功能，而不像Mosquitto / EMQ那样，如果要增加功能，只能通过开发插件或修改Mosquitto / EMQ源代码并重新编译的方式，而且还需要使用C语言 / Erlang语言开发，很麻烦，而且不是所有团队都有这个技术栈。
当然mosca也有缺点，很多高级功能都没有提供，需要你自行实现，虽然实现起来比较方便，但是我这个人是很懒的，有现成的决不自己发明轮子。

3.EMQ (http://www.emqtt.com)
一个重量级高并发mqtt broker，还是国产开源软件，中文文档完善丰富，大部分业务需要的高级功能都已经实现了，集群、负载均衡，完善的身份认证和访问控制功能，支持多种身份认证方式，支持使用MySQL/MongoDB/PostgreSQ/Redis等管理用户身份及ACL规则，除了TCP和SLL，还支持WebSocket和HTTP访问mqtt服务，支持消息持久化，提供命令行控制台和WEB控制台，提供REST API监控管理客户端。虽然进行二次开发和插件开发仍然需要使用Erlang语言开发，不是方便。但实际上它本身已经提供了众多高级功能以及丰富的API接口，已经可以满足绝大多数业务需求。

尤其是这个WEB控制台，让我非常满意，一行代码都不用写，就可以方便的一览大局，看到每个客户端设备的状态和在线情况以及订阅情况，在这个控制台上还集成了一个简单的mqtt client，对于调试和手工排查问题非常方便。强烈安利！




本文由CharlesSimonyi发表于CSDN博客：https://blog.csdn.net/CharlesSimonyi/article/details/89365141 转载请注明出处