面向云邊端協同網絡的eBPF賦能任務卸載研究

中圖分類號： TP393 文獻標志碼： A

文章編號： 1671-6841（2025）04-0015-08

Abstract： As a key enabling technology for cloud-edge-end collaborative networks， computing offloading is an effective approach to alleviate issues like insufficient computing capabilities and limited resources in edge embedded devices. Some existing studies focused primarily on reducing latency and energy consumption in simulated settings. Yet accurately perceiving the real-time dynamics of cloud-edge-end collaborative networks and implementing flexible task offloading strategies remained an urgent challenge to tackle. FreeOffload， a task offloading framework for Cloud-Edge-End Collaborative Networks was proposed. Leveraging eBPF technology， FreeOffload realized real-time awareness of computing resources and network status. It also incorporated flexible task re-offloading schemes tailored for heterogeneous embedded end devices， which achieved load balancing across edge nodes. A small-scale cloud-edge-end prototype tested for evaluation was constructed. Results demonstrated that FreeOffload while efficiently and flexibly offloaded tasks from end devices， with low overhead.

Key words： cloud-edge-end collaborative network; extended Berkeley packet filter; task offloading; load balance

0 引言

隨著 5G 人工智能時代的到來，新型網絡業務不斷出現，對算力的需求急劇增加，高算力和低時延的應用場景越來越多樣化，其中包括物聯網、車聯網、云游戲、AR / VR 等。 在這種背景下，邊緣計算的概念得以提出。 邊緣計算將算力和存儲資源部署在網絡邊緣，為用戶提供就近的云計算服務環境和能力。 同時，隨著萬物互聯愿景的進一步推進，聯網終端和設備數量將以指數級速度增長。

算力需求和算力供給的飛速增長，使得算力供需之間的不平衡問題愈加凸顯。 特別是邊緣計算節點，由于它們均是面向特定場景建設的，計算負載的潮汐效應往往更加明顯。 為更加高效地利用網絡邊緣的海量分布式計算資源，推動分布式邊緣計算與網絡的深度融合，云邊端協同網絡的概念被提出。通過云、邊、端協同，利用計算能力強大的云服務器資源和低訪問時延的邊緣服務器資源，將計算從終端和云轉移到邊緣，實現算力下沉，提供更加合理、高效的端設備任務處理方案。 同時，算力網絡[ 1] 旨在提供泛在網絡連接和算力服務，并實現算力資源靈活調度。

作為云邊端協同網絡的關鍵技術，計算卸載具有重要的地位。 資源有限的終端設備通常將自身任務卸載至云端以及邊緣服務器，當前，關于計算卸載的研究工作主要以延遲最小化、能耗最小化和系統效用最大化等[ 2-5] 作為優化目標，采用非線性規劃、啟發式算法、博弈論、馬爾可夫決策過程（ Markovdecision process， MDP ） 和 強 化 學 習 （ reinforcementlearning， RL） [ 6-8] 等多種方法對任務卸載過 程 進 行仿真建模，以制定最優卸載方案。 但是不難發現，現有多數方案主要從仿真模擬算法的角度出發，而對具體系統場景下的設備算力與網絡實時感知、任務靈活卸載等方面的技術研究較少。

在云邊端協同網絡環境中，計算卸載面臨著一些挑戰。 首先，由于云邊端設備廣泛分布，實時感知算力和網絡狀態成為一大挑戰;其次，由于云邊端網絡中節點算力、網絡鏈路等信息動態變化，卸載策略需要具備靈活調整的能力;最后，如何有效地利用云邊端網絡狀態信息來準確、高效地制定并執行計算卸載策略，同時構建協同系統具有重要意義。 現階段算力網絡的落地主要關注提供透明化的云端服務，對端設備的泛在計算能力模式還處于概念探索階段，這也制約了對云邊端協同的更深入探討。

