ACS与CPE的全双工实现

Part 01TR069协议简介

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

【资料图】

Part 02TR069协议用途

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

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

Part 03CPE连接ACS

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

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

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

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

HTTP/1.1 401 UnauthorizedServer: XXXWWW-Authenticate: Digestrealm="XXX",qop="XXX",nnotallow="5ad62dabf90594eed8d2d72cec12e5f9",opaque="60D0FDDCC498497B82138713D1383D9F"......

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

POST /ACS-server/test HTTP/1.1SOAPAction: 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 OKServer: XXXSet-Cookie:JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29; Path=XXX;XXX......

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

POST /ACS-server/test HTTP/1.1Authorization: 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: 0Cookie:JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29......

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

HTTP/1.1 200 OKServer: XXXContent-Type: text/xml;charset=UTF-8Content-Length: 2226......

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

POST /ACS-server/acs HTTP/1.1SOAPAction: 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: 528Cookie:JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29......

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

HTTP/1.1 204 No ContentServer: XXXDate: 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 04ACS连接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协议进行纳管；在万物互联背景下，未来规模也许会更大。

关键词：