物联网面临的四大现代挑战

物联网面临的四大现代挑战

1 物联网的硬件设计

人们首先要从 社会 发展的角度来考虑物联网的发展。在以往，与互联网连接的设备的问题是硬件设计。

起初，笔记本电脑通过Wi-Fi连接到互联网，但由于缺乏相应的通信基础设施，人们无法在任何地方使用Wi-Fi，所以笔记本电脑也并不方便携带和使用。

在2007年苹果发布iPhone之前，连接到互联网的手机的用户体验通常非常糟糕。而目前iPhone和Android手机应用非常普遍，人们通常使用手机访问互联网。

与此同时，还推出了一些连接互联网的可穿戴设备，如智能手表和腕带，其功能包括帮助监测人们的 健康 状况。

最近，智能家电已经成为智能家居的重要组成部分。例如，智能电视成为最常见的设备。人们可以直接观看在线视频并上网冲浪。此外，更多智能家电将以智能冰箱、智能烤箱、智能洗衣机、智能加热器的形式进入人们的家中。

一开始，笔记本电脑和手机使用2G/ 3G网络。如今，Wi-Fi和4G是最常用的通信技术。当可穿戴设备连接手机时，由于其能源效率的原因，蓝牙技术是最佳选择。但是由于某些应用场景的限制，这些技术无法扩展。例如，智慧城市使用传感器的特性来收集数据并将其发送回服务器。这些传感器通常无法使用Wi-Fi。通常，传感器与服务器之间的距离很长，因此蓝牙技术无法在这样的应用中使用。

2低功耗远程通信

为此，行业厂商开发了一些低功耗和长距离通信技术，称为低功耗广域网。 LoRa是一种流行的无线电调制技术，它促进了许多应用，例如智能远程测量仪，但仍有很多工作要做。

物联网设备传统上是采用传感器来收集数据或控制器。当人工智能应用于这些设备时，这些设备将变得越来越智能。由于物联网设备没有足够的计算能力来处理收集到的数据，因此将它们发送回服务器。然而，目前它耗费了太多的通信能量，而物联网设备并不总是能够上网。

3 人工智能集成物联网

最近，学术界和工业界开始应用机器算法，而不是“云计算”。iPhone X中的Face ID就是一个很好的例子。实际上，直接在手机上运行这些人工智能算法并不容易，因为这些算法是为服务器或计算机设计的，而不是针对物联网设备的。因此，需要考虑资源受限的物联网设备的优化。因此，更智能的物联网应用将变得更加可用。

4物联网设备的安全

工程师的另一个任务是确保物联网设备的安全。由于计算资源受限，物联网设备容易受到网络攻击。与个人电脑不同，人们无法在其上安装任何防病毒软件，其方法也不高效。为了保护物联网设备，需要仔细设计替代的安全方法。而且，物联网设备也能收集敏感数据。

在未来一年中，与物联网相关的更多技术将会逐渐成熟并应用于人们的日常生活中，以提高生活质量，但这四个技术领域需要取得更多的进展。

通过加密来保护物联网传输层能够进一步提高物联网传输层的安全性。
在工业、医疗、运输及其他关键应用中，对物联网应用的依赖程度迅速增加，这极大地改变了安全格局。以往，企业应用普遍拥有随时可用的资源来处理安全算法，但如今企业级物联网应用却饱受威胁日益增多之苦，且其攻击目标是不断扩大的资源受限型物联网设备网络。企业在急于迎接快速涌现的物联网机遇时，部署的物联网设备在功能上往往无法支持基本的安全措施，因此难以保护存储的数据，且无法保证在易受攻击的网络上进行数据和命令交换。所以要通过加密来保护物联网传输层。

IOT网关，接收sensor数据的总入口，主要是日志，安全防护，流控，协议转换等功能，

图1 IOT网关

之前有提到IOT网关是基于python的twisted框架实现的，初期的时候该IOT网关主要实现的功能是 数据接收和转换功能 和 安全防护 。

数据接收和转换功能 ，这里很简单，拟定好数据交互格式后，IOT网关按照约定好的格式进行解析，然后转发给后端服务进行进一步的处理

安全防护 ，设备的区分主要是依靠烧录到硬件的SN号来实现，SN号包含的信息比较多，如生产批次，设备型号等，受制于厂商我安全防护不能做的非常完善，同时sensor与IOT网关的交互不能非常复杂。安全防护这一块理论上是设备接入要一型一密或者一机一密，协议上还应该启用tls/ssl安全通信协议。

图2 鉴权

安全防护要做ssl这类的安全通信协议的话，要考虑设备厂商实现通信模块能力，设备功耗，设备性能（低端设备cpu性能可能比较差，可考虑对称加密形式），IOT网关也需要引入相应模块。

另外认证从性能方面考虑，后期在设备比较多的情况下，可以加入redis等内存型key-value数据库，缓存设备信息，提高鉴权模块性能。

实践中，我们的sensor基本都是依靠电池供电，因此我们的IOT网关基本是面向短链接（后期我们有监测设备，依靠外部电源直接供电，为长连接），因此在每次发起连接我们都要进行一次鉴权，鉴权通过后，设备方可上传传感器监测数据和设备自身状态。

图3 数据交互流程

这一块的调试工作长达半年左右，才基本稳定下来，主要集中在设备商处除了硬件稳定性，还有在调试中发现传输的字符串乱码（c语言处理问题），沾包（厂商开发人员tcp协议不熟），优化传输效率，关闭cork或者 Nagle 算法（传输包很小）。

因为IOT网关不能主动断连接，理论 *** 作中，IOT网关应该和sensor有心跳协议，保证连接的有效性。设备商在数据流程交互完成后，竟然没有close 连接，直接休眠，导致网关所在服务器的连接的文件描述符一直没有正常释放，后面为了预防这种现象，我开启了 *** 作系统层面的keepalve定时器，回收失效连接（系统默认时间是2小时左右，我缩短了失效时间），理论上来说应该是应用层面去实现心跳协议。

整个IOT网关的设计，是无状态，可伸缩的，单网关在普通型ecs上可轻松达到数百tps。

---