IoT 亿级设备接入层建设实践

一、前言

不同的接入层

互联网的产品基本都需要解决终端的接入问题，每个接入层会因为终端数量、终端能力、网络环境等不同的因素有各自的设计特性，比如：淘宝网需要解决海量短连接问题、微信需要解决海量长连接问题，同时大家都要解决移动网络问题，那么阿里云 IoT 物联网接入层需要解决的是什么？在回答这个问题之前，先来看看物联网的特性

物的特性

既然要解决"物"的问题，那么首先需要了解"物"，先来看看这些"物"包括哪些，这些物有什么特性？

• 居家类：电视机、音箱、开关、灯泡，空调、洗衣机等

• 基础设施类：水表、电表、燃气表等

• 工业场景：产品信息、质量信息、设备能耗信息等

• 安防类：摄像头、门磁、烟感等

• 其他：汽车、手表、眼镜、单车、门锁、充电宝、起搏器等

image

"物"的种类非常多，应用场景、成本各不同，比如水表一般安装在户外，一般采用电池供电，这种设备对能耗的要求非常苛刻，比如基站铁塔的后备电源，一般安装在荒野，这种设备对网络的要求非常苛刻，比如开关，这种设备对存储、内存、cpu 的要求非常苛刻，不同的"物"特性催生了不同的 IoT 接入层，下面来看看 IoT 接入层需要做什么？

二、IoT 接入层需要解决什么问题？

2.1 接入层关键问题

通用接入层需要解决的问题

• 安全性：通道安全、身份安全、数据安全

• 连接方式：采用 TCP、UDP，使用长连接还是短连接？

• 协议选择：http 协议、protobuf 协议、mqtt、coap、私有协议等

• 网络问题：就近接入/就快接入、系统及 TCP/IP 协议内核参数的调优等

• 海量连接问题：当海量连接在线时，怎么保障系统的可用性？

IoT 接入层有什么不同

特性：多样性、碎片化

针对这些设备特性，IoT 接入层需要怎么来解决？

2.3 相同的问题，不同的解法

• 安全性：各种设备都联网后，设备将在我们的生活中更加根深蒂固，给安全带来更大的挑战，比如：汽车、门锁、起搏器等收到安全攻击，那么用户的隐私、财产、生命都会带来严重的威胁。IoT 场景下很多设备对存储、内存、cpu、网络都有要求，那么在设计安全时，就不能简单的通过加强加密的安全方法来解决这个问题，因为它们执行复杂加密和解密的速度不足以让它们实时安全地传输数据。IoT 接入层既要考虑安全性，又要对受限设备做妥协，需要怎么去平衡两者的需求？

• 网络问题：IoT 场景下的网络更加复杂，通信层面包括有广域网技术：GPRS/4G/5G/Lora/NB-IoT 等，有局域网技术：Ble、ZigBee 等，不同的通信模组会有不同的网络质量，怎么来保障网络稳定性，网络 RT 是非常关键的点。IoT 场景下很多设备只能采用局域网通信技术，这类设备不能直接上网，需要边缘网关来代理上网，针对边缘网关的场景，接入层需要怎么设计？一个边缘网关下面可能挂了几万个设备，如果一个通道来处理的话，怎么解决单通道的拥塞问题以及单通道的热点问题？如果多通道来处理，这些通道之间怎么建立网络拓扑模型？    

• 协议选择：一般的接入层只会选择一种协议(比如淘宝的 http、钉钉的 lwp、微信的私有协议)，但是 IoT 不同，它需要支持多种协议，支持这么多协议，就是为了解决不同的业务场景，比如业务场景会主动给设备推送消息(共享充电宝、共享自行车等)，那么需要使用 tcp 长连接来解决，这种情况下采用 mqtt+tcp 协议会比较合理。比如业务只需要设备上报消息(水表、电表等)，不需要发控制指令给设备，那么采用 coap 的 udp 短连接就比较合适，既能省能耗，又能省流量。比如业务需要在浏览器上使用，那么 http 的 tcp 短连接就比较合适，天然的适配。比如业务已经有大量存量设备，同时采用了私有协议，连接了自建的平台，但是现在又想要接入阿里云 IoT 平台，使用平台各种能力(数据分析、监控、生态等)，那么采用泛发接入是比较合理的做法，通过泛发协议把私有协议转成标准协议，设备不需要改动，只要在自建平台做个适配层就可以了。

image

三、怎么解决 IoT 的接入问题，阿里云的优势在哪里？