本文的主要貢獻可歸納為以下三個方面。 1）提出了一個面向云邊端協同網絡的任務卸載框架FreeOffload，利用算力與網絡狀態感知功能和卸載策略執行功能，實現異構端設備任務的動態、靈活卸載。 2） 基于 eBPF 技術，面向云邊端協同網絡，實現了對其狀態的感知，提供了網絡的資源表示、資源度量與通告等方案;面向異構端設備的任務卸載，可以根據網絡實時拓撲信息，動態地調整卸載策略，實現云邊 端 的 負 載 均 衡。 3 ） 在 實 驗 方 面， 搭 建 了FreeOffload 框架的原型系統，從算力感知、端設備任務卸載方案可行性，以及性能開銷等角度進行了評估。 結果表明，FreeOffload 方案能夠在引入較小開銷的情況下高效地實現任務卸載。

1 相關工作

1. 1 計算卸載

云邊端協同網絡是云、邊、端深度融合的新興范式，以優勢互補的方式放大云計算與邊緣計算的價值。 其中，計算卸載技術正呈現出從云計算卸載向邊緣計算卸載方向發展的明顯趨勢。 在這一背景下，文獻[9] 對邊緣計算的計算任務卸載技術進行了研究，并從卸載決策、資源分配和系統實現三個方面進行了全面分析總結。 文獻[10] 對移動邊緣計算中的任務卸載進行了深入建模，將其視為一個以降低整體能耗為目標的優化問題，并基于此目標提出了一種基于群智能優化技術的高能效任務卸載算法。 針對時延敏感的計算卸載問題，文獻[11] 綜合考慮了用戶對任務執行延遲的容忍度以及計算和通信約束下的網絡狀態，提出了一種集中式迭代重定向卸載算法，以提高計算卸載效用。 文獻[12] 研究了云邊端協同架構中具有任務依賴性的邊緣計算卸載策略，將該問題形式化為混合整數優化問題，最小化所有物聯網設備的平均能耗和時間延遲，所提算法利用任務優先級隊列和基于深度強化學習的方法來獲得有效的計算卸載策略。 文獻[13] 探索了基于區塊鏈的計算卸載方法，利用區塊鏈技術確保任務卸載過程中的數據完整性。

1. 2 eBPF 技術及其應用

eBPF[ 14] 是一種 可 以 在 Linux 內 核 中 運 行 用 戶程序，而不需要修改內核代碼或加載內核模塊的技術，具有全覆蓋、無侵入、可編程的技術特點，在網絡優化、安全監控、性能監控等場景中有著廣泛應用。文獻[15]基于 eBPF 實現了一種開源網絡，在 Linux內核動態插入網絡控制邏輯，提供了網絡互通、服務負載均衡等解決方案。 文獻[16] 則從嵌入式物聯網設備固件熱修復的角度出發，利用 eBPF 虛擬機的高效性與安全性來執行漏洞補丁代碼，對實時系統進行修復。

針對云邊端網絡中節點算力變化大、鏈路狀態波動性強等特點帶來的實時感知困難問題，本文選擇利用 eBPF 技術具備的系統觀測能力強、額外運行開銷低、限制執行等特性，進行網絡中節點算力狀態、網絡鏈接等信息的收集與度量，并將用戶態 eBPF 虛擬機改造為靈活、易于使用、與操作系統無關的第三方庫（ e 虛擬機） ，用于異構嵌入式設備的任務卸載策略執行。 本文重點關注改變嵌入式端設備的計算卸載行為，以實現靈活、可配置的任務卸載。

2 FreeOffload 框架設計

2. 1 概覽

在云邊端協同網絡中，一體化已成為重要的發展趨勢。 基于云邊協同，將終端設備的服務作為邊緣節點的負載。 通過控制邊緣節點、云端影響終端來實現三者的協同。

圍繞前文所討論的算力與網絡狀態感知和端設備任務卸載等問題，本文提出了 FreeOffLoad 框架，其主要包括基于 eBPF 的算力與網絡狀態實時感知模塊和異構端設備任務靈活卸載策略執行模塊兩部分，整體框架如圖 1 所示。

