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

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

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

1. 介 紹

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

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

2. 分布式軟總線特性

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

2.1 設備間自發現&連接

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

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

2.2 多設備互聯、組網

基于網絡互聯、交互的系統，開發者往往需要適配不同網絡協議和標準規范。而在鴻蒙系統設定的分布式開發模式中，無需關心網絡協議的差異及組網方式，業務開發與設備組網解耦，僅需監聽設備上下線，開發成本大大降低。

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

2.3 多設備間數據傳輸

提供統一的基于Session的認證、傳輸功能，上層業務系統可以通過sessionId收發數據或獲取其相關基本屬性，實現業務消息、流、控制指令等操作交互。

3. 軟總線協議COAP

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

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

3.1 COAP協議特征

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

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

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

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

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

5） 支持可靠傳輸，數據重傳，塊傳輸;

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

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

8） 支持觀察模式；

3.2 協議類型及結構

COAP協議有4種消息類型。

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

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

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

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

協議結構定義

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

3.3 COAP包的傳輸

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

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

3.4 COAP設備發現

源碼discovery/coap/source/coap_discover.c實現了基于COAP的設備發現功能。

3.5 COAP的安全性

TLS不能用來保證UDP上傳輸的數據的安全，因此Datagram TLS試圖在現存的TLS架構上提出擴展，使之支持UDP。

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

4. 源代碼結構與解析

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

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

4.1軟總線的初始化

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

4.2操作系統適配層

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

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

源碼目錄os_adapter下的代碼即實現了分布式軟總線對操作系統的適配。

LiteOS

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

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

4.3設備發現與連接

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

輕量設備作為被發現端設備，調用PublishService發布服務。入口代碼截圖：

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

1） 權限檢查

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

2） 參數檢查

4） 初始化服務

A） CoapInit

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

B） CoapWriteMsgQueue（）

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

5） 信息加入Module

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

7） 回調發布成功

調用PublishCallback（）執行cb中的發布成功的回調函數。

4.4 設備的認證管理

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

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

MODULE_AUTH_SDK 加密數據類型

MODULE_TRUST_ENGINE 可信類型，直接進行數據傳輸

MODULE_CONNECTION 進行IP及設備認證

1） 模塊的內部結構關系

2） 加密發送步驟及算法

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

3） 鴻蒙設備互聯安全

以下是鴻蒙官網文檔的設備互聯安全參考圖

實現用戶數據在設備互聯場景下，在各個設備之間的安全流轉，實現用戶數據的安全傳輸。

綁定的流程

設備分別生成Ed25519密鑰對；

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

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

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

通信的流程

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

使用會話密鑰加密通信數據。

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

4.5 認證與會話傳輸

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

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

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

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

CreateSessionServer［會話］ à SelectSessionLoop［數據］ à OnBytesReceived［回調］

1） CreateSessionServer創建會話

2） SelectSessionLoop

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

3） OnBytesReceived

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

最 后

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

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

編輯：hfy