總線是一種內部結構，在計算機系統(tǒng)中，主機的各個部件通過總線相連，外部設備通過相應的接口電路再與總線相連接，是CPU、內存、輸入、輸出設備傳遞信息的公用通道。按所傳輸?shù)男畔⒎N類，可劃分為數(shù)據、地址和控制總線，分別用來傳輸數(shù)據、數(shù)據地址和控制信號。

HarmonyOS系統(tǒng)的使命和目標是將不同的設備串聯(lián)，成為設備的“萬能語言”，讓一個系統(tǒng)連接起所有上網的智能設備，實現(xiàn)萬物互聯(lián)的終極目標。其核心能力之一，【分布式軟總線】讓多設備融合為“一個設備”，帶來設備內和設備間高吞吐、低時延、高可靠的流暢連接體驗。

本文分享鴻蒙分布式軟總線，并對相關源代碼進行解析，作為在此平臺上工作的相關人員的信息參考和指導。具體開發(fā)請參考鴻蒙官網。

1. 介 紹

設備的通信方式多種多樣，譬如USB、WIFI、BT，通信方式差異大且繁瑣，鏈路的融合、共享、沖突、安全等問題也難以保證。

鴻蒙分布式軟總線致力于實現(xiàn)近場設備間統(tǒng)一的分布式通信能力，提供不區(qū)分鏈路的設備發(fā)現(xiàn)和傳輸接口，具備快速發(fā)現(xiàn)并連接設備，高效分發(fā)任務和傳輸數(shù)據。作為多終端設備的統(tǒng)一基座，是鴻蒙架構中的底層技術，是鴻蒙的大動脈，其總的目標是實現(xiàn)設備間無感發(fā)現(xiàn)，零等待傳輸。對開發(fā)者而言，無需關注組網方式與底層協(xié)議。

2. 分布式軟總線特性

鴻蒙分布式軟總線的設計目標在于推進極簡通信協(xié)議技術，在設備安全場景下，即連即用。關鍵技術特性覆蓋設備的自動發(fā)現(xiàn)&連接、組網（多跳自組網、多協(xié)議混合組網）、傳輸（多元化協(xié)議與算法、智能感知與決策）。

2.1 設備間自發(fā)現(xiàn)&連接

分布式軟總線提出自動發(fā)現(xiàn)設備，實現(xiàn)用戶零等待的自發(fā)現(xiàn)體驗，附近同賬號的設備自動發(fā)現(xiàn)無需等待，自動安全連接。

IoT設備分為發(fā)現(xiàn)端和被發(fā)現(xiàn)端。發(fā)現(xiàn)端一般為請求使用服務的設備或稱為主控設備，常指智慧屏設備（如手機、平板等）。被發(fā)現(xiàn)端為發(fā)布服務的設備，指輕量設備（如AI音箱、智能家居、智能穿戴等設備）。目前軟總線的設備互聯(lián)，需保證發(fā)現(xiàn)端和被發(fā)現(xiàn)端處于同一個局域網內。

2.2 多設備互聯(lián)、組網

基于網絡互聯(lián)、交互的系統(tǒng)，開發(fā)者往往需要適配不同網絡協(xié)議和標準規(guī)范。而在鴻蒙系統(tǒng)設定的分布式開發(fā)模式中，無需關心網絡協(xié)議的差異及組網方式，業(yè)務開發(fā)與設備組網解耦，僅需監(jiān)聽設備上下線，開發(fā)成本大大降低。

分布式軟總線提出了異構網絡組網，自動構建一個邏輯全連接網絡，以解決設備間不同協(xié)議交互的問題。設備上線后會向網絡層注冊，同時網絡層會與設備建立通道連接，實時檢測設備的變換。網絡層負責管理設備的上線、下線變換，設備間可以監(jiān)聽自己感興趣的設備，設備上線后可以立即與其建立連接，實現(xiàn)零等待體驗。

2.3 多設備間數(shù)據傳輸

提供統(tǒng)一的基于Session的認證、傳輸功能，上層業(yè)務系統(tǒng)可以通過sessionId收發(fā)數(shù)據或獲取其相關基本屬性，實現(xiàn)業(yè)務消息、流、控制指令等操作交互。