圖 1 FreeOffload 方案整體框架Figure 1 The architecture of FreeOffload

FreeOffload 框架首先利用 eBPF 技術在云端和邊緣節點上進行 Linux 內核函數跟蹤，以收集網絡信息和算力信息。 隨后，基于所得數據構建算力資源拓撲圖，用于表示計算資源狀態與分布，其中具有計算能力的設備表示為節點，網絡鏈路表示為邊。

基于該拓撲圖，本文設計了計算資源和網絡資源協同的負載均衡機制，可綜合考慮用戶需求，制定靈活的端設備任務實時卸載策略。 在端側，首先將任務卸載到邊緣節點或者云端執行（ 如圖 1 中步驟 ① ） ，當出現資源負載不均衡或任務執行無法滿足用戶需求時，eBPF 虛擬機執行由云端或者邊緣節點下發的eBPF 任務卸載策略代碼（ 如圖 1 中步驟 ② ），以對用戶透明的方式實現動態地將任務重新卸載到最合適的執行位置，從而匹配算力供給與需求（ 如圖 1中步驟 ③ ），提升系統整體資源利用率。

2. 2 算力與網絡狀態感知模塊

2. 2. 1 資源表示 根據算力模型應當面向服務這一特征，本文提出面向任務處理能力的設備算力表示方案，即針對不同類型的任務請求，用于處理任務的同一設備的算力度量結果可能發生變化。 考慮了不同任務請求下設備的算力度量具有差異性的計算模型才能夠將任務合理分配到執行設備。

為了實現設備資源實時算力與任務執行能力的映射，本方案設計了兩種類型的原子任務：CPU 密集型原子任務和 IO 密集型原子任務。 這兩種類型的任務每隔一段時間就由端設備發送處理請求到其連接的邊緣節點或云端服務器，待處理完成后將結果返回至端設備。 在上述過程中，收集邊緣節點的任務處理時延以及端設備、邊緣節點之間的鏈路傳輸時延，用以評估邊緣節點和云端節點為不同類型的端任務提供的計算能力，實現云邊端協同網絡中算力/ 網絡延遲的面向服務映射。

2. 2. 2 資源度量與通告 對云邊端協同網絡算力資源與網絡狀態進行標識和度量，將相關信息同步到系統是實現算力感知、構建算力資源拓撲圖的重要途徑。 為此，FreeOffload 開展了云邊設備內核層面和網絡拓撲層面的信息收集與聚合，如圖 2所示。

圖 2 基于 eBPF 的算力與網絡狀態感知Figure 2 eBPF-based perception of computingresources and network

在內核信息采集方面，eBPF 系統探針被無侵入式地部署在系統底層，用以采集云端與邊緣節點的系統運行、資源狀態、網絡傳輸等信息。 具體來說，主 要 使 用 kprobes、 uprobes、 tracepoints 等 類 型 的 探針，收集包括 CPU 性能指標、內存性能指標、磁盤性能指標等關鍵算力信息。 根據 Linux 網絡協議棧結構，eBPF 網絡探針分別被設置在傳輸層、網絡層、數據鏈路層等位置的 hook 點，對不同網絡環境下的網絡通信報文、帶寬、平均響應時間等數據進行采集，以支持對云邊端網絡的鏈路關系與通信狀態進行分析。 值得注意的是，由于 eBPF 字節碼的跨平臺特性，該資源感知方案也是跨平臺的。

在網絡拓撲分析階段，根據兩種類型的 eBPF探針采集的指標數據生成算力節點數據。 利用網絡流量進行關聯分析與存儲，進一步形成完整的節點間網絡拓撲關系數據， 構建出算力資源拓撲圖。

