开源LoRa网关与服务器
IBM有提供过一个几个基于原始空口物理层协议的资产定位原型,使用了Node Red等,没有使用LoRaWAN。所以,封闭系统未见得要使用LoRaWAN,除非目标是标准化的公开系统。
国内的许多应用,如智慧城市、船务管理等,一旦需要多家供应商参与,则尽量参考LoRaWAN进行部署。
浏览了一下Github中的开源LoRaWAN网关与服务器,因为这两者与设备,存在配套的必要性。当然,通过配置可以整合这三者。但是设备与网关之间配置难度要大于网关与服务器之间配置难度。
大体上,LoRaWAN终端都来自IBM LMiC参考设计,无论是mbed/Arduino都是衍生版本。只是需要根据不同地区和频率进行设计。主要频段包括:
还有其他的一些频段,但是大体上就是这些频段了。
一般公众IoT LPWAN网关已经标准化了。所以采用LMIC参考设计的设备既可以接入,担心是附近没有LoRaWAN基站。所以有个鸡和蛋的关系。
LoRaWAN网关和服务器之间,有若干种连接方式:
采用TLS over TCP,使用MQTT,比较适合网关与服务器之间的通讯。这样,满足了安全性,连接性要求。
在LoRa联盟中,The Things Network (TTN) 是一个经常被提及的网络服务,该公司为诸多LoRaWAN网关提供网络接入托管服务,同时为用户应用提供REST接口。
一般来说,云端算是比较重要的,且耗费开发时间的。但是现在也有开源的设计: https://wwwloraserverio 。而且,VM/Vagrant/Docker一应俱全。
云原生相关技术
依据CNCF发布的云原生10版本的定义,云原生技术主要包括容器、微服务、服务网格、不可变基础设施以及声明式API:
容器技术
容器技术和云原生好比一对螺旋体,容器技术催生了云原生思潮,云原生生态推动了容器技术发展。从2013年Docker技术诞生,到2015年CNCF这个云原生领域重量级联盟成立,这不是历史的巧合而是历史的必然。作为云原生关键技术之一的容器,从2013年诞生以来一直是行业关注的焦点之一。
2013年之前,云计算行业一直在为云原生的正确打开姿势而操心。Platform as a Service(PaaS)看起来是个有前途的方向。2006年Fotango公司发布的Zimi服务,可以说是PaaS行业的鼻祖,具有按使用付费、免运维(Serverless)、API化配置和服务等典型云原生的特征;2008年Google推出Google App Engine(GAE);2011年Pivotal发布Cloud Foundry。
这些早期的PaaS平台在云原生领域进行了非常有益的探索,推动了云原生生态的健康发展,但是这些早期探索技术并没有形成大的行业趋势,而是局限在一些的特定的领域。直到Docker开源,大家才如梦方醒,原来不是方向不对,而是应用分发和交付的手段不行。
Docker真正核心的创新是容器镜像(docker image),一种新型的应用打包、分发和运行机制。容器镜像将应用运行环境,包括代码、依赖库、工具、资源文件和元信息等,打包成一种操作系统发行版无关的不可变更软件包。
容器镜像打包了整个容器运行依赖的环境,以避免依赖运行容器的服务器的操作系统,从而实现“build once, run anywhere”。容器镜像一旦构建完成,就变成read only,成为不可变基础设施的一份子。
微服务
微服务架构是相对于单体架构来说的,两者分属不同的架构风格。在微服务架构中,服务是一个单一的、可独立部署的软件组件,它实现了一些有用的功能,服务的API封装了其内部实现,与单体架构不同,开发人员无法绕过服务的API直接访问服务内部的方法和数据,因此,微服务架构强制实现了应用程序的模块化。
微服务架构的最核心特性是服务之间的松耦合性。服务之间的交互采用API完成,这样做就封装了服务的实现细节,从而实现了在不影响客户端的情况下,对实现方式做出修改。
微服务架构通过将大的系统按照业务服务的粒度进行拆分,每个服务可独立开发、测试、验证和部署,这样分解后,带来的好处有如下几点:
使大型的复杂应用程序可以持续交付和持续部署
每个服务都相对较小并容易维护
服务可以独立部署
服务可以独立扩展
微服务架构可以实现团队的自治
更容易实验和采纳新的技术
更好的容错性
服务网格
服务网格是用于处理服务间通信的专用基础设施层,负责在微服务间进行可靠地请求传递。服务网格通常通过一组轻量级网络代理来实现,这些代理与应用程序代码一起部署,而不需要感知应用程序本身。
随着规模和复杂性的增长,服务网格包含的实现的功能越来越多,它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等。
服务网格有如下几个特点:
应用程序间通讯的中间层
轻量级网络代理
应用程序无感知
解耦应用程序的重试/超时、监控、追踪和服务发现
如果用一句话来解释什么是服务网格,可以将它比作是应用程序或者说微服务间的TCP/IP,负责服务之间的网络访问、限流、熔断和监控。对于编写应用程序来说一般无须关心TCP/IP这一层(比如通过HTTP协议的RESTful应用),同样使用服务网格也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情,比如Spring Cloud、OSS,现在只要交给服务网格就可以了,从而极大地方便了微服务应用的开发。
不可变基础设施
一个工作负载(比如容器、虚拟机等)一旦部署以后就不会被修改。当需要更新,修复或修改某些内容的时候,只需要将新的、经过验证的工作负载替换旧的即可。
不可变基础设施的作用主要体现在系统的稳定性方面。传统的应用程序一旦部署到用户特定的服务器上以后,服务器系统是会不断变化的,不是操作系统升级,就是安装了新的应用,可能引起冲突,导致应用程序需要跟着用户系统环境的改变而不断升级,这中间就会不断地出现新的问题。而不可变基础设施就规避了所有的这些问题,因为云原生应用是部署在不可变的基础设施上的,因此就不存在变化的问题。
声明式API
声明式API是一种比命令式API更高级的接口设计方式,简单来说,命令式API提供给用户怎么做的能力,而声明式API给用户提供了做什么的能力。
声明式API是比命令式API更高级的一种接口,举个例子,假如我们有一个炒菜机,如果炒菜机提供的接口是放油、放调料、放食材、大火、小火等操作,那就是命令式API。
如果炒菜机提供的接口是来盘宫保鸡丁、来盘鱼香肉丝之类的,那就是声明式API了。声明式API比较典型的例子就是数据库提供的SQL接口,只需要告诉数据库你需要什么数据即可,至于怎么去获取这些数据,数据库自己会去按步骤操作。
PPTP,L2TP,IPSec和SSL ***的区别为:性质不同、用途不同、应用不同。
一、性质不同
1、PPTP:PPTP是由包括微软和3Com等公司组成的PPTP论坛开发的一种点对点隧道协议。
2、L2TP:L2TP是IETF基于L2F (Cisco的第二层转发协议)开发的PPTP的后续版本第 2 层隧道协议 。
3、IPSec:IPSec是封装、路由与解封装整个隧道过程的隧道模式。
4、SSL ***:SSL ***是在应用协议传输第一个数据字节以前,彼此确认,协商一种加密算法和密码钥匙的SSL协议。
二、用途不同
1、PPTP:PPTP通过跨越基于 TCP/IP 的数据网络创建 *** 实现了从远程客户端到专用企业服务器之间数据的安全传输。
2、L2TP:L2TP为跨越面向数据包的媒体发送点到点协议 (PPP) 框架提供封装。
3、IPSec:IPSec主要是为了与其他不支持 IPSec 上的 L2TP 或 PPTP *** 隧道技术的路由器、网关或终端系统之间的相互操作。
4、SSL ***:SSL ***在数据传输期间,记录协议利用握手协议生成的密钥加密和解密后来交换 的数据。
三、应用不同
1、PPTP:PPTP在要跨越公司 IP 网络或公共 IP 网络上使用。
2、L2TP:L2TP在IP(使用UDP),桢中继永久虚拟电路 (PVCs),X.25虚拟电路(VCs)或ATM VCs网络上使用。
3、IPSec:IPSec应用于路由器、防火墙、代理服务器或其他安全网关中。
4、SSL ***:SSL ***置身于网络结构体系的 传输层和应用层之间。
物联网 (internet of thing) ,表示的是可以把一些带某些传感器的设备(终端),接入到互联网的行为。
通过互联网连接这些设备,这些设备就能够互相协作。
而 MQTT 就是这些设备之间数据通信的一个基于 TCP/IP 的协议。
每个终端都和实现了 MQTT 协议的代理/服务器相连。
通过 published MQTT 代理服务器的某个 主题 发送数据。
通过 subscription 从 MQTT 代理服务器获取自己订阅的 主题 数据。
MQTT 协议是一种轻量级的、灵活的网络协议。并且非常适合 IOT 的场景。
大多数开发人员已经熟悉了 HTTP WEB 协议。那么为什么不让 IOT 设置链接到 WEB 服务?
设备可以采用 HTTP 请求的形式发送数据,并采用 HTTP 响应的形式从服务器获取数据,接受更新。
因为对于 IOT 的设备来说,这种 主动请求--> 被动等待应答的 数据传输模型存在严重的局限性:
那么,MQTT 为什么如此轻便且灵活?MQTT 协议的一个关键的特性是 发布/订阅模型 。它将数据的发布者和接受者分离。
一个设备终端既可以是数据的发布者 (published) 也可以是数据的订阅者 (subscription) 。
一个设备如果要发布数据,只需要往代理服务器中 相应的主题发布数据内容即可。
一个设备如果需要接受到数据,只需要在代理服务器中, 提前订阅自己需要关注的主题即可。
MQTT 最基本的体验,就是使用 mosquitto 。
Mosquitto是一款实现了 MQTT v31 协议的开源消息代理软件,提供轻量级的,支持发布/订阅的的消息推送模式,使设备对设备之间的短消息通信简单易用。
它可以理解成一个 MQTT 的代理服务器。
基本步骤如下:
安装成功截图
使用 brew services start mosquitto 启动 MQTT 服务
运行截图
然后再打开另外两个终端窗口,模拟两个IOT设备。A 订阅 MQTT 服务。B 向 MQTT 的服务发送数据。
A订阅当前MQTT的某个服务。
B向 MQTT 服务器发布(published) 数据。
然后,我们就可以在A控制台里看到由 B 通过 MQTT 服务发送的数据了。
基本流程图
控制台 A 向 MQTT 服务器订阅 dw/demo 服务,并被动的等待 MQTT 服务器返回数据。
控制台 B 主动的向 MQTT 服务器的 dw/demo 服务发送 published 数据,之后。服务器会主动向事先订阅了 dw/demo 的终端分发此消息。
MQTT 是一种链接协议,它指定了如何组织数据字节并通过 TCP/IP 网络传输它们。但实际上,开发人员并不需要链接这个链接协议的具体细节。我们只需要知道,每条消息都有一个命令和数据有效负载。该命令定义消息类型(比如 CONNECT 消息或者 SUB SCRIBE 消息)。所有的 MQTT 库和工具都提供了直接处理这些消息的基本方法,并且能自动填充一些必要的字段(在数据包的对应字节填充),比如消息和客户端 ID。
首先客户端发送一条 CONNECT消息 来链接代理。CONNECT 消息要求建立从客户端到代理服务器的链接。
CONNECT 命令的基本参数
当客户端向代理服务器发送一条 CONNECT 命令之后,服务器会调用 CONNACK 命令,告知服务链接的状态。
CONNACK 命令的基本参数
当客户端和服务器建立连接之后,客户端就可以向服务器订阅某些主题的。(发送一条或多条 SUBSCRIBE消息 )。
表明当服务器接受到其他终端推送的此主题数据时,服务器会默认发送给它。
SUBSCRIBE 参数列表
当客户端成功的向服务器订阅某个主题之后,服务器会返回一条 SUBACK 的消息,其中包含一个或者多个 returnCode 参数。
SUBACK消息参数
returnCode : 值 0 - 2 ,表示成功订阅,并返回这个订阅消息的 QOS。值 128 : 订阅失败。
既然客户端可以向服务器订阅某个主题,当然也可以取消订阅。
与 SUBSCRIBE 订阅命令相反的命令是 UNSUBSCRIBE 取消订阅命令。
此命令非常简单。只有一个topic(主题)参数。
上面讲的是订阅,订阅是需要有消息从服务器发送过来的。但是服务器本身基本不产生数据,那数据从何而来呢?
通过另外一个客户端执行 PUBLISH 命令,往代理服务器发送数据。并最终通过代理服务器将数据传递给订阅了此服务的客户端。
PUBLISH 消息参数
对于 MQTT 的一张基本理解图
基本流程图:
最后总结
参考资料:
如果是学习的话我推荐你去看看Linux、FreeBSD系统中与网络有关的那些命令程序的代码,比如ping、tcpdump等等,他们还有很多更强大的开源替代方案,比如mtr,都是学习的好材料。这些程序都追求把一件事情做到极致,所以往往结构清晰却又不会过于简单,你看看光是下载就有wget和curl两大神器够你折腾了。Linux和FreeBSD的这类自带命令虽然功能相同,但往往实现方式有很大差别,对比阅读效果甚好。
ebbench是一个在linux下使用的非常简单的网站压测工具。它使用fork()模拟多个客户端同时访问我们设定的URL,测试网站在压力下工作的性能,最多可以模拟3万个并发连接去测试网站的负载能力。Webbench使用C语言编写,代码实在太简洁,源码加起来不到600行。下载链接:GitHub-EZLippi/WebBench
Tinyhttpd是一个超轻量型HttpServer,使用C语言开发,全部代码只有502行(包括注释),附带一个简单的Client,可以通过阅读这段代码理解一个HttpServer的本质。下载链接链接:GitHub-EZLippi/Tinyhttpd
高性能web服务器nginx:download
C语言写的事件驱动框架libevent/libevent·GitHub
ACE:C++面向对象网络变成工具包
BoostAsio:用于网络和底层I/O编程的跨平台的C++库
Casablanca:C++RESTSDK
cpp-netlib:高级网络编程的开源库集合
Dyadc:C语言的异步网络
libcurl:多协议文件传输库
Mongoose:非常轻量级的网络服务器
Muduo:用于Linux多线程服务器的C++非阻塞网络库
net_skeleton:C/C++的TCP客户端/服务器库
nopec:基于C语言的超轻型软件平台,用于可扩展的服务器端和网络应用。对于C编程人员,可以考虑nodejs
Onion:C语言HTTP服务器库,其设计为轻量级,易使用。
POCO:用于构建网络和基于互联网应用程序的C++类库,可以运行在桌面,服务器,移动和嵌入式系统。
RakNet:为游戏开发人员提供的跨平台的开源C++网络引擎。
Tufo:用于Qt之上的C++构建的异步Web框架。
WebSocket++:基于C++/BoostAiso的websocket客户端/服务器库
ZeroMQ:高速,模块化的异步通信库
这个网站整理的比较全,可以看看ezlippicom的页面另外编写高性能web服务器当然离不开缓存啦,可以关注下Redis和Memcached
0条评论