一種面向虛擬化環境的Linux TCP/IP流程優化方法

翁 創

（上海船舶運輸科學研究所有限公司 艦船自動化系統事業部，上海 200135）

0 引言

隨著互聯網和大數據技術的蓬勃發展，云計算逐漸成為現代計算領域的核心技術之一。眾多企業和個人紛紛將數據和應用部署在云服務器上，以便利用強大的云計算能力降低本地硬件和軟件成本。云計算技術的迅速普及催生了計算資源、存儲資源和網絡資源的集中化管理。虛擬化技術作為云計算的關鍵組成部分，為用戶提供了靈活、安全、易用的計算環境［1］。在云環境和大數據環境下，例如HDFS［2］和分布式文件系統［3］以及HTTP 靜態資源訪問等場景中，服務器經常采用虛擬機的方式進行部署。該方式有助于提高數據的可靠性和安全性，同時便于備份［4］。

然而，在虛擬化環境中，由于虛擬機資源的隔離性和數據傳輸過程的復雜性，云服務器的性能受到了顯著影響［5］。在應對大量并發請求和大規模數據處理時，性能瓶頸問題尤為明顯［6］。例如在圖1 所示的KVM（Kernelbased Virtual Machine）虛擬化環境下，一個宿主機安裝著多個虛擬機，不同類型的資源分別被存放在不同虛擬機里［7］。當請求資源時，請求報文首先被宿主機系統內核接收，然后宿主機解析報文并將報文發往指定的虛擬機，最后虛擬機將資源按原路返送回去。在整個過程中，TCP/IP協議經歷了多層解析，每一層解析都會消耗CPU 資源［8］。同時，用戶態和內核態的頻繁切換也進一步增加了性能開銷，可能導致CPU 利用率上升、系統響應速度降低。

Fig.1 KVM virtualization infrastructure圖1 KVM虛擬化基礎架構

為了解決上述問題，本文提出一種基于Linux 內核的優化方 法（Kernel-Oriented TCP/IP Optimization Method，KOTOM）。該方法利用宿主機內核態netfilter 的掛鉤函數監控發往目標服務器的TCP 請求和服務器響應，并建立被請求資源的緩存，通過LRU 算法實現熱點資源的緩存替換，從而降低TCP/IP 協議處理過程中資源在內核態與用戶態之間傳遞帶來的性能開銷。實驗結果表明，該方法成功地節省了服務器計算資源，并縮短了請求時間，降低了服務器在虛擬化環境中的CPU 資源利用率。本文的主要創新點如下：

（1）優化了Linux TCP/IP 解析流程，實現了直接在內核態進行TCP 報文解析。

（2）建立了內核態緩存機制，減少了用戶態與內核態之間的切換次數，提高了系統整體效率。

（3）提出一種根據請求熱點數據變化的動態自適應緩存替換策略，實現更高效的緩存利用。

1 相關工作

本文關注的是虛擬化環境中云服務器的數據傳輸效率和計算資源利用效率，為介紹該領域的研究現狀，以下對一些與本文主題相關的工作進行了回顧。

Yasukata 等［9］為解決操作系統內核棧和專用網卡（NICs）之間交互性能的問題，提出了StackMap 方法。該方法通過優化操作系統內核棧和專用網卡（NICs）之間的交互來降低網絡延遲。其分析了現有內核棧和網卡的通信過程，發現了一系列可以優化的點。這項工作對于理解內核棧和網卡之間通信過程的優化具有重要意義。本文提出的KOTOM 方法優化了面向虛擬環境的Linux TCP/IP 解析流程，并實現了直接在內核態進行TCP 協議解析。此外，其采用了一種新型的內核態緩存機制，通過降低用戶態和內核態之間的切換次數，提高了系統整體效率。與本文方法相比，StackMap 方法主要關注操作系統內核棧和專用網卡之間的交互優化，而本文方法更著重于內核態緩存機制和動態自適應緩存替換策略設計。