如圖 3 所示，使用 YAML 格式的文件來進行算力資源拓撲圖的表示。 其主要由兩部分組成：表示算力資源的節點與表示網絡鏈路的邊。 對于節點，Name 表示節點名稱，ComputingPower 表示該設備節點擁有的算力情況，包括 CPU、Memory、Storage 等方面，Security 表示該設備是否具有任務運行時安全防護能力，Resource 表示設備的資源使用/ 任務執行情況，Capability 則表示設備的原子任務處理能力。 對于邊，StartNode 表示起始邊緣節點，EndNode 表示終點邊緣節點，BandWidth 表示鏈路帶寬，Latency 表示原子任務時延。

在云邊端實驗平臺中，云端節點定期收集并更新所有其他節點的算力資源與網絡鏈路信息，包括邊緣節點與端設備節點。 在邊緣，將計算節點分組，并在組內設置“ 中心” 節點，實時收集組內成員的算力與網絡信息。 當邊緣節點進行端設備任務卸載策略制定時，首先查詢組內是否具有滿足需求的節點，若有則進行卸載，否則由組內“ 中心” 節點向其他組或者云端進行查詢，確定任務卸載的最終地址。

2. 3 端設備任務重卸載模塊

2. 3. 1 任務重卸載機制 云邊端協同網絡整體狀態的動態性對任務卸載提出了更高的要求，傳統的靜態任務卸載方案[ 12] 無法實時地對這種變化進行觀測，也無法對任務卸載策略進行動態調整，并重新設置任務的執行位置。 因此，本文提出了一種適用于端設備的任務卸載功能更新方案，如圖 4所示。

圖 4 基于 eBPF 的端設備任務卸載執行方案Figure 4 eBPF-based task offloading schemefor end devices

該方案中，可依據云邊端網絡中各節點的算力信息與鏈路狀態，并基于 eBPF 框架編寫端設備任務卸載策略代碼，將任務卸載至合理的邊緣節點或者云端，無須重啟程序或系統。 具體來說，使用語言編寫自定義任務卸載策略，提供相應配置信息，再結合特定任務卸載程序的代碼上下文，策略 C 代碼將會被編譯成字節碼。 在經過驗證器的合法性驗證之后，該代碼將插樁到特定函數入口位置，從而在運行時改變端設備任務卸載行為。

為了實現任務策略動態執行的自動化，本文設計了兩種 eBPF 策略代碼的觸發方式，包括固定代碼觸發和動態代碼觸發。

1） 固定代碼觸發。 通過在函數入口插樁實現對函數執行流的攔截。 在該框架內，函數入口 hook點可以由設備廠商在開發固件的時候手工加入，也可以由開發者給出需要插樁的關鍵函數列表，然后通過在固件編譯階段插樁。 hook 點攔截成功后，會進入對應的處理函數，嘗試執行策略代碼。 該方法適用于嵌入式實時系統和 Linux 系統。

2） 動態代碼觸發。 針對嵌入式實時操作系統，可基于設備 CPU 所支持的硬件調試原語，用于實現函數執行流的攔截。 當硬件調試寄存器中的地址匹配后，會觸發一個硬件中斷異常，由 DebugMonitor 對中斷異常進行處理，將中斷時的 CPU 寄存器狀態壓棧，然后加載策略代碼。 針對嵌入式Linux 系統，采用 PLT hook 方式對端設備上任務卸載相關函數進行攔截，當目標函數被調用時，自定義函數將加載執行 eBPF 策略，從而改變端設備任務卸載行為。

2. 3. 2 卸載策略制定 在云邊端協同網絡中，端設備和邊緣節點的計算資源往往是有限的，而且計算能力通常各不相同。 邊緣節點上計算負載狀況是動態變化的，致使負載不均衡現象時有發生。任務卸載策略優化是云邊端協同網絡中的重要問題。