3. 軟總線協(xié)議COAP

互聯(lián)網的WEB應用無處不在，很多依賴于REST協(xié)議架構。為在大多的受限節(jié)點上（如RAM和ROM很有限的8位單片機）及受限網絡上（如6LoWPAN）也能支持REST，工程師們著手處理“受限制的restful環(huán)境”，即CoRE。如6LoWPAN的受限網絡支持將IPv6數(shù)據分成小包，但極大降低了傳輸效率。

CoAP（Constrained Application Protocol）的主要目標之一是設計一個通用的Web協(xié)議，保持非常低的開銷，以滿足受限環(huán)境的特殊要求，如能源、樓宇自動化或其它M2M應用。實現(xiàn)REST的一個通用HTTP子集，針對M2M應用做了簡化，而非盲目壓縮HTTP。COAP協(xié)議可很容易轉換為HTTP，方便和現(xiàn)有WEB體系轉化，同時還能滿足諸如內置發(fā)現(xiàn)、組播支持和異步消息傳輸?shù)取?/p>

3.1 COAP協(xié)議特征

屬于一種應用層協(xié)議，運行于UDP協(xié)議之上而不是像HTTP那樣運行于TCP之上。

1） COAP協(xié)議網絡傳輸層由TCP改為UDP;

2） 基于REST，server的資源地址也類似URL格式，客戶端同樣有POST，GET，PUT，DELETE方法來訪問server，對HTTP做了簡化；

3） COAP是二進制格式，HTTP是文本格式，COAP比HTTP更加緊湊；

4） 小巧、輕量化，最小長度僅僅4 Bytes，一個HTTP的head都要幾十Bytes;

5） 支持可靠傳輸，數(shù)據重傳，塊傳輸;

6） 支持IP多播， 可同時向多個設備發(fā)送請求，鴻蒙設備的發(fā)現(xiàn)功能就是用的這個特性；

7） 非長連接通信，適用于低功耗物聯(lián)網場景；

8） 支持觀察模式；

3.2 協(xié)議類型及結構

COAP協(xié)議有4種消息類型。

CON： 需要確認，如果CON請求被發(fā)送，那對方必須做出響應，確認收到消息，用以可靠消息傳輸；

NON： 不需要被確認的請求，如果NON請求被發(fā)送，那對方不必作出回應。適用于消息會重復頻繁的發(fā)送，丟包不影響正常操作。和UDP很像，用于不可靠消息傳輸；

ACK： 應答消息，對應的是CON消息的應答；

RST： 復位消息，可靠傳輸時候接收的消息不認識或錯誤時，必須回RST消息；

協(xié)議結構定義

在源碼discovery/coap/include/coap_def.h中對COAP協(xié)議的結構體進行了定義。

3.3 COAP包的傳輸

傳輸方式為客戶端和服務器端模式，服務器端啟動COAP包的監(jiān)聽服務。

源碼discovery/coap/include/coap_socket.h中提供了COAP包的發(fā)送和接收函數(shù)定義。

3.4 COAP設備發(fā)現(xiàn)

源碼discovery/coap/source/coap_discover.c實現(xiàn)了基于COAP的設備發(fā)現(xiàn)功能。

3.5 COAP的安全性

TLS不能用來保證UDP上傳輸?shù)臄?shù)據的安全，因此Datagram TLS試圖在現(xiàn)存的TLS架構上提出擴展，使之支持UDP。

COAP的安全性是用DTLS加密實現(xiàn)。DTLS的實現(xiàn)需要的資源和帶寬較多，如果是資源非常少的終端和極有限的帶寬下可能會跑不起來。DTLS僅僅在單播情況下適用。

4. 源代碼結構與解析

分布式軟總線的源代碼在communication_services_softbus_lite目錄，結構如下：

說明： 目錄下所有源碼文件將被編譯為一個動態(tài)庫，其它依賴模塊在編譯的時候加上這個動態(tài)庫的依賴即可。譬如：分布式調度子系統(tǒng)所在的foundation這個bin文件的編譯就依賴這個動態(tài)庫。

