通信協(xié)議ACS和CPE之間的全雙工實(shí)現(xiàn)設(shè)計(jì)方案

TR069協(xié)議提供了對(duì)下一代網(wǎng)絡(luò)中家庭網(wǎng)絡(luò)設(shè)備進(jìn)行管理配置的通用框架、消息規(guī)范、管理方法和數(shù)據(jù)模型。在網(wǎng)管模型中，ACS負(fù)責(zé)對(duì)終端設(shè)備CPE進(jìn)行遠(yuǎn)程集中管理，解決CPE設(shè)備的管理困難，節(jié)約成本，提高問題解決效率。ACS實(shí)現(xiàn)對(duì)CPE的遠(yuǎn)程管理，核心便是ACS與CPE之間的連接交互，本文主要講解ACS和CPE之間的全雙工實(shí)現(xiàn)。

Part 01 ●??TR069協(xié)議簡(jiǎn)介?●?

協(xié)議即約定，通信協(xié)議約定了通信雙方交互所遵循的方式和細(xì)則。TR069協(xié)議約定用戶側(cè)設(shè)備（Customer Premises Equipment，即CPE）和自動(dòng)配置服務(wù)器（Auto-Configuration Server，即ACS）之間交互的規(guī)則。我們知道HTTP協(xié)議是基于TCP協(xié)議，COAP協(xié)議是基于UDP協(xié)議，而這里的TR069協(xié)議則是基于HTTP1.1的協(xié)議傳輸，SOAP標(biāo)準(zhǔn)封裝XML的消息內(nèi)容格式，消息內(nèi)容部分如下圖1：

Part 02 ●??TR069協(xié)議用途?●?

TR069協(xié)議提供了對(duì)下一代網(wǎng)絡(luò)中家庭網(wǎng)絡(luò)設(shè)備進(jìn)行管理配置的通用框架、消息規(guī)范、管理方法和數(shù)據(jù)模型。在網(wǎng)管模型中，ACS負(fù)責(zé)對(duì)終端設(shè)備CPE進(jìn)行遠(yuǎn)程集中管理，解決CPE設(shè)備的管理困難，節(jié)約維護(hù)成本，提高問題解決效率。

ACS實(shí)現(xiàn)對(duì)CPE的遠(yuǎn)程管理，核心便是ACS與CPE之間的連接交互。不同于MQTT協(xié)議，客戶端與服務(wù)器之間維持一個(gè)長(zhǎng)鏈接，ACS同CPE的連接僅在存在交互需要時(shí)建立短鏈接。

Part 03 ●??CPE連接ACS?●?

CPE首次啟動(dòng)會(huì)主動(dòng)對(duì)ACS發(fā)起HTTP連接，進(jìn)行注冊(cè)上線動(dòng)作，通過RPC方法中的inform方法上報(bào)0 BOOTSTRAP和1 BOOT（如上圖SOAP封裝的XML消息內(nèi)容案例），如平臺(tái)有需要配置或者獲取的參數(shù)，也會(huì)在這次連接中進(jìn)行。交互如下：

第一步：CPE直接對(duì)ACS發(fā)起HTTP連接請(qǐng)求，請(qǐng)求案例頭部如下：

?

?

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

?

?

第二步：ACS響應(yīng)401，要求CPE進(jìn)行HTTP Digest Authentication認(rèn)證，即摘要認(rèn)證，響應(yīng)案例如下：

?

?

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

?

?

第三步：CPE根據(jù)ACS響應(yīng)的WWW-Authenticate信息，以及url、username和password，按照摘要認(rèn)證算法計(jì)算response，構(gòu)建出再次請(qǐng)求的摘要認(rèn)證信息Authorization，并再次發(fā)起HTTP請(qǐng)求，進(jìn)行inform上報(bào)。攜帶認(rèn)證信息再次請(qǐng)求，案例如下：

?

?

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

?

?