本文對端設備上的任務進行建模，同時考慮了不同任務的處理需求定義了任務屬性，包括是否安全敏感、是否緊急、完成任務所需的算力等。 這些任務屬性通過 YAML 格式表示，如圖 5 所示。 如果一個任務是安全敏感的，就意味著它無法在不具備安全防護能力的邊緣節點上執行;如果一個任務是緊急的，那么它應當盡量被安排在邊緣節點上執行，而不是在云端執行;不同的任務類型影響著邊緣節點上的算力資源建模，而任務的算力需求則決定著某一個節點能否承擔該任務。

Task Type： #任務類型 Sensitive： #任務是否敏感 Urgent： #任務是否緊急 Demand： #任務算力需求

根據上述對端設備任務屬性的描述與分析，從用戶的需求出發，考慮任務的安全敏感性和緊急程度，本文提出了任務卸載過程中的指導性策略，用于輔助任務卸載地址的選擇。

1） 任務緊急且安全敏感時，首選有安全防護能力且處理能力強的邊緣節點，次選云端節點。2） 任務緊急但不安全敏感時，首選處理能力強的邊緣節點，次選云端節點。3） 任務不緊急但安全敏感時，選擇云端節點，因為云端具有更強的防護能力。4） 任務不緊急且不安全敏感時，選擇可用的邊緣節點，以最大化資源利用率。

結合面向用戶需求的任務卸載策略和基于 eB-PF 的算力資源拓撲圖，可設計出端設備任務卸載目標節點選擇算法，算法偽代碼如下。

算法 1 任務卸載目標節點選擇算法。

輸入： 算 力 資 源 圖 CR-map， 任 務 所 在 節 點edge_from ，待卸載任務 task。

3 原型實現與實驗評估

3. 1 原型實現

本文實現了 FreeOffload 框架的原型，其中包括算力與網絡狀態感知模塊和端設備任務重卸載模塊。 把算力與網絡狀態感知模塊部署到搭建的云邊端實驗測試平臺中，并將任務重卸載模塊作為系統模塊集成到嵌入式 Zephyr[ 17] 操作系統與 Linux 操作系統中。 在兩個不同配置的設備（ STM32F429 和Raspberry Pi 3b）上，均運行了集成任務卸載模塊后的系統，結果表明，這些設備上任務卸載模塊的所有功能均可以正常使用。

3. 2 實驗評估

本節從云邊端協同網絡狀態感知方案的可行性、FreeOffload 重卸載方案的可用性、性能開銷三個方面展開了實驗評估。 實驗環境方面，搭建了由單個云服務器節點、四個邊緣計算節點，以及兩個終端設備組成的測試系統，其中邊緣節點使用定制化虛擬機進行模擬，終端設備分別與邊緣節點和云節點相連。 具體的硬件配置及相關軟件版本如表 1所示。

表 1 實驗環境配置Table 1 Experiment environment

3. 2. 1 面向服務的資源狀態感知可行性 算力資源表示方案是面向服務的，不同的任務類型意味著整個云邊端協同網絡系統不同的狀態，因此先給出一般情況下不同類型的任務處理請求示例，然后應用狀態感知模塊的功能進行算力度量與建模，最后觀測云邊端協同網絡中節點算力狀態信息變化。

鑒于在云邊端協同網絡相關工作中并未有標準的真實任務數據集，于是選取視頻格式轉換、web 請求等作為實驗任務，并劃分為 CPU 密集型和 IO 密集型，如表 2 所示。

表 2 不同類型的卸載任務Table 2 Different offloaded tasks

根據算力與網絡狀態感知方案章節描述的方法，在不同類型任務的情況下對云邊端協同網絡進行節點算力建模，實驗結果如圖 6 所示。

可以看到，在云邊端協同網絡中，當端設備需要處理不同的任務時，不論是云、邊還是端，提供的算力都在不斷地變化，且與任務類型呈現出較強的相關性，CPU 頻率較高的設備更適合處理 CPU 密集型任務，而 RAM 較大的設備處理 IO 密集型任務更有優勢。

3. 2. 2 卸載方案可行性分析