呂梅桂［10］詳細闡述了在KVM 虛擬化環境下虛擬機網絡性能優化的一般方法，特別是基于Direct IRQ 技術的優化方案。Direct IRQ 是指將網卡產生的中斷直接發送到虛擬機，而不經過虛擬機監控器。與本文的研究相比，其主要是通過Direct IRQ 技術達到優化效果。該方法將網卡直接分配給虛擬機，本文方法不將網卡直接分配給虛擬機，而是通過虛擬機監控器緩存靜態數據實現優化效果。KOTOM 方法針對性地解決了用戶態和內核態之間頻繁切換帶來的資源開銷問題，并且引入了紅黑樹和LRU 策略，進一步提高了緩存查找和使用效率，從而使性能得到顯著提升。

劉禹燕等［11］詳細介紹了Virtio 框架的基本原理，闡述了該框架如何實現半虛擬化環境下的高性能網絡通信。通過對Virtio 框架中的數據傳輸和緩存策略進行優化，實現了在半虛擬化環境下更高效的網絡請求處理。該項工作為提高虛擬化環境中的網絡性能提供了實際的解決方案。與本文方法相比，該研究主要關注半虛擬化環境下的網絡通信性能優化，而本文方法適用于全虛擬化環境，通過優化內核態TCP/IP 數據處理和緩存策略，提高云服務器在虛擬化環境中的性能。本文方法不僅針對性地解決了用戶態和內核態之間頻繁切換帶來的資源開銷問題，而且提出一種根據請求熱點數據變化的動態自適應緩存替換策略，實現更高效的緩存利用和性能提升。

1.1 TCP/IP優化

在傳統的數據傳輸模式中，服務器遵循協議層次對報文進行逐層解析。具體來說，報文從物理層開始，逐級經過數據鏈路層、網絡層、傳輸層，最終達到應用層［12］。如圖2 所示，實線代表服務器內核在解析請求和發送數據時的傳統模式。在該模式下，當服務器收到一個TCP 請求時，請求報文首先在內核態被各個協議層進行處理，之后傳輸層（例如TCP 層）處理完的報文會傳遞給用戶態的socket進行深入分析。在應用層處理完請求后，其會將響應報文再次傳遞給內核態，以便進行下行傳輸。在此過程中，內核態與用戶態需要頻繁切換。

Fig.2 TCP/IP protocol parsing process in Linux圖2 Linux下TCP/IP協議解析流程

內核態與用戶態之間的切換涉及上下文切換、內存映射及資源調度等操作，會導致顯著的資源與時間開銷。此外，報文在逐層解析時需多次進行封裝與解封裝，增大了處理過程的復雜性和附加開銷［13］。因此，在傳統的數據傳輸模式下，服務器性能往往受到用戶態與內核態頻繁切換以及報文逐層解析所帶來的資源與時間消耗的影響。

本文提出的KOTOM 方法致力于在虛擬化環境中基于內核態進行請求報文的解析與數據傳輸。與傳統方法相比，該方法規避了報文的逐層解析和用戶態與內核態間的頻繁切換問題。圖2 的虛線部分揭示了KOTOM 方法對數據包的另一種處理模式。首先，內核在網絡層對請求進行解析，進而確定請求報文中應用層協議的起始地址；然后，內核對應用層協議進行解析，獲取請求路徑，并根據此定位緩存內容；最后，系統開始構建內容報文new_skb。new_skb的構建遵循以下指定順序：

（1）數據區。從緩存中提取請求內容，并填入new_skb的數據區。緩存包含用戶態協議以及請求內容本身，使得KOTOM 方法省去了用戶態協議首部的構建。

（2）TCP 層。為new_skb 構建TCP 首部，需準確設定源端口、目標端口、序列號、確認號等TCP 首部字段。事實上，源端口、目標端口及序列號對應于請求報文的目標端口、源端口及確認號與內容長度之和。