第四步：ACS響應(yīng)200 OK，SOAP內(nèi)容為InformResponse，摘要認(rèn)證到這里已經(jīng)完成。根據(jù)響應(yīng)頭的Set-Cookie信息設(shè)置CPE下個(gè)請(qǐng)求的Cookie。案例如下：

?

?

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

?

?

第五步：CPE發(fā)起的一個(gè)空的HTTP請(qǐng)求，根據(jù)TR069協(xié)議，消息體長(zhǎng)度必須為0，如下案例可以看到Content-Length是0：

?

?

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

?

?

第六步：ACS響應(yīng)HTTP 空請(qǐng)求，封裝SOAP調(diào)用RPC方法，對(duì)終端設(shè)備進(jìn)行參數(shù)配置或者查詢等操作。

?

?

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

?

?

第七步：CPE發(fā)起請(qǐng)求，封裝SOAP對(duì)應(yīng)響應(yīng)RPC方法。如果終端管理平臺(tái)查詢后還需要進(jìn)行配置，則第六步和第七步會(huì)有兩次，如都不需要，則第六步和第七步可省略。如存在，案例如下：

?

?

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

?

?

第八步：ACS下發(fā)一個(gè)空HTTP響應(yīng)，根據(jù)TR069協(xié)議，狀態(tài)碼使用“204（無內(nèi)容）”，表示本次會(huì)話結(jié)束。案例如下：

?

?

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

?

?

這里我們針對(duì)第三步的摘要認(rèn)證展開說明。這里簡(jiǎn)要說明下WWW-Authenticate和Authorization中涉及到的一些參數(shù)，更多詳細(xì)內(nèi)容可以自行參閱RFC2617等相關(guān)文檔。

? digest ==>認(rèn)證方式

? realm ==>領(lǐng)域，領(lǐng)域參數(shù)是強(qiáng)制的，必須存在

? qop ==>保護(hù)的質(zhì)量，“auth”表示只進(jìn)行身份查驗(yàn)， “auth-int”表示進(jìn)行查驗(yàn)外，還有一些完整性保護(hù)

? nonce ==>服務(wù)器側(cè)生成的隨機(jī)數(shù)，在每個(gè)401回應(yīng)產(chǎn)生時(shí)，被唯一創(chuàng)建，為防止攻擊產(chǎn)生，參與加密

? cnonce ==>即client nonce

? uri ==>客戶端想要訪問的URL

? nc ==>連續(xù)請(qǐng)求次數(shù)，在同一個(gè)TCP連接里，設(shè)備每POST一次，nc+1

? algorithm ==>用來生產(chǎn)摘要及校驗(yàn)和的算法對(duì)

? response ==>用來證明用戶是否知道口令

response計(jì)算通常過程分以下三步[2]：

第一步：計(jì)算HA1

HA1=MD5(A1)=MD5(usernamepassword)；

第二步：計(jì)算HA2

如果 qop 值為“auth”或未指定，那么HA2=MD5(A2)=MD5(method:uri)；

