OneNet5.0 规则引擎+http推送

平台提供数据推送功能，可以将平台作为客户端，将相关信息以HTTP/HTTPS请求的方式，发送给应用服务器。

其中，相关信息包括：

平台发起的HTTP请求主要包括：

用户可以以数据流模板为过滤条件，过滤掉例如设备的频繁的周期性上报等大量时间不敏感数据，只推送用户自己关心的实时性要求较高的数据。

推送功能提供数据压缩的功能，用户可以设置数据量以及时间的压缩方式，将一定时间内的一定量的多包单信息报文，合并成为一包包含多条信息的json数据，可以大大减少应用服务器的处理压力。

以明文模式验证创建:

或者, 以token验证模式创建:

两种创建的get验证方式不同, 详见下一节

get验证有两种方式, 第一种:明文方式, 第二种: token计算

验证流程如下:

根据流程图, 我们收到get 请求后返回msg的内容即可

为此,我使用 koa2写了一个简单的后端应答

这一部分大家可以用自己熟悉的后端来写,

我们把后端程序在自己服务器上运行起来,

当后端程序启动后就能验证成功了

根据流程图, 我们收到get请求后应计算token

计算方法如下:

应用服务器收到请求后，需要对请求参数中的signature字段合法性进行校验，其校验步骤如下：

以下内容全是以 nodejs koa2为例

我们需要模块crypto

(待添加)

平台通过HTTP获取推送数据，需要在项目下的规则引擎页面完成数据源和推送目的地配置，详细操作见 规则引擎使用说明

找到规则引擎界面

这样数据就可以通过规则引擎过滤后推送到http绑定的服务器了

我们使得服务器可以接收POST请求

我们把POST请求直接返回给ONENET, 就被视为接收了请求并回应了

看我们服务器后台收到的数据:

分析下POST的body格式

分析msg的负载数据

分析下POST的body格式:

摘取一条msg看一下:

成熟的媒体应用往往面对这样的需求：

其中一种比较灵活的解决方案是把自定义媒体数据推流为http，而大部分播放器都能很好地支持http（vlc/ffmepg/mediaplayer/ijkplayer/kodi等）。

数据流示意：

本篇文章主要讲解上图的http协议部分。

http协议是应用层协议，使用tcp进行传输。

请求报文是播放器(http客户端)发给http服务器的内容，由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成，如：

响应报文由协议版本、状态码、状态码原因短语、可选的响应首部字段和实体主体构成，如：

流媒体就是像流水一样把视频数据通过网络传输到终端上播放。

通过http推送流媒体的时候，对应的是http的chunk传输。

chunk传输的典型（响应）报文如下：

即，通过 Transfer-Encoding: chunked 告知客户端现在传输的是分块数据，这样客户端就会维持这个连接，直到数据接收完成。

数据传输过程中，每个chunk都是以 大小\r\n数据\r\n 的格式传输，最后以大小0通知客户端数据完成。

流传输在多媒体应用中常用于直播，因为直播的数据长度一般是不定的，这样就可以借助客户端和服务端间的这个长连接持续不断地传输媒体数据。

流媒体的缺点是不能跳进。

不能跳进不仅意味着用户无法seek观看节目，也意味着一些节目的信息无法获取(如时长)。

为了支持跳进，可以借助http的range请求。

range请求常以断点续传闻名，它允许客户端从任何位置开始，向服务器请求任意长度的数据。

比如：

这个请求报文通过 Range 向服务器请求了第500~1000字节的数据(共501字节，第一个字节是索引0)

服务器如果能正确返回这部分数据，就回复：

Accept-Ranges:bytes 意思是接收按字节为单位进行range请求； Content-Range 告诉客户端返回的数据对应的是哪个范围的数据，这里回复的是客户端请求的 500-1000 ，其中 1024 是整个媒体的数据长度； Content-Length 表示返回的数据长度(1000-500+1 = 501)

所以，一般播放器在播放http源的时候要进行seek就是通过发起新的http请求，并在请求中加入 Range 字段来从seek的目标位置读取数据。

然而，实际情况会复杂一些。

其一，播放器可能会在开始播放的时候就会跳转到尾部读取视频数据，以确定节目时长(比如ts封装就需要读取尾部数据来估算视频时长)；

其二，seek可能需要经过多次range请求才能跳转到目标位置(如ffmpeg会用二分查找来查找目标时间点)；

其三，http是无状态的，所以每次客户端来的请求所在的处理线程不一定相同，而且同次点播的多个http请求间是无关联的。这对于静态文件资源而言是无关紧要的，但对于动态内存资源（如动态解密的视频）而言就需要谨慎处理多线程问题和session管理了。

上节了解过，seek基于多次range request的实现机制会导致在一次点播期间，服务端与客户端间会有多次的通信，而http的无状态特性导致这几次通信是无关联的，服务器无从知道这几次通信对应的是同一次点播。

通用的解决方法是利用http的cookie机制，在多次通信中携带id字段进行session关联。示意图如下：

对应于http报文则是：

"第一次通信"：

"你的id是123"：

"我的id是123，Range 500-1000":

"你的id是123，你的请求已受理"：

上面通信过程主要依赖 Set-Cookie 和 Cookie 两个字段保证。协议也很简单，服务端通过 Set-Cookie 给客户端发送 id=123 ，客户端识别如果有 Set-Cookie ，则在下次请求中把 Set-Cookie 的内容放到 Cookie 中通知回服务端。

上述基本就是完成http推流所需要的核心协议了。总结下：

我们将在 http推流设计与实现 这篇文章中介绍 xport ，详解如何自己动手实现一个http推流框架。

HTTP(HyperText Transfer Protocol，超文本传输协议)是一种主要由web使用的协议规范，完成从客户端到服务器端的一系列运作流程。

HTTP协议是基于TCP协议开发的，在网络传输模型中属于应用层的内容。

HTTP/1.0协议最早于1996年正式使用，其主要特点为：

HTTP/1.1协议于1997年正式使用，主要是优化并且扩展了HTTP/1.0的内容，主要特点为

由于HTTP1 HTTP1.x HTTP2都是基于TCP开发的，其中的TCP握手问题就无法避免，为了解决这个问题，Google 就另起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上。其特点主要为：

以上内容均为笔者在看了文章后以自己的理解讲的内容，如有错误，请不吝指正

HTTP3 为什么比 HTTP2 靠谱？ | 技术头条

HTTP1.0、HTTP1.1 和 HTTP2.0 的区别

HTTP/2之服务器推送(Server Push)最佳实践

---