（3）IP 層。為new_skb 構建IP 首部，需準確設定源IP地址、目標IP 地址、協議類型（TCP）以及首部長度等IP 首部字段。源和目標IP 地址分別與請求報文中的目標和源IP地址相對應。

（4）MAC 層。為new_skb 構建以太網首部，需準確設定源MAC 地址、目標MAC 地址及協議類型（IPv4）等以太網首部字段。目標MAC 地址與請求報文的源MAC 地址相同，而源MAC 地址是發送端網卡的地址。

完成這些步驟后，new_skb 被發送至原先發出數據請求的主機。值得注意的是，在整個請求流程中，TCP 連接的建立與釋放均遵循3 次握手和4 次揮手的原則。盡管使用KOTOM 方法傳輸內容，但3 次握手和4 次揮手仍按照傳統模式執行，該方法僅影響內容報文的傳輸流程。

1.2 基于LRU的內核緩存

KOTOM 緩存區允許熱點內容在內存中進行短暫存儲。當后續請求發生時，相關內容能直接從內存中提取。為了合理使用服務器內存并確保其穩定性，必須對緩存區的大小進行限制。首先，確定緩存區的最大容量。當緩存區的總容量達到此上限時，低頻訪問的內容將被新數據所替代。為此，基于實驗，本文選擇了一個適宜的緩存替換策略。其次，為簡化內容管理，緩存區采用一個稱為obj 的內容存儲對象，該對象包含內容名稱、大小、實體、請求路徑以及訪問時間等信息。最終，為緩存區設計了一套API，實現存儲對象插入和基于路徑的對象檢索等功能。

當API 執行對象插入或刪除操作時，內核會即時更新內容緩存區的可用空間、已占用空間及當前對象數。內容緩存區采用紅黑樹作為其對象的存儲結構。與鏈表或其他具有O（n）搜索時間復雜度的數據結構相比，紅黑樹具有O（logn）的搜索時間復雜度，是一種更加高效的搜索結構。

LRU（Least Recently Used）緩存替換算法是一種廣泛應用的高效的緩存管理策略［14］。其核心思想在于：每當對象被創建或已存在于緩存中的對象被訪問時，其最近訪問的時間戳會被更新。當緩存容量達到上限時，緩存中最久未被訪問的對象將被新對象替代。例如，在圖3 中，新創建的對象7 嘗試進入一個已滿的緩存，因此最久未被訪問的對象5 被移除，使得對象7 得以存入［15］。因為LRU 策略將最近最少使用的數據置于緩存替換的較低優先級［16］，所以與其他緩存替換策略相比，LRU 策略往往能夠在多數場景下提高緩存命中率。

Fig.3 LRU cache replacement algorithm schematic diagram圖3 LRU緩存替換算法原理圖

為了有效實施LRU 策略，本文采納了Linux 內核中的標準定時器jiffies［17］作為對象屬性中“訪問時間”的時間來源。jiffies 是Linux 操作系統的一個核心全局變量，記錄了從系統啟動到當前的時間單位數，常用于跟蹤內核中各種定時器和計時器任務的執行時長。借助jiffies，本文能夠精確地為LRU 算法記錄訪問時間，確保在緩存容量達到極限時，能夠優先替換掉最近最少訪問的對象。

為了高效地管理緩存區，本文需要提供API 以實現對象的插入、刪除和查找功能。以插入功能為例，每當新的存儲對象被創建，內核必須為其各成員（例如“對象名稱”、“數據”和“路徑”）以及對象本體動態分配內存。Linux 內核中的kmalloc 函數能夠滿足此需求，其允許動態分配連續的內存塊。但值得注意的是，kmalloc 可分配的最大內存容量受到當前內核可用內存和連續內存塊大小的限制，一般最大為128k 字節。為了實現緩存對象的動態創建，本文引入名為obj_create 的API，并借助kmalloc 來申請必要的內存。圖4 詳細展示了obj_create 的工作流程。首先，任何超過緩存區容量的數據都不能被保存；其次，如果當前的緩存空間不足，LRU_search 會遍歷紅黑樹，定位到最近最少被使用的對象并通過node_delete 進行刪除，此過程會重復，直至釋放足夠的空間給新對象；最后，obj_insert 會將新對象加入緩存區。

