摘要：本文分享鴻蒙分布式軟總線，并對相關源代碼進行解析，為在鴻蒙系統平台上工作的相關人員的資訊參考和指導。
總線是一種内部結構，在計算機系統中，主機的各個部件通過總線相連，外部裝置通過相應的接口電路再與總線相連接配接，是CPU、記憶體、輸入、輸出裝置傳遞資訊的公用通道。按所傳輸的資訊種類，可劃分為資料、位址和控制總線，分别用來傳輸資料、資料位址和控制信号。
HarmonyOS系統的使命和目标是将不同的裝置串聯，成為裝置的“萬能語言”,讓一個系統連接配接起所有上網的智能裝置，實作萬物互聯的終極目标。其核心能力之一，【分布式軟總線】讓多裝置融合為“一個裝置”,帶來裝置内和裝置間高吞吐、低延遲時間、高可靠的流暢連接配接體驗。
本文分享鴻蒙分布式軟總線，并對相關源代碼進行解析，作為在此平台上工作的相關人員的資訊參考和指導。具體開發請參考鴻蒙官網。
裝置的通信方式多種多樣，譬如USB、WIFI、BT，通信方式差異大且繁瑣，鍊路的融合、共享、沖突、安全等問題也難以保證。
鴻蒙分布式軟總線緻力于實作近場裝置間統一的分布式通信能力，提供不區分鍊路的裝置發現和傳輸接口，具備快速發現并連接配接裝置，高效分發任務和傳輸資料。作為多終端裝置的統一基座，是鴻蒙架構中的底層技術，是鴻蒙的大動脈，其總的目标是實作裝置間無感發現，零等待傳輸。對開發者而言，無需關注組網方式與底層協定。
鴻蒙分布式軟總線的設計目标在于推進極簡通信協定技術，在裝置安全場景下，即連即用。關鍵技術特性覆寫裝置的自動發現&連接配接、組網(多跳自組網、多協定混合組網）、傳輸(多元化協定與算法、智能感覺與決策）。
分布式軟總線提出自動發現裝置，實作使用者零等待的自發現體驗，附近同賬号的裝置自動發現無需等待，自動安全連接配接。
IoT裝置分為發現端和被發現端。發現端一般為請求使用服務的裝置或稱為主要裝置，常指智慧屏裝置（如手機、平闆等）。被發現端為釋出服務的裝置，指輕量裝置（如AI音箱、智能家居、智能穿戴等裝置）。目前軟總線的裝置互聯，需保證發現端和被發現端處于同一個區域網路内。
基于網絡互聯、互動的系統，開發者往往需要适配不同網絡協定和标準規範。而在鴻蒙系統設定的分布式開發模式中，無需關心網絡協定的差異及組網方式，業務開發與裝置組網解耦，僅需監聽裝置上下線，開發成本大大降低。
分布式軟總線提出了異構網絡組網，自動建構一個邏輯全連接配接網絡，以解決裝置間不同協定互動的問題。裝置上線後會向網絡層注冊，同時網絡層會與裝置建立通道連接配接，實時檢測裝置的變換。網絡層負責管理裝置的上線、下線變換，裝置間可以監聽自己感興趣的裝置，裝置上線後可以立即與其建立連接配接，實作零等待體驗。
提供統一的基于Session的認證、傳輸功能，上層業務系統可以通過sessionId收發資料或擷取其相關基本屬性，實作業務消息、流、控制指令等操作互動。
網際網路的WEB應用無處不在，很多依賴于REST協定架構。為在大多的受限節點上(如RAM和ROM很有限的8位單片機)及受限網絡上(如6LoWPAN)也能支援REST，工程師們着手處理“受限制的restful環境”，即CoRE。如6LoWPAN的受限網絡支援将IPv6資料分成小包，但極大降低了傳輸效率。
CoAP(Constrained Application Protocol)的主要目标之一是設計一個通用的Web協定,保持非常低的開銷,以滿足受限環境的特殊要求，如能源、樓宇自動化或其它M2M應用。實作REST的一個通用HTTP子集，針對M2M應用做了簡化，而非盲目壓縮HTTP。COAP協定可很容易轉換為HTTP，友善和現有WEB體系轉化，同時還能滿足諸如内置發現、多點傳播支援和異步消息傳輸等。
屬于一種應用層協定，運作于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) 支援觀察模式；
COAP協定有4種消息類型。
CON: 需要确認，如果CON請求被發送，那對方必須做出響應，确認收到消息，用以可靠消息傳輸；
NON: 不需要被确認的請求，如果NON請求被發送，那對方不必作出回應。适用于消息會重複頻繁的發送，丢包不影響正常操作。和UDP很像，用于不可靠消息傳輸；
ACK: 應答消息，對應的是CON消息的應答；
RST: 複位消息，可靠傳輸時候接收的消息不認識或錯誤時，必須回RST消息；
在源碼discovery/coap/include/coap_def.h中對COAP協定的結構體進行了定義。
傳輸方式為用戶端和伺服器端模式，伺服器端啟動COAP包的監聽服務。
源碼discovery/coap/include/coap_socket.h中提供了COAP包的發送和接收函數定義。
源碼discovery/coap/source/coap_discover.c實作了基于COAP的裝置發現功能。
TLS不能用來保證UDP上傳輸的資料的安全，是以Datagram TLS試圖在現存的TLS架構上提出擴充，使之支援UDP。
COAP的安全性是用DTLS加密實作。DTLS的實作需要的資源和帶寬較多，如果是資源非常少的終端和極有限的帶寬下可能會跑不起來。DTLS僅僅在單點傳播情況下适用。
分布式軟總線的源代碼在communication_services_softbus_lite目錄，結構如下:
說明： 目錄下所有源碼檔案将被編譯為一個動态庫，其它依賴子產品在編譯的時候加上這個動态庫的依賴即可。譬如：分布式排程子系統所在的foundation這個bin檔案的編譯就依賴這個動态庫。
StartListener()函存在對應不同版本平台的适配，展現了各部分解耦的子產品化設計思想，針對不同的硬體裝置，組合成最适合該裝置的OS。比如建立線程時采用了統一的static void WaitProcess(void)函數，而其内部封裝了不同底層API的适配代碼。
HarmonyOS的作業系統底層可以是：HarmonyOS micro kernel，Linux kernel，且Lite OS将成為一個完整的鴻蒙微核心架構。
鴻蒙系統内部各個子產品内部使用的函數需要支援針對不同版本平台的适配，展現各部分解耦的子產品化設計思想，針對不同的硬體裝置，組合成最适合該裝置的OS。譬如，建立線程時采用了統一的static void WaitProcess(void)函數，而其内部封裝了不同底層API的适配代碼。SemCreate在LiteOS中使用LOS_SemCreate建立信号量，在Linux上用sem_init() Posix标準接口建立。
源碼目錄os_adapter下的代碼即實作了分布式軟總線對作業系統的适配。
是華為面向物聯網領域開發的一個基于實時核心的輕量級作業系統，現有基礎核心支援任務管理、記憶體管理、時間管理、通信機制、中斷管理、隊列管理、事件管理、定時器等作業系統基礎元件，為更好地支援低功耗場景，支援tickless機制，支援定時器對齊。
LiteOS開源項目支援ARM Cortex-M0，Cortex-M3，Cortex-M4，Cortex-M7等晶片架構。
各個裝置以服務的形态推送、釋出，釋出後周邊的裝置可以發現、連接配接并與之通訊互動,源代碼位于discovery\discovery_service\source目錄中。
輕量裝置作為被發現端裝置，調用PublishService釋出服務。入口代碼截圖:
以下是針對操作序列中的代碼解析截圖，供參考.
os_adapter為适配OS系統，封裝的函數在不同的作業系統有不同的實作。如SemCreate在LiteOS上使用LOS_SemCreate建立信号量，而Linux上用sem_init()Posix标準接口。
A) CoapInit
COAP初始化，注冊TCP/IP協定棧的處理，注冊session的底層socket的操作處理.
B) CoapWriteMsgQueue()
寫入消息，觸發擷取Wifi 的IP位址，啟動總線。
說明：将g_localDeviceInfo.serverData指派成“port:auth_port”,auth_port是基于TCP的認證服務的socket綁定的端口号(在StartBus函數中指派).
調用PublishCallback()執行cb中的釋出成功的回調函數。
裝置之間的互聯、互通需要建立點對點的信任關系，并在具備信任關系的裝置間建構安全的連接配接通道，實作使用者資料端到端的加密傳輸。建立點對點信任關系的過程即是互相交換裝置的身份辨別的過程。信任關系的建立相當于一次握手，譬如：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密鑰等；
使用會話密鑰加密通信資料。
當建立信任關系的主要裝置與裝置間在進行通信時，雙方首先完成信任關系綁定，然後基于存儲在本地的對端身份公鑰互相進行認證；在每次通信時完成雙向身份認證以及會話密鑰協商，之後裝置使用此會話密鑰來解密雙方裝置間的傳輸通道。
trans_service子產品依賴于系統OS提供的網絡socket服務，向認證子產品提供認證通道管理和認證資料的收發；向業務子產品提供session管理和基于session的資料收發功能，并且通過GCM子產品的加密功能提供收發封包的加解密保護。
被發現端（輕量裝置）注冊、釋出服務，成功後回調處理，被發現端使用CreateSessionServer來建立會話伺服器并等待發現端的連接配接、建立會話。發現端(如：智慧屏裝置)根據服務的名稱和裝置ID建立一個會話，就可以實作服務間的資料傳輸。
資料傳輸部分的源代碼位于trans_service/source/libdistbus目錄。
主要處理的步驟參考如下：
CreateSessionServer[會話] à SelectSessionLoop[資料] à OnBytesReceived[回調]
啟動總線後即建立了基于TCP的會話管理服務，服務的任務線程為SelectSessionLoop，處理所有的會話資料的接收。
會話資料到達的回調函數，調用上層應用注冊的onBytesReceived。接收會話封包并進行格式解析，執行相應動作。如在分布式排程子產品中，可能是START_FA指令。
分布式軟總線是鴻蒙作業系統的基座子產品，也是分布式資料管理和分布式任務排程的基石，透徹了解分布式軟總線是深入了解整個鴻蒙OS的基礎。
本文是基于開放的源代碼對分布式軟總線子產品的切入分析、解析，文中會有部分源碼分析、場景分析未完全覆寫到，後續會視情況進行相關補充。
具體開發，請參考鴻蒙官網相關文檔： https://developer.harmonyos.com/
本文分享自華為雲社群《【鴻蒙作業系統專題二】分布式軟總線-解析x1》，原文作者：張X峰。
點選關注，第一時間了解華為雲新鮮技術~