4.1軟總線的初始化

StartListener（）函存在對應不同版本平臺的適配，體現(xiàn)了各部分解耦的模塊化設計思想，針對不同的硬件設備，組合成最適合該設備的OS。比如創(chuàng)建線程時采用了統(tǒng)一的static void WaitProcess（void）函數(shù)，而其內部封裝了不同底層API的適配代碼。

4.2操作系統(tǒng)適配層

HarmonyOS的操作系統(tǒng)底層可以是：HarmonyOS micro kernel，Linux kernel，且Lite OS將成為一個完整的鴻蒙微內核架構。

鴻蒙系統(tǒng)內部各個模塊內部使用的函數(shù)需要支持針對不同版本平臺的適配，體現(xiàn)各部分解耦的模塊化設計思想，針對不同的硬件設備，組合成最適合該設備的OS。譬如，創(chuàng)建線程時采用了統(tǒng)一的static void WaitProcess（void）函數(shù)，而其內部封裝了不同底層API的適配代碼。SemCreate在LiteOS中使用LOS_SemCreate創(chuàng)建信號量，在Linux上用sem_init（） Posix標準接口創(chuàng)建。

源碼目錄os_adapter下的代碼即實現(xiàn)了分布式軟總線對操作系統(tǒng)的適配。

LiteOS

是華為面向物聯(lián)網領域開發(fā)的一個基于實時內核的輕量級操作系統(tǒng)，現(xiàn)有基礎內核支持任務管理、內存管理、時間管理、通信機制、中斷管理、隊列管理、事件管理、定時器等操作系統(tǒng)基礎組件，為更好地支持低功耗場景，支持tickless機制，支持定時器對齊。

LiteOS開源項目支持ARM Cortex-M0，Cortex-M3，Cortex-M4，Cortex-M7等芯片架構。

4.3設備發(fā)現(xiàn)與連接

各個設備以服務的形態(tài)推送、發(fā)布，發(fā)布后周邊的設備可以發(fā)現(xiàn)、連接并與之通訊交互，源代碼位于discoverydiscovery_servicesource目錄中。

輕量設備作為被發(fā)現(xiàn)端設備，調用PublishService發(fā)布服務。入口代碼截圖：

以下是針對操作序列中的代碼解析截圖，供參考。

1） 權限檢查

os_adapter為適配OS系統(tǒng)，封裝的函數(shù)在不同的操作系統(tǒng)有不同的實現(xiàn)。如SemCreate在LiteOS上使用LOS_SemCreate創(chuàng)建信號量，而Linux上用sem_init（）Posix標準接口。

2） 參數(shù)檢查

4） 初始化服務

A） CoapInit

COAP初始化，注冊TCP/IP協(xié)議棧的處理，注冊session的底層socket的操作處理。

B） CoapWriteMsgQueue（）

寫入消息，觸發(fā)獲取Wifi 的IP地址，啟動總線。

5） 信息加入Module

說明：將g_localDeviceInfo.serverData賦值成“port:auth_port”，auth_port是基于TCP的認證服務的socket綁定的端口號（在StartBus函數(shù)中賦值）。

7） 回調發(fā)布成功

調用PublishCallback（）執(zhí)行cb中的發(fā)布成功的回調函數(shù)。

4.4 設備的認證管理

設備之間的互聯(lián)、互通需要建立點對點的信任關系，并在具備信任關系的設備間構建安全的連接通道，實現(xiàn)用戶數(shù)據端到端的加密傳輸。建立點對點信任關系的過程即是相互交換設備的身份標識的過程。信任關系的建立相當于一次握手，譬如：A設備發(fā)送密文給B設備，B成功解密并把自己的信息封裝到報文中再次加密傳輸給A，A拿到報文再次解密確認是B.