3.1 安全设计

对于系统设计来说，安全是基础，但又不能因为安全问题影响用户体验，需要在安全性和体验上找到平衡点，同时对于低功耗设备需要有不同的安全考量，那么阿里云 IoT 接入层是怎么来做的呢？

核心思想：通过三层安全防护机制 + 云端的安全风控模型来保证设备的安全性

三层防护机制

第一层：DDos 防护系统

基于阿里云强大、专业的 DDos 安全防护体系，防止 IoT 业务出现重大经济损失、数据泄露等问题，详细参考DDos防护

image

第二层：通道安全

通过支持 TLS、DTLS、X509、ID2 四种方式来解决通道的安全问题，同时针对低功耗设备，做了多个维度的优化

• 不同传输协议上的 TLS：mqtt 协议跑在 TCP 之上，而 coap 协议跑在 UDP 之上，针对不同的传输协议，IoT 接入层分别实现了 TLS、DTLS，用来解决不同协议的通道安全问题

• 流量维度：TLS 认证流程中，需要把服务端证书传给设备端，大概消耗 4K 左右流量，同时要求设备支持非对称加密算法，对于某些低功耗设备来说，能耗、流量、加密能力都是有要求的，IoT 接入层通过 PSK 技术，解决证书传输带来的流量消耗问题，同时解决非对称加密算法对 cpu 的性能损耗问题

• RTT 减少 1 次：TLS 的握手需要 2 次 RTT，正常公网的 RT 50 毫秒，两次 RTT 需要消耗 100 毫秒时间，为了减少网络交互次数，IoT 接入层实现了 sessionTicket 技术，利用 sessionTicket 的复用能力来减少通道建立过程中的 RTT 次数，同时也去掉了证书传输和非对称加密

注：ID2 是阿里云安全团队实现的类 TLS 协议，能力跟 X509 的双向 TLS 对等，同时在双向认证的基础上，减少了设备证书的传输，适用于对安全等级要求较高、同时对设备流量有要求的场景。

第三层：设备身份授权及验证

阿里云 IoT 的设备身份叫三元组，由平台授权颁发的设备身份信息，每个设备全球唯一，在设备建立连接时，设备通过 DeviceSecret 加签设备信息，然后有平台对加签信息进行验证，用来完成设备登陆 IoT 平台，保障设备的安全性。

三元组指的是 ProductKey、DeviceName、DeviceSecret 的组合。

• ProductKey：是物联网平台为产品颁发的全局唯一标识。

• DeviceName：在注册设备时，自定义的或系统生成的设备名称，具备产品维度内的唯一性。

• DeviceSecret：物联网平台为设备颁发的设备密钥，和 DeviceName 成对出现。

云端一体的安全风控体系

为了进一步提升设备的安全等级，阿里云 IoT 建立安全风控模型，针对设备暴力认证、设备恶意连接等行为，采取主动预警，快速阻断等措施，为设备安全保驾护航。比如某个设备不停的来认证，但是每次认证都是因为签名验证而失败，同时设备每次上传的签名又不同，根据这三个条件基本可以判定该设备存在暴力认证的行为。

3.2 网络优化

直连网络

不同的通信模组(GRPS/3G/4G/5G、Ble/ZigBee)，不同的部署环境(电梯、地下车库、荒野)，会导致各种不同的网络差异，给设备的连接稳定性带来风险，阿里云 IoT 针对这些问题，是怎么来解决的？核心思路：让设备就近接入，同时提供稳定、高速的网络环境。阿里云 IoT 接入层通过部署多 region(如下图)的方式来为用户提供就近接入的能力，通过 BGP 网络为设备提供稳定、高速的网络环境。

BGP 网络有什么优势？

• 消除南北访问障碍。由于 BGP 可以将联通、电信、移动等运营商的线路“合并”，使得中国南北无障碍通讯成为可能。对接入层来说，可使“联通、电信”这类区别消失，更能使一个网站资源无限制的在全国范围内无障碍访问，而不需要在异地部署 VPN 或者异地加速站来实现异地无障碍访问。

• 高速互联互通。原来一条线路访问另一线路往往要经过很多层路由，但实现 BGP 以后就像进入了高速公路。

• 质量最好的网络：从运营商网络质量来看，BGP 带宽是中国内地地域目前最昂贵的、线路质量也是最好的线路。对于延迟要求比较苛刻的业务可以使用 BGP 线路来解决。

image

就近接入