1） 代碼編寫難度。 在 FreeOffload 框架下編寫卸載策略代碼是容易的，因為 eBPF 是類 C 的代碼，而嵌入式物聯網設備的操作系統（ 包括以 Linux 為代表的分時操作系統和以 Zephyr OS 為代表的實時操作系統）和其使用的開源第三方庫通常均由 C 語言實現。 此外，編寫策略代碼時開發者無須關心具體的二進制固件或程序信息，只要分析算力資源實時情況和相關程序源碼，然后在源碼層面編寫額外的替換代碼邏輯即可。 嵌入式物聯網設備使用的數據傳輸協議多種多樣，本文選擇了具有代表性的協議類型，將這些協議的名稱、功能、協議實現程序/ 代碼、策略代碼行數等信息整理在表 3 中。 從表 3 中可以看出，這些協議均可以通過不超過 50 行的 eB-PF 策略代碼來完成 connect 類型函數的 hook，任務卸載策略代碼編寫難度較小。

圖 6 不同任務下的設備相對算力表示Figure 6 Representation of the relative devicecomputing resources with different tasks

表 3 不同數據傳輸協議及策略代碼長度

Table 3 Different data transmission protocols

2） 卸載方案有效性。 通過不斷增加邊緣節點1（簡記為 edge1，其余類似） 上的任務負載（ 類型為任務 1），并將這些任務屬性設置為安全敏感的（ 只有節點 edge1 和 edge3 是具有安全防護能力），然后觀測云邊端協同網絡中邊緣節點與云端服務器的CPU 利用率變化情況，可以測試出本文所提出的FreeOffload 方案的可行性。 由圖 7 可知，隨著 edge1的工作負載數量不斷增加，CPU 利用率不斷上升。當達到設定的任務重卸載策略觸發臨界點時（ CPU利用率 70% ），edge1 將輔助下發端設備任務卸載策略以減輕設備運行壓力。 由于這些任務是安全敏感的，所以 edge2 與 edge4 不能被用于執行任務，只有云端服務器和 edge3 能夠作為任務卸載目的地。 又因為 edge3 節點本身運行壓力較小，算力資源豐富，所以根據提出的任務卸載目標節點選擇算法，節點edge1 上的任務不需要交由云端執行。 因此，可以觀測到只有邊緣節點 edge3 的 CPU 利用率發生了明顯上升，符合預期。 這說明邊緣節點 edge1 能夠感知自身工作負載與周圍算力資源情況， 利用FreeOffload 框架將端設備任務處理調整到其他合適的邊緣節點，從而使負載均衡化。

圖 7 云邊網絡中節點 CPU 變化情況

3. 2. 3 性能評估

1） eBPF 資源監測高效性測試。 在 Linux 系統資源感知方面，比較受歡迎的工具有 sar、collectl 等，因此可將本文實現的基于 eBPF 的資源感知方案與之做對比，以體現 eBPF 在資源感知方面的性能優勢。 從表 4 中可以看到，傳統的監測工具通常在用戶態運行，在長時間對系統資源進行監控的情況下，引入更多的上下文切換和系統調用會導致相對較高的開銷。 而 eBPF 程序在內核中執行，減少了用戶態和內核態之間的頻繁切換，在監測 30min 的情況下，系 統 調 用 數 量 分 別 是 collectl 與 sar 的 41.5% 、26.0% 。

表 4 不同資源感知方案下的系統調用數量比較Table 4 Comparison of system call numbers for different

2） 策略代碼執行給應用程序帶來的開銷。 為了直觀呈現啟用 FreeOffload 卸載給應用程序造成的延遲，在 Linux 系統上用視頻格式轉換任務（ 任務1）和 web 訪問請求任務（任務 4）進行端到端的應用測試。

具體應用場景與卸載方案可行性相同，但是這里關注的目標是在卸載不同類型任務的情況下，對比是否使用 FreeOffload 框架對端設備任務發送造成時延，結果如圖 8 所示。