authmanager模塊是鴻蒙為設備提供認證機制的模塊。模塊內的主要處理過程包括報文的接收、解密、再次封裝、加密、發(fā)送的步驟。譬如，當發(fā)現(xiàn)有請求時，調用ProcessDataEvent（wifi_auth_manager）函數(shù)，收包、檢驗包頭，根據數(shù)據包的類型確定不同的處理方式。數(shù)據包的類型主要包括以下三種：

MODULE_AUTH_SDK 加密數(shù)據類型

MODULE_TRUST_ENGINE 可信類型，直接進行數(shù)據傳輸

MODULE_CONNECTION 進行IP及設備認證

1） 模塊的內部結構關系

2） 加密發(fā)送步驟及算法

AES-GCM加密算法：AES是一種對稱加密算法，GCM是對該對稱加密采用Counter模式，并帶有GMAC消息認證碼。AES-GCM算法是帶認證和加密的算法，同時可以對給定的原文，生成加密數(shù)據和認證碼。

3） 鴻蒙設備互聯(lián)安全

以下是鴻蒙官網文檔的設備互聯(lián)安全參考圖

實現(xiàn)用戶數(shù)據在設備互聯(lián)場景下，在各個設備之間的安全流轉，實現(xiàn)用戶數(shù)據的安全傳輸。

綁定的流程

設備分別生成Ed25519密鑰對；

利用PIN碼和PAKE（Password authenticated key exchange）進行密鑰協(xié)商，生成會話密鑰；

通過會話密鑰加密彼此的公鑰（也可不用加密，算個MAC就行，只要能驗證公鑰確實來自對方即可）

這里的身份標識公鑰指的應該是（設備標識， 公鑰）的二元組

通信的流程

通過公鑰協(xié)商會話密鑰；會話密鑰應怎么用，一般來說，會將初步協(xié)商的密鑰進行密鑰分散，分為加密密鑰、MAC密鑰等；

使用會話密鑰加密通信數(shù)據。

當建立信任關系的主控設備與設備間在進行通信時，雙方首先完成信任關系綁定，然后基于存儲在本地的對端身份公鑰相互進行認證；在每次通信時完成雙向身份認證以及會話密鑰協(xié)商，之后設備使用此會話密鑰來解密雙方設備間的傳輸通道。

4.5 認證與會話傳輸

trans_service模塊依賴于系統(tǒng)OS提供的網絡socket服務，向認證模塊提供認證通道管理和認證數(shù)據的收發(fā)；向業(yè)務模塊提供session管理和基于session的數(shù)據收發(fā)功能，并且通過GCM模塊的加密功能提供收發(fā)報文的加解密保護。

被發(fā)現(xiàn)端（輕量設備）注冊、發(fā)布服務，成功后回調處理，被發(fā)現(xiàn)端使用CreateSessionServer來創(chuàng)建會話服務器并等待發(fā)現(xiàn)端的連接、創(chuàng)建會話。發(fā)現(xiàn)端（如：智慧屏設備）根據服務的名稱和設備ID建立一個會話，就可以實現(xiàn)服務間的數(shù)據傳輸。

數(shù)據傳輸部分的源代碼位于trans_service/source/libdistbus目錄。

主要處理的步驟參考如下：

CreateSessionServer［會話］ à SelectSessionLoop［數(shù)據］ à OnBytesReceived［回調］

1） CreateSessionServer創(chuàng)建會話

2） SelectSessionLoop

啟動總線后即創(chuàng)建了基于TCP的會話管理服務，服務的任務線程為SelectSessionLoop，處理所有的會話數(shù)據的接收。

3） OnBytesReceived

會話數(shù)據到達的回調函數(shù)，調用上層應用注冊的onBytesReceived。接收會話報文并進行格式解析，執(zhí)行相應動作。如在分布式調度模塊中，可能是START_FA命令。

最 后

分布式軟總線是鴻蒙操作系統(tǒng)的基座模塊，也是分布式數(shù)據管理和分布式任務調度的基石，透徹理解分布式軟總線是深入了解整個鴻蒙OS的基礎。

本文是基于開放的源代碼對分布式軟總線模塊的切入分析、解析，文中會有部分源碼分析、場景分析未完全覆蓋到，后續(xù)會視情況進行相關補充。

編輯：hfy