如果 qop 值為“auth-int”，那么HA2=MD5(A2)=MD5(methodMD5(entityBody)；

第三步：根據(jù)HA1和HA2計(jì)算response

如果 qop 值為“auth”或“auth-int”，那么response=MD5(HA1ncqop:HA2)；

如果 qop 未指定，那么response=MD5(HA1HA2) 。

Authorization構(gòu)建:CPE端生成cnonce，nc從00000000開始累計(jì)，response根據(jù)上述公式計(jì)算，opaque、qop、nonce、realm繼承自WWW-Authenticate，添加上username、algorithm和uri。

此外，終端管理系統(tǒng)可能還會(huì)對(duì)Manufacturer、OUI等參數(shù)進(jìn)行查驗(yàn)，如查驗(yàn)不通過，響應(yīng)403，即服務(wù)器理解客戶的請(qǐng)求，但拒絕處理它。

Part 04 ●??ACS連接CPE?●?

通過ACS對(duì)CPE進(jìn)行參數(shù)配置時(shí)，ACS作為主動(dòng)方觸發(fā)本次連接。此時(shí)，ACS主動(dòng)連接CEP，方式有兩種：

（1）非NAT模式下，ACS對(duì)CPE發(fā)起HTTP連接請(qǐng)求，使用終端上報(bào)的地址：Device.ManagementServer.ConnectionRequestURL，終端要求進(jìn)行HTTP摘要認(rèn)證。

（2）NAT模式下，ACS在公網(wǎng)環(huán)境下與內(nèi)網(wǎng)下CPE交互，通過NAT穿越獲取CPE公網(wǎng)地址進(jìn)行交互，實(shí)現(xiàn)流程見下文。

NAT，即網(wǎng)絡(luò)地址轉(zhuǎn)換。STUN 存在的目的就是進(jìn)行NAT穿越[1]，這里STUN將作為一個(gè)工具來服務(wù)于本次的ACS連接CPE實(shí)現(xiàn)。讓終端用來發(fā)現(xiàn)其在公網(wǎng)IP和端口，并作為一種?；睿╧eep-alive）協(xié)議來維持NAT的綁定。

NAT模式下，ACS連接CPE實(shí)現(xiàn)具體如下：

第一步：基于STUN協(xié)議實(shí)現(xiàn)ACS與CPE之間的捆綁請(qǐng)求和響應(yīng)，并維持?？山柚谌介_源JSTUN庫，地址：https://gitee.com/javabedlamite/JSTUN/。如下是相關(guān)報(bào)文案例：

第二步：根據(jù)捆綁響應(yīng)解析CPE公網(wǎng)IP和端口。根據(jù)STUN協(xié)議定義，MAPPED-ADDRESS屬性對(duì)應(yīng)即是客戶端映射地址；在這里也是CPE的公網(wǎng)地址。

第三步：根據(jù)映射的端口地址構(gòu)建終端管理系統(tǒng)的UDP回連地址；并上報(bào)ACS。涉及使用TR069數(shù)據(jù)模型中以下兩個(gè)參數(shù)：

Device.ManagementServer.UDPConnectionRequestAddress=CEP公網(wǎng)地址

Device.ManagementServer.NATDetected=true通過Inform 4 VALUE CHANGE?

通知上報(bào)ACS，CPE支持NAT穿越，以及其在公網(wǎng)UDP回連地址。

第四步：某時(shí)刻，ACS需要對(duì)CPE進(jìn)行配置，只需終端管理平臺(tái)對(duì)CPE的發(fā)起UDP請(qǐng)求，終端設(shè)備側(cè)解析后，觸發(fā)CPE對(duì)ACS發(fā)起Inform 6 CONNECTION REQUEST（根據(jù)Tr069協(xié)議，Inform 6表明本次會(huì)話是由ACS側(cè)要求而建立的）。到此ACS連接CPE完成。

第五步：在本次連接中，ACS下發(fā)對(duì)CPE的配置、查詢、重啟、診斷等約定支持的任務(wù)，CPE執(zhí)行并響應(yīng)。

整體流程大致實(shí)現(xiàn)可如下：

Part 05 ●??主流圖形數(shù)據(jù)庫?●?

ACS和CPE之間雙向連接建立的實(shí)現(xiàn)，是終端管理系統(tǒng)遠(yuǎn)程管理終端的基本和前提。本文主要就ACS連接CEP和CPE連接ASC，各詳細(xì)講述一種連接實(shí)現(xiàn)方式和流程。目前，家庭智能網(wǎng)關(guān)普遍通過TR069協(xié)議納管于各省份的省側(cè)管理平臺(tái)，一些機(jī)頂盒也在通過TR069協(xié)議進(jìn)行納管；在萬物互聯(lián)背景下，未來規(guī)模也許會(huì)更大。

編輯：黃飛

?