圖 8 FreeOffload 框架對設備任務發送造成的時延Figure 8 Latency caused by FreeOffload framework ondevice task transmission

當任務較為復雜時，應用 FreeOffload 方案會給設備的任務發送帶來 10%～20% 的開銷，而在任務相對簡單時，FreeOffload 的開銷一般低于 10% ，這在對應的任務場景下是完全可以接受的。

3） FreeOffload 框架下的任務卸載方案高效性。為了測試啟用 FreeOffload 方案后對云邊端協同網絡中端設備任務處理效率的影響，可將本文方案與傳統邊緣計算任務卸載策略進行比較，測量在不同調度策略下的任務執行時間，包括從任務發起到任務執行結果返回。 其中，本地處理策略指由端節點處理所有任務，而貪婪處理策略指端節點隨機選擇有處理能力的節點執行任務。

如圖 9 所示，以音頻處理任務（ 任務 2，屬性設置為緊急且安全敏感） 為例，實驗測試了在不同的任務卸載策略下，端節點 1 上的任務執行時間變化與分布情況，可以看出，本地處理策略在任務數量較少時，執行時間較短，而隨著任務數量的增加，由于設備自身計算資源不足，執行時間變長;使用貪婪處理策略時，遍歷云邊端協同網絡中的節點以尋找有處理能力的節點進行計算，與本地處理策略相比，能夠在一定程度上減少任務執行時間，但是由于任務屬性的要求，仍然需要消耗大量時間在尋找處理節點上;而本文提出的 FreeOffload 方案，在算力資源感知能力的加持下，能夠為任務快速準確地選擇處理節點，從而極大地降低任務執行時間，提高計算效率。

圖 9 任務卸載策略對任務執行時間的影響Figure 9 Impact of strategies on task execution time

4 結語

本文提出了面向云邊端協同網絡的 eBPF 賦能任務卸載方案 FreeOffload，能夠幫助實現云邊端協同網絡中端設備任務的靈活、可配置式卸載，有利于邊緣節點和云計算任務的負載均衡，提高整個系統的資源利用率。 其中，算力與網絡狀態感知模塊利用 eBPF 技術，實現了資源表示、資源度量與通告等關鍵功能;端設備任務重卸載模塊根據算力與網絡信息變化動態調整卸載策略，彌補了云邊端協同網絡中異構端設備任務卸載策略固化的不足，實現了云邊端設備的負載均衡。 通過原型實現與實驗環境搭建，證明了 FreeOffload 方案的可行性，能夠在引入較小開銷的情況下靈活、高效地實現任務卸載。

在未來的工作中，鑒于算力網絡相關技術的發展，研究本文方案在云網融合、計算調度等方面任務卸載的應用將會具有一定的價值。

參考文獻：

[1] 何濤， 楊振東， 曹暢， 等. 算力網絡發展中的若干關鍵 技術問題分析[J]. 電信科學， 2022， 38（6）： 62-70. HE T， YANG Z D， CAO C， et al. Analysis of some key technical problems in the development of computing power network [ J ] . Telecommunications science， 2022， 38（6） ： 62-70.

[2] CHEN Y， ZHANG N， ZHANG Y C， et al. Energy efficient dynamic offloading in mobile edge computing for Internet of Things[ J] . IEEE transactions on cloud computing， 2021， 9（3） ： 1050-1060.

[ 3] QU G J， WU H M， LI R D， et al. DMRO： a deep meta reinforcement learning-based task offloading framework for edge-cloud computing[ J] . IEEE transactions on network and service management， 2021， 18（3） ： 3448-3459.

[4] 趙夢遠， 郝萬明， 楊守義， 等. 多用戶多邊緣的公平 卸載及優化策略研究[ J]. 鄭州大學學報（ 理學版）， 2022， 54（5） ： 16-21. ZHAO M Y， HAO W M， YANG S Y， et al. Research on multi-edge fair offloading and optimization strategy for multi-user[ J] . Journal of Zhengzhou university （ natural science edition） ， 2022， 54（5） ： 16-21.