Fig.4 obj_create process flow圖4 obj_create流程

在KOTOM 方法中，多個API 包括obj_create，都依賴于node_search 來查找特定的存儲對象。node_search 能夠僅憑請求路徑高效定位和訪問整個存儲對象，主要歸功于其使用的container_of 宏來識別存儲對象的起始地址。在Linux 內核中，container_of 是一個特別設計的宏，其允許通過已知結構體中某個成員的指針以及該成員類型和名稱迅速定位到該結構體的首地址。在本文的內核模塊設計中，container_of 發揮了至關重要的作用，確保了高效的緩存管理和內容查詢。

1.3 基于sysfs的緩存監控與配置

KOTOM 方法在內核態下處理數據，可避免冗余的內容拷貝和CPU 的額外開銷，提供了一種效率極高的數據處理模式。但在實踐中，實時的緩存區域管理和模塊參數監視是不可或缺的。頻繁地加載、卸載或調試內核模塊不僅繁瑣，而且可能帶來潛在的系統風險。為此，本文采用sysfs 接口，以實現用戶態與內核態之間順暢的數據交互。sysfs 不僅便于對緩存區域和參數的管理監控，而且能確保所有內容處理始終在內核態下進行。這一設計平衡了實時監控與高效處理的需求，對系統的穩定性和可維護性都帶來了積極影響，成為實施KOTOM 方法的關鍵策略。

sysfs 位于Linux 內核中，作為一種虛擬文件系統［18］，其構建了一個統一通道，便于用戶訪問和控制設備樹、內核對象、設備驅動以及其他核心組件。因此，利用其在用戶空間中展示的分層目錄，用戶可以輕易地瀏覽和調整系統的各類參數。該設計巧妙地優化了Linux 內核與用戶空間的互動方式，確立了其作為內核與用戶交互的核心途徑。

在模塊的執行階段，本文寄望于對緩存區的幾個關鍵參數進行實時管理和監控：容量上限（cache_size）、剩余容量（free_space）、對象總數（obj_count）和已占用空間（used_space）。為實現這一目標，KOTOM 的內核模塊設計了一個名為attr_group 的屬性組。該屬性組關聯了4 個主要屬性：cache_size_attr、free_space_attr、obj_count_attr 以及used_space_attr，且每一個屬性都有相應函數來完成數據的讀寫操作。內核將此4 個關鍵參數以文件的形式傳至用戶態，使得用戶可以直接通過這些文件來管理和調整參數。該設計巧妙地建立了內核與用戶間的通信橋梁，大大簡化了對緩存區的管理和監控。因此，用戶能夠便捷地訪問和調整這些關鍵參數，從而實時了解并控制緩存區狀態。

1.4 整體架構

Netfilter 是嵌入在Linux 內核中的網絡過濾機制，其提供了一套靈活的工具，使得內核模塊能夠在網絡棧的各個環節注冊并對數據包進行實時攔截［19］。當請求報文在服務器內核中流動時，Netfilter 會對其進行路由調整，確保其正確地轉發到虛擬機中。同樣地，從虛擬機返回的數據包會被Netfilter 進行處理［20］。通過這一機制，本文得以深入地對數據包進行審查、修改或攔截，進而實現對進出請求和響應數據的精準處理。

