ACS与CPE的全双工实现

移动开发
ACS实现对CPE的远程管理,核心便是ACS与CPE之间的连接交互,本文主要讲解ACS和CPE之间的全双工实现。

Part 01

TR069协议简介 

协议即约定,通信协议约定了通信双方交互所遵循的方式和细则。TR069协议约定用户侧设备(Customer Premises Equipment,即CPE)和自动配置服务器(Auto-Configuration Server,即ACS)之间交互的规则。我们知道HTTP协议是基于TCP协议,COAP协议是基于UDP协议,而这里的TR069协议则是基于HTTP1.1的协议传输,SOAP标准封装XML的消息内容格式,消息内容部分如下图1:

图片

Part 02

TR069协议用途 

TR069协议提供了对下一代网络中家庭网络设备进行管理配置的通用框架、消息规范、管理方法和数据模型。在网管模型中,ACS负责对终端设备CPE进行远程集中管理,解决CPE设备的管理困难,节约维护成本,提高问题解决效率。


图片

ACS实现对CPE的远程管理,核心便是ACS与CPE之间的连接交互。不同于MQTT协议,客户端与服务器之间维持一个长链接,ACS同CPE的连接仅在存在交互需要时建立短链接。

Part 03

CPE连接ACS 

CPE首次启动会主动对ACS发起HTTP连接,进行注册上线动作,通过RPC方法中的inform方法上报0 BOOTSTRAP和1 BOOT(如上图SOAP封装的XML消息内容案例),如平台有需要配置或者获取的参数,也会在这次连接中进行。交互如下:


图片

第一步:CPE直接对ACS发起HTTP连接请求,请求案例头部如下:

POST /ACS-server/test HTTP/1.1
SOAPAction:
Content-Length: 3923
......

第二步:ACS响应401,要求CPE进行HTTP Digest Authentication认证,即摘要认证,响应案例如下:

HTTP/1.1 401 Unauthorized
Server: XXX
WWW-Authenticate: Digest
realm="XXX",qop="XXX",nnotallow="5ad62dabf90594eed8d2d72cec12e5f9",opaque="60D0FDDCC498497B82138713D1383D9F"
......

第三步:CPE根据ACS响应的WWW-Authenticate信息,以及url、username和password,按照摘要认证算法计算response,构建出再次请求的摘要认证信息Authorization,并再次发起HTTP请求,进行inform上报。携带认证信息再次请求,案例如下:

POST /ACS-server/test HTTP/1.1
SOAPAction:
Authorization: Digest realm="XXX", username="XXX", algorithm="MD5", nnotallow="5ad62dabf90594eed8d2d72cec12e5f9", uri="/ACS-server/test", nc=00000001, cnnotallow="12327701", respnotallow="XXXXXX", opaque="60D0FDDCC498497B82138713D1383D9F", qop="XXX"
Content-Length: 3923
......

第四步:ACS响应200 OK,SOAP内容为InformResponse,摘要认证到这里已经完成。根据响应头的Set-Cookie信息设置CPE下个请求的Cookie。案例如下:

HTTP/1.1 200 OK
Server: XXX
Set-Cookie:
JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29; Path=XXX;XXX
......

第五步:CPE发起的一个空的HTTP请求,根据TR069协议,消息体长度必须为0,如下案例可以看到Content-Length是0:

POST /ACS-server/test HTTP/1.1
Authorization: Digest realm="XXX", username="XXX", algorithm="MD5", nnotallow="5ad62dabf90594eed8d2d72cec12e5f9", uri="/ACS-server/test", nc=00000002, cnnotallow="12327701", respnotallow="XXXXXX", opaque="60D0FDDCC498497B82138713D1383D9F", qop="XXX"
Content-Length: 0
Cookie:
JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29
......

第六步:ACS响应HTTP 空请求,封装SOAP调用RPC方法,对终端设备进行参数配置或者查询等操作。

HTTP/1.1 200 OK
Server: XXX
Content-Type: text/xml;charset=UTF-8
Content-Length: 2226
......

第七步:CPE发起请求,封装SOAP对应响应RPC方法。如果终端管理平台查询后还需要进行配置,则第六步和第七步会有两次,如都不需要,则第六步和第七步可省略。如存在,案例如下:

POST /ACS-server/acs HTTP/1.1
SOAPAction:
Authorization: Digest realm="XXX", username="XXX", algorithm="MD5", nnotallow="5ad62dabf90594eed8d2d72cec12e5f9", uri="/ACS-server/test", nc=00000003, cnnotallow="12327701", respnotallow="XXXXXX", opaque="60D0FDDCC498497B82138713D1383D9F", qop="XXX"
Content-Length: 528
Cookie:
JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29
......

第八步:ACS下发一个空HTTP响应,根据TR069协议,状态码使用“204(无内容)”,表示本次会话结束。案例如下:

HTTP/1.1 204 No Content
Server: XXX
Date: Fri, 23 Jan 2023 00:15:14 GMT

这里我们针对第三步的摘要认证展开说明。这里简要说明下WWW-Authenticate和Authorization中涉及到的一些参数,更多详细内容可以自行参阅RFC2617等相关文档。

➤ digest ==>认证方式

➤ realm ==>领域,领域参数是强制的,必须存在

➤ qop ==>保护的质量,“auth”表示只进行身份查验, “auth-int”表示进行查验外,还有一些完整性保护