[5] 張秋平， 孫勝， 劉敏， 等. 面向多邊緣設備協作的任 務卸載和服務緩存在線聯合優化機制[ J]. 計算機研 究與發展， 2021， 58（6） ： 1318-1339. ZHANG Q P， SUN S， LIU M， et al. Online joint optimization mechanism of task offloading and service caching for multi-edge device collaboration [ J] . Journal of computer research and development， 2021， 58（6）： 1318-1339.

[6] LI Y， ZHANG X， SUN Y K， et al. Joint offloading and resource allocation with partial information for multi-user edge computing[ C] ∥2022 IEEE Globecom Workshops. Piscataway：IEEE Press， 2022： 1736-1741.

[ 7] XIONG X， ZHENG K， LEI L， et al. Resource allocation based on deep reinforcement learning in IoT edge computing[ J] . IEEE journal on selected areas in communications， 2020， 38（6） ： 1133-1146.

[ 8] BAEK J， KADDOUM G. Heterogeneous task offloading and resource allocations via deep recurrent reinforcement learning in partial observable multifog networks[ J] . IEEE Internet of Things journal， 2021， 8（2）： 1041-1056.

[9] 謝人超， 廉曉飛， 賈慶民， 等. 移動邊緣計算卸載技 術綜述[ J] . 通信學報， 2018， 39（11） ： 138-155. XIE R C， LIAN X F， JIA Q M， et al. Survey on computation offloading in mobile edge computing [ J ] . Journal on communications， 2018， 39（11） ： 138-155.

[10] MAHENGE M P J， LI C L， SANGA C A. Energy-efficient task offloading strategy in mobile edge computing for resource-intensive mobile applications [ J ] . Digital communications and networks， 2022， 8（6） ： 1048-1058.

[ 11] WANG M Z， WU T， MA T， et al. Users′ experience matter： Delay sensitivity-aware computation offloading in mobile edge computing [ J] . Digital communications and networks， 2022， 8（6） ： 955-963.

[12] TANG T T， LI C， LIU F G. Collaborative cloud-edgeend task offloading with task dependency based on deep reinforcement learning [ J ] . Computer communications， 2023， 209： 78-90.

[13] XU X L， ZHANG X Y， GAO H H， et al. BeCome： blockchain-enabled computation offloading for IoT in mobile edge computing[ J] . IEEE transactions on industrial informatics， 2020， 16（6） ： 4187-4195.

[ 14] STAROVOITOV A. Net： filter： rework / optimize internal BPF interpreter′ s instruction set [ EB / OL ] . （ 2014-03- 28 ） [ 2023-04-10 ] . https： ∥ git. kernel. org / pub / scm / linux / kernel / git / torvalds / linux. git / commit / ？ id""bd4cf0 ed331a275e9bf5a49e6d0fd55dffc551b8.

[15] ISOVALENT. Cilium GitHub repository [ EB / OL ] . （2023-03-17 ） [ 2023-04-10 ] . https： ∥github. com / cilium / cilium.

[16] HE Y， ZOU Z H， SUN K， et al. rapidpatch： firmware hotpatching for real-time embedded devices [ C ] ∥ 31st USENIX Security Symposium. Boston： USENIX Association， 2022： 2225-2242.

[ 17] Zephyr. A proven RTOS ecosystem， by developers， for developers[ EB / OL ] . （ 2023-02-19 ） [ 2023-04-10 ] . https：∥zephyrproject. org / .

[ 18] FFmpeg. A complete， cross-platform solution to record， convert and stream audio and video[ EB / OL] . （ 2022-05- 14） [ 2023-04-10] . https：∥ffmpeg. org / .

[ 19] EasyDarwin. Open source， high performance， industrial rtsp streaming server[ EB / OL] . （2017-03-07） [2023-04- 10] . https：∥github. com / EasyDarwin / EasyDarwin / .