需要将两个设备在网络中相互通信，一个设备是手机一个设备是计算机。我们选择mqtt来进行通信，RN提供了react-native-mqtt的第三方库，帮助我们很好的建立mqtt连接。
因为 IP v4 的 IP 量有限，2011年2月3日中国农历新年， IANA对外宣布：IPv4地址空间最后5个地址块已经被分配给下属的5个地区委员会。2011年4月15日，亚太区委员会APNIC对外宣布，除了个别保留地址外，本区域所有的IPv4地址基本耗尽。
以至于二十世纪90年代初，网络专家们意识到，这样大手大脚下去，IPv4地址很快就要耗光了。于是，人们开始考虑IPv4的替代方案，同时采取一系列的措施来减缓IPv4地址的消耗。正是在这样一个背景之下，本期的主角闪亮登场，它就是网络地址转换——NAT。
运营商分配给手机终端的 IP 是运营商内网的 IP，手机要连接 Internet，就需要通过运营商的网关做一个网络地址转换（Network Address Translation，NAT）。简单的说运营商的网关需要维护一个外网 IP、端口到内网 IP、端口的对应关系，以确保内网的手机可以跟 Internet 的服务器通讯。
NAT 功能由图中的 GGSN 模块实现。大部分移动无线网络运营商都在链路一段时间没有数据通讯时，会淘汰 NAT 表中的对应项，造成链路中断。
对于有Internet访问需求而内部又使用私有地址的网络，就要在组织的出口位置部署NAT网关，在报文离开私网进入Internet时，将源IP替换为公网地址，通常是出口设备的接口地址。一个对外的访问请求在到达目标以后，表现为由本组织出口设备发起，因此被请求的服务端可将响应由Internet发回出口网关。出口网关再将目的地址替换为私网的源主机地址，发回内部。这样一次由私网主机向公网服务端的请求和响应就在通信两端均无感知的情况下完成了。依据这种模型，数量庞大的内网主机就不再需要公有IP地址了。
这就带来了问题，都知道要想两个设备通信，必须知道两个设备的ip地址，但是显示在手机的ip地址是网关路由器分配的，外网设备不能直接通过手机显示的ip和手机进行通知，这样也就出现了无法获取两端的ip地址发送消息的问题。而MQTT就解决了这个问题
NAT详解http://www.52im.net/thread-50-1-1.html
MQTT概述：
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。
转发：作者：JackJiang2011 链接：https://www.jianshu.com/p/ff86ee967825
该协议面向M2M和物联网的连接，采用轻量级的“发布和订阅”消息传输机制。一般有三方参与，发布方、订阅方（可以有多个实体）、代理方。三方会有一个共同的主题作为整个通讯的识别基础，然后当发布方将信息发送给代理后，代理方会推送给所有订阅了该主题的客户端。
我们之前项目中经常用socket基于TCP/IP或者UDP进行数据的上传，为什么不直接这样使用呢？事实上，MQTT就是基于TCP/IP之上建立通信的，其底层的connect机制就是TCP/IP，如果我们对物联网这种应用场景，采用TCP/IP进行自下而上的开发，需要做大量其它的工作，比如client客户端，服务器端程序，以及对网络延迟、即时性以及用户是否在线的处理，而这些MQTT都已经做了大量的工作和优化，这时采用MQTT，它的优势就显现出来了。
MQTT就是基于TCP/IP协议的长连接。是客户端到代理服务器的长连接，在代理服务器中可以观察到连接的情况。如果超过一个时间的阈值，客户端没有收到服务器的应答，或者服务器没有收到客户端的心跳，那么对客户端来说则断开与服务器的连接重新建立一个连接，对服务器来说只要断开这个连接即可
短连接的操作步骤是：
建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接
长连接的操作步骤是：
建立连接——数据传输…（保持连接）…数据传输——关闭连接
MQTT协议的另一大特点是提供了三种不同质量的消息传递服务等级：
1．“至多一次”。消息是按照基础的TCP/IP网络进行尽力交付。可能发生信息丢失或重复。这种质量等级可以被使用在传递的消息数据并不十分重要的情况下，例如，检测环境的传感器数据，即使一个单独读取的数据丢失下一个数据也会很快被发布。
- 没有回复，不需要存储。有可能丢失（网络异常断开，业务层繁忙或者错误）
2．“至少一次”，消息能够确保送达，但可能会出现重复。
- 发送者S 发送前需要做持久化存储，接受者R 不需要持久化存储
- 如果 发送者S 没有收到 接收者R 的回复 PUBACK，过一段时间 发送者S 会重新发送，DUP标记为1（在同一Session内）。
- 接受者R 发送 PUBACK 后，不需要知道对方是否收到，马上把消息交给上层业务。如果此时网络异常，会导致发送者重发。这样接受者收到多个消息（所以叫至少一次）。
3．“恰好一次”，消息确保能够送达并且只被送达一次。这种质量等级可以用于计费系统中，因为重复或丢失的消息可能导致不正确的费用统计。
- 发送者S 发送 PUBLISH 前，需要做持久化存储。接受者R 回复PUBREC 后，也需要做持久化存储
- 如果 发送者S 没有收到 接收者R 的回复 PUBREC，过一段时间 发送者S 会重新发送，DUP标记为1（在同一Session内）。
- 如果 接受者R 没有收到 发送者S 的回复 PUBREL，过一段时间 接受者R 会重新发送PUBREC。
- 发送者S 收到 PUBREC后，删除持久化消息，但是要保存 PacketID
- 接收者R 受到 PUBREL后，删除持久化PUBREC。然后将消息发给上层，同时回复 PUBCOMP。
- 发送者S 收到 PUBCOMP 后，删除 PacketID，通信完美结束。
-
这套流程可以 严格保证 一个包不管在什么情况下 接收者R 只收到一次 。
MQTT的QoS机制以及它们的应用场景？MQTT提供了三种QoS机制，第一种是至多一次传输（At most once delivery），这种方式可能会有数据丢包，适用于允许个别数据丢失的场景；第二种是至少一次传输（At least once delivery），这种方式可能会有数据包的重复；第三种是精准一次传输（Exactly once delivery），这种方式只能传输一次并且保证送达，适用于金融支付类不允许丢包和重复的应用场景。
长连接维护与管理
Keep Alive 心跳
- 目的是保持长连接的可靠性，以及双方对彼此是否在线的确认。
- 客户端在Connect的时候设置 Keep Alive 时长。如果服务端在 1.5 * KeepAlive 时间内没有收到客户端的报文，它必须断开客户端的网络连接
- Keep Alive 的值由具体应用指定，一般是几分钟。允许的最大值是 18 小时 12 分 15 秒
每一个订阅需要指定一个QoS，转自：https://blog.****.net/u011216417/article/details/69666752
HTTP是一种同步无状态的协议，不支持推送，设备端需要通过轮询模拟推送，反复的轮询需要耗费额外的资源。