➤ nonce ==>服务器侧生成的随机数,在每个401回应产生时,被唯一创建,为防止攻击产生,参与加密

➤ cnonce ==>即client nonce

➤ uri ==>客户端想要访问的URL

➤ nc ==>连续请求次数,在同一个TCP连接里,设备每POST一次,nc+1

➤ algorithm ==>用来生产摘要及校验和的算法对

➤ response ==>用来证明用户是否知道口令

response计算通常过程分以下三步[2]

第一步:计算HA1

  • HA1=MD5(A1)=MD5(username:realm:password);

第二步:计算HA2

  • 如果 qop 值为“auth”或未指定,那么HA2=MD5(A2)=MD5(method:uri);
  • 如果 qop 值为“auth-int”,那么HA2=MD5(A2)=MD5(method:uri:MD5(entityBody);

第三步:根据HA1和HA2计算response

  • 如果 qop 值为“auth”或“auth-int”,那么respnotallow=MD5(HA1:nonce:nc:cnonce:qop:HA2);
  • 如果 qop 未指定,那么respnotallow=MD5(HA1:nonce:HA2) 。

Authorization构建:CPE端生成cnonce,nc从00000000开始累计,response根据上述公式计算,opaque、qop、nonce、realm继承自WWW-Authenticate,添加上username、algorithm和uri。

此外,终端管理系统可能还会对Manufacturer、OUI等参数进行查验,如查验不通过,响应403,即服务器理解客户的请求,但拒绝处理它。

Part 04

ACS连接CPE 

通过ACS对CPE进行参数配置时,ACS作为主动方触发本次连接。此时,ACS主动连接CEP,方式有两种:

(1)非NAT模式下,ACS对CPE发起HTTP连接请求,使用终端上报的地址:Device.ManagementServer.ConnectionRequestURL,终端要求进行HTTP摘要认证。

(2)NAT模式下,ACS在公网环境下与内网下CPE交互,通过NAT穿越获取CPE公网地址进行交互,实现流程见下文。

NAT,即网络地址转换。STUN 存在的目的就是进行NAT穿越[1],这里STUN将作为一个工具来服务于本次的ACS连接CPE实现。让终端用来发现其在公网IP和端口,并作为一种保活(keep-alive)协议来维持NAT的绑定。

NAT模式下,ACS连接CPE实现具体如下:

第一步:基于STUN协议实现ACS与CPE之间的捆绑请求和响应,并维持。可借助第三方开源JSTUN库,地址:https://gitee.com/javabedlamite/JSTUN/。如下是相关报文案例:

图片

第二步:根据捆绑响应解析CPE公网IP和端口。根据STUN协议定义,MAPPED-ADDRESS属性对应即是客户端映射地址;在这里也是CPE的公网地址。


图片

第三步:根据映射的端口地址构建终端管理系统的UDP回连地址;并上报ACS。涉及使用TR069数据模型中以下两个参数:

  • Device.ManagementServer.UDPCnotallow=CEP公网地址
  • Device.ManagementServer.NATDetected=true通过Inform 4 VALUE CHANGE 

通知上报ACS,CPE支持NAT穿越,以及其在公网UDP回连地址。

第四步:某时刻,ACS需要对CPE进行配置,只需终端管理平台对CPE的发起UDP请求,终端设备侧解析后,触发CPE对ACS发起Inform 6 CONNECTION REQUEST(根据Tr069协议,Inform 6表明本次会话是由ACS侧要求而建立的)。到此ACS连接CPE完成。

第五步:在本次连接中,ACS下发对CPE的配置、查询、重启、诊断等约定支持的任务,CPE执行并响应。

整体流程大致实现可如下:

图片

Part 05

主流图形数据库 

 ACS和CPE之间双向连接建立的实现,是终端管理系统远程管理终端的基本和前提。本文主要就ACS连接CEP和CPE连接ASC,各详细讲述一种连接实现方式和流程。目前,家庭智能网关普遍通过TR069协议纳管于各省份的省侧管理平台,一些机顶盒也在通过TR069协议进行纳管;在万物互联背景下,未来规模也许会更大。

责任编辑:庞桂玉 来源: 移动Labs
相关推荐

2023-08-07 14:29:26

模拟电话全双工通信

2013-06-06 10:49:14

以太网以太网接口

2022-12-16 22:06:29

2011-09-13 10:05:43

无线技术网络

2012-04-28 18:29:28

博通100 Gbps

2021-08-23 15:45:55

5GCPE终端网络

2018-03-23 08:36:47

微软数据机器人

2010-01-04 17:28:20

交换机端口

2010-01-08 09:26:27

千兆以太网交换机

2019-10-24 18:05:49

人工智能

2022-03-18 10:43:12

WebSocketHTML5TCP 连接

2019-05-05 05:39:23

TCP三次握手网络协议

2021-11-15 22:31:16

面试题小程序Rpc 通信

2023-08-18 14:28:18

UART异步通信

2022-03-21 06:35:23

HTML5NginxWebSocket

2020-11-03 07:09:31

5GCPEWi-Fi

2010-01-14 10:43:11

交换机端口级联

2010-06-13 16:57:58

IPv4协议网络

2021-02-05 12:04:45

LinuxUARTLinux系统

2022-07-26 14:53:10

WebSocket网络通信协议
点赞
收藏

51CTO技术栈公众号