圖5 詳細展示了Linux 內核中Netfilter 的核心架構［21］。在請求報文到達服務器時，服務器的網卡首先捕獲這一報文，并迅速將其交付給Netfilter 進行處理。隨后，Netfilter的ip_rcv 函數會介入，并對請求報文執行系列操作，如校驗報文的完整性、對其進行解碼，并進行必要的前期處理等。接下來，處理后的請求報文被傳遞給第一個路由節點（路由1）。該路由節點基于報文的目標地址信息進一步將報文導向第二路由節點（路由2），由其負責將請求報文準確地投遞到預定的虛擬機中。值得注意的是，報文在傳輸過程中會依序經過Netfilter 的兩個關鍵掛鉤點，即NF_INET_PRE_ROUTING 和NF_INET_FORWARD。

Fig.5 Netfilter architecture圖5 Netfilter架構

一旦目標虛擬機接收到請求報文，其立即生成并返回相應的內容報文。該報文首先被傳遞給路由2，接著路由2 將其交由ip_output 作進一步的處理和轉發。完成對ip_output 及其他相關IP 層函數的處理后，內容報文進入物理層，并由dev_queue_xmit 負責進行物理封裝。經過這一系列操作，內容報文最終通過服務器的網卡發送，直達客戶端。值得注意的是，在整個傳輸和處理過程中，內容報文必然會經過Netfilter 的關鍵掛鉤點NF_INET_POST_ROUTING。

當需要攔截請求數據包時，雖然有兩個可能的掛鉤點：NF_INET_PRE_ROUTING 和NF_INET_FORWARD，但本文優先選擇NF_INET_FORWARD。這是因為NF_INET_PRE_ROUTING 掛鉤處理的數據包的目的地也可能是本地服務器，而NF_INET_FORWARD 掛鉤只關心那些需要轉發至其他虛擬機的數據包。如果本文選擇在NF_INET_PRE_ROUTING 位置設立掛鉤，那么其將不得不處理額外、非目標性的數據包，因而可能會拖慢處理速度。所以，KOTOM 內核模塊選擇在NF_INET_FORWARD 位置設立了一個掛鉤函數watch_in［22］，專門用于捕獲和轉發數據包。該設計策略巧妙地避開了不必要的數據包處理過程，從而大大提升了整體的處理效率。

為了確保請求和響應的完整捕獲與高效處理，本文還在NF_INET_POST_ROUTING 掛鉤點設置了另一個掛鉤函數，名為watch_out。該函數的主要任務是對內容進行緩存操作。具體的架構和流程可參考圖6。圖6 明確展示了請求和響應數據包如何被相應的掛鉤函數watch_in 和watch_out 進行處理，并描述了其在整個Netfilter 框架中的位置和角色。

Fig.6 KOTOM architecture圖6 KOTOM 架構

當客戶端發出的請求報文通過路由1 并到達轉發的掛鉤點時，掛鉤函數watch_in 立即捕獲該報文。其首先解析報文，提取請求路徑，并在緩存區查找是否存在與請求路徑匹配的內容。根據查找結果，會有以下兩種可能的情況：①緩存命中：如果緩存區中已有與請求路徑匹配的內容，這些內容將被直接提取出來，繞過目標虛擬機，直接傳遞給函數dev_queue_xmit 進行打包，并快速轉發給客戶端。這期間原先被捕獲的請求報文因為已經得到了響應，會被直接丟棄；②緩存未命中：當緩存區中沒有與請求路徑匹配的內容時，watch_in 不會立即作出反應，而是允許該請求報文繼續通過路由2 被轉發到目標虛擬機。當目標虛擬機生成響應并通過函數ip_output 處理完畢后，掛鉤函數watch_out 會捕獲該響應內容。在dev_queue_xmit 將響應報文轉發給客戶端之前，watch_out 首先將其保存到緩存區中，從而為未來的相同請求提供快速響應。需要注意的是，無論緩存是否命中，報文最后都要交給內核函數dev_queue_xmit進行處理。

圖7 展示了函數watch_in 在實驗環境下的詳細工作流程。

Fig.7 watch_in process flow圖7 watch_in流程