先来看看用户怎么就近接入？分两种情况：

• 设备使用的区域确定：设备厂商在生产设备时，已经知道设备需要卖到哪些地方，对于这类情况，设备直接写死就近的 region 接入地址就可以了。

• 设备使用的区域未定：设备在生产时，并不清楚设备在哪个区域使用？这种情况肯定不能直接写死一个接入地址了，这种情况下，首先需要解决的是设备的区域归属问题，解决这个问题有两种方式：一种方式是让用户指定设备的归属地，这种方式比较普遍，比如买苹果产品时，不管 iphone，ipad 都会在设备初始化时要求设定一个归属地，还有一种是根据设备 IP 地址来判定，可以做到无人工干预，完全自动化，但因为 IP 库存在一定的误差，这种自动化同时也会带来归属地判定的错误。

那么阿里云 IoT 针对这两种归属地判定场景做了什么优化？

• 用户指定归属地：用户可以在配网的时候设置归属地到设备里，也可以在阿里云 IoT 平台提前预置设备的归属地，设备只需要在接入 IoT 平台之前去设备引导服务获取就近接入点地址就可以了。 这里有个问题：去哪里获取设备接入点地址？阿里云 IoT 只部署一个中心，然后通过全球设备引导服务中心+加速通道+智能域名来解决这个问题。

• 自动判定设备归属地：为了减少 IP 判定带来的误差，阿里云 IoT 支持产品的多区域指定能力，比如可以指定设备可能会在新加坡，上海、美东等地使用，然后动态的根据 IP+设定区域来判定设备归属地，这样的精度就会有明显的提升。

region 覆盖不到的区域的网络优化方案

阿里云 IoT 通过多 region 部署来满足设备的就近接入，但是 region 数量有限(部署 region 的代价较大)，不能解决一些偏远地区的网络问题，IoT 接入将通过部署前置节点 + 智能动态路由能力来解决这个问题。比如把 IoT 前置接入点(不需要部署整个 region)部署在离偏远地区最近的机房，然后通过该前置接入点代理设备登陆到指定的 region 中，然后在前置接入点跟指定 region 部署加速通道，这样就能解决这些偏远地区设备的网络问题。        

image

边缘网关

针对网关设备，如果子设备较多的情况下，会带来哪些问题？

• 网关下有 10w 个子设备，同时每个子设备定时数据上报，需要怎么设计？

• 网关下的 10w 个子设备，因为网关下线，全部需要断线重连，需要怎么保障子设备快速上线？

大数据的上报的解决方案

image

阿里云 IoT 的网关技术方案核心技术点：

• 多通道：一个网关有多条物理 TCP 连接，每个物理连接等价，网关可以往任意一个物理连接发送或者接受数据

• 子设备虚拟连接：网关代理子设备上线，每个子设备对应一个虚拟连接的 session

• 子设备 &自连设备打平：服务器对子设备跟直连设备等同处理，唯一差别就是直连设备有独立 channel，子设备是共享物理 channel，这样设计便于设备的各种运维操作

通过多通道解决了网关的海量数据上报问题、通道的热点问题，同时解决了通道容灾问题。

通过虚拟连接解决了子设备通道复用的问题，不需要为每个子设备建立一个 TCP 连接。

通过子设备和直连设备打平解决了各种运维的复杂性，子设备相当于一个直连设备。

子设备的登陆慢的解决方案

核心思想：优化登陆速度、减少离线次数、延迟离线时间+增量同步策略。

业务场景：针对不同的子设备数量，可以采取不同的策略，比如子设备在 1000 以内，可以只提升登陆速度就可以了，如果子设备在 10w 以上，建议多种策略配合，同时根据业务对设备的状态敏感度来定义这些策略，比如子设备全部下线了，业务都无所谓，那么建议网关按简单的来处理，串行/并行批量登陆都是可以的。

优化策略：

• 提升登陆速度：通过并发批量登陆来解决。

• 减少离线次数：首先需要定义网关离线，只有网关的全部通道都断开了，才认为网关断开，这样可以通过多通道的模式来减少网关的离线次数。

• 延迟离线时间+增量同步策略：服务端只有在网关离线一段时间后，才会把所有子设备下线，如果网关在这个时间段内重新登陆，那么网关只需要登陆/离线在这个时间内有变动的子设备。

其他优化点

阿里云 IoT 接入层不尽对应用层做了很多积极的优化，同时对系统内核、CPU、网卡、TCP 内存参数都做了优化，连针对防火墙、路由器等中间网络设备都专门做了优化