（1）報文過濾。watch_in 的第一步是區分并過濾掉那些非HTTP 請求的數據包，以確保只處理對緩存有意義的請求報文。在真實的網絡場景下，watch_in 可以通過IP 目的地址、端口號和統一資源標識符（Uniform Resource Identifier，URI）過濾掉非HTTP 請求的數據包。

（2）路徑提取。接下來watch_in 從HTTP 請求報文中提取請求路徑，該路徑是后續查找緩存的關鍵，所以會被保存在全局變量temp_path 中。需要注意的是，當Linux 內核創建數據包時，會經歷組裝多個數據片段的過程。該組裝過程包含了大量數據拷貝工作。為了減少拷貝次數，網絡接口利用分散/聚集 I/O 的方法將網絡數據直接從用戶空間緩沖區傳輸出來，實現“零拷貝”。因為KOTOM 模塊在內核態執行，而內核態的數據片段存放地址是分散的，所以KOTOM 模塊在提取請求的路徑之前，需要利用skb_linearize 將多個數據片段合并在一起，實現數據線性化。否則，KOTOM 模塊無法提取請求路徑。

（3）緩存查找。通過調用函數node_path_search 并遍歷紅黑樹，watch_in 嘗試在緩存區中找到對應內容。如果在緩存中找到了匹配的內容，watch_in 首先會重置temp_path 為NULL，清除之前保存的路徑。接下來，為了直接從內核態中將已緩存的數據快速返回給客戶端，避免不必要的用戶態和內核態之間的切換，watch_in 會構造一個新的數據包new_skb，new_skb 會將內容發送回客戶端。除內容本身外，new_skb 的其他字段（如源地址、目的地址等）會根據實際需求進行填充。數據包構建完成后，使用dev_queue_xmit 函數將new_skb 從服務器的網卡發送至客戶端。如果未在緩存中找到請求的數據，watch_in 直接返回NF_ACCEPT，將請求數據包交給目標虛擬機處理。

圖8 描述了函數watch_out 的執行邏輯：①報文過濾：watch_out 開始時會通過條件判斷來過濾掉非內容的報文；②內容保存：當確定接收到的是一個內容報文后，watch_out 會檢查“temp_path”是否為空。非空狀態表示當前報文與之前在watch_in 中捕獲的請求報文有關。在此情況下，watch_out 會調用函數obj_create 將數據報文中的數據部分保存至緩存區，并為未來的相同請求提供快速響應。最后“temp_path”會被重新設為NULL，為處理下一個請求作好準備。

Fig.8 watch_out process flow圖8 watch_out 流程

2 實驗與分析

2.1 實驗環境

如圖9 所示，實驗使用了一臺Windows 主機A 作為請求客戶端，一臺安裝了KVM 虛擬機的主機B 作為部署KOTOM 的云服務器。主機A 負責發送HTTP 請求。主機B安裝一臺虛擬機，使用Apache httpd 作為HTTP 服務器，負責接收客戶端發出的HTTP 請求并返回相應內容。

Fig.9 Experiment environment圖9 實驗環境

具體配置如下：

（1）客戶端（TPC-W Client 端）：物理機。操作系統：Windows 7；處理器：i5-6300U，2.40GHz。

（2）服務器（TPC-W Server 端）：物理機。操作系統：CentOS 7.9；內核版本：5.9。

（3）虛擬機：KVM。操作系統：CentOS 7.9；內核版本：3.10。

當需要使用KOTOM 方法時，將KOTOM 內核模塊加載到主機B 的Linux 內核中。當HTTP 請求報文到達主機B時，內核會攔截并解析報文，獲取請求路徑并在緩存區中進行搜索。如果緩存區中已存在對應內容，內核會直接創建一個包含所需內容的報文，并將其返回給客戶端，而不再繼續發送攔截的請求報文至KVM 虛擬機。