TCP/IP 内核参数优化

• TCP 三次握手的优化：半连接队列、全连接断链、syn 重试策略、syn+ack 重试策略、fastopen 等

• TCP 传输的优化：初始窗口大小优化、tcp 内存优化、支持缓冲区的动态调整、快速重传策略等

• TCP 四次挥手的优化：主要是针对 time_wait 状态的优化、孤儿连接优化

系统优化

• 网卡队列大小优化

• 利用 reuseport 来提升 TCP 建连性能

针对防火墙的优化

• 对于 mqtt 的 1883 端口，有些防火墙可能会阻断连接，阿里云 IoT 通过支持 443 端口来绕过这个问题

针对路由器的优化

• 对于一些非标的路由器，可能不支持分片，因为 MSS 报文太大而被这些中间路由器丢弃，导致设备连接不上或发送数据异常，阿里云 IoT 通过优化 MTU 大小来解决这个问题

3.3 架构设计

对于协议的选择，阿里云 IoT 采取的是标准化策略，通过标准化来解决设备之间的互通问题，通过标准化来解决设备接入平台的理解成本，标准的好处很多，不一一列举。这里主要讲讲多种标准协议和接入层怎么适配？怎么在系统发布时，设备做到无感？怎么让每个设备在连接层、协议层都做到连接高可用？

协议层和接入层适配

核心思想：接入层、协议层分离，让接入层更纯粹、让协议层支持更多的能力。接入层更纯粹指的是什么、协议层支持更多的能力是什么意思？

• 接入层更纯粹：让接入层只做接入的事情，包括：基础网络优化、智能路由、TLS 卸载、证书管理、限流等，这样做的好处很明显，接入层只有基础能力，不支持任何业务特性，没有业务特性也意味着减少系统变更，减少了系统变更意味着更加稳定(据统计 80%以上的故障都是变更引起的)，同时为了解决接入层发布带来的设备批量断连问题，阿里云 IoT 接入层支持二进制热更新能力，在接入层发布过程中，可以不断开设备连接，同时为了让设备更快的体验新能力，可控的触发设备重连(比如针对连接一直稳定的设备，在发布新功能后，让设备在低峰期慢慢的重连)，通过不同的组合策略，让设备连接更稳定。

• 标准协议层支持更多的能力：这里的能力指的是在协议层上做的各种业务特性，同时也包括协议本身的扩充能力。业务特性包括实例逻辑隔离、实例规格能力限制等，协议的扩充：比如 mqtt 3.1 通过 pub、sub 来模拟通用的 RPC 能力(解决用户控制设备的能力，比如用户通过手机借用共享充电宝的业务)，通过 clientId 字段打标来支持 payload 的解压缩能力，通过压缩能力减少设备的流量，通过智能心跳机制减少心跳报的发送。

通过两层分离机制，让接入更稳定，同时让业务更快的迭代发展。

3.4 连接高可用

通用的高可用策略：副本、隔离、failover 机制。副本是最常用的做法，对于连接来说，副本就是每个设备建立多通道，如果同一个设备有多个通信模组(比如：4G+wifi)，还可以根据不同的模组建通道，这个成本对于设备端和服务端来说都会比较高，想做成通用比较麻烦，但是对于边缘网关设备确实可能会有这种业务场景，后续我们会支持起来，那么阿里云 IoT 现在的策略是什么？隔离 + failover

• 连接型实例的物理隔离(隔离)：提供连接型实例，让设备可以独占物理资源，在物理上做到实例的连接完全隔离。

• 设备端重试(failover)：提供 SDK 支持设备快速重连能力，同时支持重连的指数退避策略，防止因为服务本身问题而不停的重连，导致设备资源的消耗。

• 每个设备独享一条通道(隔离+failover)：设备<-->接入层<-->协议层，这三者之间一一对应，这样做的目的是每个设备的连接不会相互影响，在该连接通道上的消息上下行全部隔离。接入层<-->协议层之间也支持了 failover 能力，比如当协议层应用发布时，接入层会自动把该通道 1-1 恢复到另一台协议层上，做到了设备无感知。

四、结尾

IoT 接入层涉及的技术点非常多，上面只是针对 3 个核心的问题做了简单的介绍，后续会陆续展开介绍其关键点。 比如：设备 SDK 是怎么设计的？统一接入层技术细节有哪些？整个接入层的高可用是怎么保障的等等，