若緩存區不存在對應內容，攔截的請求報文將被繼續發送至KVM 虛擬機。當從KVM 虛擬機返回的內容報文經過內核時，報文會被攔截和解析，解析得到的內容將被保存在內核的緩存區中。因此，當下一次客戶端發送相同的HTTP 請求時，內容將不再需要從KVM 虛擬機返回，而是直接從內核返回。通過該實驗環境，能夠直觀地展示與驗證高效緩存模塊在提高數據響應速度和降低CPU 利用率方面的有效性。

2.2 實驗設置

為了評估高效緩存模塊在提高數據響應速度和降低CPU 利用率方面的有效性，本文采用TPC-W［23］進行實驗。TPC-W（Transaction Processing Performance Council's Web Benchmark）是一個廣泛應用于Web 服務器性能評估的基準測試。其通過模擬真實世界的Web 應用負載來生成一系列典型的HTTP 請求，從而為服務器性能提供一個標準化的衡量標準。

在實驗中，本文分別部署了TPC-W Client 端和Server端，并采用靜態數據模擬真實的HTTP 請求。在實驗過程中，Client 端向Server 端發送HTTP 請求，請求次數可根據實際需求進行設定。首先，CPU 利用率可通過Linux 的top指令進行觀測并記錄。然后，客戶端在發送請求的同時開始計時，請求結束后計時器停止計時并輸出響應時間。最后通過數據量與響應時間計算響應速度，如式（1）所示。

本文在實驗中測試了不同請求次數下，模塊加載前后的數據響應時間和CPU 利用率。在相同的請求次數下，本文進行了10 組數據測試，以計算平均值、最高值和最低值。最后，根據實驗數據繪制了CPU 利用率和響應速度的折線圖，并通過正負偏差表示10 組數據中的最高值和最低值。實驗指標包括數據響應速度和CPU 利用率，以此評估KOTOM 方法在不同工作負載下的性能表現。通過對比模塊加載前后的實驗結果，可以得出KOTOM 方法對服務器性能的影響。

此外，還對StackMap 方法、Direct IRQ 方法和本文的KOTOM 方法進行了對比測試。

2.3 實驗結果

KOTOM 模塊加載前后的CPU 利用率與響應速度如圖10所示。

Fig.10 CPU utilization and response speed before and after KOTOM module loading圖10 KOTOM 模塊加載前后的CPU利用率與響應速度

由圖10（a）可以看出，在請求次數小于500 次時，模塊加載前后的CPU 利用率都隨著請求次數的增加而上升，表明在請求次數較少時，CPU 利用率與請求次數呈正相關。同時，在相同的請求次數下，10 組數據中最高值和最低值的差異較大，說明在請求次數較少時，CPU 利用率的不確定性較大。當請求次數超過500 次后，模塊加載前的CPU利用率穩定在約35%，而模塊加載后的CPU 利用率穩定在約28%?？傊?，在不同請求次數下，模塊加載前的CPU 利用率都會比模塊加載后高約7%。

由圖10（b）可以看出，模塊加載后的響應速度在模塊加載前響應速度的基礎上提升了約22%。在請求次數較少時，KOTOM 方法的響應速度更快。另外，圖中的正負偏差揭示了在請求次數較少時，不論在模塊加載前還是加載后，響應速度的不確定性都較大；而在請求次數較多時，響應速度逐漸穩定?？傮w而言，無論請求次數多少，模塊加載后的響應速度都明顯高于加載前。

對應用不同方法的CPU 利用率與響應速度進行比較，如圖11所示。

Fig.11 CPU utilization and response speed under different methods圖11 應用不同方法的CPU利用率與響應速度

由圖11（a）可見，應用StackMap 方法與加載前的CPU利用率區別不大。應用Direct IRQ 方法的CPU 利用率低于加載前，但當負載增加時，該差異逐漸縮小。這是因為Direct IRQ 要將網卡直接分配給虛擬機，當存在大量虛擬機且網絡負載較高時，會帶來較大的附加開銷。StackMap 方法通過優化操作系統內核棧與專用網卡間的互動，有效降低了網絡延遲，但在普通網卡上優化效果并不顯著。KOTOM 方法針對性地解決了用戶態與內核態之間頻繁切換造成的資源損耗問題，因而具有相對較低的CPU 利用率。

圖11（b）展示了應用不同方法的響應速度，可見應用3 種方法的響應速度相較于加載前都有不同程度的提升。然而，應用StackMap 方法在普通網卡下的提升效果不明顯。應用Direct IRQ 方法的CPU 資源開銷較大，會間接影響請求的響應速度。在CPU 利用率較低的情況下，KOTOM 方法能夠使響應速度明顯提升。

2.4 技術分析與討論

本文在引言部分提出了3 個主要的創新點，其對于提高Linux 服務器在虛擬化環境中的響應速度及降低CPU 利用率起到了關鍵作用，在此總結這3 個創新點的技術內涵以及對實驗效果的影響。

（1）Linux TCP/IP 解析流程優化。傳統的Linux TCP/IP解析流程在多個網絡協議層次之間需要進行多次的解析和封裝操作，無疑增加了數據處理的復雜性和時間開銷。KOTOM 方法對TCP/IP 解析流程進行了優化，直接在內核態實現報文的解析，從而避免了在不同協議層之間的頻繁轉換。這種直接的解析方式不僅加快了數據包的處理速度，而且減少了不必要的數據包復制和內存使用。

（2）內核態緩存機制。在傳統的數據處理流程中，數據經常在用戶態和內核態之間進行切換，這種切換帶來的額外開銷對系統性能有很大影響。為優化這一流程，本文建立了內核態緩存機制，將經常訪問的數據直接保存在內核態，從而避免了數據在用戶態和內核態之間的頻繁切換。該方法降低了CPU 利用率，提高了系統整體效率。此外，這也意味著對于某些高頻訪問的數據，不需要再從硬盤或其他存儲介質中讀取，因而大大加快了數據訪問速度。

（3）動態自適應緩存替換策略。KOTOM 采用經典的LRU（最近最少使用）算法作為其緩存替換策略。LRU 策略的核心是當緩存空間不足時，優先替換最長時間未被訪問的數據，從而確保經常被訪問的數據始終保留在緩存中，提高了緩存利用效率。

3 結語

本文提出一種基于內核態的TCP/IP 數據處理優化方法（KOTOM），目的是提高面向虛擬化環境的Linux 服務器響應速度，并降低服務器的CPU 利用率。通過對內核模塊的設計與實現，以及在掛鉤NF_INET_FORWARD、NF_INET_POST_ROUTING 處建立掛鉤函數watch_in 和watch_out實現報文的捕獲與轉發，可實現在內核態中高效地處理數據。在實驗部分對比了模塊加載前后的響應速度和CPU利用率，結果表明，模塊加載后的響應速度明顯高于加載前。同時，無論請求次數多少，模塊加載后的CPU 利用率都較加載前有所降低，證實了本文設計的高效緩存模塊在提升服務器性能方面的有效性。

本文提出的基于Linux 內核的KOTOM 方法在提高響應速度和降低CPU 利用率方面取得了顯著成果。該方法適用于虛擬化環境下的HTTP 靜態資源訪問場景，在此場景下對讀取速度有要求時，該方法可以簡化協議解析流程，減少用戶態與內核態之間的切換次數，提高數據請求效率。雖然KOTOM 方法目前尚不適用于動態數據請求較多或數據寫請求較多的場景，但該方法具有擴展性。通過對其進行改進和優化，比如增加其他協議類型的支持，使其不僅能服務于HTTP 請求，而且能為諸如HDFS 等系統提供支持，或者采用針對動態數據的緩存替換策略實時更新KOTOM 模塊在內核保存的熱點數據，從而適應動態數據請求較多的場景。通過這些改進和優化，KOTOM 可以成為一個更加全面、高效的解決方案，在更廣泛的應用場景中展現其價值。